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