It would be great if we could also record sysex sends from midi devices within the MIDI mapper’s learning mode.
For example, the Korg M3 sends sysex messages instead of midi cc#s on some buttons and some modes. The full potential of the Korg M3 as remote controller could be only achieved, if there is sysex support for automation.
It’s enough, if sysex records only work for one-shot-operations, not value changes. Maybe this would be too complicated.
I’m not a Renoise developer, so I can’t speak on their behalf. But my own (limited) experience with hardware that send sysex is that it’s hard to come up with a clean-cut model for mapping sysex to parameters - how the data is formatted differ widely between manufacturers.
That said, there are some standards, or perhaps practices, that are followed. For example, it’s quite common to couple sysex together with standard CC messages to expand the precision/range of parameters.
As for one-shot vs. value changes, this isn’t really the deal-breaker. The challenge is to understand (and not misinterpret) as many different sysex messages as possible.
Several tools have been written by members of this community that prove that it’s possible to interpret even the most tricky hardware. One such example is Airmann’s Faderport driver, which he released shortly after the Renoise API was made public. Perhaps cross your fingers that such a development will happen with the M3 as well?
Ok, one-shot sysex support would be enough to use lots of buttons on the Korg M3 imo. I am currently trying to add support for the Korg M3 to Duplex… The Fadeport driver is a standalone tools or also for duplex?
Cool, I’ll help in any way I can, of course. And no, the Faderport is a standalone tool. Would have taken Duplex ages to get to the point he got to in weeks - write something just for a single piece of hardware can have it’s benefits