deferCallbacks and Its Effect on MIDI-Mapped Controls

[aaronventure]

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.

[Christoph Hart]

@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 the processorId / parameterId attributes.

[aaronventure]

@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)?

[Christoph Hart]

@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.

[d.healey]

@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.