Temperament: Multiple Custom Pitches

[pikurasa]

Development for temperament stopped before we could allow for users to create multiple custom pitches. Right now, the user can only create one.

This ticket is an enhancement because it adds additional functionality.
This ticket is also a bug report because, as of right now, if the user generates more than one custom pitch they bump up to very strange behavior of the pie menus for custom pitch blocks on the palette and in their code.

Log:

wheelnav.js:57 Uncaught TypeError: Cannot read property 'navAngle' of undefined
    at wheelnav.navigateWheel (wheelnav.js:57)
    at Block._piemenuPitches (block.js:4629)
    at Block._changeLabel (block.js:3292)
    at a.<anonymous> (block.js:2694)
    at VM17 easeljs.min.js:12
    at a.b._dispatchEvent (VM17 easeljs.min.js:12)
    at a.b._dispatchEvent (VM17 easeljs.min.js:12)
    at a.b.dispatchEvent (VM17 easeljs.min.js:12)
    at a.b._dispatchMouseEvent (VM17 easeljs.min.js:13)
    at a.b._handlePointerUp (VM17 easeljs.min.js:13)

Images of issue:

[sksum]

I am not sure how we would display different customNotes in palette . a different block for each custom pitch or maybe a pie menu .

[pikurasa]

As we discussed, a pie menu seems to be a clever solution.

[pikurasa]

One design thing that we will bump into very soon is that the set temperament block needs to be present in the code in order for the custom pitches to be properly initiated AND we only have one value for "custom" in our temperament pie menu.

The issue is that, if we have multiple "custom" the user will never be able to really utilize any after the first.

Do we add extra "custom" options to the temperament based on the name the user defines for define temperament?

If we do this, then we should do the same for "custom mode".

The other design idea I had was:

I think the easiest solution is this:
* The chosen custom temperament is implicit by the presence of its corresponding custom pitch blocks.
* Therefore, we do not need the "custom" value in our temperament block. We remove it.
* We still allow a user to override this assumption by putting a `set temperament` block at the top of their script. For example, if they wrote some code using custom pitch blocks and wanted to hear it in equal temperament, they could still do that.
* I do not think this design affords the possibility to test something written out in regular pitches to be tried in the user's chosen "custom" temperament, which is perhaps the only drawback to this design.

...however, this also has its drawbacks...

[pikurasa]

Or, when temperament block is set to custom, we allow the user to type??? (like we do for a number)

[sksum]

One design thing that we will bump into very soon is that the set temperament block needs to be present in the code in order for the custom pitches to be properly initiated AND we only have one value for "custom" in our temperament pie menu.

Adding more ways to change temperament inside code could be confusing to the user , In my opinion , removing custom from options and making custom pitches function independently might be better .

I do not think this design affords the possibility to test something written out in regular pitches to be tried in the user's chosen "custom" temperament, which is perhaps the only drawback to this design.

Also , the set temperament =>(custom ) block doesn't seem to work .... i.e. it doesn't change tuning according to the custom defined temperament ,
Although other temperaments work well: set temperament =>(equal) , set temperament =>(pythagorean) , , , ,

[pikurasa]

Adding more ways to change temperament inside code could be confusing to the user , In my opinion , removing custom from options and making custom pitches function independently might be better .

Fine by me.

[pikurasa]

Fine by me.

I am exploring this a little more...

If we take custom from options we may be losing a way to do things like the following:

(Custom Mode of Custom Temperament)

Also, currently this is how we reinitialize the temperament widget to custom temperament:

I think I am fine if, for custom mode, we express that we are working within a custom temperament just with the presence of a custom pitch block:

However, this looks a little awkward to me since the temperament block will always be incongruent with the custom pitch block:

...but then again, our current way of reinitializing the widget to the custom temperament is also incongruent...

I suppose I have circled myself back to the previous conclusion of "fine by me". Please take these corner cases into consideration.

[pikurasa]

Re: #2368 (comment)

I think the define mode block should take a string, which the user can edit to assign the mode name. All the defined names should appear in the pie menu for the set mode block.

@walterbender should we implement the same design for temperament as well (see the above thread for the discussion that Saksham and I have been having)?

[walterbender]

Should work for both.