Hey all,
Well I'm back from Norway and pretty well though my email. (600 messages this time!)
Anyhow Patrick for the record this "feature" is not implimented, and it was always my intension that this should be integrated into the rradical/memento thing, with Frank's help.
So I'll outline my vision first and then talk about the way the architecture could work.
From the user perspective:
The user loads a pixelTANGO (actually the idea is any memento) patch.
An abstraction (or second patch) is loaded to wich you send a message
like: [midi table<
- The abstraction creates a new sub-window that contains a dynamically
generated array of GOP abstractions, each looking something like:
/pt/layer/1/pt.fader/a [ ] On/Off [X] Learn [0 \ CC [0 \ Channel
On and off just turns on and off a spigot to disable/enable routing to that OSC name, Learn turns on the latching stuff to associate that OSC name with a controller/channel.
One of these is generated for every memento'ed parameter in the patch. (yes it could be a really long list)
And the channel/cc are saved based on the OSC name so that you could load an old state after your patch has changed and the mappings still work.
- The user goes through each parameter turning on "learn" and then
moving a slider/fader to associate each OSC name to the MIDI CC
Possible Architecture:
Frank was/is (still?) planning on the idea of a central pool that stores not only the state of the commun objects, but also creates a list of all of them in a patch. (well I think Frank wanted to do this per abstraction). I would also like the OSC name to be pulled into this pool.
This table would be something like:
index OSC-name
perhaps..
Of course if one deleted an abstraction in the patch then we would need to re-generate this list... I guess a signal that queries all the communs and resets that directory in the pool. Frank, I think your prototype did do this.
Then the mapping abstraction takes care of reading the table and generating the array of abstractions.
Then each abstraction simply latches its CC/channel data and sends it to the OSC target.
Problems/Issues:
Frank already mentioned the issue around non-float messages and MIDI mapping. Perhaps the pool that collects the communs would have a freild for the data type, and a MIDI mapping abstraction would only be created for each float type... Or floats are kept seperate from the Lists and Symbols... Thinking aloud here.
I have not thought much about the numeric range thing, maybe all MIDI controllers are automatically ranged to 0-100 floats and then all parameters expect the 0-100 range.
OSC control is broken in pixelTANGO. This is due to the programatic limits of OSCx (OSCroute actually). For pixelTANGO the user does not define the OSC name of a parameter, this is defined by the module itself. So it is not an argument to the abstraction but generated dynamically. To do this we need to be able to set the OSC route name by message, rather than by argument. (This is not really an MIDI mapper issue)
The general purpose OSC Mapper:
So after all this effort we can map MIDI controllers onto arbitrary OSC names in any memento/RRADical patch. nice. But what I really want is to be able to use this for general bulk control, not just MIDI. That means:
LFO bank uses the same system to automate parameters (but this would require a way of turning on and off certain commun objects from state-saving, and to avoid conflicts with MIDI controllers etc..)
Also crazy things like feeding an RSS feed into the symbol [commun] objects would be very cool.
Ok so thats my statement to date...
Frank, care to get back into the discussion, I have not had a chance to look at the patches you mention in this thread yet, I would really like to work with you on this to have an integrated system that can be used for any RRADICAL/memento patch...
.b.
Frank Barknecht wrote:
Hallo, patrick hat gesagt: // patrick wrote:
in pixeltango there's a nice feature. if you touch a [commun] object you can assign a midi controller to it. i didn't test it, but i think it's there. for an example:
- you touch rotate_x slider
- you turn a know on your controller
- the rotate_x is assign to the last cc
- you save this routing
it would be great to have this kind of template in memento!
There is "rradical/control/rrad.ctlearn.pd" in RRADical which you could use to wrap the [communs] you'd like to be midi controllable. I don't want to add this directly to [commun] as [commun] also can be used to state-save non-floats like lists and symbols.
Alternatively I personally prefer to use a seperate patch to interface with midi altogether. In CVS you can find this approach realized in: rrad.evo33.pd and rrad.evo33b.pd
They work as a kind of general purpose mapper from midi-CC to arbitrary OSC messages with scaling of value ranges. All settings are saved into a memento as well. This way you can create different CC-OSC-mapping groups, that you can change on the fly. This is veryvery powerful, much more so than a direct CC-to-slider-mapping could be. However I agree, that it requires a bit more planning, though.
Ciao