Forums > MaxMSP

send~ and receive~ not sync?

May 2, 2011 | 2:02 pm

Hello list, i’ve been running into a problem with sending and receiving msp signals.
When I route a signal via a few send and receive objects and the receive object is encapsulated, the signal gets delayed. Attached an example showing the problem.
Any idea’s what might be the problem and a possible solution?
Best Lev

– Pasted Max Patch, click to expand. –

May 2, 2011 | 2:07 pm

thats intended.

the explanation can by found by searching the forums.

a possible solution is to use the "normal" [send] and [receive] for your
signals – of course they have other drawbacks then, which are releated
to the nonappearing delay. :)

-110


May 2, 2011 | 2:07 pm

thats intended.

the explanation can by found by searching the forums.

a possible solution is to use the "normal" [send] and [receive] for your
signals – of course they have other drawbacks then, which are releated
to the nonappearing delay. :)

-110


May 2, 2011 | 2:34 pm

Hello Roman, thanks for the quick reply.
Until today I was under the impression there is no difference between a patch chord and a pair of send and receive objects…;-(
Maybe my forum searching isn’t very good (or the search function on the forum isn’t very good), I have not found an explanation on the forum (or in the helpfiles or the tutorials for that matter).
If you happen to have the search query that leads to the explanation of this behavior, that would be very much appreciated….;-)
Best Lev


May 2, 2011 | 2:34 pm

Hello Roman, thanks for the quick reply.
Until today I was under the impression there is no difference between a patch chord and a pair of send and receive objects…;-(
Maybe my forum searching isn’t very good (or the search function on the forum isn’t very good), I have not found an explanation on the forum (or in the helpfiles or the tutorials for that matter).
If you happen to have the search query that leads to the explanation of this behavior, that would be very much appreciated….;-)
Best Lev


May 2, 2011 | 2:46 pm

:)

http://www.google.de/search?hl=de&source=hp&q=site%3Acycling74.com+send%7E+receive%7E+&btnG=Google-Suche&aq=f&aqi=&aql=&oq=

it is always a bit dumb to search MSP objects because the ~ is ignored everywhere, even in google.

one of the drawbacks of [send] for audio is that it requires more CPU.


May 2, 2011 | 2:46 pm

:)

http://www.google.de/search?hl=de&source=hp&q=site%3Acycling74.com+send%7E+receive%7E+&btnG=Google-Suche&aq=f&aqi=&aql=&oq=

it is always a bit dumb to search MSP objects because the ~ is ignored everywhere, even in google.

one of the drawbacks of [send] for audio is that it requires more CPU.


May 2, 2011 | 4:02 pm

Thanks Roman!

So what I found is when using send~ and receive~ objects max/msp automatically creates a signal vector of delay when it suspects feedback. Very strange this is not documented in the helpfiles or tutorials..
Even stranger is that this delay also introduced when cleaning up (and encapsulating) a patch (no feedback there)…..
Anyway, here is another example demonstrating this undocumented ‘feature’.
Best Lev

– Pasted Max Patch, click to expand. –

May 2, 2011 | 4:02 pm

Thanks Roman!

So what I found is when using send~ and receive~ objects max/msp automatically creates a signal vector of delay when it suspects feedback. Very strange this is not documented in the helpfiles or tutorials..
Even stranger is that this delay also introduced when cleaning up (and encapsulating) a patch (no feedback there)…..
Anyway, here is another example demonstrating this undocumented ‘feature’.
Best Lev

– Pasted Max Patch, click to expand. –

May 2, 2011 | 5:38 pm

Does anyone have any idea if the same delay as the abstractiosn would be introduced sending between [bpatcher]s? I am using seven bpatchers, all the same size, using bringtofront scripts to manage screensets, sending all audio to a patchbay screenset, flopping around between screens and eventually going to my DAC.

I was under the same impression that it was the same as patching, so I wasn’t concerned about having several layers of sends (routing flexibility was my main concern). If this is not the case I may halt work on that and just connect the bpatchers directly with inlets and outlets instead.

Suggestions?


May 2, 2011 | 5:38 pm

Does anyone have any idea if the same delay as the abstractiosn would be introduced sending between [bpatcher]s? I am using seven bpatchers, all the same size, using bringtofront scripts to manage screensets, sending all audio to a patchbay screenset, flopping around between screens and eventually going to my DAC.

