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
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
Frank Barknecht _ ______footils.org__
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
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
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.
Understandable, because it's ugly. I'm relucant to touch this myself, fearing I might break things. That's also why I'd rather promote [sssad]. It's not as powerful (yet) but has a much cleaner design that's easier to extend and also more flexible in the long run. I wouldn't recommend to spend a lot of time in [originator]'s internals.
Ciao
Frank Barknecht _ ______footils.org__
I also find [sssad] easier to understand, but I really like the power of [pool] underneath memento (as well as the OSC integration).
I suppose [pool] could be used with [sssad] as well. I'd be interested in hearing more of your thoughts on the future of state-saving in PD, Frank (and Luke).
Phil
Frank Barknecht wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
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.
Understandable, because it's ugly. I'm relucant to touch this myself, fearing I might break things. That's also why I'd rather promote [sssad]. It's not as powerful (yet) but has a much cleaner design that's easier to extend and also more flexible in the long run. I wouldn't recommend to spend a lot of time in [originator]'s internals.
Ciao
On Mon, Mar 17, 2008 at 2:23 PM, Phil Stone pkstone@ucdavis.edu wrote:
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?)
Hi Phil, sorry for the delay in responding; I've had my head buried in Controctopus and need time to load Polaroid/Semento back in to my brain : ). But quickly: all you need from Semento is Polaroid, sft.originator and sft.rradical.state. Polaroid's helpfile has a basic description of how the local-state-saving works, but I agree that it could definitely use a nice straightforward example. I'll think about it, whip it up and get back to you.
But I will say, I use Polaroid daily and it is really fantastic and worth the initial effort; getting Memento and then Polaroid integrated into my patches really changed how I look at and use Pd.
More to come, Luke
So I read my helpfile for Polaroid and it brought back a good rush of memories : ). I realized it might be a bit confusing, as within Polaroid I describe a structure I created for my own use which may or may not be the way people would like to use Polaroid.
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.
So, I'm working on examples for both of those arrangements, and now I'm back to thinking about how to get a hybrid of those so one could also copy Minimoog/1/Oscillator/1 to Minimoog/1/Oscillator/2 because I'm sure I'll want to do that eventually too.
I haven't gotten to thinking about Memento's preset system yet (I tend to just use preset 0 and the filesystem).
Cheers Luke
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
Hi Phil,
On Wed, Mar 19, 2008 at 9:18 PM, Phil Stone pkstone@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
-
Frank Barknecht -
Luke Iannini (pd) -
Phil Stone