Wait function request



If there isn’t one already (I cannot see one in the list of functions) - then can we please have a simple Delay/Wait function (i.e. Wait 5 ) [ms].

I’m having a problem whereby I send a change message to change the patch on my Motif XS and then follow it up with a Volume change - but the volume change does not happen. If I insert a somewhat whopping ‘for’ loop to calculate some pointless double precision number a few thousand times then it does work. I feel I would prefer something more controllable and elegant than this kludge.

I see there are functions for sending midi messages after some time delay - but this is not what I need (i don’t think).

Anyway - it would be much appreciated please.



Hi Barry,

how to you send the change message to the Motif XS?

Via scripting?


I’ve been working to use a free VST I found that allows you to send patches and the like using Sonar Instrument Definition files (i.e. select by a real patch name and not some cryptic prog change number)’ plus also send a user selectable set of Control change messages (e.g. Volume, Pan, etc). ‘Out of the box’ it doesn’t quite work as the environment it was written for is different from GP - so I wrote a script to make it happen. I’ve have been using it for a couple of months and it worked flawlessly on my Roland Integra-7 module. I was about to publish it on this forum (today actually) when I noticed that there was something not quite right about the volume settings on my Motif - and thats when I found my timing problem (it doesn’t happen on Integra-7).



Believe it or not, there’s no such thing as a “simple” delay function. Consider, suppose you added a delay for 5 seconds. Do you really want the rest of the scripting system to stop working for 5 seconds, meaning that no other MIDI events would be processed?

Doing this properly means either implementing a “yield” mechanism or setting up a new callback. The former would be a significant (and potentially dangerous) change to the language, requiring much more thought. The latter can be done now using a “hack”

In the next update (due to be released in the next few days, we just need some more Windows users to test it), there’s a new function called ScheduleMidiEvent which allows you to schedule a MIDI event into the future. That event, when it occurs, can be processed by an existing callback. So, for example, you could create a new unused MIDI In block (use an OSC block and disable OSC and enable GPScript) to receive that event and then use a callback to receive it and do what you want.


Hmm!! I see the problem …

I certainly didn’t or wouldn’t suggest a delay of 5 seconds (although somebody might I guess for some artistic reason that I cannot even think of). I’m only talking about a momentary delay. I don’t know how long my temporary calculation takes (which seems to work perfectly) - it might even be much much less than <<1ms.

So would such a short calculation loop have impact on the midi event processing?



I know you are but I need to consider the general case and this is not something one just throws into a language without thought.

As I mentioned, you can get the effect you need without too much effort using the new Schedule functionality


I was a programmer in a scientific environment for many years (a long while ago) and did real time data collection from scientific instruments - so well understand the problem of delays or hold ups in the wrong place or in critical sections.

But - on thinking about it - I think my problem is a specific case. This only happens at rack activation and ensures the setup VST sends externally to the Motif-XS - its program change data and [pause very briefly ?1ms ] then its control change data (i.e. vol, pan). This gives the synth time to gets its 10 year old brain sorted out before it receives the volume etc settings. I suspect this might be a common problem with some hardware (it is with my Motif - it is not with my Integra-7 module).

But so many other things must be happening at rack activation all over the place in GP - that I suspect a negligible delay won’t make that much difference. However, I agree that a similar delay at other times when musical midi data is flying all over the place could have serious side effects as you suggest.

The downside of having the Motif with the wrong volume etc. settings when you start playing is equally not a good thing.



I’m using the Strike 2 drum vst. When programming a fill, I have to build in a delay or the next rhythm pattern will come in too soon. Because I use an iPad app called OnSong as my main midi controller, I am able to do this as it has the midi delay command available (up to 3000 milliseconds are on tap to use). Could using OnSong be a useful procedure in this instance?


Bigalminal: Thanks for the suggestion of an iPad - that could be a solution - but I’m not keen to go down that route. For what I do - controlling everything from the Motif (as a master keyboard) and a nanKONTRO2 should be adequate.

I got an email saying there was a new message from PianoPaul (which I cannot now seem to find on the forum - so perhaps it was deleted!) asking 'why can’t I use the new schedule functionality in GP Script. The answer is that I could and will indeed try it out when its available - although the phrase sledgehammer and nut sprang to mind.

