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