Max 4 Live MIDI effect - only channel 1?

Joseph Hyde's icon

A search of the forums has found some discussion on this, but it's a little contradictory and (possibly) out of date.

Max Patch
Copy patch and select New From Clipboard in Max.

Is it (still) the case that you can only use MIDI channel 1 with Max for Live plugins?
I'm trying to make a little 'round robin' patch that will send notes in sequence to one of 8 tracks, 8 midi channels. Something like this:

- but as far as I can tell, whilst it should change the channel with every note, they all seem to be set to channel 1.

Jdudeo's icon
Max Patch
Copy patch and select New From Clipboard in Max.

You'll need to use send and receive objects with another device on each track you want to send to

Evan's icon

Each track in Live can only deal with one channel in (or all channels) and one channel out , so it's more a limitation of Live than of M4L. You can send any channel you want into and out of the device, you just can't deal with multiple channels. It is a drag.

broc's icon

> Each track in Live can only deal with one channel in (or all channels) and one channel out...

Yes, but there is an exception for multi-instruments. So if you have an M4L *instrument* device on a track it can receive multiple separate channels provided that they are sent from different other tracks of the Live set.

Joseph Hyde's icon

Thanks everyone for clear answers. Broc, that's particularly good to know. Unfortunately I specifically want to send to (rather than receive from) multiple channels. I guess this is not possible due to the limitations in Live, but I've managed a weird workaround anyway - I'm basically using program changes as though they were MIDI channels. Clunky I guess but it works.

Jdudeo's icon

you can do it easily with [send] and [receive] just check the patch I posted

broc's icon

[send/receive] is generally problematic for time-critical data like notes because such extra routings are not included in Live's plugin delay compensation (PDC). So depending on your actual configuration the data may be received a bit too late or even too early. I find the workaround with program changes quite clever as they are sent via standard routing which ensures perfect timing.

Joseph Hyde's icon

Yeah, that's exactly what I was finding - send and receive were giving dodgy timing (I do use them quite a lot in other instances where this is less critical. The program changes workaround keeps things nicely in sync.