Choose Key in Menu; Changes Central Options in Pitch Pie Menus

[pikurasa]

I have a few ideas that will enhance the utility and accessibility of our key/mode features, but this one is the more "low-lying fruit" and will make way for the others.

I think it should be visible in both easy and advanced mode, but when the user clicks the hamburger for more menu options they will also have a choice to "change key". This "change key" option will be limited only to the traditional 7 note major/minor options and will be represented as circle of fifths (not chromatic order).

The default is C major / A minor (which is the current default).

This will affect the following two things:

1. In all the pitch blocks, the central option will become the key chosen in the menu. So, for example, if the user chooses D major/B minor, then instead of C,D,E,F,G,A,B being the central options, the central options will include F# and C#. The user will have the option to make them natural, but it would not appear at the center of the pie menu.

2. The chosen key will be piped to Lilypond at the first instance of where the key is chosen (above the key options for each voice).

Notes:

• Circle of Fifths Options: C,G,D,A,E,B,F#/Gb,C#/Db,G#/Ab,D#/Eb,Bb,F (I am open to different ways of dealing with the enharmonic equivalent keys (e.g. F# <--> Gb), but the simplest solution would be to just present them as one option like F#/Gb. However, the more robust solution would be to allow the user to specify between the two options as it impacts the accidentals displayed within the key.)
• Key options limited to "major" and "minor"
• This change does not impact how a user's code is run. It will, however, make it easier for a user to access non-c-major pitches. They can just say, "I want to make a project that is in D major" and have those pitches at the fore as they choosing pitches instead of having to specify the common accidentals every single time.
• When an accidental for a given key is "within the center", I mean that when the user clicks on the pitch the sharp or flat will automatically be selected. So if we are in D major and select Do or C, then the sharp would automatically be selected for the user. The user can negate this selection by explicitly choosing natural (or flat, etc).

[walterbender]

Specifying the key would let us simplify many of the menus. The challenge had been that we didn't know the key until the code was running.

[pikurasa]

This is more a "Music Blocks as IDE" enhancement than a "Music Blocks as Code Interpreter" enhancement.

The menus would stay the same, but the default options would change according to the key chosen in top menu (and could be overridden by the user).

[pikurasa]

My current thinking on this, as I have already shared with @aviral243 , is that this feature would simply specify "number of sharps" or "number of flats" and would look pretty much just like the circle of fifths.

It would be organized similar to this, but does not even need major/minor keys:

It does not need any mode information. Having the common options for number of sharps and number of flats is enough to help users work outside of c major (or a minor and other related modes) for a fixed system.

For simplicity, we probably only need to display the image of what it looks like on the staff in the middle (of the pie menu) for the specified key. Otherwise, the user is just selecting between "number of sharps" and "number of flats".

This feature will be very helpful when working in a fixed system, such as alphabet (a,b,c,d,e,f,g) or fixed do.

I can also think of a way to make this feature helpful for movable systems. The user would need to specify that they are conceptualizing their music in a movable system. However, we can leave that for now.

[aviral243]

@pikurasa Please take a look at the following images:

This image shows the position of the icon: (the musical note icon, the icon to use is subject to change)

Following is a very basic starting on the pie menu and we can add more stuff to it:

I was in a doubt to use the same colors we use for pitch wheel colors since the menu resides on Aux Menu and colors should be according to the general 'bluish' theme.

[walterbender]

I think we should stick with the green for the hue. But maybe make the center reticle be menu blue?

Not sure the icon tells me much but it will do as a placeholder. I'll think about it.

[aviral243]

I think we should stick with the green for the hue. But maybe make the center reticle be menu blue?

Sure. This is the look with a blue central marker.

[pikurasa]

There needs to be a way to select either a sharp key or a flat key even when they are enharmonically equivalent.

[aviral243]

There needs to be a way to select either a sharp key or a flat key even when they are enharmonically equivalent.

Yes. I'll add those options. Then I think of a submenu that appears when you click such options and lets you choose between those options.

