non-send~/receive~ feedback loops
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?
cheers!
you could make an "vector delay" abstraction based on
[send~ #0_myabstraction] and [receive~ #0_myabstraction].
-110
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 tap.tools, which I can’t spend on atm) that allows the same functionality but without the need for a patcher argument.
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.
http://www.music.columbia.edu/PeRColate/
I haven’t tried either of these, but they popped up searching for "Vector Delay’ on maxobjects.com, and seem to fit what you’re asking for.
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 tap.tools 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……..
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!
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~.
-110
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.
cheers