Key signatures in Notation editor and MIDI editor

[panicaftermath]

It is not clear how the key signature is being determined.

The notation editor seems able to determine the correct key of an item or group of items, eg, four sharps for the key of E: F#, C#, G#, D#.

But in the ME, with the exact same items, note events are labeled as Gb, Db, Ab, Eb.

Shouldn't these be consistent?

Using the "key" option in the ME will cause the notes to display their correct names, but it also (AFAICT) prevents note events from being inserted or moved to notes that are not in that key.

Am I missing something?

[casrya]

Some discussion on the topic here http://forum.cockos.com/showpost.php...&postcount=737

Personally I think key sigs in notation view work well but do not map to the MIDI editor as smoothly as they could but is workable once you figure it out

[peter5992]

To add to this, it would be helpful to have the key signature displayed on the timeline in the main edit window as well.

(In the meantime, you can add markers and then add the key changes to those whenever there is a key change.)

[panicaftermath]

Even though this issue might not be specific to the notation editor, it seems clearly related to the overall effectiveness of notation, so I'm resurrecting this pre-release thread (and also because I got yelled at for mentioning it out in the wild.)

The song is in the key of A. If I do not indicate a key at bottom of editor, then accidentals are displayed as flats. That sucks. (Is there a way around this?)

If I set the key to A, then notes that are not in the key of A are unavailable. That sucks worse. (Is there a way around this?)

If I switch between piano roll and notation, the notes names and the key sig are completely different, amping the suckitude even more. (Is there a way around this?)

On what basis does it work this way? Is this just the way it is?

Why is notation indicated with different key names, placing it effectively in a different key, than the underlying midi?

Why are notes that are not in the indicated key unavailable for editing? It's not as if music actually works that way. (Is there a way around this?)

Is it something I'm overlooking?

How does any of this make sense?

[hamish]

The greyed out keyboard for key being selected is really old, goes back 4-5 years probably when 'key awareness' happened in the MIDI Editor.

Not crazy about it overly, but it does make some things, like creating a 'diatonic sequence' of a phrase really clear and easy. (Select, Ctrl+left click-drag)

