Johannes

I am trying to do a 4 chnl setup in Ableton. This is possible if I choose one audio-channel with the normal master-out that is routed to chnl 1-2. Then I open a second audio-chnl and assign this to ext-out 3-4. I created to m4l patches: the master-patch contains my generator and the spatialisation-logic: signal 1+2 is mounted to the normal plugout (master 1-2). signal 3+4 is connected to two plugsends (rear3 and rear4). The second channel in ableton contains a m4l patch with this named plugrecieves~.

Only if I open both patches in the Max-Environment the plugsend/receive implementation is working.

Is there a possibility to use this technology without openening both patches in max?

I am trying to do a 4 chnl setup in Ableton. This is possible if I choose one audio-channel with the normal master-out that is routed to chnl 1-2. Then I open a second audio-chnl and assign this to ext-out 3-4. I created to m4l patches: the master-patch contains my generator and the spatialisation-logic: signal 1+2 is mounted to the normal plugout (master 1-2). signal 3+4 is connected to two plugsends (rear3 and rear4). The second channel in ableton contains a m4l patch with this named plugrecieves~.
Here is the problem:
Only if I open both patches in the Max-Environment the plugsend/receive implementation is working.

plugsendplugreceive

plugsend~/plugreceive~ is not officially supported in M4L.

https://cycling74.com/docs/max5/refpages/msp-ref/plugsend~.html

It seems to work somehow, but unusable due to substantial and unpredictable latency.

In theory a work around should be possible with 3rd party software. Route channels 3+4 of the generator to a [vst~] object in the M4L patch and load 'Plogue Bidule' as plugin. Within the plugin route the incoming audio to external 3+4 channels. If needed, you can route it back into Live via Soundflower or Jack. Obviously this will introduce latency but it's predictable and thus can be compensated.

I've just checked and it turns out that external audio channels/devices are NOT available within the Bidule plugin (in contrast to external midi ports). So unfortunately, the theory is disproved by reality.

EDIT:
I've just checked and it turns out that external audio channels/devices are NOT available within the Bidule plugin (in contrast to external midi ports). So unfortunately, the theory is disproved by reality.


I see. Thanks for the info. It is a pity that it is not supported anymore. But it looks like I am lucky because I did not notice a remarkable latency using plugs/r in my environment. (checking with metro on and simple beat-pattern).

Yes, it seems to work well in the Max environment but I was referring to M4L without opening the patches in Max.

https://cycling74.com/forums/m4l-audio-not-sending-to-midi-track

Thanks for the links. There is a lot of discussion going on already, although the thread is almost half a year old. From now on I will keep an eye on the ableton forum too (the third board) to expand my m4l knowledge.

I know this is an old thread, but I wondered if anyone here used [plugsend~] [plugreceive~] these days.

Still now, Max's documentation says: “The use of the plugsend~ and plugreceive~ objects to pass audio between Max for Live devices is not supported.” but it seams to work...

I am trying them at the moment. With my setup I get a steady 46ms latency (2048 samples) between [plugsend~] and [plugreceive~], and I have not noticed any problem.

Well, it is not perfect, as I get 1ms latency between [send~] and [receive~].

Here my latency test devices, if it is any use:

http://liveelectronics.musinou.net/devices/latencytest/

Could you share your experience with [plugsend~] and [plugreceive~]. Any bug, glitches? Excessive random latency?

Here my latency test devices, if it is any use:
http://liveelectronics.musinou.net/devices/latencytest/

Keep in mind that PDC (plugin delay compensation) in Live works only for native audio routings.

So I think the timing of extra routing across tracks is generally not reliable.

Keep in mind that PDC (plugin delay compensation) in Live works only for native audio routings.
So I think the timing of extra routing across tracks is generally not reliable.


So, if I understand well, the latency between [plugsend~] and [plugreceive~] would change depending of the latency of the other plugins one is using because of Live's automatic plugin delay compensation. That's right?

Hi Broc,
Thank you for your reply.
So, if I understand well, the latency between [plugsend~] and [plugreceive~] would change depending of the latency of the other plugins one is using because of Live's automatic plugin delay compensation. That's right?


The problem is not caused by PDC but the lack of it for extra routings, ie. if you have tracks with plugins that introduce latency, the timing of sender/receiver in relation to standard audio processing will depend on their position (latency stage) in the device chain.

Notice that in Live all 3rd party plugins and M4L devices introduce latency. So you can easily check the timing problem of sender/receiver when inserting some empty M4L devices on the tracks.

Do you know any reliable work-arround? Ideally something that does not need to leave Max/MSP open.

Annoying...
Do you know any reliable work-arround? Ideally something that does not need to leave Max/MSP open.
Thank you!


plugsend/plugreceive