RapidComposer v5 beta feedback and discussion

[Brian Collins]

EDIT: are you sure it is a crash and not a deadlock, because I introduced a bug in beta4 which caused a deadlock and which is fixed in beta5.

My original bug report video (that led to BluGenes' simplified recipe) was definitely a hang (deadlock), not a crash. I have just retried with b5 and it appears to be fixed.

Also thanks for the Rhythm Lab and track variation enhancements - I look forward to playing with those.

[musicdevelopments]

Thanks, Brian! Also, thanks for your idea to improve the Rhythm Lab which should have been the next logical step.

[Brian Collins]

@musicdevelopments

Did you ever notice my suggestion in viewtopic.php?p=9099514#p9099514 and viewtopic.php?p=9100720#p9100720

This may not be of any interest or may not fit in with future plans for RC. But I would hate for the idea to be ignored just because I posted in the wrong topic.

[musicdevelopments]

Hi Brian,

I added your idea about assigning a 'voice' to notes to my to-do list. It is great, and it will be interesting to make an algorithm to assign voices automatically. At the moment I have my hands full, so this is planned after the v6.0 release.

Thanks,
Attila

[musicdevelopments]

And by the way, in the latest beta version the track variation "Note range limit" doesn't work for me.

Yes, you are absolutely right, lulukom. I have fixed this in beta6.
Attila

[musicdevelopments]

RapidComposer v5.9b6 is available!

Only bug fixes in this update.

Improvements:

• Fixed 'Limit Note Range' track variation not working
• Fixed track variations applied on phrases with 'lock' enabled
• Fixed crashing bug when gluing lines

[Brian Collins]

I added your idea about assigning a 'voice' to notes to my to-do list. It is great, and it will be interesting to make an algorithm to assign voices automatically. At the moment I have my hands full, so this is planned after the v6.0 release.

Thanks. It was definitely suggested as an idea for the future. But it could be a much better (and more flexible) alternative to routing RC output as input to DivisiMate.

I am sure you have your hands full with the current plans and am looking forward to whatever makes it into 6.0

[Brian Collins]

Another "music theory" comment. Sorry to be "picky"...

The spelling of modal scales should contain exactly one instance of each note letter. So the C Phrygian scale, which appears as:


should be C, Db, Eb, F, G, Ab, Bb
And that spelling should be used in the chord names and the chord note names also.

And (being even more pedantic) ideally that should extend to scales like G# Harmonic Minor (key signature 5 sharps) which has F double-sharp as the leading tone!

[Brian Collins]

And (being even more pedantic) ideally that should extend to scales like G# Harmonic Minor (key signature 5 sharps) which has F double-sharp as the leading tone!

And following on from this, triads should always be spelled with three letters two scale steps apart (with each extension adding a further two scale steps, all modulo 7). So Eb diminished would be E flat, G flat and B double-flat

Following the rules like this is not only correct, but also presents RC as reliably authoritative in its teaching of music theory, which I believe is one of its goals.

[Brian Collins]

And a follow-up on scale selection and spelling ...

If I set a scale in the header, there is no way to specify the sharp and flat choice:


Two things come to mind:

• B flat and E flat should always be spelled with a flat. A# and D# make no real sense

• Perhaps the master track should have a choice to prefer sharps or prefer flats for scales globally within the composition, and that would determine whether F#, C# and G# scales are spelled like that or as the flat enharmonics. Then the scale choice need only offer a single spelling for scales in the composition

Note that I am talking about the spelling of scale roots; spelling of notes and chords should come from the current scale according the the rules I previously talked about.

[BluGenes]

You do know that the sharps and flats are in the settings ?

[musicdevelopments]

Thank you, Brian! This really needs to be fixed.
Attila

[Brian Collins]

You do know that the sharps and flats are in the settings ?

I did know, but it's not really a "settings" thing as it's not global. I could conceive of doing one composition which is predominantly sharps (say in B) which modulates up a couple of clicks on the circle of fifths and so ends up via F# in C#. But another in A flat could modulate the other way to D flat or G flat or maybe A flat minor. But any one composition would naturally be at one side or another (flat or sharp) of the "circle" - within a real composition it won't really wrap around. That was why I suggested the setting should be a master track property.

But I may be trying to push RC a bit too far in the direction of absolute correctness and generality.

[BluGenes]

Ok, I haven't looked at any thing yet, but, if it needs to be affected by a setting and isn't, that should be addressed.. (is my point).

[sj1]

I agree also with Brian's theory comments. I think what he's described should be the defaults. This would be consistent, logical, and sound as theory is generally taught.

However, I also think that users should have an option to "Avoid bb and ## note names", if that is what they prefer.

So, for example, Eb diminished could be E flat, G flat and A, if that is what the user prefers.

For some people's cognition, moving down by half-steps from B, the next note is Bb, and then the next note is A, period. The notions of ## or bb just do not compute for everyone!

Rather than force some people into symbology that they have a lifetime of bias against, and are not fluent in recognizing or using, I suggest that making the program smooth to use for each user as an individual as per their needs/desires is still the ideal path (albeit, some extra work on the programming side).

This would be consistent with the accommodative intent of the current options (Automatic/Use #'s only'/Use b's only) - but even more sophisticated, while robustly supporting nominally "correct" theoretical representation, which will be a very good thing to do.

I write this for consideration now before the topic is engaged for implementation, because I'm sure that revisiting it yet again later is much not-to-be-desired.

All of this stems from the fact that the 12 tones don't have generally accepted individual names/symbols - the original sin of western music theory, IMO!