OK it's now clear that a M4L device can't do MIDI routing in Max. I've decided to stick with Live & M4L, especially because it's widely expected that they add MPE support this year with the release of Live 10. So: using Live's limited MIDI system with M4L devices:

It seems the only method to getting that data from each note is to make a 10+ MIDI channels (as many voices as I want to be able to use simultaneously), and put in each of them a M4L Midi Send device using the [send] object, each which routes note input info to corresponding [receive] objects in my synth. I could then have my [poly~] voices each individually handle things like note pressure, y-axis movement, etc.

I'm wondering if anyone has an example patch of this, or advice? Thanks in advance!

Alright I've built a little M4L midi routing device that gets 10 voices of MPE data into my synth. Screenshot attached--it works fine. If anyone has any experience working with MPE synths in Max or M4L, I'd love to hear about it!

Here is how the routing in the above screenshot looks like inside my patch. Does anyone know if multiple inputs in this way will confuse a [mpeparse}?

Perhaps not coincidentally, since I started using this method, and using [polymidiin], my synth can only play 1 voice at a time :( A tutorial demonstrating these new MPE objects would be much appreciated.

I think the send/receive objects are not needed at all since you could use the routing of a *multi-timbral instrument* as explained in the Live manual, chapter 14.6.2 'Making Use of Internal Routing'.

Hey Broc--thanks for the suggestion. I read the manual, but my set-up though is all about live-sampling, it's a granular synth that can record a new sampling buffer on the fly.

For that reason, I put my sampler-synth in a audio track and route the MIDI performance data from MIDI track. I could alternatively put it in a MIDI channel and record into the buffer~ in another track, but I feel sharing buffer~ data between M4L devices is more processor intensive than simply sending MIDI data between them (though this is a question of the architecture of M4L).

Can anyone speak to whether I can send in 8 streams of MIDI data into an [mpeparse] without losing speed/efficiency of processing?

I've come to the conclusion, after dozens of hours of tests and patch edits, that there's probably something fundamentally wrong with the above M4L routing. Sending MPE data through separate LIVE channels using the [send] object in each, to be received by a corresponding number of [receive] objects in the M4L audio object DOES NOT seem to work. The patch that receives the MPE midi data becomes monophonic.

It seems like the result is this: however many voices the poly~ is supposed to be able to play (e.g. 8), it ends up playing all of those voices (e.g. 8) on the latest note to be hit.

I would love to see some tests done by someone else, to see if they could successfully route mult-channel MPE data in Live to a Max synth.

Actually, it's probably not the problem of the routing, it's something with M4L and mpeevent messages. If I run all 16 of my MPE channels into my 1 M4L device, they work as long as I use [mpeparse] to only send my poly~ object note-on and note-off messages.

If I use the last outlet of that [mpeparse] to send poly~ mpeevent data, then suddenly is doesn't work in M4L, though the identical set-up will work perfectly in Max.

If you are sending/merging multiple streams of raw MIDI bytes, the receiver may not recognize correctly the bytes that belong together as messages. So I would pack the bytes on the senders into MIDI messages (notes, CCs) and unpack on the receiver side.

Hey Broc--thanks for the reply. Here's the thing: if I send my poly~ just ONE note on ONE mpe channel using a send and receive object, then it still activates all 16 of my poly~ voices. And this is only if that data is sent to poly~ in mpeevent format--if poly~ receives the data in midinote format it works fine with all 16 send/receive objects.

Further reason for thinking this is a M4L bug: the PGS1 MPE device doesn't doesn't play polyphonically in M4L. It's an .amxd file, and works fine in Max, but no matter how you try routing the MIDI in Live--using the *multi-timbral method* outlined in the Live manual and on the ROLI website, or by using [send] and [receive] routing... nothing works! It has the same issue in M4L--every voice available gets used on the first note that is played.

Here are two super-simple devices that one can test this phenomenon with. I'd be so grateful for any advice!

MPE MIDI Sender for M4L

Super-Simple MPE Synth for M4L

Re MPE Sender: Keep in mind that [midiin] of an M4L device does not reflect the track input channel but will always use channel 1. So I think you need to set the corresponding channel explicitly for each sender.

GENUIS! Thank you Broc, I so appreciate that. This seems to be a long-running issue with Live. I will try this on my ROLI when I get home. Here's the revised M4L patch:

Alright using [midiselect] definitely didn't work. I've tried using the live.object, which I thought would definitely work, but it doesn't seem to either :( Can anyone take a look and give some suggestions?

[midiselect] is not useful here as you need to set/change channel info of the midi data. Try using [midiparse] and [midiformat] to construct new messages with the corresponding channels.

Agreed--any thoughts on the live.object method I just posted?

Your method with the Live API should basically work, but I think you want instead to *get* the current_input_sub_routing of the track.

I really appreciate it! Here's a tester MPE synth patch

For testing I suggest to put 'print' on the mpeparse output to see what actually arrives there.

Uhoh... it seems the MPE voice number for all my notes (3rd digit in the mpeevent data) is -1... is this a limitation of Live?

No, it's the same in Max when sending notes on channel 1. According to the MPE specification channel 1 is used for global messages and channels 2-15 are "per-note" channels.

You know I think 3rd digit in the mpeevent stream is our culprit!! I'd been analyzing the mpeevent data streams coming out of my Roli (see the other MPE forum thread) and that's how MPE voices are assigned to polymidiin.

I did a little workaround that gives each of our MIDI channels one voice for poly~, I don't know what'll happen if I ever get more than 16 voices, but it works for now!! Really appreciate your guidance in figuring this out.

BTW, following your idea of using the Live API I've made a patch that automatically reports the track input channel to the M4L device on that track, thus working around the limitation that Live doesn't pass the track input channel.

NB. The LOM documentation still refers to an old/deprecated version of the track I/O routings. My patch uses the new version which is a bit more complicated but generally more powerful.

Extremely cool Broc! It took me a while to figure out what this patch was doing, but that's very handy and elegant. I'll gratefully add this to my M4L MPE project :)

I'm wondering--is my workaround in using [zl nth] to manually reassign the mpe voice number necessary?

I realized that the mpe VSTs like Equator work just fine in Live, so long as you use multiple tracks and get the MIDI routing right. So using the Live API to properly assign the MIDI routing, shouldn't we be able to get accurate mpe voice numbers?

(I want to use objects like [mpestartremap] in my synth to process raw MIDI, but under this set-up I can't.)

I've attached my current patch with (Broc's API improvements incorporated), would be interested to hear thoughts.

I have no experience with MPE and thus can't help with the details.

But my patch is independent from MPE and it seems you didn't understand its purpose. Just to clarify, the patch observes the track input channel and reports its number to the M4L device in that track. So it can be used to replace manual selection within the device. The attached patch demonstrates how choosing the track input channel is reflected in the device.

Holy smokes you're right I've misunderstood. But I think I get it now.

To recap: M4L devices can receive data from any MIDI channel, no fancy Live API workarounds needed. However, once that MIDI data gets into the M4L device the MIDI channel information is stripped away, and will be processed as arriving at Channel 1 (even if it came from elsewhere). Your API workaround allows us to get that "elsewhere" information (which MIDI channel the data *really* came from). We can then re-assign the MIDI channel in Max manually if need be. Rad!

Yes, exactly!

hey guys just saying interesting read i am getting a roli tomorrow and am looking into ways to incorporate MPE into ableton... will be getting into this soon. or pay someone to do so haha.