hi,
after a private conversation with guenther it looks like the (IMO _very_ useful) state object is dying, is there anyone out there already familiar with the gui internals willing to take the challenge and write a state object that saves the current state of all (including the somewhat newer) the gui objects ?
regards,
x
...
with the gui internals willing to take the challenge and write a state object that saves the current state of all (including the somewhat newer) the gui objects ?
Ideally I think the feature should go into PD itself... have each object which is 'state-able' implement a method to export/import its state. This would be a binary chunk of data with known size, parsed out with sscanf or somesuch.
just an idea... (i.e. I'm not going to do it ;)
andy
Originally the idea behind the "state" object was to store the values of all atoms, therefore the sliders in the ggee library were implemented by providing the atom interface.
Obviously this important feature got lost, and as far as I have looked at the code, the sliders don't hold their value anymore, but they compute it at run time, therefore storing the atom value is not sufficient anymore, the value has to be stored together with the slider type.
Well, finally, IMO this should be fixed in the gui objects, ...
Guenter
On 15 Mar 2002, Andrew (Andy) W. Schmeder wrote:
...
with the gui internals willing to take the challenge and write a state object that saves the current state of all (including the somewhat newer) the gui objects ?
Ideally I think the feature should go into PD itself... have each object which is 'state-able' implement a method to export/import its state. This would be a binary chunk of data with known size, parsed out with sscanf or somesuch.
just an idea... (i.e. I'm not going to do it ;)
andy
-
Andrew (Andy) W. Schmeder -
CK -
g�nter geiger