I know that it's possible in Ableton to make an AU or VST receive MIDI from an separate MIDI track when the plugin is put on an audio track.

Can somebody explain me how to achieve this in Max4Life.

Perfectly it should show me the possibility in lives send menu of the MIDI Track to send to the Audio Track Device.

Can somebody explain me how to achieve this in Max4Life.
Perfectly it should show me the possibility in lives send menu of the MIDI Track to send to the Audio Track Device.

max4live-send-midi-to-device-on-audio-track

This is problematic in the current version of Live, since devices are either Audio, Midi, or Instruments (and not combinations of). Hopefully Live 9 will address this problem. Search in the Max for Live part of the forum and you will find some workarounds for this issue. Also, try posting in the Max for Live part of the forum for a quicker response.

This is problematic in the current version of Live, since devices are either Audio, Midi, or Instruments (and not combinations of).  Hopefully Live 9 will address this problem.  Search in the Max for Live part of the forum and you will find some workarounds for this issue.  Also, try posting in the Max for Live part of the forum for a quicker response.


Thanks for the tip! sorry wasn't aware of the m4l part.

https://cycling74.com/forums/midi-input-for-max-audio-effects

Personally, I'm waiting for Live 9. For now I am building audio devices with a sequencer instead of midi input. If I need midi input, I first make an audio device that records to a buffer, and then have that buffer play back from a seperate instrument track, which is triggered by midi. Not ideal, but it keeps me going.

Here's one post with a workaround.   https://cycling74.com/forums/midi-input-for-max-audio-effects

Personally, I'm waiting for Live 9.  For now I am building audio devices with a sequencer instead of midi input.  If I need midi input, I first make an audio device that records to a buffer, and then have that buffer play back from a seperate instrument track, which is triggered by midi.  Not ideal, but it keeps me going.


Your idea with the is really good, you're right it's by far not ideal but thanks for sharing your thoughts on this!

Guess I'll be waiting for Live 9 too then..

Thanks for the workaround post!
Your idea with the is really good, you're right it's by far not ideal but thanks for sharing your thoughts on this!

Guess I'll be waiting for Live 9 too then..


I do exactly this with send / receive, with Live 8. Does Live 9 really suppresses this limitation ?

There is no indication that Live 9 would change anything in that department.

Stephane, I might have to try the send / receive method again. My understanding though, was there some inherent latency in doing that.

Stephane, I might have to try the send / receive method again.  My understanding though, was there some inherent latency in doing that.

According to my tests the (maximum) latency of send/receive depends on Live's audio buffer.

So at 512 samples you get about 12ms and at 128 samples it's reduced to 3ms.

According to my tests the (maximum) latency of send/receive depends on Live's audio buffer.
So at 512 samples you get about 12ms and at 128 samples it's reduced to 3ms.


Broc, are you talking about send~and receive~ or non-audio versions ?

I'm talking about the non-audio versions.

The audio versions are not supported in M4L as mentioned in the docs (Max vs. M4L):

"The use of the send~ and receive~ objects to pass audio between Max for Live devices is not supported."

The audio versions are not supported in M4L as mentioned in the docs (Max vs. M4L):
"The use of the send~ and receive~ objects to pass audio between Max for Live devices is not supported."


I can confirm from my own tests the statemet of broc about send and receive latency.

It is bound to Live audio buffering, even if there is no audio involved. So it may be an issue sometimes, while in many cases not.

I can confirm from my own tests the statemet of broc about send and receive latency.
It is bound to Live audio buffering, even if there is no audio involved. So it may be an issue sometimes, while in many cases not.

does lh_midiinout give you better latency than send/receive ?

According to my tests, any extra communication across tracks (ie. send/receive, lh_midiinout or OSC) introduces the same latency bound to Live's audio buffer. I think it's because different tracks are running on different threads and switching between them (scheduling) is determined by the audio buffer size.

How about direct patchcord connection? This should be lowest possible latency? I'm talking about between patchers here, strictly as an alternative to send / receive.

Trying to evaluate whether it's worth refactoring quite a large device, fairly riddled with send / receive matchups.

TIA for any enlightenment forthcoming. :)

Trying to evaluate whether it's worth refactoring quite a large device, fairly riddled with send / receive matchups. 

TIA for any enlightenment forthcoming. :)


According to my tests, any extra communication across tracks (ie. send/receive, lh_midiinout or OSC) introduces the same latency bound to Live’s audio buffer. I think it’s because different tracks are running on different threads and switching between them (scheduling) is determined by the audio buffer size.

How did you implemented your tests? I would like to replicate them in my computer,

I did two simple devices, but i didn't detect any latency.

@BROC
According to my tests, any extra communication across tracks (ie. send/receive, lh_midiinout or OSC) introduces the same latency bound to Live’s audio buffer. I think it’s because different tracks are running on different threads and switching between them (scheduling) is determined by the audio buffer size.


Hello broc,
How did you implemented your tests? I would like to replicate them in my computer,
I did two simple devices, but i didn't detect any latency.

My tests were done some time ago. I've simple sent a bang from one device to another and printed cpuclock on each side in the Max runtime window. Out of curiosity I've now repeated the same test and strangely enough don't get latency anymore, even in complex multi-track Live sets. It looks like the behavior of send/receive has been changed. Can somebody from cycling please comment on this?

I just did the same test and can confirm your results! The max. latency I get is about 0.02 ms which is basically nothing! This is fantastic!

really great news! can someody from c74' confirm this fact?

Max4Live send Midi to device on Audio Track