RapidComposer v5 beta feedback and discussion

[musicdevelopments]

Maybe this has something to do with unexpected terminations of the program?

Yes, exactly, this should not happen! Many thanks! I'll have a fix shortly (only tomorrow...)
Thanks!
Attila

[musicdevelopments]

Hello lulukom,

thanks for reporting this bug which affected only the macOS version.
Please download v5.2b2 again, and it will work well.

Thanks for your help!
Attila

[lulukom]

Thanks Attila !

[sj1]

Hi.

I'm noticing that even with display of flats chosen:

RC - Flats Chosen.jpg

it is sharps that are displayed for chords in the Master Track:

RC - Sharps Shown.jpg

Is there another setting elsewhere that would make the chords in the Master Track display with flats? (e.g. bVII7 instead of #VI7 )

If not, could this be made possible?

Thanks.

[sj1]

Hi.

Without getting deep into an example (yet), I'm noticing that making a change in the Scale for a Part/Line can result in the Master Track chords changing.

Is this supposed to happen?

My initial expectation is that when a chord is set by the user (or as a consequence of some user choice where the setting of a chord is an expected result) it will not change from that point without user intent to cause such a change.

When I assign a scale after the fact, to my way of thinking I'm just saying "use this scale for melody generations at this point in the composition". I am not saying "rewrite the chord according to the scale" (although I acknowledge that as a valid operation if desired, and I may want that under some circumstance). The use-case here, so to speak, is merely to pick one of many possible scales (maybe consonant, maybe dissonant) for melody creation over the given chord.

OTOH, I can totally see that "rewrite the chord (or all chords) according to the scale" is also a use-case.

So I think probably RC already accommodates both cases (?), but I need education about how to be in control here.

Can anyone guide me on this subject?

[BluGenes]

Is there another setting elsewhere that would make the chords in the Master Track display with flats? (e.g. bVII7 instead of #VI7 )

Did you look in setting -> Misc. -> chords ?

There is a setting there..

You can also save your self a lot of time if you use the search in the settings, in the future.

[sj1]

Did you look in setting -> Misc. -> chords ?

That's exactly what the picture above shows.

[BluGenes]

oops maybe a bug..

[BluGenes]

Using the AI in the phrase editor, you should be allowed to just select the notes you want to change and just affect those notes with generation. Can this be done? Example prompt would be: syncopate these notes

[BluGenes]

Using the AI in the phrase editor, you should be allowed to just select the notes you want to change and just affect those notes with generation. Can this be done? Example prompt would be: syncopate these notes

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..

[sj1]

About Roman Numeral (RN) notation -

I seem to be observing that RN is calculated locally.

I 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.

You probably do have my meaning, but to be certain, consider this picture -

RC - Base Scale - Key 02.jpg

The Key of the piece is "E major" (it would be notated on a staff with 4 sharps), even if it is a simple standard blues form, and all the chords are dom7 chords.

In Roman Numerals the 12 tones are:

I bII II bIII III IV bV V bVI VI bVII VII I

Any chord in the piece has an absolute alpha name (E7, A7, B7), and also an absolute Roman name (I7, IV7, V7).

If a piece is considered to be in one Key, then there is one set of absolute Roman chord names that applies, regardless of whatever the scale-of-the-moment might be.

If I understand correctly, then currently the only candidate for the "one Key" would be what I've circled in yellow above. Surely this can be referenced where needed if the user were to say "Build the Roman Chord Symbols from Base Key".

Where it really gets interesting is when we consider that pieces (be they symphonies, jazz tunes, or whatever) can actually change keys during the piece.

I believe this is currently not accommodated. Ideally it should be.

IOW, "Key" and "scale-of-the-moment" are not the same animal.

1. Roman numeral chord symbols that stay stable with the "home Key" of the piece are always correct. That stability is their very point! (We don't have this now, we need it.)

2. Roman numeral (RN) chord symbols that change reference infrequently to match an actual change of Key in the piece may also be considered valid if the intent is specifically to "think in a new Key at this point" (IOW, to match a new key signature on the staff). (We don't have this now, it would be nice-to-have - so if doing a redesign it is certainly worth thinking about.)

3. Roman numeral chord symbols that change willy-nilly per scale-of-the-moment are basically wrong (IMO), from a musical and notational perspective. In changing this way, RN loses the very information/reference it is intended to provide. (This is what we have now, and it is deeply problematic.)

If we can only have one of the above three, it needs to be #1 !

Having #1 and #2 would certainly be nice. No doubt it would be a more extensive design job.

#3 really shouldn't even be allowed to happen (IMO). Is there anyone who actually wants that? If so, then I suppose we need options!

If you want to have multiple RN modes, then UI-wise successive clicks on the I/II/III icon could cycle between them.

[Dewdman42]

Roman Numerals definitely should represent the current key scale of the piece unless it has modulated, in which case the modulation should be noted in the analysis and the RN notation can continue from that point based on the new key scale. Agreed. I also think it would be much more useful to use flatted RN, not sharped RN in the case of chord substitutions (modal interchange). The flat of a RN notation should only be there to indicate that the chord is flat relative to the current key. In other words, if you are in the key of C Minor, the Eb major chord should not be bIII. It should be III.

Flatted RN chords are really for modal interchange... where the line blurs between modal interchange and actual modulation is a bit subjective..but in general if the key center is changed due to an actual act of modulation, then its a new key. If the key center is still there like a magnet, then the key has not changed.

don't forget also that secondary dominants, including the secondary ii are also part of RN notation...and can introduce accidentals out of the key...but still....the key center has not changed.

Generally RN that I have ever seen is based on Major or Minor modes, though there is no reason it might not be based on other modes, but extreme chromaticism doesn't make any sense to use RN really.

I think its possible the RN notation in rapidcomposer is a little off perhaps its been a while since I looked at it, but basically yea... they should be flatted, not sharped, and when they are flatted its relative to the current key. And there should be a way to indicate an actual intended modulation, where the key center has changed. And there needs to be a way to notate secondary dominants as well, for example ( V/III )

[sj1]

The flat of a RN notation should only be there to indicate that the chord is flat relative to the current key. In other words, if you are in the key of C Minor, the Eb major chord should not be bIII. It should be III.

We are on the same page except for this one specific.

I see RN notation as specifying one of the 12 tones relative to the root tone of the key. IOW, whether in C maj or C min any Eb chord is b3. (Any Bb is b7, etc.)

This is a major-centric view of the 12 tones, but it is absolutely stable, and that is what is needed, IMO.

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 3maj7).

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)

Perhaps there is a counter-example(s) (?), in which case we need a user-settable option to do it either as I describe, or as the quote above describes. I'm never against options as a user (but I know developers sure can get tired of them!). <g>

[Dewdman42]

We are on the same page except for this one specific.

I see RN notation as specifying one of the 12 tones relative to the root tone of the key. IOW, whether in C maj or C min any Eb chord is b3. (Any Bb is b7, etc.)

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.

Any flats or sharps on the RN should be relative to the current key.

This is a major-centric view of the 12 tones, but it is absolutely stable, and that is what is needed, IMO.

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.

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 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 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)

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.

Perhaps a product suggestion for Rapid Composer would be to also provide nashville style notation or whatever it is you are using in that other program, but do not change RN to some strange frankenstein.

In your case always use a major key in RapidComposer...it ought to be correct so long as RapidComposer stops using sharped roman chords and only uses flatted.

[sj1]

Ah, it seems we disagree, significantly.

Here is another example, from Band-in-a-Box this time (key of Gm):

BIAB 4on6 Bb.jpg

BIAB 4on6 biii.jpg

Also, the idea that one (anyone!) should wang the Key in order to make the notation come out per desire is unsupportable, IMO.

The Key is the Key, it is what it is. It has to be, else any and every aspect of the program that might ever reference it will be corrupted.