Can someone please help me to understand when one would choose SendNow (p : MidiInBlock, m : midiMessage) and when one would choose InjectMidiEvent (physicalDeviceName : String, m : midiMessage)?
There is a powerful metaphorical difference between the ideas of “sending” versus “injecting”. Is one of them more efficiently implemented than the other?
And, I would surmise that if I have multiple MidiInBlock blocks all listening to the same MIDI input device, an “injected” event would show up at all of them, but a “sent” event would only appear at the block it is sent to?
SendNow is intended for sending a MIDI message out through the output port of the MIDI block (or scriptlet) in which the SendNow exists. The Inject mechanism is a lower level function that emulates a MIDI message coming into a MIDI device from the outside world.
What does it mean for the SendNow to exist “in a MIDI block”?
The code I’m writing is all within the global rackspace script. I have callbacks that respond to MIDI events from the two MidiInBlock objects that correspond to my two physical MIDI controllers, and then need to send new MIDI events onward to plugins in both the global and local rackspaces. I’ve been accomplishing this by injecting the new events into the Local GP Port, and then receiving them using MidiInBlock objects (listenining to the Local GP Port) in both the global and local rackspaces, but it has occurred to me that instead perhaps I should send the new events straight to the MidiInBlock objects rather than injecting them.
You say that sending and injecting have very different purposes, so I guess the answer should be obvious to me, but I can’t decide which one to use in this situation.
Actually, the more I think about this, the more I think that I have to inject these events rather than sending them, because I don’t think there’s any other way to transmit MIDI events from the global rackspace to the local rackspace (short of using OSC or some kind of virtual MIDI cable, but on principle I don’t want to be messing with networking just to move data within one instance of an application).
I haven’t yet played with Scriptlets at all. Thank you, I will explore this avenue, although thus far it seems that the global rackspace script serves my needs well.
That’s really easy, they have a MIDI input and a MIDI output. So, you don’t need to define any handle on MIDI in block you simply connect the Scriptlet input to the MIDI in block and the Scriptlet output to a plugin or a MIDI out block (in you case a virtual MIDI out port or an OSC MIDI out port)
I’ve read that article, but I just think that resorting to wrapping every little MIDI event in an IP packet just to send it to a plugin within the same application seems like way overkill. That’s like mailing a postcard to my roommate instead of just sticking a note on the fridge.
This is a view that I think is wrong. The implementation of the OSC protocol in GP is super efficient and perfectly transparent to the user. I’m currently using it to control a GP Mixer plugin from my control surface and it offers a lot of flexibility. I’m used to using virtual MIDI ports, but it’s not at all clear that implementing a virtual MIDI port is lighter than an OSC communication.
Ha ha ha! OSC would be more like sticking a note on your roommate directly!
I wonder if you are aware that OSC was designed to be a replacement for MIDI to handle musically expressive information at a much higher rate than MIDI could ever do?
Except that I prefer not to have to use scripting if there is a way to do it directly in GP. The MIDI OSC blocks are the way to do it and they’re going to be faster as well.
