[PD] More about PD state-saving

[Phil Stone]

Hi Luke, Frank, and list.

Luke Iannini (pd) wrote:

> Basically the original presentation of RRADical is organized so that
> Polaroid can be used to copy/paste or save/load settings  from one
> instance of a module to another.  So it is like a big Moog Modular,
> where the settings of one 901 oscillator can be copied to a second 901
> oscillator, or a 911 envelope to second 911 envelope.  And then, to
> save the whole rack of modules at once, you use [careGUI].
>
> What I describe is a bit different; what I wanted was more like
> combining 3 oscillators and a filter to get a Minimoog, and then using
> Polaroid to copy the settings of all 4 modules to a second Minimoog,
> or using [careGUI] to save both of them at once.
>   

> I haven't gotten to thinking about Memento's preset system yet (I tend
> to just use preset 0 and the filesystem).

That is a clever way to get around the problem (of accessing individual 
"presets"), but it's a bit of a shame when you consider that the 
underlying storage, [pool], is very well-designed to handle arbitrary 
hierarchies, yet you have to use the filesystem (with its inherent 
disadvantages...e.g. glitching during disk access) with a "shallow" 
[pool] to achieve the desired functionality.

With the current Memento setup, one can have an arbitrary number of 
"Minimoog" presets, and switching them is as easy as sending a new 
"substate" message via OSC (and it all happens without any filesystem 
access).  What one *can't* do is individually *access* those presets 
(e.g., to save them individually, or to cut/copy/paste them), because 
Memento's hierarchy is not organized that way.

There's nothing magical about "substate" in rradical/memento -- it's 
just mapped to a "relative directory change" message for [pool].  What 
if the current hierarchy were inverted, so that what is now called 
"substate" became "superstate" (corresponding to a "preset", in a 
modular-synth vocabulary), with [originator]-spawned parameter groupings 
(the current system's directory roots) underneath?

Illustrating this desired [pool] directory structure with your Minimoog 
analogy:

Preset 1            <-- this is the "superstate"
    VCO             <-- this is the [originator]-delineated module
       freq. 2000   <--  these are key/value pairs (parameters)
       wave saw
       (etc.)
    VCF             <-- another [originator]-delineated module
       cutoff 5000
       q 0.05
       (etc.)
    ETC.            <-- (other modules)

Preset 2            <-- "superstate" 2
    VCO             <-- [originator]-delineated module
       freq. 2000   <-- key/value pairs (parameters)
       wave saw
       (etc.)
    VCF             <-- another [originator]-delineated module
       cutoff 2000
       q 0.10
       (etc.)
    ETC.


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.


Of course, it's easy to theorize about this; perhaps not so easy to 
implement!  Thoughts?


Phil Stone
www.pkstonemusic.com