Delays smaller than signal vector size with feedback


    Dec 10 2006 | 11:50 am
    Hi,
    I need to have small delays, in 8 seperate voices with feeedback. And further processing after delay and before feedback is needed so comb~ is not helping.
    I am new to this -you cannot delay and feedback in any way you want- phenomenon so I need help. As far as I've seen through subjects discussing similar things, I've had the impression that, if I delay my whole signal chain, then these small delays become possible but I'm not very clear on doing that.
    The instrument does not have to be very responsive, I mean some latency(up to 500ms) in whole sound is acceptable. So is there any way to delay under signal vector size with the help of being able to delay whole signal?
    I can't work in poly~ btw.
    Any suggestions?
    Thanks

    • Dec 10 2006 | 12:24 pm
      you could try delay~ after tapout~ 0
      /J
      10/12/06, kl. 12:50 +0100 , skrev Batuhan:
      >
      >Hi,
      >
      >I need to have small delays, in 8 seperate voices with feeedback. And
      >further processing after delay and before feedback is needed so comb~ is
      >not helping.
      >
      >I am new to this -you cannot delay and feedback in any way you want-
      >phenomenon so I need help. As far as I've seen through subjects
      >discussing similar things, I've had the impression that, if I delay my
      >whole signal chain, then these small delays become possible but I'm not
      >very clear on doing that.
      >
      >The instrument does not have to be very responsive, I mean some latency
      >(up to 500ms) in whole sound is acceptable. So is there any way to delay
      >under signal vector size with the help of being able to delay whole signal?
      >
      >I can't work in poly~ btw.
      >
      >Any suggestions?
      >
      >Thanks
    • Dec 10 2006 | 9:53 pm
      Why can't you work in poly~? Is there a particular reason?
      If you want to process the signal being fed back using other MSP
      objects, the only way to do it is using poly~. You'll need to run the
      feedback part of the patch inside a poly~, with a different vector
      size for the poly~ (using the vs argument to poly~). The vector size
      of the poly~ should be chosen to be smaller than your minimum desired
      delay time. Do you need an example?
      The alternative is to reduce the vector size of the whole graph (i.e.
      using DSP Options), but you'll really eat up your CPU.
      Changing latency isn't going to help in any way.
      On Dec 10, 2006, at 3:50 AM, Batuhan wrote:
      >
      > Hi,
      >
      > I need to have small delays, in 8 seperate voices with feeedback.
      > And further processing after delay and before feedback is needed so
      > comb~ is not helping.
      >
      > I am new to this -you cannot delay and feedback in any way you
      > want- phenomenon so I need help. As far as I've seen through
      > subjects discussing similar things, I've had the impression that,
      > if I delay my whole signal chain, then these small delays become
      > possible but I'm not very clear on doing that.
      >
      > The instrument does not have to be very responsive, I mean some
      > latency(up to 500ms) in whole sound is acceptable. So is there any
      > way to delay under signal vector size with the help of being able
      > to delay whole signal?
      >
      > I can't work in poly~ btw.
      >
      > Any suggestions?
      >
      > Thanks
    • Dec 10 2006 | 10:13 pm
      Thanks for all the help!
      > Why can't you work in poly~? Is there a particular reason?
      >
      > If you want to process the signal being fed back using other MSP
      > objects, the only way to do it is using poly~. You'll need to run the
      > feedback part of the patch inside a poly~, with a different vector
      > size for the poly~ (using the vs argument to poly~). The vector size
      > of the poly~ should be chosen to be smaller than your minimum desired
      > delay time. Do you need an example?
      >
      Well maybe because I do not know how to use it properly, because I could not find a way to make it work for my purposes. I need to have 8 copies of the same sound generator which are controlled by 6 parameters. These 6 parameters are different to each instance. I could not manage to find a way to send 6x8=48 parameters into a poly object then seperating those values 6 by 6 and sending them to relevant instances(these sound generators are always producing sound by the way). The tricky part for me is that, each seperate instance is fed back with the summed signal(sum of all 8 instances) and there needs to be a delay in the feedback loop. Delay times range from 0.1 to 20ms(variable and different for each instance).
      > The alternative is to reduce the vector size of the whole graph (i.e.
      > using DSP Options), but you'll really eat up your CPU.
      >
      > Changing latency isn't going to help in any way.
      Yeas, this(low signal vector size) is not an option for me actually. But I need delay times smaller than 1ms so, I do not know what to do about it.
      Thanks!
    • Dec 11 2006 | 12:38 am
    • Dec 11 2006 | 12:57 am
      At 44100 kHz sampling rate, there are 44.1 samples processed per
      millisecond. With an extremely small vector size of 4 samples, your
      minimum delay time will be 4 / 44.1 = 0.09ms, satisfying your minimum
      delay time requirement.
      I've tried it, and it seems that the only way to have multiple
      processing sharing the same feedback loop seems to be putting them
      all in one subpatch within a poly~. Sharing send~ and receive~ names
      between poly~s introduced unpredictable delay times.
      Trying to figure out how to prevent the feedback exploding is
      difficult with a shared feedback bus; and especially at tiny delay
      times it's really important to watch for this!
      p_delay.pat:
      max v2;
      delay.pat:
      max v2;
      On Dec 10, 2006, at 2:13 PM, Batuhan wrote:
      >
      > Thanks for all the help!
      >
      >> Why can't you work in poly~? Is there a particular reason?
      >>
      >> If you want to process the signal being fed back using other MSP
      >> objects, the only way to do it is using poly~. You'll need to run the
      >> feedback part of the patch inside a poly~, with a different vector
      >> size for the poly~ (using the vs argument to poly~). The vector size
      >> of the poly~ should be chosen to be smaller than your minimum desired
      >> delay time. Do you need an example?
      >>
      >
      > Well maybe because I do not know how to use it properly, because I
      > could not find a way to make it work for my purposes. I need to
      > have 8 copies of the same sound generator which are controlled by 6
      > parameters. These 6 parameters are different to each instance. I
      > could not manage to find a way to send 6x8=48 parameters into a
      > poly object then seperating those values 6 by 6 and sending them to
      > relevant instances(these sound generators are always producing
      > sound by the way). The tricky part for me is that, each seperate
      > instance is fed back with the summed signal(sum of all 8 instances)
      > and there needs to be a delay in the feedback loop. Delay times
      > range from 0.1 to 20ms(variable and different for each instance).
      >
      >> The alternative is to reduce the vector size of the whole graph (i.e.
      >> using DSP Options), but you'll really eat up your CPU.
      >>
      >> Changing latency isn't going to help in any way.
      >
      > Yeas, this is not an option for me actually. but I need delay times
      > smaller than 1ms so, I do not know what to do about it.
      >
      > Thanks!
      >
    • Dec 11 2006 | 1:00 am
      >
      >> I need to have 8 copies of the
      >> same sound generator which are controlled by 6 parameters. These 6
      >> parameters
      >> are different to each instance. I could not manage to find a way
      >> to send
      >> 6x8=48 parameters into a poly object then seperating those values
      >> 6 by 6 and
      >> sending them to relevant instances(these sound generators are
      >> always producing
      >> sound by the way).
      If the messages are not signals, just use a few [route ] objects, and
      prepend the signal instance and parameter name. This is a nice way
      to also auto-document your patch, by the way.
      If they are signals, you might want to use send~ and receive~ instead
      of in~.
    • Dec 11 2006 | 1:19 am
      Wow, thanks for the example patch!! I'll be working on it for sure, I think I get the idea.
      And sending different bunch of messages to different instances inside a poly, I am overlooking something in the manual I think, I can't find a way to do it.
      Say I have 8 message inputs in the poly~ and sending all the 6 parameters for each instance within a list to each inlet. then how will I be able to map the 6 values coming from first inlet to instance 1, second inlet to instance 2 and so on... ?
      Thank you very much for your help.
    • Dec 11 2006 | 3:54 pm
      Oh I'm sorry, your example shows a way how to do it, so I'll have to recopy the code for every other instance I think.
    • Dec 11 2006 | 7:33 pm
      Well, for my example and your particular case, you'd need to put all
      of your units inside one patch that is the only voice within the
      poly~ (it seems to be the only way they can share the feedback loop).
      But for messaging I'd really recommend using the [route ] route.
      G
      On Dec 11, 2006, at 7:54 AM, Batuhan wrote:
      >
      > Oh ı2m sorry, your example shows a way how to do it, so I'll
      > have to recopy the code for every other instance I think.
    • Dec 11 2006 | 7:48 pm
      So I'll be using a poly~ with 1 voice and within the poly patch, i'll have 8 copies of the same code right?
      Actually I'm translating an instrument from another software(NI reaktor) for my own purposes and it has a very different approach for handling multiple instances. You are always working with one structure, but the cords can send polyphonic data, you assign the number of voices you want from the instrument panel. Than all cords send different values together in a single cable. Then if you want them in a whole within the structure, you use a voice combiner module, that sums all the numbers for all the voices in that polyphonic cord, and gives it's output.
      So that is a different way of working, translating between them is what confuses me, but with your help I think I2ll be able to figure that out.
      Thanks!
    • Dec 13 2006 | 4:02 am
    • Dec 13 2006 | 9:10 am
      Ok I've done it successfully with your invaluable help, but there is a problem with this approach.
      Using poly~ with low vector sizes still eats much, very much CPU.
      I do not know if the thing I want is possible within Max/MSP. This is very possible in other software, I'm talking about other software because I want to give a little example and ask if the same approach is possible in MSP.
      Say in synthedit, if you want to make any kind of feedback, you put a module called feedbackdelay to the chain, and that module successfully delays the whole chain one cycle thus making feedbacks of any length in any signal vector possible(by adding latency). If it does not work in this way, I won't be surprised but I think that's the way things work in that software. To create a successfull feedback, it waits one chunk of data to pass and catches it from the next one.
      In NI Reaktor, if you use feedback of any kind, you put a Unit Delay module on outputs so the whole chain is delayed to make the feedbacks possible. If you do not put it, according to the manual, sufficient length of delay is calculated and added to signal.
      So this way you become able to process feedbacks with any vector size by giving some extra buffer to software to work on. Signal chain is delayed in a whole but you use much less processing power.
      I things things work out like this with them. Is the same thing possible in MSP?
      Thanks...
    • Dec 13 2006 | 3:02 pm
      This issue has been discussed before on the list, so you may wish to search the archives. I know of two solutions to the problem. You've discovered the first: use poly~ with a small vector size. The second is to use a custom external that combines delay with feedback. I've written one. I think Tim Place also has one or more such objects. You can find my objects here:
      The disadvantage of the poly~ approach is that it can be CPU expensive. The disadvantage of using third party objects is that you have to keep track of them all, which can be inconvenient when you want to move to a different machine.
      Eric