Good day,
I now use only one module, but if you use more, how is the midi-in routed? To all modules, so that in each module you need to filter the ‘replies’ that did not originate from it before you calculate or map the led index?
Good day,
I now use only one module, but if you use more, how is the midi-in routed? To all modules, so that in each module you need to filter the ‘replies’ that did not originate from it before you calculate or map the led index?
Yes, this is the case currently. The MIDI-RX lua APIs are currently being reworked to use a more flexible callback based architecture so expect changes in this area of the firmware.
For now the easiest way to handle RX would be to:
Now, there is a pre-defined calculation of module position etc to midi ch/cc/note, that I tweaked for my own prupose.
Maybe standard functions that work both ways (mod/profile(1…4)/num >> ch/cc/note, ch/cc/note >> mod/profile(1…4)/num) could be provided, that still leave room for shift / bank enhancements that do not overlap with the standard ‘mappings’? Or the other way round, if you would route midi-in with standard calculations, how do we keep enough flexibility?
Explanations are good but examples are better, is there any community configs or piece of code we can get a look?
Edit: never mind, wrong answer to the right question. Next try
What I did, probably this is too simple if you add modules because I ignore the channel in the MidiRx.
The use case is a start track for a DJ app. The respond is on a different channel, but same CC with a status value, 0 or 127, that I use to control the led belonging to the button. The num calculation in MidiRx for the led is the inverse of the id (CC) calculation for the button
Button midi send:
Midi Rx: