Wishlist: Simple MIDI Routing/Midi out functionality

[rob]

Someone please tell me if I'm being annoying by submitting all these wishlist items... I'm operating under the assumption that passing ideas along as they occur to me is not a bad thing, but I can easily see how it would be annoying.

Anyhow, I was thinking that controller scripts might be able to accomplish some simple midi routing by just connecting the midi output for that controller (which is created in order to send sysex messages back to the controller to light LEDs, etc.) to another program, and then sending midi messages out using midi.sendShortMsg on a channel that the controller doesn't listen to. This would theoretically allow controller scripts to send midi messages out to control other software, effects, etc., or to simply route incoming control messages for a given button or slider through mixxx and out to another program.

But when I tried to test this idea by connecting the mixxx output to a midi monitor in Patchage, it seems that the mixxx output refuses to connect to anything other than the controller it's linked to.

I think it would be useful to do any or all of the following:
- allow the mixxx midi outputs to connect to anything (assuming my midi.sendShortMsg idea above would work, I think this would be all that would be needed to hack together midi routing functionality in script.)
- implement mixxx functionality (ie: a mixxx control, and/or script function) to send midi messages out of a dedicated mixxx midi out port (or ports) separate from the controller out ports.
- implement "direct passthrough" functionality - so that MIDI mapping xml files could specify that certain controls should be routed through mixxx and out on a certain midi out port, channel, and note (or cc) number - this would allow simple XML only mappings to route controls without having to use any scripting.

[rob (another-rob)]

This would leverage the fact that Mixxx has already implemented a fairly robust MIDI scripting system - most software (at least on Linux) doesn't have any scripting functionality built-in - you might be able to map controls, but there's generally no ability to do anything more complex than a direct mapping.

Conceivably, complex functionality could be scripted in something like Mididings, and then routed to Mixxx as well as to other software, but then Mixxx wouldn't benefit from mappings that could be easily shared with the community. By providing MIDI outputs, mixxx might be able to attract more users and script developers by allowing the scripting interface that's already been created to be used as a relatively accessible programmable midi router.

...and, in case it's not clear from my initial post, in addition to simply passing through signals from a physical controller, mixxx scripts could generate their own midi messages, possibly based on characteristics of the song that's currently playing - triggers could be sent to external samplers or effects based on song tempo, etc...

[RJ Skerry-Ryan (rryan)]

Please keep the wishlist bugs coming :).

I think Mixxx works fine with virtual MIDI ports but if you load a script for a particular device (e.g. a physical controller) then that particular script can only send/receive to the physical device. If you load a script for a virtual MIDI port then the script can only send/receive from that virtual MIDI port, etc.

[rob (another-rob)]

Not sure if I'm understanding you - by "virtual midi ports", do you mean mixxx ports opened by scripts for anything other than a physical controller? (Like accepting input from a sequencer or something?) If so, I've tested that, and yes, mixxx works fine with those ports...

