Hi,
Just to add to the noise, I'd like to say that I wholeheartedly support this feature request.
On Fri, Dec 15, 2006 at 11:44:54PM +0100, Frank Barknecht wrote:
I am a big fan of the way that you have done it, Frank, using only
existing objects. I think to make the whole thing complete, there
should be a set of GOP GUI objects with your state saving stuff
inside. Then people just use those GOP objects if they want state- saving.Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...)
You can get my GOPified modifications of Frank's sssad abstractions here:
http://mccormick.cx/viewcvs/s-abstractions/sssad/ http://mccormick.cx/viewcvs/s-abstractions/sssad.tar.gz?view=tar
I use these a lot in my own patches at the moment in order to do in-patch state saving of all sliders without any externals. It works very nicely with no fuss. Here's a four step program to follow if you want in-patch state saving with no extra files, assuming that you have saved the sssad/ directory somewhere in your Pd path:
- All of your abstractions' widgets should have a receive called
$1/whatever and a send called $0/whatever.
- All of your abstractions should include:
[sssad/auto $0/whatever $1/whatever] for each widget.
- When you create a new top level performance/composition patch, you
should add a box called [pd datastore].
- Instansiate [sssad/datastore] once in your top level
performance/composition patch, and use the save and load buttons to save/load the state of all widgets in all abstractions into the [pd datastore] subpatch of your main patch.
As far as I'm concerned this means that Pd has state saving already. If you add a [loadbang] to the load bang of [sssad/datastore] and if there was a [savebang] which banged whenever a patch was saved, then it would be possible to make this process completely transparent. One of these days I'll get round to writing [savebang].
Have fun!
Best,
Chris.
chris@mccormick.cx http://mccormick.cx