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?
----------begin_max5_patcher---------- 745.3oc2W1rbaBCD.9L9oPCWqqqQfv3doSeN5joiLRNVMfDCRtN+LwO6U+.D nsIlHSbyTePLZsj1c+ztKKOLKHbi3VpLD7Yv2.AAOLKHvJxHHnYdPXI917Br ztrvbQYIkqBm69OE8VkUNSBT6n0T.lCzxn0bbgVBVAvEEhCRvVJkrAmeCnPH pjfCL0NwdEXujwuFHobxwOUSyoreROBpvrZ4WZ0AeeIiWPUVCHpQ3VAWwwkT qx+ZMCWza45Ctc8KajVgU46zp56ZknbNbzxEKmChxPlGInHyCnVF3pd5Pxt2 piH3h1ihQrJUr4GeDlFZj83rYlg4mICOH1WP.anZnP2tu.v1pInFrDFAnDhE leu0PAl4nRBxAGunRxzRk5aju0tMB0yqSf93zPebZsAtgVer0dkrqsFZmBF3 uvS5uU0TcpjBqXBdOuKwEpCiSLOV1Lz4bCoTqVbhT2UQcGhw33FUAB2VHv5i tc+kBBs+NegvJnEvnTO.bzZu.L8fdy+QP0GNBhB8iwCoUzInUmC97PI0NFi7 gIYSHSHzB7cG+mSkXWv5Z6XRlOTIdJohrRpSnnGmjRPIOGXXlJesYVy6lad7 hvB1KDJM1GX4UcK58Db9KGqL9Zu1RBtWB2N14.8rz0uCJvdAJU17pHWkRWVv q7JM6+sBkNjzTmbsGDY0DRjttTUToZRJJbNnYkEMwVzrxGzjNgnw1F+zwkkm xscYGo9zMAZJca10OWVRjusrEmYuLiVhFQKaSPSHtJu97Bjj2Kjbpq23ORFz +gcegEL9u+g1VEajOjSRw957VisocF8kem5I5zKF2FuzeQY5EE0sncLBgx6m DUxHUBc6Dx1trVu.o2QzJWQU6m7LbFxUuUGAhbS.W8WuoGsejMF+X8fEcR+3 hXSwuNaBlYYaVhYrAzlImoslL1vfKH9fZ0AGC9htX1T5HvzpKpEsZDVzk8da LVD50YQoIOEy+z3YZmwi7tzWxom73reAlM.3yC -----------end_max5_patcher-----------
you could make an "vector delay" abstraction based on
[send~ #0_myabstraction] and [receive~ #0_myabstraction].
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?
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~.
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.