Forums > MaxMSP

non-send~/receive~ feedback loops

Sep 20 2009 | 5:29 pm

Been trying to make an abstraction which uses a feedback loop, but I want to have more than one instance of it at once, and the send~/receive~ objects seem to interfere with eachother.

Rather than trying to make a way of renaming the send~/receive~ pairs, I need an external that can introduce the signal vector delay. I’m sure I’ve seen one, but I can’t remember where!

It’s a shame that delay~ doesn’t work, but I guess thats just how msp works?

— Pasted Max Patch, click to expand. —


Sep 20 2009 | 5:37 pm

you could make an "vector delay" abstraction based on
[send~ #0_myabstraction] and [receive~ #0_myabstraction].


Sep 20 2009 | 5:50 pm

But then I would need to do [vectordelay 1] [vectordelay 2] ………..etc…

That’s what I’m trying to avoid, I would do that, but I’ve seen an external somewhere (possibly in, which I can’t spend on atm) that allows the same functionality but without the need for a patcher argument.

Sep 20 2009 | 7:11 pm

Perhaps one of these will help:


PeRColate – contains an object called ‘Pause~’ which delays by a single vector, I think. Donno if it works for max 5.

I haven’t tried either of these, but they popped up searching for "Vector Delay’ on, and seem to fit what you’re asking for.

Sep 20 2009 | 9:33 pm

ahhh, pause~ is one of the ones I was thinking of, I didn’t realise it’s an abstraction though, so not quite what I need!

Just downloaded demo again, and tap.thru~ is the one! May need to purchase after all…….so many great objects.

Just one thing is bugging me now……….tap.thru~ operates by connecting signal cables in an actual loop, and I assume is delaying the signal by 1 signal vector (which is how send~/receive~ works to allow fb loops isn’t it?).

So why does delay~ with a delay time of 1 signal vector not do the same? As far as I understand, each method is just delaying by 1 sig vector right?

slight confusion……..


Sep 20 2009 | 9:45 pm

I guess tapin~/tapout~ would work the same way as send~/receive~ and not have the namesharing issue.

It seems to be a feature of delay~ that it can’t be part of a feedback chain, which must be what allows it to have delay times less than a signal vector……….nevermind the confusion!


Sep 21 2009 | 1:09 am

hm? no, with #0_ you wont need to write an argument. read again.

yes tapout~ can do it too, but of course thats needs far more CPU
than a send~/receive~.

why not delay~?

there ae people which can explain it more accurate than me.
let me put it like this, if the delay~ object which have a
buffer inside (of a length "in vectors") it could not do
a delay by 3 samples.

tapin~ is writing into a … buffer … similar to the buffer
of a buffer~ object. such buffers size is always in vectors.

that is what makes it possible to have 3 readhaeds reading from
it, copying it, reading backwards from it … delay works more like
an accumulator it just remebers the incoming values and replaces
the incoming samples with the remebered ones.

kinda the "same signal", not a new one like in tapout~ or send~.


Sep 21 2009 | 11:17 am

Oh ok, I see what you mean now about #0_. Where is that explained in the max documentation? I wish I had known about it sooner for abstractions!

I *kind of* get what you’re saying about delay~, it will get clearer the more I think about it.


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

Forums > MaxMSP