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?

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