Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I think it is a very useful thing to have indeed, I could not imagine the complexity of my patches without the "state" object. But first we have to give the concept one or another thought.
Yes, we should definitely collect, what might be expected of a preset system, a specification. I didn't use [state] for years, I guess, and just now looked at the help patch again, when the first problem arose. Clicking 1 gave:
state: unable to open /usr/lib/pd/doc/5.reference/state.1
This is one feature I would like to see: Saves should not automatically select a save file, but should require a (full) path to a file provided by the user. Maybe [state] allows that, I didn't look very hard, it's just something that stroke me when it happened.
Then I figure that two kinds of preset behaviour would be cool. One is of course persisting things to the disk, the other is a kind of preset in memory. If you look at my just announced memento-0.2.tgz: Here the new "substate" feature is just that, a way to switch states on the fly, without the need to store to or load from disk.
In the end this will of course lead to a tightly related thing: automation. Automation could be seen as switching states (or presets) on a higher level than just some message passing to change a float value. I shortly mailed with Thomas Grill about that and he remarked, that in complex patches changing a lot of values at once can get very costly if all this is done through messages. Moving all that data around through send/receive might be slow. (I didn't do any benchmarks yet...)
Another very important feature IMO is the saving and loading of states in child patches from the parent patch and into a single file (or several files in a single directory, but I'd strongly prefer a single file), or similar, but probably more tricky: saving the parent and all his childs from inside a child patch.
This could maybe be achieved by using something like the shared datapool in Thomas' pool: Have a [preset StateGroup] object, where "StateGroup" collects related states. The user could put a [preset StateGroup] into the abstractions, that should get saved in this group. Every [preset StateGroup] object, even in child patches, would be able to save all other presets in the same group. A default could be to just save every state in every patch.
A lot of this is possible with an abstraction, as my Memento, but it's tedious. Your state external could be extended to support above features, as well, but of course it should be able to read the state of every changeable object including IEM-GUIs, maybe tables, anything else? I have no idea what changes would be needed inside Pd, though.
ciao