Internal MIDI routing between VSTs
I'm looking to send midi directly from one vst to another. For instance a suite of proprietary vsts that have internal midi routing (with no exposure to the daw). While I was hoping to accomplish this inside of RNBO (before exporting) it has been confirmed by C74 that this is not possible.
As an alternative, I am currently exporting my RNBO project to C++ for use with the rnbo.example.juce template, with the intention of augmenting the Juce and/or RNBO code to implement this functionality.
As it stands, the AudioProcessorGraph from the Juce library is my only lead.
Any insight or direction is appreciated.
As you talk about an internal midi routing, I assume you do NOT want to make a general MIDI router between tracks like Blue Cats Connector (https://www.bluecataudio.com/Products/Product_Connector/) supports it, which does a lot more, but can also be used to route MIDI inside a DAW that lacks internal MIDI routing capabilities.
So I guess its more about MIDI that you generate in one of your Rnbo Plugins to be used in other ones - technical more like a cross track MIDI FX chain.
From a composition perspective maybe something like Captain Plugins (https://mixedinkey.com/captain-plugins/), Scaler 2 and alike : in the sense that 1 master Rnbo pluging creates the chord progression and the other client Rnbo plugins know when which chords are playing and hence can create their musical output in relation to that.
If this is the case, you could abstract the MIDI you genereate in the master Rnbo plugin in some data representation and push it to the client Rnbo plugins by means of "general purpose" I/O, e.g. Open-Sound-Control over UDP.
Or in other words : use udpsend & udpreceive between your Rnbo plugins - if you need to have the same MIDI running in the receiver plugins, let the master & client plugins share the generating algorithm and (re-)create the MIDI in the Rnbo client in realtime, based on the configuration you created and send over from the master.
This might inspire you : https://rnbo.cycling74.com/learn/rnbo-raspberry-pi-oscquery-runner
Whereby I do not know if UDP (network I/O) is 100% allowed (specifed to be present and ready to use by the standard) in VST & AU plugins or if some DAW may supress it, but as we see a lot of VST & AU plugins that are internet connected for authentication purposes and other internal aspects as well (I think Capting Plugins are even rely on an internet connection for some of their generation features), I think this could work.
What exactly did Cycling 74 confirm as not suported? Using "send" and "receive" Max objects for "cross Rnbo instance" communication? As this sheds a light on the process / thread separation of the Rnbo plugin instances and the differences to Max for Live ... would be interessting to know.
I think Rnbo is a very interessting technology ... I am lookking forward to get some time to dive into it.
- edit -
If this works for you or not also depends on your realtime needs. Using UDP (network I/O) for inter plugin communication will introduce latency.
MIDI based client-server architecture is a fair description. Real-time is a priority.
In the past I've had success in Max with udpsend, and even by just using the send object in M4L, but RNBO doesn't support the udpsend/udpreceive objects, and vst's generated from RNBO code do not expose normal send/receive objects to other vst's. To quote my conversation with C74 support "There isn't anything in the RNBO build code currently that would allow for intercommunication between vst's."
These considerations have lead me to the C++ export for use with the Juce template. Juce has OSC send/receive modules but from what I have gathered the AudioProcessorGraph is more efficient being that it uses the host's audio processing engine.
I'm not totally helpless with C++ as I can export the vst correctly from Visual Studio, but otherwise it is a bit like open water. In my mind there is a point in the Juce template where messages that are being sent out of the midiout object (in RNBO) get "intercepted" for use with the vst. It is at this point (RNBO_JuceAudioProcessor.cpp ??) that I imagine custom implementation of the AudioProcessorGraph would take place: creating channels for proprietary inter-plugin midi communication.
Last time I just overflew the Cycling 74 documents regarding RNBO Raspberry Pi and did not realize that its only the "runner" (like a shell that hosts the RNBO export ?) that is able to communicate via OSC and hence reachable via updsend from Max.
What's also "funny" : the Docs about the key differences between Max and RNBO do not state that udpsend and updreceive are not supported (https://rnbo.cycling74.com/learn/key-differences) - this is something that should be mentioned.
I think your conversation with the support will be more accuarte than the docs, but maybe this is a hint, that that OSC (UDP network I/O) is planned and will come in a future update? Did they say something about that?
Any luck in the Juce forum?
I believe that RNBO inter-plugin communication is essential to have and something that Cycling 74 should implement, at least at parameter / normal data exchange level - expecting mechanisms for realtime midi and audio maybe overcharged, as this is "DAW level" respectively VST & AU level.
Hence I think doing "realtime MIDI", you are right trying to accomplish this in Juce, although I can imagine that is a bunch of stuff to learn and not to forget that you have to maintain 2 very different technology stacks ... its not only to get it work, but to keep it running with the updates and changes that the developers bring to the table ... and not to forget that different DAWs maybe behave differently.
Anyways - good luck!
I posted on the Juce forum last night. Twiddling my thumbs for now.
"and not to forget that different DAWs maybe behave differently" that's exactly what prompted this escapade to begin with; about once a year I find myself reading the same page in the Ableton docs that reminds me "Ableton Live merges midi channels when routing midi from one track to another".
There's gotta be a couple Juce wizards hiding in the Cycling forums...
Thanks SOUNDYI, I appreciate the insight.