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