Modality-toolkit
Modality-toolkit copied to clipboard
Preset management
E.g. by saving the state of an MKtlElementGroup
and recalling it later.
related to #140
if all the accessors are implemented, this could be starting as a cookbook example. If popular, can be made into a separate class.
This should simply be Mktl(\x).elements.value; not tested whether this works both ways.
wit the new MKtlDesc implementation, we could have a method serialise
which returns MKtl:fullDesc
including all MKtlElement:value
(and lastValue etc.) serialised into a state dictionary...
yes, very good idea.
:100:
gogogo!! b
- mai 2015 kl. 21:16 skrev LFSaw [email protected]:
— Reply to this email directly or view it on GitHub.
MKtl(x).presetValuesAt(\sl) could return a similarly formatted writable array, for a chosen subset of all elements, in nested [key: val, [key: val, key: val]] format, and MKtl(x).presetStringAt(\sl); creates a pretty-printed string from it, saveable to text file.
in many use cases, some controls should be saved, and others not (e.g. master volume). so maybe a good way is to add a collective called eg \paramPreset, which get its values as [ [ \kn, [ val1, ..., valueN] ], [\sl, [val1, ... ]]], which can be saved in memory as a named setting, and saved to disk as a prettyString.
will try to get NamedList to do this nicely.
wondering now how useful having presets of controller state is: what is a use case where one would want to save and recall the state of an elementGroup? it seems that usually the interesting state is in the controlled objects themselves, not in the controllers, or am I missing something?
I think this stems from me.
What I suggested is that we should have the opportunity to easily freeze, store and later manage/sort the incomming data from controller(s) in order to store for later use, a feature I think is usefull both in performance and in development situations.
I know that this can be done in many different ways and at different levels, but I think there should be a modality-specific approach to this.
b
- okt. 2015 kl. 17:22 skrev Alberto de Campo [email protected]:
wondering now how useful having presets of controller state is: what is a use case where one would want to save and recall the state of an elementGroup? it seems that usually the interesting state is in the controlled objects themselves, not in the controllers, or am I missing something?
— Reply to this email directly or view it on GitHub.
ok thanks, makes sense - just did a simple example for your use case, in ef8abe2. hope that works for what you had in mind: https://github.com/ModalityTeam/Modality-toolkit/blob/master/Modality/Tests/Presets_w_MKtl.scd best a
Moved this to Tutorials/Creating_Presets ... Clear practical use cases would help here to figure out what the wish is exactly.
I'm also looking at implementing something like this. My use case is that I want to store all values of MKtlElements, so that when I reconnect the controller I can send the values back to the controller and recreate the previous state. I was thinking of storing a flat dictionary of keys to values, and naming the methods something like storeState loadState. Any comments ?
Something like:
MKtl('bcr').gui
(
x = MKtl('bcr').elementsDict
.collect(_.value).asCompileString
)
(
x.interpret.keysValuesDo{ |key,val|
MKtl('bcr').elementsDict[key].valueAction_(val)
}
)
hi @miguel-negrao, yes makes sense - probably best implement it in elementGroup though, so it gets everything from the group down, then you have full flexibility to store everything in readable order, or any custom groups that should be presettable.