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

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

:)

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.

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

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?

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

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  

Thanks for the example. Nice way of cheap audiorouting!

brilliant, thanks !

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

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