I was under the same impression that it was the same as patching, so I wasn’t concerned about having several layers of sends (routing flexibility was my main concern). If this is not the case I may halt work on that and just connect the bpatchers directly with inlets and outlets instead.

Suggestions?


May 2, 2011 | 7:05 pm

If you use several sends~ and receives~ in a msp chain with p or b patchers it is more than likely there is a delay introduced by max/msp. You can easily try it out with a testing system like the ones I posted earlier in this thread.
Would be great if you can share you findings here!
Best Lev


May 2, 2011 | 7:05 pm

If you use several sends~ and receives~ in a msp chain with p or b patchers it is more than likely there is a delay introduced by max/msp. You can easily try it out with a testing system like the ones I posted earlier in this thread.
Would be great if you can share you findings here!
Best Lev


May 2, 2011 | 8:20 pm

just try to avoid sending stuff, connecting is often less work than using s/r.

btw, you can also do this in max…

(signal) (signal)
[prepend /signal/right] [prepend /signal/left]
|
[route /signal/right /signal/left]

…and have 2 signal connections using only one patch cord.

you can also have signals mixed with messages over prepend-route.

this way you can route 100 audio channels with only one [gate 8] object, for
zero CPU – in case it is okay for you that you have to restart the audio in
max after using a gate.

this also works with send and receive …

-110
 

[attachment=161092,2173]


May 2, 2011 | 8:20 pm

just try to avoid sending stuff, connecting is often less work than using s/r.

btw, you can also do this in max…

(signal) (signal)
[prepend /signal/right] [prepend /signal/left]
|
[route /signal/right /signal/left]

…and have 2 signal connections using only one patch cord.

you can also have signals mixed with messages over prepend-route.

this way you can route 100 audio channels with only one [gate 8] object, for
zero CPU – in case it is okay for you that you have to restart the audio in
max after using a gate.

this also works with send and receive …

-110
 

[attachment=161092,2173]

Attachments:
  1. mcore.jpg

May 3, 2011 | 9:13 am

Thanks for the example. Nice way of cheap audiorouting!


May 3, 2011 | 9:13 am

Thanks for the example. Nice way of cheap audiorouting!


May 4, 2011 | 9:49 am

brilliant, thanks !


May 4, 2011 | 9:49 am

brilliant, thanks !


May 4, 2011 | 11:33 am

@ Lev: the analysis of the issue is not correct. The delay has nothing to do with the fact that there is an abstraction, but that there is a chain of multiple send~/receive~ pairs. Normally a send~/receive~ pair will not introduce a vector delay. Whenever feedback occurs, automatically a vector of delay is introduced. What msp might analyze in the case of your patch, is that even though there is no feedback in the patch currently, it might occur in the future because the receive object can dynamically be changed to receive a signal from another send.

> Until today I was under the impression there is no difference
> between a patch chord and a pair of send and receive objects…

That is correct. Send and receive (the non signal versions) will not allow dynamic reconnecting, without restarting the dsp. That is the main difference between s/r and s~/r~.

– Pasted Max Patch, click to expand. –

May 4, 2011 | 11:33 am

@ Lev: the analysis of the issue is not correct. The delay has nothing to do with the fact that there is an abstraction, but that there is a chain of multiple send~/receive~ pairs. Normally a send~/receive~ pair will not introduce a vector delay. Whenever feedback occurs, automatically a vector of delay is introduced. What msp might analyze in the case of your patch, is that even though there is no feedback in the patch currently, it might occur in the future because the receive object can dynamically be changed to receive a signal from another send.

> Until today I was under the impression there is no difference
> between a patch chord and a pair of send and receive objects…

That is correct. Send and receive (the non signal versions) will not allow dynamic reconnecting, without restarting the dsp. That is the main difference between s/r and s~/r~.

– Pasted Max Patch, click to expand. –

May 5, 2011 | 11:08 am

If I make an abstraction of a send~ and receive~ chain that has no vector delay, the the same chain in an abstraction has a vector delay.
So it can’t be only the chain of send and receives itself….

– Pasted Max Patch, click to expand. –

May 5, 2011 | 11:08 am

If I make an abstraction of a send~ and receive~ chain that has no vector delay, the the same chain in an abstraction has a vector delay.
So it can’t be only the chain of send and receives itself….

– Pasted Max Patch, click to expand. –

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