Preset management

[LFSaw]

E.g. by saving the state of an MKtlElementGroup and recalling it later.

[LFSaw]

related to #140

[LFSaw]

if all the accessors are implemented, this could be starting as a cookbook example. If popular, can be made into a separate class.

[adcxyz]

This should simply be
Mktl(\x).elements.value;
not tested whether this works both ways.

[LFSaw]

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...

[adcxyz]

yes, very good idea.

[LFSaw]

💯

[bhabbestad]

gogogo!!
b

1. mai 2015 kl. 21:16 skrev LFSaw notifications@github.com:

—
Reply to this email directly or view it on GitHub.

[adcxyz]

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.

[adcxyz]

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.

[adcxyz]

will try to get NamedList to do this nicely.

[adcxyz]

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?

[bhabbestad]

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

1. okt. 2015 kl. 17:22 skrev Alberto de Campo notifications@github.com:

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.

[adcxyz]

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

[adcxyz]

Moved this to Tutorials/Creating_Presets ...
Clear practical use cases would help here to figure out what the wish is exactly.

[miguel-negrao]

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)	
} 
)

[adcxyz]

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.