Forums > MaxMSP

Max4Live send Midi to device on Audio Track



Sym
Dec 28 2012 | 6:55 pm

Hello,

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.

Thanks!
Imbie

Dec 28 2012 | 8:09 pm

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.


Sym
Dec 28 2012 | 9:11 pm

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

Dec 28 2012 | 11:24 pm

Here’s one post with a workaround. http://cycling74.com/forums/topic.php?id=40470

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.


Sym
Dec 29 2012 | 12:53 am

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..

Dec 29 2012 | 9:54 am

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

Dec 29 2012 | 10:03 am

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

Dec 31 2012 | 11:53 pm

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

Broc, thanks for your sobering advice!

Jan 01 2013 | 11:36 am

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.

Jan 01 2013 | 1:00 pm

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

Jan 01 2013 | 1:24 pm

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."

Jan 08 2013 | 1:04 pm

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.

Cheers
Fabrizio

Jan 09 2013 | 9:21 am

does lh_midiinout give you better latency than send/receive ?

Jan 09 2013 | 12:41 pm

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.

Jan 09 2013 | 5:32 pm

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. :)

Jul 18 2013 | 8:59 am

@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.

thanks,
dc

Attachments:
  1. latency-test.zip
Jul 18 2013 | 1:24 pm

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?

Jul 18 2013 | 11:01 pm

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!

Jul 19 2013 | 6:18 am

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

Viewing 19 posts - 1 through 19 (of 19 total)

Forums > MaxMSP