Live coding MIDI with BopPad and sensory percussion

Hi all, so the idea came yesterday from a drummer, who asked me if I could live-code sounds in SC that he could trigger via midi live (IE I make the sounds live and he plays them). He uses a BopPad by Keith McKillen and Sensory Percussion by sunhouse. A few problems arose.

The first problem is that I’m on Linux (Manjaro), so the editor for these controllers is not available, and I’m still not 100% fluent with Jack/ALSA midi.
I ran “MIDIdef.trace” anyway to see what messages came from the BopPad (I haven’t tried with sensory percussion), it just received the midinote 62 and a bunch of control messages. We also tried with the web editor, but SC couldn’t see the changes that we made (for example different notes for each quadrant) and kept receiving the same data. Is there a way to make SC see those editor changes? Or to maybe change the behaviour of the controller directly from SuperCollider, IE treat SC like a MIDI editor? Maybe with a sysex? (After all, all controllers come as sources AND destinations, and I saw Eli Fieldsteel briefly mention this possibility here around 10:30 mark https://www.youtube.com/watch?v=FVz2vzsZAbs)
OR maybe just keep everything the way it is and try with fancy if statements?

The second question is: even if the controllers are fully capable of comunicating, which would be the safest way to live-code? Just use MIDIdefs and live-code them, IE live-code the SynthDefs that I store in the MIDIdef? This works with my keyboard btw…
I also saw a class called “NNdef” by Miguel Negrao which handles Functional Reactive Programming together with UGen graphs, but it uses the Modality toolkit and the controllers that we use are not supported. I haven’t dug deeper into MKtl, but is it possible to add my own controllers to the list?

Thanks very much in advance. Hope what I wrote makes sense.

The same is in: “every bit is exactly the same” or the same as in “just a bunch of meaningless numbers”? (In the latter case, the meaningless numbers probably contain the information you are looking for).

The problem with sysex is that it is not standardized, so every manufacturer can use it as they please, encoding information in whatever format they fancy (as long as it obeys the constraints that midi itself imposes).

If you cannot locate sysex reference documentation for your device it will be very difficult to make progress. In some cases it’s possible to reverse-engineer sysex by painstakingly changing small details on the device and systematically analyzing what the device sends out, but if you say you cannot see any differences in information from the device there’s nothing to start from.

Taking a look at the manual, apparently there’s a web editor which may be worth a try in a browser that supports webmidi (e.g. chrome): BopPad Editor | Keith McMillen Instruments