Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mode/Key Pie-Selector #1223

Closed
pikurasa opened this issue May 28, 2018 · 13 comments
Closed

Mode/Key Pie-Selector #1223

pikurasa opened this issue May 28, 2018 · 13 comments
Milestone

Comments

@pikurasa
Copy link
Collaborator

First mentioned #1204 (comment) but mode/key selection implicates complexity beyond what the pie-selectors for other parameters call for.

First proposed change is very, very easy. For pitch selection, when inside of key block (and possibly only when inside of key block), it should be ordered as circle of fifths (C, G, D, A, E, B, F).

...

@pikurasa
Copy link
Collaborator Author

Foreword: Please let me know what you think. I am trying to balance simplicity of representation with pitch-sets' inherent complexity.

The thing is, 1) there are a lot of possible combinations (although finite), 2) many sets of pitches are known by many different names, and 3) it is nice to have an organizational structure for the possible pitch sets.

We could have something like the following (note that both pictures are the same thing--one with pencil, the other on a whiteboard):

img_20180528_173211
img_20180528_172251

Examples of "Locrian" and "Major" (aka Ionian), which only differs by "transpositional rotation" although they are in the same family for scales with the same cardinality (left of hyphen) and list number (right of hyphen) for "normal form".

Note: I chose to come up with "transpositional rotation" ("TR" as I have it in the designs) instead of "transposition" because it simplifies how possibilities are handled (for example, if one chooses the number "3", not all list possibilities have the potential to be "transposed by three semitones", but can be "rotated three times").

The details of where the boxes are and where the graphic representation is, I do not have a particular opinion about.

Note that modifying the number in the list number would be redundant to rotating through the list (so perhaps it is not necessarily modifiable...). However, modifying the cardinality has important implications--it changes the entire pie menu list items! Also, changing TR and/or I (Inversion) changes the possible scales in the list.

Locrian:
img_20180528_172019

Ionian (Major):
img_20180528_172438

@walterbender walterbender mentioned this issue May 30, 2018
@walterbender
Copy link
Member

I've simplified the modename pie menu with the intention that most of the esoteric work happen in the mode widget. The plan is to launch the mode widget if the custom mode is selected. Some work to be done in that regard as well as some method of discovery for modes we no longer show in the pie menu.
screenshot from 2018-06-08 08-33-14

@pikurasa
Copy link
Collaborator Author

pikurasa commented Jun 8, 2018

This is the idea I had last night, which I think puts the simplicity at the fore while maintaining access to the potential complexity. It also overlaps pretty much completely with what we have implemented now.

NOTE: The reason of the black space is that I had an idea to align the modes with their respective starting points. The inner circle would rotate when clicked, and its corresponding number would reset to the new "0". However, this is more of a detail, and I am open to different implementations, but I thought the general idea was kind of nice.

Now into the main substance...

(hmm... image is fuzzier than I thought... will try to improve it later, but for now...)
img_20180608_093731

There are three layers of mode:

  1. Choosing the starting point, and whether or not to inverse the pattern. All common modes, for example, fit within just this one layer. It is more or less the same as what we have now. Clicking the starting point, effectively changes the mode since it rotates the wheel (as in the proposal under "NOTE" above, or perhaps just selects the new mode as we have now)
  2. Choosing from other geometries, but those that have the same number of pitches ("cardinality"). In the example, we have "7", which is the same as our common modes default.

Having this allows the user to see all the modes in the same "family", and only those modes. This is important as it is possible to shift from modes that have the same cardinality whereas it is not really possible to shift from modes of different cardinalities without fudging something.

I chose the numeric naming system that many theorists have been using since the 20th century (Forte and others)

  1. Choosing from different cardinalities.

Here, the user can choose to see the selection for all the modes of a chosen cardinality. If they choose 5, for example, they would see all modes with five pitches in layer 2.

More NOTES: I think that, for all modes (and "chords", which would be cardinalities 3 and 4) that we have a name for, there should be something that indicates it in layer 2. It could be a name, like "common notes" or it could just be an asterisk.

Widget: The widget could still be opened, perhaps from any of the layers.

@walterbender
Copy link
Member

walterbender commented Jun 8, 2018

Not sure I completely understand, but I will make some sketches we can iterate from. Meanwhile, check this out https://vimeo.com/51072812 and think modes. And this one: https://vimeo.com/51073078

@walterbender
Copy link
Member

screenshot from 2018-06-10 18-16-19

This is a sketch of what I am thinking. We can have a wheel for mode length (although we probably want to entries for 7 -- the common modes and all the others). I have not implemented your spacing idea yet in this sketch, but it should be doable. I also have not thought about how to include the extra navigation you propose (which is the same navigation we have in the mode widget). Maybe we don't really need it here.

@walterbender
Copy link
Member

screenshot from 2018-06-11 09-12-25

@walterbender
Copy link
Member

screenshot from 2018-06-11 14-30-25

Almost have the mode length menu working...

@pikurasa
Copy link
Collaborator Author

@walterbender Please push this branch so that I can check it out.

I have not implemented your spacing idea yet in this sketch, but it should be doable. I also have not thought about how to include the extra navigation you propose (which is the same navigation we have in the mode widget). Maybe we don't really need it here.

Yes, I realize that there is some overlap, which I am also struggling with as I suspect that it is avoidable. However, I still think that there is some merit to these other systems of organization, and I am trying to incorporate the best of that system into our system. I will continue to explore the new possibilities we have before us.

@walterbender
Copy link
Member

Pushed to master. I'm pretty happy with it in general... much cleaner than the previous implementation.

@pikurasa
Copy link
Collaborator Author

What is happening when I click a darkened space? I see the animation and it seems to go to the nearest scale--is that correct?

I think it might be nice to have a play button, perhaps next to the close button, so that playback of the entire scale is always convenient.

@walterbender
Copy link
Member

I haven't figured out how to disable an individual slice in the pie menu, so for the time being, I advance to the next active slice.

I agree, I want to figure out how to put a play icon in the other half of the "exit" pie.

In general, is the new organization OK? Is it working OK in Japanese?

@pikurasa
Copy link
Collaborator Author

I haven't figured out how to disable an individual slice in the pie menu, so for the time being, I advance to the next active slice.

/me Has never given it much thought but wonders if this could have some clever purpose... will think about it.

I agree, I want to figure out how to put a play icon in the other half of the "exit" pie.

You did it! It is great!

The playback is a little slow for the first few notes, then quickens. I do think that it would be nice to do down the scale as well.

Also, in general a quicker playback would be nice. Eighth notes for somehwhere between 110 BPM and 120 I think would be nice.

In general, is the new organization OK?

Yes, the new organization is certainly better, but I know we can do better still. The places I see improvement are basically in the interaction of layers 2 and 3 from what I proposed above. Since common modes is contained in its current design, the problem is not within the common modes part of the selector. However, let's continue this conversation later...

Is it working OK in Japanese?

Some of the names extend outside of the wheel.

Also, it is funny to read some of them upside down.

Perhaps they are always up and have something to help the user identify the name with the corresponding point on the wheel? Or a short name and the full name reveals with tooltip?

screenshot at 2018-06-12 14 35 17 japanese musicblocks scale wheel

@pikurasa
Copy link
Collaborator Author

pikurasa commented May 8, 2020

I think the original issue has been resolved. We can discuss taxonomies in other discussions.

@pikurasa pikurasa closed this as completed May 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants