while playing around with my newly discovered Arturia KeyLab MkII LED functionality I was wondering why I cannot send some final MIDI data within On Deactivate are there any limitations?
I was trying to send some final SysEx when leaving the Rackspace/Scriptlet
I can see the Print() output in the script logger window, however no outgoing MIDI data.
Any ideas/explanations?
BBB
PS: the SendLEDSring() is working very well in the other parts of the scripts…
Probably because the actual execution of that callback is asynchronous and so by the time it runs (even though it may be just milliseconds), the rackspace will be deactivated which means that ALL plugin blogs are deactivated
Probably send an OSC message to the global rackspace with the values and have a script in the global rackspace that responds and sends the data to a midi out block in the global rackspace
There’s another possibility though unfortunately I don’t remember whether it will work for sysex messages (and if it doesn’t, I might have to add that sooner rather than later)
You can have MIDI In (OSC) blocks and send MIDI messages to them over OSC
So, for example, you could have a MIDI In (OSC) block in the global rackspace connected to a regular MIDI Out block and then just send MIDI messages over OSC to that MIDI In (OSC) block.
Hm, I did not further try so far. But, would there be a different behaviour if I send OSC (or MIDI) in the On Deactivate callback, instead of real MIDI data to an external device?
I will check later or in the next days.
What about, if it’s asynchronus, just using the good old loop trick after your for loop, having a new for loop with a variable, say j, where j = j + 1, until j reaches a number high enough to let the asynchronus command finish?
So what happens inside On Deactivate is not performed before deactivating?
I used something like what I described in a large Visual Basic programming project once upon a time to keep the program itself up and running until some asynchronus householding stuff were finished running.
So you’d like to hold up the rackspace deactivation process until some script has finished, thereby preventing whatever sound is needed next during a song from being available?
VB is not designed for real-time systems programming where you’re not allowed to just blindly hold things up or “wait”
First of all, how do you guarantee that a user’s script will only take “a few more milliseconds”?
Secondly, if you’re running your audio at 44.1k with 128 buffer size, you only have 2.9 ms to do everything, including switching an entire set of plugins before the next audio buffer has to be ready or you will glitch.
Hi, an interesting discussion! As far as I understand the architecture of GP a little bit more now:
sending MIDI over an MIDI out block within an On Deactivate is not possible, as all MIDI blocks get deactivated before the callback gets called
some processes/function are asynchronus (I already made some more experiences while the implementation of my latest version of my Arturia KeyLab Scriptlet …)
However I finally have have been able to send OSC messages to the GP listening port out of my Scriptlet. Funny side note: moving some sliders of an open scriptlet panel may even send further OSC messages, even if the Rackspace where this Scriptlet resides is not active
In my Global Rackspace I’ve implemented a callback for my OSC message and can react on.
For me everything is fine at the moment. Thanks for pointing me in the right direction @dhj - and all others
Some details of my solution:
Reading out the used OSC Listener Port in On Activate and injecting an OSC message in On Deactivate (OSC_ListeningPort is a global integer…)