I knocked up this draft of a simple Max For Live utility device last night, and thought it might be worth sharing: it uses send & receive pairs and Max’s maxtrixctrl & router objects to route 8 separate streams of MIDI information between different places in Live, with an 8 x 8 button grid as a matrix, allowing you to send any combination of the 8 inputs to any combination of the 8 outputs.
This means you can route MIDI signals dynamically between monome apps, Live MIDI clips, software synths and external hardware without having to dive into Live’s input/output routing panels. For example: if you have a MIDI sequence running from polygome to a modular synth, you can re-route that sequence to a drum rack, then combine different sequence from two other Live MIDI clips and send them to the modular instead, all with a couple of button presses.
There are 3 max for live MIDI effects in the zip file: an input device, which goes after whatever you’re using to generate MIDI information, whether that’s a MIDI clip, another monome device like polygome, or an incoming sequence from an external sequencer; an output device, which goes before your software instruments or MIDI outputs to external hardware; and a router device, which maps to an 8x8 grid via serialosc (also has autofocus). There’s a grid on the router device so you can use it without a monome grid if you want, too.
I hope that all makes sense! Let me know if you find it useful.
(Quick edit: I stupidly used Max drop-down menus rather than Live ones, so selections didn’t save when re-loading the Live set. Now corrected)
This is fantastic. I don’t currently have a use for it, but it seems like an incredibly interesting tool with lots of creative possibilities! Thanks for sharing.
Thanks all… one thing I’ve discovered since posting is that M4L’s send & receive objects (possibly all M4L devices?) are not subject to Live’s plugin delay compensation. This means that routing signals via send & receive causes small but occasionally noticeable timing jitters.
I don’t find the effect unpleasant to be honest (the slight wobbles in sync sound very human, or like using James Holden’s excellent Humaniser plugin) but your mileage may vary; certainly if your music requires absolutely precise timing for MIDI sequences then there might be something of a trade-off between that and the signal-routing flexibility offered here.
Has anyone come across similar issues before? Any suggestions on how to get around it?
It’s funny, the matrix router must be in the Zeitgeist, I’ve been working on ocTOMaTRIX for the past week or two (and not much else as far as spare time). Looking forward to checking this out too, looks super useful.
Re: timing issues, just looking at it in Max without time to test drive, could you use int or zl.reg objects to store upon send/receive but then trigger with a separate (tempo-synced, therefore delay compensation immune?) object? I guess the delay compensation is probably heavier on the instrument i.e. downstream side so that probably wouldn’t help, unless maybe store / trigger is in MIDI Matrix out? still don’t know if it’d solve anything.
I’ll enjoy playing with this when less sleep-deprived - thanks for building and sharing!
@ehg
hi ! that’s un super usefull & fun utility ! i would love to see some presets management things
i don’t know if it’s only me but when i route the input 1 to output 1 with the top left button lit i get no midi data. then when i set receive from matrix output 2 i get something.
instead of using send/receives, u can try setting the midi in / out on a track through the live api (check out the LOM). there’s also udpsend / udpreceive, not sure what the latency would be like.
@i_morgendoerfer thanks for spotting this! Updating the drop-down objects caused their numbering (which starts from 1) to fall out of step with the list index within Max (which starts from 0)… hence when you select output 2 you actually hear output 1. I’ve uploaded a corrected version of the patch above.
@elquinto thanks, so it seems the send / receive latency is unavoidable! I tried re-coding the devices with udpsend & udpreceive pairs, but that caused even more latency. I don’t think using the api to control Live’s in/out routing would give you quite the same flexibility to combine multiple inputs or split inputs to multiple outputs at will.
If you put a Time device immediately after the Matrix Out device, that helps reduce the timing jitters to a slightly more acceptable level.
there’s also this ‘vt’ max external which acts just like send/receive, but doesn’t have the latency issue when communicating across devices in m4l. (it’s mac only though)
@ehg work fine now. Thank you ! and i’d like to say that i really like the “groove”. And as you said thanks to the Time device you can get more “controle” on this. I’m actually using it with MarkEats Seq and they’re pairing very well.
Good evening. I have started using MIDI Matrix and I really like it! Great utility! The only issue I am having is autofocus does not work.
When I switch to and from remix my 128 completely disconnects from MIDI Matrix and I have to hit reconnect every time. I will try and fix it. I don’t know max much at all but I’ve had some success messing with autofocus on other patches.
Anyway, thanks for the cool patch!
Edit: I got autofocus working nicely. If anyone is interested in the revised patch let me know.
@i_morgendoerfer,
Give it a try. I didn’t use it with the other components of the patch yet (it was late when I finished up) but it seemed good to go. I’ll try it out in a few hours.
i managed to get around the latency issues managing almost sample accurate timing with midi routing by giving the max for live device that receives the midi notes a 512 sample latency and transmitting the exact transport time with every midi event from the sender device.
this allows me to use live’s delay compensation to delay the received midi notes and send them out at the exact moment using max’s pipe to delay the notes.
this adds an overall latency to live’s delay compensation of course. but you get rock solid midi routing.