It will take time for the Notation editor to become fully knitted to the underlying system (the 'substrate' if you'll humour me).

Think of it as a piece of toast (quite old too) and the Notation as some lovely fresh jam. Or not maybe, lousy analogy.

Anywaaaaaaaay. Try to be patient. The greyed out notes will stay in the piano roll when 'key' is checked.

HOPEFULLY the incorrect enharmonics will go from the Piano Roll very soon. I never have notenames on by the way, so I never even saw this. I colour by channel, don't have velocity handles on notes and pretty much change all the defaults in MIDI editor, and I quite like working with it.

I hope you come to terms with it too.

[panicaftermath]

Thanks Hamish. I've come to terms with it, more or less. And I like Reaper's midi editing quite a lot... which is why these little things really stand out.

The frustration comes when the behavior seems to make no sense and it's hard to tell if I'm looking at user error (which I'm well acquainted with) or a bug, or an unfinished or just off-kilter implementation.

The nitpicks! The nitpicks!

[schwa]

Note names are not shown in the piano roll editor by default, so this behavior, while not great, is not a high priority to fix (meaning we won't hold up the 5.20 release for it).

The "key" checkbox means "snap to key" in both the notation editor and the piano roll. The key snapping can be overridden with a mouse modifier (shift+control+alt+drag by default).

The piano roll editor doesn't have any concept of "now we are in this key" independent of the snap-to-key checkbox. We can certainly change things so that a key signature entered via the notation editor will carry over to the piano roll and affect how individual note names are displayed, regardless of whether snap-to-key is enabled or not. But like I said, we won't hold up the 5.20 release for this change.

[panicaftermath]

Hi schwa. Thanks for the explanation.

What's not clear is what the grayed out notes indicate when key snap is enabled, since they don't correspond either to the notes of the scale or to legal snap positions.

Key  Grayed out
C    all notes 
G    F, F#
F    Bb, B
A    A, Bb, B, D, Eb, E

The gray overlay doesn't seem to actually mean anything. It can always be ignored, but it's very prominent and so seems to amount to just visual noise.

We can certainly change things so that a key signature entered via the notation editor will carry over to the piano roll and affect how individual note names are displayed, regardless of whether snap-to-key is enabled or not.

JMO, but that would probably be a good thing at some point, as it would meet basic expectations that names and key be consistent across views, especially now that notation is here.

But like I said, we won't hold up the 5.20 release for this change.

Understood! And congrats again on this milestone release!

[PitchSlap]

I'd like it if the key signature could be set in the project settings and written as metadata during export.

I don't read notation, but defining the key of a project could be useful for future functionality i.e auto-pitch shift to match the project key in the media explorer based on an items file name or metadata (like tempo-match but for tonality)...

[schwa]

Originally Posted by panicaftermath

Key  Grayed out
C    all notes 
G    F, F#
F    Bb, B
A    A, Bb, B, D, Eb, E

I think you are visually misreading grayed out vs not grayed out. The grayed out piano keys are the ones that are not in the selected key signature. Try toggling the key checkbox on and off and notice which keys change appearance. (I see that the keyboard does not immediately redraw when you do this until you move the mouse into the piano roll; we'll fix that.)

[EvilDragon]

schwa - I do think that it could be displayed a bit more consistently regarding grayed out/transparent keys in the piano roll.

Right now, black keys get transparent, and white keys get grayed-out. Why the inconsistency? Why not make them all grayed-out? It would be less confusing I would say.


After 5.20 is out, of course


(Also, I very much agree that piano roll's note names should follow the accidental names as defined by the key signature - and there's no real need for an option to adjust this behaviour, really - it's a sane and expected thing to happen automagically! Db has nothing to do in A major, for example!)

[hamish]

Originally Posted by PitchSlap

I'd like it if the key signature could be set in the project settings and written as metadata during export.

I don't read notation, but defining the key of a project could be useful for future functionality i.e auto-pitch shift to match the project key in the media explorer based on an items file name or metadata (like tempo-match but for tonality)...

+1 (Keysigs are exported with MIDI now, they're added in the Notation editor by right-clicking at the start of a staff, when you get the 'clef' cursor)

Just need to quote this as a 'told you so', because I told you so

I will go further and predict that 93% of all neophytes coming to REAPER from a Notation-centric MIDI sequencer because they heard that it has a new Notation editor/Score view will ask for this.

Mock-up:

[panicaftermath]

Originally Posted by schwa

I think you are visually misreading grayed out vs not grayed out.

Um, yes, I can see that... I was wrong when I said that in C maj all the keys were grayed out -- when all the black keys went gray, the effect was that the white keys seemed to also "go gray" when in fact they were just all white, as usual. And now having seen that, I see more clearly where the problem is, at least as I'm perceiving it.

The problem, visually, is that when the white keys are grayed out, their grayness isn't fully registering as grayed-out, possibly because the shade is too close to that of the default window background color (eg, the cc channels) and so they don't quite read as gray. The grayed-out black keys are easy to see.

But as the number of grayed out white keys increases, the color coding becomes more difficult to read, and the alternating gray and non-gray groupings, overlaid on the regular (non-grayed) key groups, impede quick pattern recognition (again, at least as I'm perceiving it.)

Then throw in how, in the main editing area, the last-touched note tints the entire row white, even for accidentals, including grayed accidentals, and pattern recognition (which is heavily dependent on the regular distribution of black keys) is further impeded.

Hmm... interesting problem.... though my confusion has (hopefully) lessened at this point, having analysed it this closely.

[panicaftermath]

Originally Posted by schwa

(I see that the keyboard does not immediately redraw when you do this until you move the mouse into the piano roll; we'll fix that.)

Related to that, when note names are displayed, and the Key setting changes, the names do not update until you actually click somewhere in the editor.

[panicaftermath]

Originally Posted by EvilDragon

Right now, black keys get transparent, and white keys get grayed-out. Why the inconsistency? Why not make them all grayed-out? It would be less confusing I would say.

I think you're right about that ED.

What we have now are multiple shades of gray, in the piano roll (keys) section, and then separately in the editing field, that correspond to each other, but that don't actually match each other. So quick grokability is reduced especially (as I said above) as the number of accidentals increases, and the balance of grayed-white to non-grayed-white tips over.

[casrya]

Originally Posted by schwa

The "key" checkbox means "snap to key" in both the notation editor and the piano roll. The key snapping can be overridden with a mouse modifier (shift+control+alt+drag by default).

That is quite a shortcut Is there an action for it since I couldn’t find it in the MIDI editor action list? Also, it looks like you have to enter the note in the wrong spot first then drag it to the non-snapped location?

Originally Posted by schwa

The piano roll editor doesn't have any concept of "now we are in this key" independent of the snap-to-key checkbox. We can certainly change things so that a key signature entered via the notation editor will carry over to the piano roll and affect how individual note names are displayed, regardless of whether snap-to-key is enabled or not. But like I said, we won't hold up the 5.20 release for this change.

I would certainly welcome this post 5.20! Anyway, congrats on the 5.20 release, you have come a long way in a short time

[hamish]

Agree on the greying nitpick as defined by ED and panicaftermath. That's exactly the reason I find it a bit tiring.

[panicaftermath]

Originally Posted by hamish

Mock-up:

And that would propagate to the ME and notation. It's just the kind of project init I'd expect to find in project settings. In fact, I recall looking for it there when I started using the notation pre-releases and saw discrepancies between how key sigs and note names were displayed.

It's funny what a big difference labeling has. The "Key" checkbox in the ME, which when checked opens two dropdowns for entering key details, seems like it should be specifying the key, given the label, the content of the dropdowns, and the fact that it appears in a note-oriented window. So when those expectations aren't met, something seems wrong.

But in fact, it's not a "Key" checkbox, but a "Snap to key" checkbox. In retrospect, it's obvious. And having that pointed out (#7), everything else starts falling into place.

Somewhat similar to how colors and tinting operate in the TCP, there are too many shades of gray in the piano roll for them to be read easily.

What if grayed out keys, both white and black, had the same coloring effect, eg, a light crosshatch, so that they looked the same, and appeared as more clearly recessed "dead" zones.

[hamish]

Originally Posted by panicaftermath

What if grayed out keys, both white and black, had the same coloring effect, eg, a light crosshatch, so that they looked the same, and appeared as more clearly recessed "dead" zones.

Yeah, something like that. I like the idea of recessed looking keys. TBH I had been assuming that the 'load colors' thing in Piano Roll did something like this, and I had just never checked it out.

I think I'll be spending a lot more time in Notation view from now on Still Piano roll will be needed for CC and velocity drawing, editing keyswitches and even some note entry. It could use some love. (Piano keys especially).

[panicaftermath]

All those shades of gray are producing an optical illusion of sorts, but one without sufficient depth. It's not a good scheme.

I was not seeing an (in retrospect obvious) color difference that was disappearing into the chrome. And without that, it became indecipherable.

But in my defense in fact, there's one color difference too many: why would "not in key" have different conventions for black keys and for white keys? There are now two different "not in key" colors/tints/treatments that need to be read -- or completely ignored -- in order to make fast sense of the piano roll. In keys with 2 or more accidentals it gets especially weird.

But now that I see it, I see it. There's still an optical illusion to it, but it's no longer a total WTF.

But WTF, it really should be better. Wouldn't take much.

I tried seeing if it was tweakable in the theme config window, but none of the obvious things made a difference, and my eyes soon glazed over.

But that's Reaper.

[Icchan]

I don't like the idea of forcing the key signature globally since how do we manage when one song has multiple key signatures?

[schwa]

In the notation editor, you can right click the start of any measure and change the key signature. Those key signature changes will carry over into the piano roll editor -- whatever measure the edit cursor is in, that key signature will be used for all displayed note names on the screen.

[G-Sun]

Originally Posted by Icchan

I don't like the idea of forcing the key signature globally since how do we manage when one song has multiple key signatures?

Unless you're the Zappa of music ala 2050,
this is normally a misconception.

(I just seem to repeat that, don't I )

[hamish]

Originally Posted by Icchan

I don't like the idea of forcing the key signature globally since how do we manage when one song has multiple key signatures?

Oh well, you're a bit late then because there already is a global key signature - C by default.

There is also the ability for tracks to have 'local' keysignatures, for any polytonal passages or parts. To do this you need to change the default (global) setting: Menu >View >Notation view options >Key Signatures >Key Signature changes affect all tracks.

All I'm suggesting is a high-level (overview) editing of global keysignature.

For example people wanting to write for concert band might want to go to project settings and put in Time sig, Tempo and also Key=Bb maj right up front. Then when they add their tracks and MIDI items they have that keysig on all new tracks/staves.

[casrya]

Related request: http://forum.cockos.com/showpost.php...31&postcount=8

[panicaftermath]

Originally Posted by hamish

....go to project settings and put in Time sig, Tempo and also Key=Bb maj right up front. Then when they add their tracks and MIDI items they have that keysig on all new tracks/staves.

This makes me think of how Reaper's time sig and tempo sig share a common marker, and how editing one requires editing the other, if only incidentally or passively, and the inconveniences it not outright problems that can cause. Time sig and tempo have no necessary relationship to each other, and combining them into a single marker just reaps (!) confusion.

Likewise, having the song's key sig be connected to the the "key snap" setting, and then having having that single setting determine how note names are displayed, seems like three different functions have been combined into one. At first glance, it seems to make some sense (definitely more so than with time sig and tempo) but in practice, it's a very uneven implementation.

I'm looking forward to seeing how this resolves itself as notation is further refined. I feel that having notation makes demands and raises the bar and on how the piano roll operates, given they they are actually just two views on the same data, with each view setting up expectations for how the other operates.

[casrya]

Originally Posted by schwa

The "key" checkbox means "snap to key" in both the notation editor and the piano roll. The key snapping can be overridden with a mouse modifier (shift+control+alt+drag by default).

Originally Posted by casrya

Is there an action for it since I couldn’t find it in the MIDI editor action list? Also, it looks like you have to enter the note in the wrong spot first then drag it to the non-snapped location?

Ok, found it .. I was looking in the wrong place :P Any chance of adding an "insert note ignoring scale/key" option to the relevant mouse modifiers so we don't have to do an insertion then a move?

[hamish]

Originally Posted by casrya

Ok, found it .. I was looking in the wrong place :P Any chance of adding an "insert note ignoring scale/key" option to the relevant mouse modifiers so we don't have to do an insertion then a move?

Worth thinking about. Personally I doubt I would use it. Keysnapping is a big advantage in Notation because the view is compressed vertically compared to Piano Roll.

In MuseScore I'm used to working this way, 1) enter diatonic note with mouse 2) use my semitone adjustment key command.

So really wonder if you'd end up using a chromatic mouse modifier much.

Just though about it more. In fact I think this would be good.

[magwa101]

Originally Posted by schwa

In the notation editor, you can right click the start of any measure and change the key signature. Those key signature changes will carry over into the piano roll editor -- whatever measure the edit cursor is in, that key signature will be used for all displayed note names on the screen.

I have loaded ZD-Ultimate.reascale but I am unable to select any of it's Key Signatures in Notation view.

Apparently, I can only select the "top level" Key Signatures that appear to not be coming from ZD-Ultimate.reascale.

To be specific, it seems to assign the scale Key Signature up to "4 note Scales" "Major TetraChord 1". After that it does not change the Key Signature in Notation view. note that "Eskima Tetratonic" appears to show a special character in the Key Signature.

Note that when I take a scale that's in a "sub menu" and promote it to the top, I can indeed select it and the key signature changes. This is a major clue I think.

Is this a bug? Or is ZD-Ultimate.reascale not formatted correctly?

[lavmort]

Originally Posted by hamish

+1 (Keysigs are exported with MIDI now, they're added in the Notation editor by right-clicking at the start of a staff, when you get the 'clef' cursor)

Just need to quote this as a 'told you so', because I told you so

I will go further and predict that 93% of all neophytes coming to REAPER from a Notation-centric MIDI sequencer because they heard that it has a new Notation editor/Score view will ask for this.

Mock-up:

Oh yeah, bump for a key signature in project settings. When starting on new project, the keys signature stays the same as in the previous one, getting annoying sometimes ngl

[creal]

Originally Posted by lavmort

Oh yeah, bump for a key signature in project settings. When starting on new project, the keys signature stays the same as in the previous one, getting annoying sometimes ngl

I support that FR as well, along that one would display the key sig in the timeline.

[goto]

Necro bump.

Correct key signature indication at least in the piano roll timeline or as a notation event in the CC lane.