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

[guenter geiger]

On Sun, 30 Nov 2003, Frank Barknecht wrote:
> 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.

yes, "state" can only load files that have been saved before, maybe I
should improve the documentation, if this is not really clear.
I think that states should be saved relative to the patch directory,
which is the case with state. If you want to change the filename
instantiate with "state mystate".

Guenter

> 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__
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
>