2 way MIDI communication and buttons
Posted: 19 May 2014 10:36
I apologize for the subject title - not sure of a better way to summarize...
Anyway, here's the question (everything below is done via scripting, not the built-in MIDI comm).
If you implement 2 way MIDI communication with a device, a common scenario is to request the current settings, update various sliders/buttons/displays, allow the user to change these things, and send the updates back. However, that means that a particular object's "x" value can be updated in 2 different ways - via incoming MIDI and by the user physically moving the control on screen.
So, if you pull back the current settings and update all your controls, the On Expression code will fire the next frame if the value of "x" has changed, which results in MIDI messages being sent back to the device. For some objects, this can be prevented by looking at the "z" variable and if it is 0, don't send any info back since the update to "x" was done programmatically. However, there seems to be no obvious way to prevent this happening for objects like buttons, switches, and pads.
Has anyone implemented a way to block those programmatic updates while still allowing user-generated changes to flow? My initial attempt sometimes works, but it's not solid enough for my liking - sometimes legitimate user touches do not generate a MIDI change message.
In one sense, it doesn't matter because the value being sent back is the value we just queried for, but for some devices, even sending back the same data triggers a 'this patch has been edited' status change on the device, which I'd like to avoid if possible.
This is one of those times where it would be really nice to know how Lemur works under the hood. During the frame where MIDI input is being processed and "x" values are being changed, are the On Expression scripts also being triggered that frame or are they being queued up for the next frame? If they are being queued up, do all of them get kicked off in the next frame or do some get kicked off in subsequent frames?
Anyway, here's the question (everything below is done via scripting, not the built-in MIDI comm).
If you implement 2 way MIDI communication with a device, a common scenario is to request the current settings, update various sliders/buttons/displays, allow the user to change these things, and send the updates back. However, that means that a particular object's "x" value can be updated in 2 different ways - via incoming MIDI and by the user physically moving the control on screen.
So, if you pull back the current settings and update all your controls, the On Expression code will fire the next frame if the value of "x" has changed, which results in MIDI messages being sent back to the device. For some objects, this can be prevented by looking at the "z" variable and if it is 0, don't send any info back since the update to "x" was done programmatically. However, there seems to be no obvious way to prevent this happening for objects like buttons, switches, and pads.
Has anyone implemented a way to block those programmatic updates while still allowing user-generated changes to flow? My initial attempt sometimes works, but it's not solid enough for my liking - sometimes legitimate user touches do not generate a MIDI change message.
In one sense, it doesn't matter because the value being sent back is the value we just queried for, but for some devices, even sending back the same data triggers a 'this patch has been edited' status change on the device, which I'd like to avoid if possible.
This is one of those times where it would be really nice to know how Lemur works under the hood. During the frame where MIDI input is being processed and "x" values are being changed, are the On Expression scripts also being triggered that frame or are they being queued up for the next frame? If they are being queued up, do all of them get kicked off in the next frame or do some get kicked off in subsequent frames?