FM matrices: feedback


    Apr 08 2007 | 12:21 pm
    hello
    i'm building an FM matrix, where i can specify the modulation of any of 4 oscillators to any of the others, including feedback routings. i am using tapin~/tapout~ pairs to implement the feedback.
    the problem i run into is that the delay (one signal vector) caused by these pairs causes unwanted clicks and artifacts in sounds particularly with short attacks. its particularly bad if i'm using it rewired since i have to use my hosts vector size, which is usually bigger than what id use in maxmsp alone.
    the only solution ive found on the forum is to build my own external to do the feedback, and i have no idea where to start with that. is there another way?
    james

    • Apr 08 2007 | 4:34 pm
      You could put the FM part of your patch in a poly~ with a small
      signal vector, say, 16 or 2.
      -Randy
      On Apr 8, 2007, at 5:21 AM, bin ray wrote:
      >
      > hello
      >
      > i'm building an FM matrix, where i can specify the modulation of
      > any of 4 oscillators to any of the others, including feedback
      > routings. i am using tapin~/tapout~ pairs to implement the feedback.
      >
      > the problem i run into is that the delay (one signal vector) caused
      > by these pairs causes unwanted clicks and artifacts in sounds
      > particularly with short attacks. its particularly bad if i'm using
      > it rewired since i have to use my hosts vector size, which is
      > usually bigger than what id use in maxmsp alone.
      >
      > the only solution ive found on the forum is to build my own
      > external to do the feedback, and i have no idea where to start with
      > that. is there another way?
      >
      > james
      > --
      > www.myspace.com/binray
    • Apr 08 2007 | 4:56 pm
      yeah Ive been using that for combs, [poly~ {your_abstraction_here} 1 vs 16]
      matrix~ is pretty nice, and you can use dialmode which will allow for tons of juicy feedback routings! (send~ recieve~ needed)
    • Apr 08 2007 | 7:22 pm
      hi, bin
      use send~ and receive~
    • Apr 08 2007 | 11:56 pm
      ok thanks . so send~ receive~ pairs are not limited by the signal vector size? i was confused by owens post in the "feedback in a patch " thread
    • Apr 09 2007 | 12:12 am
      bin ray wrote:
      > ok thanks . so send~ receive~ pairs are not limited by the signal
      > vector size?
      No, send~ and receive~ *are* constrained by the vector size, I'm afraid.
    • Apr 09 2007 | 12:18 am
      ok so i'm back to square one then.
      so the best suggestion is to put the whole routing into a poly~ and specify the signal vector size as being very small?
      send~ receive~ pairs dont help me at all it seems...
    • Apr 09 2007 | 12:25 am
      >No, send~ and receive~ *are* constrained by the vector size, I'm afraid.
      can you show me a patch that demonstrates that? . my tests so far don't seem to show any delay at all
    • Apr 09 2007 | 12:28 am
      If that's your problem . Myself, I'm not sure how the feedback delay
      should manifest as glitches; are you sure it's not something else?
      Can you post your patch?
      --
      Owen
      bin ray wrote:
      > ok so i'm back to square one then. so the best suggestion is to put
      > the whole routing into a poly~ and specify the signal vector size as
      > being very small? send~ receive~ pairs dont help me at all it
      > seems... -- www.myspace.com/binray
      >
      >
    • Apr 09 2007 | 12:56 am
      as far as i can tell , this patch shows that send~ receive~ is not dependent on the signal vextor size~. try changing your vector size, it sounds exactly the same as a direct connection, and different from tapin~ tapout~ which is definately dependent on vector size
    • Apr 09 2007 | 1:14 am
      ok i just tried connecting send~ receive~ in a feedback loop and you are correct, owen, the minimum delay becomes dependent on the signal vector size.
      so my best solution is to reduce the signal vector size inside my poly~ FM patch?
      it would be good to have the feedback delay at one sample, feedback seems to make much better saw waves (from sine waves) at lower vector sizes
    • Apr 09 2007 | 1:16 am
      Howdy,
      I got a bunch of patches that use cpPan~
      but now i am on intel...
      I don't see a new one, but am hoping a UB of cpPan~ is sitting
      somewhere sub-google....
      anyone know?
      cheers,
      kp
    • Apr 09 2007 | 1:33 am
      YOu really should check out the thing I posted
    • Apr 09 2007 | 1:50 am
      >YOu really should check out the thing I posted
      I did. its a matrix using send~ and receive~ pairs, which will have a minimum delay of the signal vector size, the same as a tapin~ tapout ~ pair. i want to minimize the delay, so i get nice saw waves and no artefacts in my FM sculpting
    • Apr 09 2007 | 1:51 am
      In the time that you were searching, couldn't you make a constant
      power panner? It's not too difficult.
      left = ( sqrt(2) / 2 ) * ( cos(x) + sin(x) )
      right = ( sqrt(2) / 2 ) * ( cos(x) - sin(x) )
      I don't have a UB cpPan~. Let me know if you need help making one.
      Thanks,
      Keith
      On 4/8/07, kevin parks wrote:
      > Howdy,
      >
      > I got a bunch of patches that use cpPan~
      >
      > but now i am on intel...
      >
      > I don't see a new one, but am hoping a UB of cpPan~ is sitting
      > somewhere sub-google....
      >
      > anyone know?
      >
      > cheers,
      > kp
      >
      >
      >
    • Apr 09 2007 | 2:32 am
      It's in GranTK
      On 4/8/07 9:51 PM, "keith manlove" wrote:
      > In the time that you were searching, couldn't you make a constant
      > power panner? It's not too difficult.
      >
      > left = ( sqrt(2) / 2 ) * ( cos(x) + sin(x) )
      > right = ( sqrt(2) / 2 ) * ( cos(x) - sin(x) )
      >
      > I don't have a UB cpPan~. Let me know if you need help making one.
      >
      > Thanks,
      > Keith
      >
      > On 4/8/07, kevin parks wrote:
      >> Howdy,
      >>
      >> I got a bunch of patches that use cpPan~
      >>
      >> but now i am on intel...
      >>
      >> I don't see a new one, but am hoping a UB of cpPan~ is sitting
      >> somewhere sub-google....
      >>
      >> anyone know?
      >>
      >> cheers,
      >> kp
      >>
      >>
      >>
      Cheers
      Gary Lee Nelson
      Oberlin College
      www.timara.oberlin.edu/GaryLeeNelson
    • Apr 09 2007 | 11:34 am
      As someone else mentioned, it's in the Granular Tookit download at
      Nathan's page:
      Also, although I've not tested this personally, it should be more
      efficient than the computation below, because it uses table lookups...
      Dan
      At 8:51 PM -0500 4/8/07, keith manlove wrote:
      >In the time that you were searching, couldn't you make a constant
      >power panner? It's not too difficult.
      >
      >left = ( sqrt(2) / 2 ) * ( cos(x) + sin(x) )
      >right = ( sqrt(2) / 2 ) * ( cos(x) - sin(x) )
      >
      >I don't have a UB cpPan~. Let me know if you need help making one.
      >
      >Thanks,
      >Keith
      >
      >On 4/8/07, kevin parks wrote:
      >>Howdy,
      >>
      >>I got a bunch of patches that use cpPan~
      >>
      >>but now i am on intel...
      >>
      >>I don't see a new one, but am hoping a UB of cpPan~ is sitting
      >>somewhere sub-google....
      >>
      >>anyone know?
      >>
      >>cheers,
      >>kp
      >>
      >>
      >>
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major
      Malfunction
      http://www.defectiverecords.com
    • Apr 09 2007 | 11:41 am
      On Apr 8, 2007, at 10:32 PM, Gary Lee Nelson wrote:
      > It's in GranTK
      Gary is correct. It is part of the Granular Toolkit download.
      Available at the URL below. If someone really needs it as a separate
      download, let me know.
      -------------------
      Nathan Wolek, PhD --- nwolek@stetson.edu
      Assistant Professor of Music Technology
      Stetson University - DeLand, FL
    • Apr 09 2007 | 12:15 pm
      On Apr 9, 2007, at 7:34 AM, Dan Nigrin wrote:
      > Also, although I've not tested this personally, it should be more
      > efficient than the computation below, because it uses table lookups...
      Thanks, Dan. I had forgotten about this excellent point. :)
      -------------------
      Nathan Wolek, PhD --- nwolek@stetson.edu
      Assistant Professor of Music Technology
      Stetson University - DeLand, FL
    • Apr 09 2007 | 3:26 pm
      On Apr 9, 2007, at 7:34 AM, Dan Nigrin wrote:
      > As someone else mentioned, it's in the Granular Tookit download at
      > Nathan's page:
      >
      > http://www.nathanwolek.com/software.html
      >
      > Also, although I've not tested this personally, it should be more
      > efficient than the computation below, because it uses table lookups...
      That's what i am talking about! hee hee
      thanks all.
      rocking
      -k