Greetings
As is unfortunately often the case, I'm getting utility from something in PD long before I understand it, in this case rradical. It works nicely as a way of saving and recalling banks of presets, but I'm trying to expand my capabilities into cutting and pasting parts of the rradical directory tree (as implemented by [pool], and this is where I'm running into a little difficulty with rradical's storage hierarchy.
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.
I don't understand the guts of rradical/memento enough yet to know if this way of organization is even possible, much less practical. [pool], at least, doesn't seem to care how its directories are organized (or tagged: it seems any atom can be used to tag a directory).
Phil Stone pkstonemusic.com