I solved it in the DSI Mopho template by setting a flag variable after input from the instrument.
That flag is checked by a single output function that sends the MIDI data out or not then it resets the flag.
Key here is having that one output function that filters stuff going back out.
I use a similar technique just to stop buttons/knobs that run a script 'on expression variable' when the values are initially loaded. Like in sections of config page changes or startup. Then the flag is cleared after one or two frames.
Another example is a button that does the same function but on different interface pages:
When you click it on/off we want the other interface buttons to show the current state.. so set the switch on the other pages using a script on all buttons.
The problem is since the script will try to set all of the other buttons which also are programmed to do the same we need to stop this recursion using up all the sweet Lemur CPU cycles.
So variable flags and checking before (or during) running the button scripts.
Have fun, this sysex stuff is complicated to setup and you've done great work so far. Keep us posted and I look forward to seeing what you do with the Moog filter stuff too!
cheers~
J
Puzzlegob wrote: Sometimes only *some* of the faders get updated, because when setexpression() sets a fader, lemur sends a message to the MKS-80, which in turn sends a separate sysex message from the MKS-80's MIDI OUT (to lemur's MIDI IN) - interrupting the original, long sysex string...
I will try and re-write the script to collect all the relevant sysex bytes from MIDI_ARGS, and send them to another defined array attached to a separate script that updates the faders etc. That way I can be sure that the 'collecting sysex data' part of the script isn't interupted by 100+ individual fader adjustments and their associated sysex messages...