Below is an example from our wheelnav library: (we'll customize it to suit our designs)

[aviral243]

Or we can also think in terms of our modename block. How choosing the number of notes leads to altered choices in the outer menu

[pikurasa]

Or we can also think in terms of our modename block. How choosing the number of notes leads to altered choices in the outer menu

I would rather like to avoid that level of complexity.

I think that the user needs to specify:

1. Pitch Class -- A pitch's Letter Class and Sharp or Flat. We should probably have the same limits to our options as the circle of fifths Choose Key in Menu; Changes Central Options in Pitch Pie Menus #1957 (comment) . I imagine an inner layer with flat options and an outer layer with sharp options--not all pitches need both options.

2. One of the seven most common modes.

Ionian, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian

If we want a complex version, that offers a (nearly) infinite number of options, we should make it only available in advanced mode.

My concern is that someone--a teacher or student at least somewhat knowledgeable in music--may start MB and try something like "Old McDonald in G major", try and find G major, and get completely lost in the nearly infinite options available to them.

What I have above is a compromise between two extreme solutions that I have considered.

Complete Simplicity

Only offer major and minor for aforementioned number 2

Completely Robust

Number 1 and 2 options available, plus a third option...

3. ...to drill down further based on the specific mode the user wants. The third option would be redundant if the user wants one of the common seven modes, but they could also choose modal (sub/super) sets outside of the common seven. Keeping the 2nd option is important because it would provide a default if the user chooses solfege or scale degree pitches outside of the specified modal set.

This third option only impacts the playback for n^th modal pitch (and n^th modal for solfege, if we decide to implement that as an additional option for movable), not the others. That is one of the reasons I think it is a little too much complexity for not a lot of benefit. That being said, we may decide it is an advanced option and make it visible in advanced mode only.

[aviral243]

I would rather like to avoid that level of complexity.

Yes I remember our discussion about this.

Or we can also think in terms of our modename block. How choosing the number of notes leads to altered choices in the outer menu

What I meant here was, taking inspiration from how we produce different sub-menus on clicking different options. Not having all options in our pie menu.

Then I think of a submenu that appears when you click such options and lets you choose between those options.

I hoped to implement something similar using sub-menus for enharmonic keys.

1. I imagine an inner layer with flat options and an outer layer with sharp options--not all pitches need both options.

But this may be better suited.
I propose the same inner layer of flats and outer layer of sharps and, in the center a mode wheel which would present with

Ionian, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian

these choices.

[pikurasa]

SHARP: C G D A E B  F# C# G# D#
FLAT :           Cb Gb Db Ab Eb Bb F (C) 

[aviral243]

This is a general idea of how to display a choice for moveable. (The styling and positioning are in accordance.)

[walterbender]

Looks good. I suppose there are three choices? the default should be Moveable None

[pikurasa]

Looks good.

[pikurasa]

@aviral243 I tested it as it is now. Works well with movable do. It seems you have yet to implement the auto-selection (sharp/flat) for fixed. Please let me know when that has been pushed.

[aviral243]

It seems you have yet to implement the auto-selection (sharp/flat) for fixed.

Can you provide an example of this? I'm having trouble visualizing this.

[pikurasa]

For example, if you are in g major and you click "fa", you get "fa sharp" by default.

[walterbender]

For movable and fixed or just movable?

[pikurasa]

This is just for fixed. Movable already adjusts everything. The specs are detailed in issue.

[pikurasa]

Imagine this: draw five horizontal lines on a page (like a staff). Then put notes in for g, a, b, c, d, e, f, and g. The f (or fa for fixed) is natural.

Then draw a sharp at the beginning for F. This suggests the key of G major or E minor. Then write in g, a, b, c, d, e, f, and g. The f (fa in fixed) is now f sharp.

That is the analogy.

Right now in MB it is like always having no sharps/flats (like in first example) and having to draw them in every single time. More importantly, the user hears the wrong note first (whereas with writing the notes in, you don't typically try to auralize it differently).

[pikurasa]

I think we cleared this up at today's meeting. @aviral243 please let me know if you have any questions.

[pikurasa]

The same implementation should be done for alphabet.

[aviral243]

Got the blocks to generate.

But generating them on pressing the play button does take away the vision and blocks just magically appear once the user sees the blocks again.

[walterbender]

Looks great.

Re updating, maybe you need to call adjustExpandableClampBlock() ???

[aviral243]

Re updating, maybe you need to call adjustExpandableClampBlock() ???

The issue here might be that the play button instantly causes everything to disappear. If I tie the same function to the stop button, it happens almost instantly without any disappearance.

[walterbender]

Oh I misunderstood.
Question: Why is it tied to a button rather than the PieMenu?

[aviral243]

Question: Why is it tied to a button rather than the PieMenu?

Should it be on closing the pie-menu?
I just thought it would be a little 'unforgiving'. But it's also convenient to have it auto-generate with the selected options.

[walterbender]

I think associating it with the pie menu makes the most sense.