[PD] More about PD state-saving

[Luke Iannini (pd)]

Hi Phil,

On Wed, Mar 19, 2008 at 9:18 PM, Phil Stone <pkstone at ucdavis.edu> wrote:
>  Going one step further, why not an ultimate flexibility for the upper
>  hierarchy?  Right now, the [originator] in each logical module functions
>  as the main architectural building block of Memento, and sits
>  accordingly at the top of the hierarchy.  What if a (superstate)
>  hierarchy list were passed as an argument to [originator], which tells
>  it where to store its underlying data in [pool]?
>
>
>  Imagine this hierarchy (perhaps a bit fanciful, but not inconceivable):
>
>  2008
>    July
>        Carnegie_Hall
>            Minimoog
>               Preset_12
>                  Module (here lies the current top of the Memento
>  hiearchy, created by [originator])
>                     key-value pairs
>
>
>  If [originator] could accept as an input the list {2008, July,
>  Carnegie_Hall, Minimoog, Preset_12} -- it could store its data at that
>  level of a [pool] hierarchy.  It would then be possible to save/restore,
>  cut/copy/paste the tree below *any* node on the hierarchy, and it would
>  be organized in a way that makes more sense.

I like this idea, and I'll see if I can implement it.  At first glance
it shouldn't be too difficult.  I'd like to make state-saving even
more transparent, and having an organized database of state in-Pd as
you propose would help with that.

Here's a first draft of the Polaroid use demonstration, let me know if
it makes sense or if you have any ideas to improve it.

Cheers
Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: polaroid-example.zip
Type: application/zip
Size: 2979 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080323/bc45c0b2/attachment.zip>