Princeton-CDH / bitKlavier

The piano, digitally reinvented.
http://bitklavier.com/
GNU General Public License v3.0
37 stars 5 forks source link

Preset categories/questions #40

Closed dantrueman closed 7 years ago

dantrueman commented 7 years ago

there are a lot of questions regarding how to structure presets. the current version of bK stores the current settings for all preparations, including keymaps, but does NOT store General Settings. the rationale for this is that the GS are things you might want to change for a particular context (tuning to A442, rehearsing at a slower tempo, etc...) without having to go in and edit all the presets individually. new things like we are considering (solo/mute, a mixer for preparations, etc...) seem to me to be similar.

however, we are considering making sub-presets, so you can export/import just a particular preparation setting, or particular keymap (it's easy to imagine composers building libraries of these individual components), so it's fair to ask whether we should do something similar for General Settings and perhaps the Mixer. it also begs the question whether something like a Snapshot, that captures EVERYTHING about the current state and can be recalled, might be useful.

and how this would all relate to Plugin preset structures is unclear to me.... i could imagine a Plugin preset really making more sense as a kind of Snapshot as i just described, whereas as presets saved to files and shared would be more like how it works currently, with the addition of sub-presets.

food for thought....

mulshine commented 7 years ago

Some musings/inclinations of mine re preset format:

What if Presets (the global ones people share) are collections of Preset information (name), GeneralSettings, mappings between Keymaps/Keys and "SubPresets"(Preparations)/Tunings/ParameterMappings, and the data for all of them? They could be arranged like:

Name: {"MyPreset"}, GeneralGain: {1.0}, GeneralSynchronicGain: {1.0}, ... GeneralHammerRelease: {1}, PianoMap: {k1, [d1, n1, s1]}, {k2, [d2,s2]}, {72, [p1]} Keymaps: {k1, [0>127]}, {k2, [60, 72]} Synchronic: {s1, [array or dictionary of preparation data]}, etc. Nostalgic: {n1, [array or dictionary of preparation data]}, etc. Direct: {d1, [array or dictionary of preparation data]*}, etc. ParameterMap: {p1, [k2, [d3,s4]]}*** Tuning: {t1, [array or dictionary of tuning data]}, etc.

*As arrays, something like [1.0, 1000, 50, 1, 0, etc.]. As dictionaries, something like ["Gain":1.0, "Pulses":1000, "ClusterMax":50, etc.]. ** Pretty quirky at first glance. Would mean that ParameterMap1 (which is mapped to key 72) causes Keymap k2 to switch from being prepared with [d2,s2] to being prepared with [d3,s4]. If we want the Keymap k2 to change as well, it could look like {p1, [k2, [k3, d3, s4]]} and we define k3 in Keymap section.

dantrueman commented 7 years ago

seems to make sense. i think the main question here is how to implement Parameter changes, or whatever we end up calling them....