EVENT_DELAY?

[Duggle]

When chaining events (we can chain up to 4 EVENT_* controls) a delay may need to be inserted between to operations to allow the receiving midi device time to react.

I encountered the situation

The idea is to forward the event to an EVENT_DELAY which in turn forwards to the next control in the chain. The EVENT_DELAY would postpone forwarding for a duration of value=milliseconds. If the EVENT_DELAY is re-triggered (i.e the forwarding control changes again) during an active delay, then the delay period restarts, guaranteeing a minimum delay period from a control change to the forwarded event. 

 

Here is an example (ignoring the possible significance of the order the EVENT_ definitions)

EVENT_ENC id= 1 hw_id= 1 fwd_id=DELAY:1 fwd_to_lcd=1 chn=1 type=ProgramChange
EVENT_DELAY id=1 fwd_id=SENDER:1 value=50
EVENT_SENDER id=1 type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x30 0x00 0x40 0xf7" 

In the above example, the effect is that the Sysex dump request only happens once the ProgramChange selection has "settled" for at least 50ms.

 

[TK.]

An EVENT_DELAY wouldn't match with the implementation concept, and in general, queues are expensive (RAM and performance wise)

 

Wouldn't it be sufficient to send the SysEx string from a .NGR script?

There is even a special command "send SysEx <port> <stream>" command which simplifies this.

 

Best Regards, Thorsten.

[Duggle]

O.k. I'll try this.

I didn't notice the "send SysEx..." looks good.

I hesitated with the NGR method  because I have these audition loops in runsections which I thought might block the action of the command. 

If the newly issued command breaks the loop that would be the best outcome.

Will try it, and see!