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