deferCallbacks and Its Effect on MIDI-Mapped Controls
-
If I set my interface script to deferCallbacks=true, how does that affect the controls being adjusted by MIDI CC? If I learn the controls vs. create a custom mapping table in the MIDI script, what's the performance result?
Is the latter more accurate/reproducible ?
Chris explained to me that it's a good idea to create identical controls in the MIDI script and link them with the interface script for cross-script communication.
-
@aaronventure the deferred callbacks are only the MIDI callbacks (
onNoteOn
etc) - if you assign a MIDI CC to a UI control using the learn popup, it will "consume" the MIDI CC event and call the UI control callback synchronously - whether this is then executing a inline function or just set a module parameter if you connect it using theprocessorId
/parameterId
attributes. -
@Christoph-Hart Thanks for clearing up, the synchronicity of it is what I wanted to learn about.
So the interface drawing, panel scripting, paint routines, that's always on the worker thread?
Should I even use deferCallbacks in my interface script, or can I just plonk all the data there directly in the on_note callback, reducing the need to have more MIDI scripts (some I'll need anyway)?
-
@aaronventure If you don't use the MIDI callbacks of your interface for UI stuff, then yes, you could leave them in the audio thread, however I found it a rather good nudge into keeping functionality modular and separate to make another MIDI processor for realtime MIDI processing.
-
@aaronventure said in deferCallbacks and Its Effect on MIDI-Mapped Controls:
Should I even use deferCallbacks in my interface script
I always add it by default. That way if I add something to one of the realtime callbacks that shouldn't be there I'll get a warning message.