Pyramind

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?

delays-smaller-than-signal-vector-size-with-feedback

10/12/06, kl. 12:50 +0100 , skrev Batuhan:

>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

>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

>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?

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

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 

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:

> I need to have small delays, in 8 seperate voices with feeedback. 

> And further processing after delay and before feedback is needed so 

> 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 

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.

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


> 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 

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.

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

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 

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!

On Dec 10, 2006, at 2:13 PM, Batuhan wrote:

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

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

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!

>
> 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!
>


>> same sound generator which are controlled by 6 parameters. These 6 

>> are different to each instance. I could not manage to find a way 

>> 6x8=48 parameters into a poly object then seperating those values 

>> sending them to relevant instances(these sound generators are 

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 

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


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

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.

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.

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.

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

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


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.

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?

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.

I things things work out like this with them. Is the same thing possible in MSP? 

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:

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/

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.

Delays smaller than signal vector size with feedback