Wish: Sleep Action

It would be nice to have an insertable "sleep" action in milliseconds.

For example, consider the case that a sequence of commands is being sent, but a subsequent command won't work unless the first one has completed at the other end.

A sleep command with variable millisecond duration could insert a safety buffer to help overcome the "race condition" and improve reliability of order-dependent sequences of commands.
This feature request would be for an insertable "sleep" action, which would pause / buffer all midi output for a fixed duration. The reason is that some receiving equipment can be sensitive to instructions sent with a very short interval of separation. Inserting a short gap can let the receiving device react properly to the first instruction before the next is sent.

I would love to know if other users would also benefit from this feature and/or if it seems like a feasible target for addition.

Cheers -- Joel


Staff member
This (and the other request) are not super easy to do. The main problem is limited time and a very long to do list. I may be able to get to these features in at some point, but I have to prioritize features that have been requested by a lot of users, for a longer period of time.
Hi Ron — Reply is appreciated & I understand your situation.

Of the two, the delayed trigger off for pedal down is more important to me.

Out of curiosity, can I ask what language/ framework you develop in?

cheers — J


Staff member
How much time do you figure you would need? If the sleep action was allowed to block everything else, it would be far easier to implement. But, that would be problematic if you need more than a few hundred milliseconds because the GT would have to wait to do all that before another button press could register.
Hi Ron --

Thanks so much for the reply. C++ is a great language, especially for performance / low-level applications. I don't have any experience with RTOS, but looked them up & read just a bit ... very interesting.

Yes, I get what you are saying on the sleep. From my *very* limited context / perspective it seems like a fully blocking implementation would be suitable here. Of course, I have no idea what problems that presents for the RTOS ... from my quick read it looks like these devices are typically unbuffered. Your suggestion that there should be a cap on the allowed sleep time to prevent drops makes sense. I do think 100-200 ms should be *plenty* to allow the other device to "catch it's breath" in the applications that have prompted my request (I think ~5 ms would do the trick in one case). Out of respect for your time, let me say that I have found a sleep action workaround that is stable enough in immediate use cases (although I still think the feature would be great, and that it makes good sense in the larger context of your products).

By contrast, the pedal position trigger interrupt request from the other thread (for which I don't currently have a functioning workaround) seems more subtle to me, like it would require a non-blocking implementation. (Please excuse me for speculating / spitballing without any specific knowledge about the internal particulars of your system.) In some contexts where I've done work it is possible to register an event to trigger on a timer, and also to cancel that timer at any moment up to its execution. (I'm guessing you might have actually done something more or less along these lines to implement the hold / repeat button features?) Anyway, I would imagine something like this: the "off" action attaches its instructions to an event timer of selectable duration (again, up to some reasonable max, say 200 ms), rather than executing them immediately. The "on" action cancels any pending event timer prior to executing user-supplied instructions.

Thanks again for chatting / considering & a very happy 2021!