Hi Scripters,
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
Hm, I already assumed something like this. What could be a possible workaround?
What I want to achieve is to send out some ‘final’ MIDI data to an external device before entering the next rackspace.
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.
I think you mean IAC MIDI connections, instead of OSC? 
No, I think, @dhj really meant OSC 
Here is helpful link
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.
Thanks for sharing thoughts!
What is “real” midi?
The issue is not about sending MIDI or OSC.
The issue is that MIDI blocks in your local rackspaces are being disabled as part of deactivation so you can’t use them.
But the MIDI blocks in the global rackspace are still active
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?
No, the GPScript Deactivate callback happens asynchronously. There is nothing to wait for….the blocks will have already been deactivated
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.
Correct
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”
Of course not. I just thought that we were talking a few more milliseconds to get something done.
Agree on that one 
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.
No guarantee. The script creator would have to test extensively.
I think I’ll rest my case. Not a good idea doing it my way in this scenario 
Hi, an interesting discussion! As far as I understand the architecture of GP a little bit more now:
On Deactivate is not possible, as all MIDI blocks get deactivated before the callback gets calledHowever 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…)
Catching the OSC message in the Global Rackspace script:
More details in the linked thread
Hmm, that’s a bug
Sent you a small gig to reproduce
