[PD] re: pref inheritance / snapshot saving

[guenter geiger]

On Tue, 6 Apr 2004, Frank Barknecht wrote:
> Hallo,
> carmen hat gesagt: // carmen wrote:
>
> > searched the mail archive but couldnt find this... do you mean
> > drawbacks of having state-saving handled by an external rather than
> > the app itself, or something else?
>
> It currently isn't clear how to handle hierarchical state saving of
> abstractions in use, there is a need for saving substates in memory
> and some of us (at least I) think that a state is not only made up of
> things that are kept in visible GUI objects. Also I want to be able to
> control the save file and what goes into it more than [state] or
> possibly Max' [preset] allows.
>
> But [state] still is useful, and would be even more useful, if it: a)
> would include the GUIs again and b) would get an outlet that can be
> used to send state values somewhere else. This way state could be used
> free of its state-file features and for example just feed a [pool]
> object.

It shouldn't be too hard to separate the state reading from state in order
to have such functionality.

In order to summarize the discussions we had about state saving, the
general problems are:

1) object identification. How do I know which state (number) belongs to
which object. This can partly be solved with the receives that GUI objects
currently have. But how would this be handled in abstractions ?
You will always have to use some explicit naming hacks.

2) Reading of the objects state: Krysztof proposed an API for querrying
the object state of each object. Implementing this would make it a lot
easier to add the GUI objects again, and it would make it possible to add
state saving to objects like float, spigot settings, etc.

3) Simplicity: the  biggest drawback of all state saving is how to
maintain simplicity. Most users of pd are not programmers, keeping it
simple is one of the main goals.

Guenter