New Keymap/(Piano) concept

[mulshine]

Keymap construction

Keymaps are collections of one or more notes. KeymapLayerId becomes KeymapLayerIds (a sort of keymap construction area) where Keys and Keymaps are combined to form a larger set of keys associated with a Piano.

So, say there are several keymaps: K1,...,Kx.

Originally we could just do K1 or K2, meaning that our Piano processes keys in either Keymap K1 or Keymap K2. With the new method, we might be able to do [K1 K5 C4 62] which would add all the keys in K1, all the keys in K5, midi notes 60 (C4) and 62 to the Piano's larger Keymap.

One step further

This also has larger implications for how we might go about assigning PreparationMappings (P1,...,Px) to individual keys or Keymaps. For example, what is now called KeymapLayerIds (but maybe should be called Key/KeymapConstructor), could look like:

K1 K5 60 62:P1 K3:P2

This would result in a Piano that contains all the keys in K1, K3, K5, 60, and 62. Plus, 62 would cause a Parameter change P1 and any key in K3 would cause a Parameter change P2.

Another step further...

If we took it one further and eliminated the notion of the Piano (as we talked about), we could have keymaps like:

K1:[S1 N2] K5:D1 62:P1 K3:P2

And that would basically be a Preset. When 62 or any key in K3 is hit, we have a new configuration of Keymaps/Preparations/Mappings, thus a new preset.

The problem, of course, is how to represent this "Another step further..." in the UI. I bet there is a way. In the end, I think that at least having the KeymapConstruction area (keeping the notion of Piano intact) would be cool and useful. Thoughts?

[dantrueman]

so, in all of these, including the last one, P is a Parameter change, right, not a Preset change?

[mulshine]

yes thats right!

On Wed, Dec 21, 2016 at 5:21 PM dantrueman notifications@github.com wrote:

so, in all of these, including the last one, P is a Parameter change, right, not a Preset change?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Princeton-CDH/bitKlavier/issues/39#issuecomment-268658258, or mute the thread https://github.com/notifications/unsubscribe-auth/AGlRgKIIC3ZMKAMq_Sbk910yn0gRPjfkks5rKaZrgaJpZM4LTPyn .

[dantrueman]

so... how about we call this new Preset... a Piano! the main difference between the new one and the current one is that it holds multiple Keymaps, with associated functionality, right?

[mulshine]

yup! and yeah. the decision is whether or not we do away with having multiple pianos and just allow an unlimited amt of key/keymap-to-preparation mappings.

lets just think on this all a bit! ill start with our basic idea of a paramter specific keymap in each piano, which allows certain keys to add or subtract keymaps. and maybe ill make the keymapid field in to a keymap constructor so we can combine multiple keys and keymaps

On Wed, Dec 21, 2016 at 6:36 PM dantrueman notifications@github.com wrote:

so... how about we call this new Preset... a Piano! the main difference between the new one and the current one is that it holds multiple Keymaps, with associated functionality, right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Princeton-CDH/bitKlavier/issues/39#issuecomment-268674179, or mute the thread https://github.com/notifications/unsubscribe-auth/AGlRgGUcmyzXAWY8Fp61GxgfQffZlD0iks5rKbf3gaJpZM4LTPyn .

[dantrueman]

yep, sounds good

[dantrueman]

i mean, might as well keep the array of Pianos for now. even if we end up only using one most of the time...

[dantrueman]

a potential complication: in practice, when we rehearse with bK, the preset names that i put in the score/parts are essential, so we can start anywhere in the piece, the pianist can pull up the appropriate preset, and we play. having to go through a series of piano key presses to reconfigure the instrument is not likely a good substitution.

[dantrueman]

i suppose a Library could be a collection of Pianos, Pianos which are largely reconfigurable internally through Parameter Keymaps, but would also be good to be able to switch Pianos via a Parameter Keymap.

[dantrueman]

or, basically the same: one Piano that is internally reconfigurable, but a way to save Presets that can be called up manually (and might as well make them settable via a Parameter Keymap as well). as long as the reconfiguring is cheap though!

[mulshine]

yeah! i think that we can preserve a notion of "Preset," but also have them easily reconfigurable internally. we may just have to toy around with the app configured in this way to really be able to tell... i'll start working on it.

On Wed, Dec 21, 2016 at 7:52 PM, dantrueman notifications@github.com wrote:

or, basically the same: one Piano that is internally reconfigurable, but a way to save Presets that can be called up manually (and might as well make them settable via a Parameter Keymap as well). as long as the reconfiguring is cheap though!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Princeton-CDH/bitKlavier/issues/39#issuecomment-268689625, or mute the thread https://github.com/notifications/unsubscribe-auth/AGlRgPUNAuXyAZjuR3kIqjoN_QzdkoBYks5rKcnOgaJpZM4LTPyn .

[dantrueman]

having multiple ways to do essentially the same thing can be a good thing. so, having a Piano that can be internally reconfigured to do something may be equivalent to having two presets that the user switches between, but having both ways to do that might still be valuable. there are lots of examples of that in other programs, of course... it seems to me that once we have multiple Keyboards in Piano, then Piano can essentially be our Preset and a Library can be an array of Pianos, so switching between them will be just switching between pointers. then, having the Parameter Keymap (the Meta-Piano ;--)) will allow a lot of internal reconfiguration, so the combination should be flexible and powerful. i bet we can find a good way to represent all this in the UI, but, right, it'll pose some challenges!

[dantrueman]

here's where i'm at currently, after having mocked up some UIs and thought about it a bit:

1. one Piano active at any particular moment (previously a Preset)
2. Piano has (possibly) multiple Preparation Keymaps and (possibly) multiple Modification Keymaps that are looped through
3. Modification Keymaps allow modification of currently active Preparations, either by setting values directly or (possibly later version) through simple iterative functions (*2, +10, etc...), or by changing to a different Piano entirely
4. multiple Pianos constitute a "Library" (or if we want to be cute: "Warehouse" or something similar)

here's my latest rough mockup of the Piano Construction Site

1. new keymaps created with auto naming with + button
2. keymaps can be renamed by clicking name...
3. list of active Preparations buttons is dynamically updated as new ones are created or deleted
4. create new ones on the fly with + button:
   • choose type (Synchronic, Nostalgic, Direct)
   • opens new window for creating chosen preparation type
   • optionally change auto-generated name
5. activate individual preparations for a particular keymap by toggling on/off (yellow text)
6. option-click on preparation button to:
   • open preparation for editing
   • delete preparation
7. when "learn" button toggled on "learning!" keys are turned on/off by playing actual keyboard

Imagining something similar for Modification Construction Site; keymaps with preparations that are connected to for modifying params internally... or for changing to different Piano

so, the front end might have: Construction Site, Modification Site, and then some kind of Performance Site where you can set it to monitor it while playing, seeing most relevant params....

anyhow, some thoughts to work with!!