My simple software generated delay more than adequately seems to do the job. I’ve calculated a real estimate of the delay on the Motif I need between ‘prog change’ and ‘volume change’ - by scaling up the delay to the point it can be measured - and it turns out to be 15ms - not my guesstimate of less than 1ms. However, I really suspect that a 15ms delay in the processing of GP data during rack activation will not make that much difference - particularly with all the other GP and VST stuff that will be going on when the rack is activated - but maybe I’m wrong.

PianoPaul also mentioned problems with timing with Kontakt. In which case he has my greatest sympathy as my experience with Kontakt and Native Instruments in general is not encouraging. I had Kompakt - they withdrew it; I had Bandstand - they withdrew it; I had Kore 2 - they withdrew it; I had the B3 organ - they withdrew it - and Kontakt seems to take a fortnight to load larger libraries - so I tend to stay clear of NI. Although I actually like what Kontakt does and is needed if you want to use some 3rd party libraries - particularly the piano ones.

I was looking at the new scheduling routines - which David suggests will be available in the next update of the Windows version - but I’m curious to know the difference between ‘ScheduleMidEvent’ and ‘SendLater’ - which seem to do more or less similar things. So perhaps he could please clarify…




First of all, it’s not quite obvious to me why you can’t just use SendLater. You would send out your program change and then use SendNow to send the CC 7 message 15 ms later.

ScheduleMidiEvent does schedule an event for later but those events go through the full MidiInBlock processing when they arrive, which means you can intercept them via callbacks just like you do for notes or other events that occur in real-time. Essentially that means that you are scheduling a function (the code in the callback) to be executed in the future.


The reason is because I am not sending program change and control change messages directly from the script - its as I said in the thread above:-

“I’ve been working to use a free VST I found that allows you to send patches and the like using Sonar Instrument Definition files (i.e. select instrument by a real patch name and not some cryptic prog change number)’ plus also send a user selectable set of Control change messages (e.g. Volume, Pan, etc). ‘Out of the box’ it doesn’t quite work as the environment it was written for is different from GP - so I wrote a script to make it happen.”

Its a matter of triggering the VST at the correct time (rack activation) to make it output the relevant information. In addition to having up to 5 user selectable control messages - you can actually easily widgitize each of them. It is working very well - part from the timing snag caused by my Motif - which is not the VST’s fault.

So I think ‘ScheduleMidiEvent’ is probably what I would need.



Maybe that VST needs to have the ability to delay events if its very purpose is to manage external hardware :sunglasses:


Yep - I agree - but we are where we are, and I cannot find another solution to the problem that is as good - and I’m fairly sure I now know how it ticks. As I said - it was designed for a completely different environment (a DAW) and what we do not know is what control that exerted. It does seem likely that the DAW does do something - because the sending of the Program change and the sending of the Control Changes are controlled separately.

Anyway - I intend to persevere because apart from this small timing glitch (which is fixable) - it does do what I want - and relaibly.



I converted my script to use ScheduleMidiEvent and although I have not tested it extensively - it does seem to work very well and is a much better solution than my previous timing loop.

I have one suggestion related to this which may or may not be desirable, or even technically possible. I can see a real future use for these scheduling/synchronizing features related to internal timing. So rather than necessarily having to add a dummy midi block to the rack every time (unless its required) - can I suggest that you somehow have an internal midi port (say called GP_Internal_Midi) which never appears in the rack - but is always available if you want to use it with things such as ScheduleMidiEvent . Just a thought!



It’s not a bad idea, I’ll put it in our tracking system.


But how to Route that to the Midi Out?


Its (presumably) just for internal use - so it doesn’t get sent to midi out - not unless you specifically send it to another separate midi out port. My point was that its always there to be used and doesn’t have to be declared.

As an example: In my case I used a note on message (60 = C3) to be sent 15ms after I activated the Program Change (via VST activation) so that the Control Changes are then processed (again via VST activation) with that 15ms delay. Usefully I then used the velocity information as a code which activates different channels (because my script supports up to 16 channels of midi) - C3 at velocity 1 activates/controls channel 1, C3 at.velocity 2 activates/controls channel 2 etc.