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