Sending Audio between M4L devices

Aug 6, 2011 at 12:23pm

Sending Audio between M4L devices

Hello guys,

maybe my question seems silly, i am pretty new to Max/MSP and still kind of confused about it.
what i am going to do is creating some kind of routing mechanism. I want to put a M4L device in one audio track and connect the signal to a send╦ť module (i named it “A”).
Then i create another audio track with one more M4L device having a receive╦ť module named “A” to receive the signal from the first audio track.
For some reason it does not work. But actually it should, or am i wrong?

As i could not find the Max' function to export a patcher as plain ascii, i just took a screenshot of my simple example devices.

i found these sentences in the reference and manuals:

“The “name space” in Max is global – when you have objects that have names associated with them such as coll, send, receive, table, or buffer~ , you can share data between Max for Live devices. In these cases, the Max name space is shared, but the “signal processing space” is independent – each Max for Live device processes its audio or data separately.”

sounds to me, that my structure is supposed to work.

or this sentence: “Signals can be received from any loaded patcher without patch cords”

what am i doing wrong?

[attachment=168338,2514]

Attachments:
  1. 2patchers.png
#58363
Aug 6, 2011 at 12:58pm

Copying and pasting the ASCII version of patches is easier than you think… just select the objects that you want to copy, and then go to the Edit menu and select “Copy Compressed”. Then paste it into your browser.

While I know that you can write and read global buffers (you can see an example of this in monomlake’s granulator input device), I’m not sure if you can arbitrarily route audio between M4L devices. That would require sample-accurate communication between threads … but I just hit the limit of my knowledge there so hopefully someone else can elaborate.

#209754
Aug 6, 2011 at 1:32pm

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

Quote from the documentation

http://www.cycling74.com/docs/max5/vignettes/core/live_limitations.html

#209755
Aug 6, 2011 at 3:20pm

you can try plugsend~ and plugreceive~ but there’s a bunch of latency.

#209756
Aug 6, 2011 at 4:26pm

Thx for your answers! Very very helpful! I was thinking about plugsend, too, until i foud this text in the reference:
“…The use of the plugsend~ and plugreceive~ objects to pass audio between Max for Live devices is not supported…”

So i am going for a buffer based solution. Something like recording Samples in a buffer at index N in the first device. And reading samples at index N-1 in the other device.
I guess I will need the modules “index~” and “poke~”.

Or does anybody already know, that i won’t have success?

#209757
Aug 6, 2011 at 10:55pm

I did it with buffers now and it really does work! Well, it’s still a little glitchy, but i hope you guys know the trick ;)

It’s still two devices, each in a different track. The first writes the sample input into a global buffer (i use poke╦ť and a counter). The second device reads out samples (here i use index╦ť and a counter) from the buffer – with a little delay to prevent glitches – and routes them to it’s output.

I don’t know what the problem is. I read out the samples with 15 ms delay and it’s still glitchy. Is written data messed up? or is the reading mechanism creating a messed up output signal?

Copying and pasting the ASCII version of patches is easier than you think… just select the objects that you want to copy, and then go to the Edit menu and select “Copy Compressed”. Then paste it into your browser.

thx man ;)

Device A – Buffer Recorder

– Pasted Max Patch, click to expand. –

Device B – Buffer Player

– Pasted Max Patch, click to expand. –
#209758
Aug 7, 2011 at 12:04am

Maybe try it in a single patch, get it working, then separate it into two patches and see if you get similar results? I definitely get glitches when approaching low delays like that….even in the same patch.

#209759
Aug 7, 2011 at 9:29am

For start/stop synchronization you may better use [plugsync~] since live.observer is not accurate in general.
Note that plugsync~ also provides sample count information which could be useful.

#209760
Aug 7, 2011 at 3:14pm

Thx again for your ideas. I made a “in-one-device”-solution. It works perfect.

thx for the hint about plugsync╦ť! very helpful! I even tried to use the sample counter for indexing the buffer samples. but for some reason that didn’t work as i expected.

i will try to split it up again. maybe it’s going to work better with the new synchro stuff.

if some one is interested in the “in-one-device”-solution which is actually a circular buffer now.

– Pasted Max Patch, click to expand. –
#209761
Aug 11, 2011 at 8:02pm

Thx for all your hints! these experiments cleared up alot in my brain!
But finally i went a completly differnt way. it’s much much easier and way more stable. I just abused the sends of the tracks and created a patch that will pull down the fader and turn up a given send (post fader), when a button is pressed. No glitches, no noises, just working, midi controlable routing.

here is the final result.

– Pasted Max Patch, click to expand. –
#209762

You must be logged in to reply to this topic.