[PD] rradical hierarchy

[Phil Stone]

Luke,

Could you clarify this?  I looked through controctopus/semento, as you 
uploaded it last month, to see if it had re-structured the hierarchy to 
make substates more editable, but I'm having a little difficulty 
figuring it out (do you have any relatively simple working examples?)

I find that powerful and complex PD systems such as memento/rradical are 
very difficult to understand without a little more documentation.  When 
I try to follow what's going on inside of [originator] (both in original 
memento and in semento), I rapidly get lost.  I'm not a total newbie 
when it comes to reading and understanding PD code, but stuff like this 
really needs a few more comments, I think!  :-)  Please don't get me 
wrong, I'm extremely grateful for the work that has gone into this 
amazing code; I'm just having trouble working with it in any but a very 
superficial way.  I think memento (and possibly semento) go a long way 
to solving the problem of state-saving in PD -- I'd like to see them 
more widely used, too.


Phil




Frank Barknecht wrote:
> Hallo,
> Phil Stone hat gesagt: // Phil Stone wrote:
>
>   
>> As I understand it, rradical builds up a tree of directories created by 
>> individual [originator directoryName $0] objects.  Within each of these 
>> directories, one can have an arbitrary number of one-level-down 
>> directories (for instance, in my case I use a preset number to access 
>> the subdirectory).
>>
>> The hierarchy ends up looking something like this (the number in the 
>> second column is the preset):
>>
>> /final_filter 0 , /enable , 1
>> /final_filter 0 , /freq , 0.543263
>> /final_filter 0 , /qfactor , 0.31746
>> /final_filter 1 , /enable , 1
>> /final_filter 1 , /freq , 0.929158
>> /final_filter 1 , /qfactor , 0.509524
>> /lfo_filter 0 , /enable ,1
>> /lfo_filter 0 , /wave ,sine
>> /lfo_filter 0 , /freq ,100
>> /lfo_filter 1 , /enable ,0
>> /lfo_filter 1 , /wave ,sine
>> /lfo_filter 1 , /freq ,0
>> .
>> .
>> other parameters
>>
>> As you can see, it's organized by originator-name, then preset number, 
>> then the key/value pair.  This makes it very difficult to access presets 
>> as units for copy, pasting, etc.  For these purposes, the ideal 
>> organization would be something like:
>>
>> (preset number) / (originator) / (key/value pair)
>>
>> One could then easily edit a preset as a logical unit.  The current 
>> configuration makes it easy to edit all of one type of parameter across 
>> all presets, but this seems much less useful than the converse.
>>     
>
> There is a little modification of [originator] by Luke, which is
> pending to be included in the official Memento and which implements
> saving and restoring presets for each [originator] separately. Luke
> also made his modification available somewhere in SVN, I don't
> remember the name currently, I guess something like "semento". As soon
> as I've catched up all the loose ends after LAC2008, I'll include it.
>
> Ciao
>