using multiple midi devices

    Dec 14 2009 | 11:50 pm
    I'd like to use multiple midi devices in a patch, as a combined control center.
    If I try to use the standard max midi stuff, then that works in preview, but stops working once the device is back in live.
    If I try to use send and receive [edit: between a normal max patch, so I can use the midi device], then again, it works fine in preview, but stops as soon as the device goes back into live.
    Do I really have to use OSC to route stuff out of max and back in again? That would be horrible!
    Am I missing something obvious?

    • Dec 15 2009 | 3:33 pm
      I'm not sure what you're trying to achieve but here are some facts.
      1. Max MIDI devices in Live have only one input and output.
      2. Send/receive works in Live for communication between patches/devices just like in Max.
      However, in contrast to Max standalone the timing of send/receive within Live is not accurate. I've measured latency/jitter in the order of 10 milliseconds. So basically it can be used only for control data but not for notes. Unfortunately, the timing problem exists also with OSC.
    • Dec 15 2009 | 4:02 pm
      What I'd like to do, is setup a big patch to control Live based on the inputs of several different midi controllers, and it looks like that isn't easily possible. It's made a bit more confusing by the way that some things work when in preview mode, but not within live.
      The send/recieve thing confused me, as it'll work fine between two Max patches, and patches running inside Live, but not between Max and Max4Live patches: if you press the edit button on a patch running in Live, then it'll happily recieve from a "native" max patch, but that disappears when you close it and revert to running in Live.
      It's a shame to hear about the jitter, but I can live with 10ms as it's mostly control data. I guess now I have to decide whether it's less ugly to
      - make a M4L device for each control input, and give them their own channel, and send it round inside M4L - separate controllers by MIDI channel, and have one M4L device which separates out all their control signals - do some OSC routing from a plain-Max patch
      Ironically, this was all much easier before using M4L, except that I had to manually MIDI map hundreds of knobs and clips.
      Now I'm wondering about writing mxj MIDI objects. Hmmm...
    • Jan 18 2010 | 11:55 pm
      So, I've now found that option 2 above doesn't work, as Live maps all the midi data onto the same channel.
      In the end, I went the MXJ route, and made wrappers for java's midi stuff. You can find it at:
    • Jan 19 2010 | 5:48 pm
      Hi Mo-Seph,
      Pardon me, but I couldn't find the jar file at the end of your blog on MXJMidiDevice.
    • Jan 19 2010 | 8:37 pm
      Clearly I need to sort out my web design! It's just after the "Technorati Tags" section, under Installation.
    • Jan 19 2010 | 8:51 pm
      Oh no, my bad - it's now properly linked in the post.
    • Jan 23 2010 | 8:00 pm
      Building on mo-sephs idea, I have implemented a set of mxj objects that try to be compatible to midiin/midiout/midiinfo. They allow you to access MIDI devices from M4L patchers directly. I'm using it to map my control surfaces to partially generate notes that are sent to Live or to control Live directly. The external and a demo patcher is available here:
      I have tested this lightly on Windows. Suggestions, bug reports, enhancements would be welcome.
      Cheers, Hans
    • Jan 24 2010 | 10:12 pm
      Channel information is useless in Live, as mo-seph discovered.
      What I've been doing in place of that is to just encode my own channel info, and watch for that on the receiving end.
      (ie, pack the value of a live.numbox in with your MIDI data so the object receiving can route MIDI appropriately. The user does have to set those pairs manually, but they're saved with the Live document.)
      The nice thing there is that you're no longer limited to 16 channels. It's a little more work, but a lot more powerful.
      Very curious about Hans' solution. Will check that out!