catch-all midi mapping

[sb]

For script-heavy mappings, it would be nice if all messages can be diverted to the script. This way, listing all controls in the XML config would not be necessary anymore.

It could be a defined method on the script object, say controllerMessage(), like there is with statusResponse() for SYSEX. Another option would be to allow wildcards in the config:

 <control>
  <key>somecontroller.receive</key>
  <status>*</status>
  <midino>*</midino>
  <options>
    <script-binding/>
  </options>
</control>

Personally, I'd prefer just having the script be called directly, without having to add a catch-all control. But in the end the difference would be small. It's not an important feature. Listing all the controls in the XML is inconvenient but no big issue.

[Be (be.ing)]

It could also be useful to specify a range for midino. For example, many controllers have a series of 4 or 8 buttons in a row that could be mapped to one script function with one <control> XML element.

[sb (sb-c)]

> It could also be useful to specify a range for midino. For example, many
> controllers have a series of 4 or 8 buttons in a row that could be
> mapped to one script function with one <control> XML element.

Maybe that would be useful in some scenarios. In my case it would not
be necessary because I'm using a dispatcher function anyway. I can
already do this with SYSEX messages, no?

SomeController.statusResponse = function(message) { /* handle SYSEX */ }

now I would like to generalize this to

SomeController.controllerMessage = function(message) { /* handle message */ }

If Mixxx could call this method (when it's defined) it would be the
easiest option. It could be made explicit by having a stanza that
diverts all messages like the example in my bug description, but that
would actually complicate matters as far as I'm concerned.

[Sean M. Pappalardo (pegasus-renegadetech)]

Implementing this would basically be the same as what HID does now. We could make the MIDIController class default to this behavior if there are no <control> elements in the XML.

[Daniel Schürmann (daschuer)]

We do this already with sysex messages and we found out that this is a mayor CPU burner.
Mixxx is not able to consume all Midi messages from a 3x speed midi device by a script callback using a recent laptop.
I think (We need to verify it) Mixxx is able to consume normal XML mapped messages with 3x speed.
We need a concept which allows it and how to fix the current overflow issue with sysex messages.
If this still involves the XML file, it is an acceptable annoyance for me, since we should take reliability over continence.
Of cause it would be best to solve both issues at once.

[Be (be.ing)]

We will be introducing a new system where all incoming MIDI messages go to JS. This will be a lot of work because we'll be rewriting the entire controller system, so it may be a while before this is implemented.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8055