What I'm proposing above would work fine even if the script could only send through the mixxx virtual midi port it's linked to, but the way things are now, it seems that port will refuse all connections except to the controller it's linked to (ie: you can't connect an arbitrary piece of midi software to that port in patchage). If mixxx were changed so that the mixxx script outbound ports could accept any arbitrary connection (in addition to the default outbound connection to the linked controller), then (I think) mixxx scripts could send arbitrary midi messages out on that port (on a channel that the hardware controller doesn't listen to), and those messages could be received and used by other midi capable software.

I'm speculating, but I imagine enabling arbitrary connections to the mixxx outbound script ports would probably not require a huge change to Mixxx... Easy-ish fix?

A more ideal, but undoubtedly more complicated solution would be to allow scripts to open arbitrary dedicated midi ports and send messages out of those ports (maybe allow different controller scripts to send to/access the same dedicated ports?). Then the user could manually connect midi capable software and devices to those ports using Patchage or something, and those connected devices could do whatever the user wants with the midi signals they receive...

...basically, it occurs to me that Mixxx's midi scripting interface is pretty unique, at least in Linux. (it's pretty easy to use, and there aren't a lot of accessible midi scripting options - mididings comes to mind, but other than that...) I've been able to really extend the capabilities of some of the controllers I'm working on scripts for (making one set of buttons function as multiple banks of buttons, etc.) Given the fact that a lot of people working with linux will cobble together solutions to problems by using bits and pieces of capability from a variety of pieces of software, it's conceivable that people who don't need Mixxx for its DJ capabilities might wind up using it just for its midi scripting capability... That might lead to attracting more developers working to extend bits of mixxx that aren't core "DJ" functions - maybe working on things like audio sends and returns, effects, adding sampler capability, etc...

...if that makes any sense at all...

[rob (another-rob)]

...and once the arbitrary (non-midi) controller scripting capabilities are fully in place in Mixxx, the attraction for non-DJ's to start using mixxx would increase - if scripts could be written in mixxx to take arbitrary usb controller input, translate that into midi, then send the midi out of an out port to another piece of software, then people might be attracted to Mixxx simply because they could repurpose an old keyboard to control any piece of midi capable software, instead of buying a new MIDI controller.

[rob (another-rob)]

...and, while I'm at it, arbitrary input ports would be useful as well, to allow scripts to receive, track and process sysex (LED lighting state, etc.) messages from connected software. Again, this would probably require significant work though.

[rob (another-rob)]

Oddly enough, a new "controller" mapping was just posted to the forums which seems to confirm that the midi.sendShortMsg idea I outlined above would work. It's a controller mapping that sends output from mixxx to control midi-dmx lighting rigs based around the mixxx tempo, etc. Cool.

see: http://www.mixxx.org/forums/viewtopic.php?f=7&t=4732&sid=fd460a01cdb86303a696c219e2ec8252

So seemingly, this routing thing would be possible, but to make it useful for the purposes I've outlined above, I think you'd have to at least be able to connect multiple controllers to the mixxx script midi outputs. I suppose it might be possible to hack something together now, using a multi-controller mixxx control script, but I haven't experimented with those yet, so I'm not really sure how they behave.

[Sean M. Pappalardo (pegasus-renegadetech)]

Mixxx currently uses the PortMIDI to communicate with devices. On Linux, it uses ALSA's MIDI subsystem which offers the virtual port. Have you tried using JACK's MIDI capabilities? That should expose more software ports for Mixxx to use any way you like.

[RJ Skerry-Ryan (rryan)]

Yea -- that's right. You can both receive and write MIDI messages from virtual MIDI devices. It works just fine and there are a number of presets that do that today.

Unfortunately, the way Mixxx's scripting system is designed every MIDI device has an isolated Javascript engine dedicated to it. This enables things like loading the same preset to multiple devices. If you have two SCS3d's then you can load the same preset to both of them and the script does not get confused about which one it is talking to because they are both totally isolated from each other.

This is for UI reasons as well -- the user needs to pick which device they want to load a preset to in the preferences. It would be a little confusing if you just loaded the SCS3d preset without specifying a device to load it to. Especially given that if you have 2 then you need some way for two separate instances of the SCS3d preset to be loaded and attach the two to different SCS3d's somehow.

I think it's unlikely we'll get to the point where single script environment can address multiple devices. It would take a lot of work at least. A hack /could/ be made... especially since as of Mixxx 1.11.0 devices are all in the same controller thread now (this was not the case in earlier versions of Mixxx).

One thing we do have plans for is to allow scripts to communicate with each other either via message passing or using the control system to create common shared controls they can pass values through. This way you could create a preset that attaches to a physical device and then send messages to a preset that controls a virtual MIDI device to have that virtual MIDI device send out a message that does something in the real world (controls a light, moves a motor, etc.).

I realize it would be really nice for tinkerers to use our MIDI script environment if it was easy to address multiple devices but really that's not what this system was designed for (nor is it really the use case it's intended for... it's main purpose is just to facilitate communication between Mixxx and a device).

Maybe this would fit better in the context of a general scripting system for Mixxx -- one that isn't associated with a particular MIDI device.

[rob (another-rob)]

Sean, on my install, mixxx exposes several ALSA midi in and out ports, currently 6 on my system, called "port-2" through to "port-7" (mixxx always shows ALSA midi ports for me, whether Mixxx is run using Jack or Alsa audio). I currently have three controllers enabled in Mixxx, those are connected to three of the mixxx midi ins, and 3 of the outs, as expected. But none of the mixxx midi ports will accept manual connections - if I try to manually connect a software or hardware midi port to mixxx in Patchage, the connection is rejected. If I wanted to, I could "enable" another controller from within mixxx, and that would connect it to one of the midi ports, but that wouldn't accomplish what I was proposing above.

I don't need mixxx to handle the additional manually connected controller, or even to be aware of it. All I'd need is for the mixxx alsa midi ports to accept connections to midi controllers other than the one "enabled" in mixxx - ie: one out port would be connected to the "enabled" controller, but also could be connected manually in Patchage to any other midi controller or midi enabled software... Then, midi messages sent out that mixxx port would be sent to all connected controllers (or software). If the message sent was on a midi channel that the "enabled" controller doesn't listen to, then the "enabled" controller wouldn't notice the signal, but other manually connected midi enabled software could be set to listen and respond to that signal.

Tough for me to guess how much work would be required under the hood in order to enable manual connections, but I would have assumed it wouldn't be that difficult - Mixxx itself wouldn't have to do anything with the manually connected devices, they'd just be listening for messages sent out that midi port... Any midi device(s) attached to the output port for a controller script would "hear" all the midi.sendShortMsg messages that the script generated, whether Mixxx (or the script) was aware that something was connected or not... All mixxx would have to do is allow them to connect.

Mixxx is unusual among the midi software I use anyway, in that midi devices are connected via the preferences window rather than manually in a program like Patchage... Other software just exposes one or more in and out ports and listens and sends to anything attached to those ports. I haven't run across any other software that rejects manual Patchage connections like Mixxx does.

Anyway, assuming you guys understand what I'm trying to say, then I'll leave this one alone - but I want to make sure you understand, since it seems to me that this would be a relatively easy tweak that would allow a lot of additional functionality without really requiring much by way of internal changes to mixxx. Of course, I could easily be wrong about my guess that this would be "easy"... Haha.

[rob (another-rob)]

Here's a screenshot of my setup as seen from Patchage... (weird, never noticed this before, but I have two scs.3ds and two kontrol one's, but they're only showing as one of each for some reason... anyway...) (Thanks, sean for the scs mapping, btw - it's pretty great.)

