[PD-dev] presets... why not?

Frank Barknecht fbar at footils.org
Sun Nov 30 23:20:29 CET 2003


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
-- 
 Frank Barknecht                               _ ______footils.org__




More information about the Pd-dev mailing list