Yes, exactly, this should not happen! Many thanks! I'll have a fix shortly (only tomorrow...)
Thanks!
Attila
Yes, exactly, this should not happen! Many thanks! I'll have a fix shortly (only tomorrow...)
Did you look in setting -> Misc. -> chords ?
Yea, this won't work based on how the current AI is used.. would have been cool as all, though. You would need to use a different AI model API for that, one that can receive a function, that is..
You probably do have my meaning, but to be certain, consider this picture -musicdevelopments wrote: ↑Tue Jan 30, 2024 4:32 pmI understand what you mean. Yes, it would be a good feature.
For evaluating a roman numeral (or universal) notation chord, the 'current' scale is used. For this feature not just a 'current' but also a 'root' scale must be used. This is no small internal change.
We are on the same page except for this one specific.
no absolutely not. RN notation is relative. in the key of Cminor, a bIII chord would be Dmajor. Flats or sharps are not literal, they are completely relative to the actual key and could be at any time transposed to another key with the same flats or sharps present on the RN notation.
It's perfectly legitimate to use RN notation for minor keys also..even for other modes. Major is what you are accustomed to, so let's take key of Ab major for example, and talk about the DbMajor chord, which should be notated simply as IV. There is no flat or sharp added to RN. If you were to say bIV that would be mean CMajor chord.This is a major-centric view of the 12 tones, but it is absolutely stable, and that is what is needed, IMO.
If that is true I view that as incorrect, but perhaps that is not RN notation you are referring to, it might be Nashville or something like that which is useful for session players. Roman notation is relative and more suitable for deeper analysis such as when composing. Actually when I reconsider your exampl it appears that tune which you say is in the key of Am, but the system is always assuming a major base key... thus requiring some of the chords to be flatted. But if that is the case it's a limitation of iRealPro to assume everything should be based on a major key center even when the tune is in a major key or other mode. You can accomplish the same thing in RapidComposer by simply specifying always a major key, in which case RapidComposer should show the CMajor7 in the above example as bIII7. (and yes I agree, not the sharp version, I can't think of any modal interchange right now that is based on the sharped version of a diatonic chord.It's also how iRealPro does their number notation. For example in iRP, take the tune 'A Felicidade'. It is in the key of Am, the 2nd chord is Cmaj7, and in the number notation it is rendered at b3maj7 (not
If you are trying to mix and match RN notation with nashville or something of that nature, then yea I feel for you, but it is what it is. RN is not as you are suggesting.It will be freakin' hell here in the field if key programs (e.g. iRP and RC) disagree with each other! (and cannot be make to agree by the user)
© KVR Audio, Inc. 2000-2024
Submit: News, Plugins, Hosts & Apps | Advertise @ KVR | Developer Account | About KVR / Contact Us | Privacy Statement