toothpaste

When there are multiple send~ receive~ pairs in a dsp chain, introduced delay is multiplied by the number of pairs?

I could test this, but rather choose to enjoy a quicker answer!

multiple-send-delay

use [send] with signals with no delay where possible

hmm. so there is no way to make use of send or send~ for the purpose of re-arranging a dsp chain (e.g an fx chain)? once send~ is used delay presents itself, once send is used, dsp should be restarted.. am i correct?

hm. more or less. at least if it is a very big system, it could be a good idea to do it with the restart method. i soemtimes use the non MSP [gate] object to route audio, this also needs a restart after every change.

for a small system you could just connect everything hardwired, and then do *~ 0. and *~ 1. to open a path. ;)

but msp won't bother to check if the signal's 0 or not, will it? so that it will stop the run anyway once there is a feedback present without a tapin~ or send~? so how am i supposed to do it?

well no, no way to have a feedback without a minimum of one vector delay~

indees if you want a flexible system of routing based on a matrix~ it's a problem ! i've run into it !...

well no, no way to have a feedback without a minimum of one vector delay~
one sample in gen~ world
indees if you want a flexible system of routing based on a matrix~ it's a problem ! i've run into it !...


right.. but I am not looking for any feedback functionality. so there should be a way to get the off channels out of the chain. maybe with begin~? or sth like that. there was an object once like that. let me check

if you are building a system where you can freely route audio, that one vector delay of [send~] will be required anyway.

if you build a linear system, routing the signals using gate~/selector~/matrix~ will be enough, or other words, [send] should not really be required if renaming the [r] and breaking the signal chain bothers you.

option #4 is to use poly~, i.e. you have everything connected and now only turn stuff on and off and/or exchange the patcher in the poly~.

if you are building a system where you can freely route audio, that one vector delay of [send~] will be required anyway. 

Well I don't think it is possible. How can it be possible?

say FX1's input and output are named in1-out1, and FX2: in2-out2 and so on...

In one setting out1 will need to feed in2, in another out2, in1. So all FX outlets should be connected to all inlets except for their own AT ALL TIMES.So msp won't let any signal flow. How can gate~/selector~/matrix~ etc. help in this case?

Seems like poly~ won't be a solution either, since it's not possible to feed audio from one instance to another in a linear fashion. Or am I missing sth?

If you could give a concrete example, I'd be more than glad Roman.

Never fear! Raja_The_Resident_Asswipe is not actually here!

"When there are multiple send~ receive~ pairs in a dsp chain, introduced delay is multiplied by the number of pairs?"

you don't even need to worry about delay if you're not creating feedback loops(no delay whatsoever with send~/receive~ pairs as long as there's no possible feedback routing, patchchord-wise...). if you do have a feedback loop, the delay is equal to just one vector-size(no need to multiply, unless you're talking about nesting several feedback-loops within each other.... even then, i'm not sure... discussion of this issue never went that far on these forums as far as i can remember :p)

"In one setting out1 will need to feed in2, in another out2, in1.So all FX outlets should be connected to all inlets expect for their own’s AT ALL TIMES"

Max detects feedback loops by patch-chord routing(i believe? doesn't allow you to do it without using send~/receive~ or delay~ within the feedback loop). So you can't do this without introducing a vector of delay when using send~/receive~. This is why Roman is referring to using a 'linear'(also known as 'serial') system(the setting you're mentioning where everything is already connected is 'parallel', but it sounds like you don't actually need parallel since you never want to create a feedback loop).

If you really want what you're describing without creating a parallel system, there are different ways to do it... simplest way i can think of is to use messaging to dynamically set the name of send~ or receive~ objects(see helpfile... change the routing on-the-fly of a particular send~ or receive~ object by sending it the message 'set ...' ....you may also need to declick for switching this kind of thing...).

Another way, as Roman mentioned is to use poly~... but i think you're confused, in the case of fx, you're only using one voice of poly~(just using poly~ for the signal-muting functionality mainly, so only creating a one-voice poly~ per effect)... in this case, you can load different fx files on the fly... swapping one out for the other(for example, if you know you want fx2 to be routed to fx1 at one point, and then vice versa at another, you can have 2 poly~s routed to each other to begin with and simply swap the fx files they load...).... i can't really explain this well... and is not something i'd cobble together quick enough for forum banter... but try it out... it'll make sense once you're in your own patch...

here's a patch that shows linear versus parallel(but you probably already know this), i didn't comment much and it doesn't exactly demonstrate everything you want, but just poke around and maybe modify to seek out what you're looking for, it's definitely possible there... you'll figure it out:

(edit: technically, the above patch would still create a vector's worth of delay no matter which version, with the patch as is, because the parallel routing system has same-named send~/receive~ pairs as the linear/serial routing system(all in the same patch just for demo). but create a patch with just the linear version, and you'll be fine ;)

Never fear! Raja_The_Resident_Asswipe is not actually here!
this was confusing:
"When there are multiple send~ receive~ pairs in a dsp chain, introduced delay is multiplied by the number of pairs?"

Max detects feedback loops by patch-chord routing(i believe? doesn't allow you to do it without using send~/receive~ or delay~ within the feedback loop). So you can't do this without introducing a vector of delay when using send~/receive~. This is why Roman is referring to using a 'linear'(also known as 'serial') system(the setting you're mentioning where everything is already connected is 'parallel', but it sounds like you don't actually need parallel since you never want to create a feedback loop).
If you really want what you're describing without creating a parallel system, there are different ways to do it... simplest way i can think of is to use messaging to dynamically set the name of send~ or receive~ objects(see helpfile... change the routing on-the-fly of a particular send~ or receive~ object by sending it the message 'set ...' ....you may also need to declick for switching this kind of thing...).
Another way, as Roman mentioned is to use poly~... but i think you're confused, in the case of fx, you're only using one voice of poly~(just using poly~ for the signal-muting functionality mainly, so only creating a one-voice poly~ per effect)... in this case, you can load different fx files on the fly... swapping one out for the other(for example, if you know you want fx2 to be routed to fx1 at one point, and then vice versa at another, you can have 2 poly~s routed to each other to begin with and simply swap the fx files they load...).... i can't really explain this well... and is not something i'd cobble together quick enough for forum banter... but try it out... it'll make sense once you're in your own patch...

it does help raja. thank you very much for teaching me and also roman...

Multiple send~ delay?