Quote:
Originally Posted by signoc
Just dipping my toes in OSC..
Lest say I have, i have a general specification for controlling VSTi.
For example
/filter/cutoff
This I would want to use to control any vsti cutoff.
NOW an general set of instruction would not be very practical in all situation, why I would want specific instructions for certain VSTi where I would build special controltemplates in TouchOSC or similar.
For example
/NImassive/filter0/cutoff
or
/ACE/filter1/cutoff
NOW how do I bind both
/filter/cutoff AND (for example) /NImassive/filter0/cutoff to control NI Massive first filter cutoff?
Is this possible? mapping multiple control messages to one parameter. One I can manage with learn, but two?
Another question is weather it is possible to bind controll messages to particular vst/vsti s in a reaperosc file. As I can se in default.reaperosc, it doesn't show any hints that it is possible.
|
I don't see either how it could be done by name, but it could be done by (fixed) number(s).
However, I think there's a better method: what I'd suggest for using a specific config for a specific (VST(i)/AU(i)/JS) plugin, is to make a separate, dedicated 'virtual' control surface configuration for it (i.e. a .ReaperOSC file), for a limited set of OSC messages (i.e. only FX_PARAM stuff, only 1 track / 1 slot, etc.), and keep it targeted somehow (selection, focus, last touch) on that VSTi. Then you can use a 'main', much more generic OSC configuration that uses a broader set of message patterns, and navigate the (rest of the) project with that. Both the dedicated and main configuration can be routed to the same physical or virtual control surface at the other end (with some UDP traffic forwarding between ports).
That would be more flexible than using 'fixed' message patterns in a single OSC config besides ones using the @ character, because you could then still do stuff like insert a JS MIDI plugin before the instrument plugin, or change track order, and would only have to adjust the track/slot number that the 'dedicated' OSC control surface targets, (or, much easier: ) re-focus, or touch the plugin to re-establish the OSC 'connection'.
Actually trying this method is still on my own to-do list, so I'm not sure it'll work as desired yet.