If I try to manually drag a connection from mixxx (aka "Client-130") port 6 to my Midi monitor, for example, the connection will fail. Same thing will happen with any other mixxx port. Any other midi device or software I have, I can just drag a connection to the midi monitor (or to any other alsa midi device) and the connection will work fine.

[Sean M. Pappalardo (pegasus-renegadetech)]

As I said, Mixxx just uses the PortMIDI library to discover and communicate with devices. If it's not behaving as other apps do, then I would suggest you file a bug with PortMIDI here http://sourceforge.net/apps/trac/portmedia/report Though they don't seem to be responsive there, I would still file it there for the record, then post to their mailing list for discussion.

[Daniel Schürmann (daschuer)]

Depends on Bug #1198163
Project is on hold due to other Tasks with higher priority. So any contribution is very welcome.

[Chloé AVRILLON (chloe-avrillon)]

This "missing" feature is really annoying.
It is impossible to use Software Midi devices ccommunicating with mixxx, or one controller for input/one for output (= 1 port for input/1 for output)
Mixxx impose the same Midi port for input and output, wich us totally out of today's uses.
Different Output and input port should be possible for the same script. Mixxx logic consists in attaching a script to a port, but instead it should je selecting à script then attaching to it an incoming port plus an outgoing one (should be the same - a dedicated controller for instance - or not )

[Swiftb0y (swiftb0y)]

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