recursive audio loop


    May 15 2007 | 7:02 am
    hi
    so i wanted to re-route the output of matrix~ to a different input of
    the same object
    _ I know about the impossibility of feed-back loops, I usually use
    send~/receive~ but since i wanted to make this in an abstraction I
    wanted to avoid the (automatic) naming of the different pairs, and
    was looking for a "wired" solution
    tapin~/tapout~ does work, but in the meantime i found a post (by
    Peter C.) suggesting using delay~ (which sounds so obvious); I
    however never managed to have this solution working
    my I/O vector size is 512
    signal vector size 256
    sampling rate 44100
    which value should i use (in delay~) to make it work (512 and 256 do
    not work)??
    thanks
    kasper
    --
    Kasper T. Toeplitz
    noise, composition, bass, computer

    • May 15 2007 | 10:05 am
      patches say more than words.. ;)
      Mattijs
      Quote: Kasper T Toeplitz wrote on Tue, 15 May 2007 09:02
      ----------------------------------------------------
      > hi
      >
      > so i wanted to re-route the output of matrix~ to a different input of
      > the same object
      >
      >
      > _ I know about the impossibility of feed-back loops, I usually use
      > send~/receive~ but since i wanted to make this in an abstraction I
      > wanted to avoid the (automatic) naming of the different pairs, and
      > was looking for a "wired" solution
      >
      > tapin~/tapout~ does work, but in the meantime i found a post (by
      > Peter C.) suggesting using delay~ (which sounds so obvious); I
      > however never managed to have this solution working
      >
      > my I/O vector size is 512
      > signal vector size 256
      > sampling rate 44100
      >
      > which value should i use (in delay~) to make it work (512 and 256 do
      > not work)??
      >
      >
      > thanks
      >
      > kasper
      > --
      > Kasper T. Toeplitz
      > noise, composition, bass, computer
      > http://www.sleazeArt.com
      >
      > http://www.myspace.com/sleazeart
      >
      >
      ----------------------------------------------------
    • May 15 2007 | 10:33 am
      >patches say more than words.. ;)
      >
      ok, so here it is
      what value to give to the delay??? (in p there will be some process,
      filter or watever)
      thanks
      kasper
    • May 15 2007 | 11:29 am
      i assumed it was just one vector's worth of audio. in your case i presume this is 256, but since that doesnt work.
      out of interest, i tried further up (in x2) until 4096. also tried it with 2 arguments to see if there was any difference in how the object initialised... nothing worked!
      strange as i also expected this feedback method to work, hopefully someone can shed some light soon...
      back to the tapin / out method, i wonder what the initial delay of tapout is without any args? is it the equivalent of 512 samples, as i seem to remember it cannot produce delays shorter than 1 vector of audio...
      think its time for some coffee!
      j
      Quote: Kasper T Toeplitz wrote on Tue, 15 May 2007 08:02
      ----------------------------------------------------
      > my I/O vector size is 512
      > signal vector size 256
      > sampling rate 44100
      >
      > which value should i use (in delay~) to make it work (512 and 256 do
      > not work)??
    • May 15 2007 | 1:31 pm
    • May 15 2007 | 2:27 pm
    • May 15 2007 | 2:38 pm
      Quote: Kasper T Toeplitz wrote on Tue, 15 May 2007 12:33
      ----------------------------------------------------
      > what value to give to the delay??? (in p there will be some process,
      > filter or watever)
      In the help file, the subtitle of delay~ says "Delay calculated in samples, without feedback". You can never use a delay~ for feedback, regardless of the delay time.
      tapin~ and tapout~ work with a different technique which has the disadvantage that it can't delay less than signal vector size but allows for feedback.
      Mattijs
    • May 15 2007 | 3:42 pm
    • May 18 2007 | 12:13 am
      justin skrev:
      > reason i'm asking is cos i'm looking into including some feedback into some of my msp patches... but i am concerned by the delay time of the feedback. ideally, i would like to be able to put both dry and feedback signals back in sync by using another delay on the dry signal before mixing. that's why i would like to know exactly how much delay there is! i'm aware this workaround may not work in all cases, but it might work in some...
      >
      > the idea being that feedback is not quite feedback if it's slightly delayed. surely the phase of the signal being fed back in will be out by x amount of samples, which in turn has an effect on the feedback.
      Dear Justin,
      to me this dilemma of yours sounds overly theoretical - e.g.; the delay
      would be in phase with... what? A sound that had passed some time ago?
      I say: Build the patch, THEN worry about shoving stuff in/out of phase
      if it sounds wrong.
      Andreas.
    • May 18 2007 | 8:18 am
      Quote: justin wrote on Tue, 15 May 2007 17:42
      ----------------------------------------------------
      > the reason i was interested in no delay feedback was for emulating analog circuits - which to my knowledge have no delay in their processing.
      >
      > unless... it would be possible to create this type of feedback processing inside the MSP object?
      >
      > problem is... i dont know enough about programming DSP objects in C! ;)
      Hi Justin,
      this sounds almost like you are trying to remake an analogue filter circuit from a scheme in a book. Note that a dsp chain is entirely different from an analogue circuit.
      There is no situation in a dsp system where you need feedback without delay. If you think you do, you probably work with a wrong assumption somewhere in your design phase. Perhaps you can make a small (not working) patch that illustrates the kind of thing you want to do.
      Mattijs
    • May 18 2007 | 3:44 pm
      Kasper T Toeplitz schrieb:
      > tapin~/tapout~ does work, but in the meantime i found a post (by Peter
      > C.) suggesting using delay~ (which sounds so obvious); I however never
      > managed to have this solution working
      Even a master like Peter isn't always right, you just prooved, that
      Max/MSP doesn't know anyhthing about the internals of delay~. It can't
      know that you give it a delay bigger than the vector size. It will not
      accept the feedback for any msp object. Tapin/out~ are connected with a
      non signal patch cord, that's why it works...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com