gtz max runtime midi thing (channel mapper)

  • This is a fairly straightforward widget. Play notes on a MIDI controller, and the overlap gets mapped to separate MIDI channels. No big deal.

    It's the subtleties that make this worthwhile:

    * Mess with your pitch bend, and it affects every channel there's a note playing on.

    * Same for CCs.

    * Pitch bend cleans up after itself (to stop you from knocking one note out of tune and leaving it there).

    * CCs try to do the same, but will likely fail at that if you're using more than one of them.



    Open this in the max runtime. (It won't work natively in M4L)

    Plug in a MIDI controller, and select that as your MIDI input.

    Set up a virtual MIDI cable ("from Max" / IAC / MIDI Yoke / LoopBe etc) and select that for MIDI output.

    Press and hold a note on your controller. That note is forwarded along, but explicitly routed to channel 1.

    Without releasing, press and hold a second note. This one's on channel 2.

    Press and hold a third one; it will be on channel 3.

    Release the first note. The next note you press will be on channel 1, because that's now open. But if you release no other notes, the one after that will be on channel 4.

    (Configure a series of MIDI instruments in your DAW, each set to receive the signal from your virtual MIDI cable. Limit each of those to one midi channel, in ascending order.)


    This is probably obnoxious beyond words to set up on PC, but I discovered yesterday that the problems I'm used to working around just don't exist on my Mac.

    The issue I'd have is that Max and Live couldn't access the same controllers simultaneously. In order for Max to see a controller, I had to edit Live's preferences and disable the controller there. I also had to disable half of the virtual MIDI cable in Live, and the other half in Max. And then remember which cable I'd set aside for that purpose.

    (Of course, if you wanted to use that controller in Live without your Max patch for some reason, you'd have to break that relationship by re-enabling it)

    On my mac, however... Not only can the controller be active in both packages, I can receive and use data from it in both concurrently.

    So, there's that.

  • What is this good for... I think you'd be wise to keep it subtle.

    It was really designed for larger orchestral libraries, where you've got a different set of samples for individuals within a section. Rather than play the first violin part and then the second, why not play both simultaneously?

    I'm loving it for plucked instruments w/ short decay times, or percussion.

    This would be better in video, but what I've got mapped right now is:

    * channels 1 and 2 are a banjo, with a pretty dry signal.

    * channels 3 and 4 are a banjoele (whatever that is), with subtle ping-pong delay.

    * channels 5 and 6 are harmonics (harp, not banjo), with lots of reverb.

    They're organized in pairs for easier control -- it's hard to avoid switching channels in a melodic line, and this hides a lot of mistakes.

    I haven't tried this for finger drumming yet, but you could conceivably have five or six drum racks, and develop your performance technique to control them all with the same pads.


  • woah yea! this is exactly the kind of widget i was looking for (allocate multiple simultaneous midi presses across multiple channels). i'm going to experiment. thank you.

  • Cool.

    I actually figured out a roundabout way to do this in m4l yesterday. If anyone cares, I can post that in the morning.

    That one works in reverse -- you add an instance before each instrument, and tell it which MIDI allocation numbers should be allowed through. It then filters out every note you didn't choose. No runtime, no channels. And you can apply it to the output of MIDI clips, or apps such as "flin" or "blinken park". It's less intuitive, but probably more versatile.

    Again, I should make a video...

  • By finding a way to do this in m4l, you mean to deal with more than one midi channel at a time? If this is so, im very interested!

  • how does the m4l version avoid utilizing midi channels?

  • @dean,

    Probably not at all close to what you're asking.

    I'll make a demo of the workaround for that, but it introduces some unpredictable amount of latency and requires hacking the apps you want to send multichannel output from.

    (if you want to send multichannel output from one m4l device into a multi-instrument VSTI, it's even more complex, but probably doable)

    @away message,

    The max runtime version takes one input and creates multichannel output. In your DAW, you then assign tracks to receive each channel.

    The m4l version, each track takes the same input, but filters out everything except what it would have received from the other setup.

    Same end result.

    In both cases, your initial MIDI input could be a controller that you're playing in realtime, or the output of some other app. (I thought that last part was unique to the m4l version, but forgot we can send virtual MIDI cables into the max runtime.)

  • m4l version attached, thereby making this thread poorly named and stuff.

    Heck, the app itself probably needs a better name.

    (this is not the demo I mentioned to Dean in that last reply; it's the device I described to Away Message)

  • Also, confirmed that the max runtime version does indeed work in the free max runtime. (I had only tested it in full max/msp before)

    In testing that, I found that the virtual MIDI outputs that come with Max have different names in each of those environments ("from max" vs "from max runtime"), so I had to reassign all of my tracks, which also meant reassigning the channels for each. That was sort of a pain, but it was also a strange and specific circumstance that most of you will never encounter. So the fact that the max for live version avoids that completely isn't all that important.

  • Dean:

    Attached is a simple MIDI device with two onscreen keyboards. Each has a channel selector sitting next to it. Assign those to 3 and 4, let's say.

    Below those, there's a device ID input box. Ignore that for now.

    Also attached is a receiver device. Add that to a MIDI track, give it channel 3, and put an instrument after it.

    Add another copy to a different MIDI track, give it channel 4, and put a different instrument after that.

    Go back to the first device w/ the onscreen keyboards. Click on the keys -- the appropriate instruments should sound.

    Change the channel selectors to 5 and 6. Play notes. The instruments ignore you because they're listening to 3 and 4. Make those match again.

    MIDI gives you a total of 16 channels per port, so the "device ID" box is basically a port selector. each number (0-255) selects a different bank of 16 channels. Match it on your instruments.

    If you've got apps that supported multi-channels in the runtime but didn't port right to max for live, there are instructions within the listener object as to how you'd adapt those. Examples are provided for all of the MIDI output objects I could think of which Ableton supports (and one that they probably don't).


    NOTE: This is largely untested and probably doesn't work.

    In particular, I'm concerned the "don't let notes get caught when the user changes ID or channel" safeguard I built into the receiver actually belongs in the app that you're sending from.

    At this stage, I'd consider it a version 1 beta experiment. But definitely mess around with it, see if we can't identify and fix all the problems.


    Also note:

    This won't give you sample-level precision by any stretch. There is latency. Every event is getting routed through [send] and [receive] objects, which are notoriously inefficient.

    We could fix a lot of that by sending and receiving over udp instead. But that starts getting into this realm:
    ...and I didn't want to go there today.

  • Also possible that isn't at all what you were looking for.

    Perhaps you've got a VSTI Multi plugin, such as Kontakt Player or Aria, and it supports loading different instruments on different channels. How do we control those?

    It's a bit stupid, but make a separate MIDI track for each of those inputs. For each of those:

    * Open the "MIDI To" drop down in your track I/O and select the track housing that.

    * A second drop-down becomes selectable just below this. Pick the appropriate input.

    Those individual MIDI tracks behave as normal; you can record and play back MIDI Clips, add apps and devices inline with them, etc. But the output at the end of the chain goes into that VSTI, on the channel you specified.

    Don't put an instrument or any audio effects directly on those controller tracks; that will terminate the chain before your signal reaches the VSTI.

  • (I would be so happy if I could figure out how to create multi inputs like that on a m4l device...)