redhexagonal

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?

fm-matrices-feedback

You could put the FM part of your patch in a poly~ with a small 

On Apr 8, 2007, at 5:21 AM, bin ray wrote:

> 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 

You could put the FM part of your patch in a poly~ with a small  
signal vector, say, 16 or 2.

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


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)

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

> ok thanks . so send~ receive~ pairs are not limited by the signal

No, send~ and receive~ *are* constrained by the vector size, I'm afraid.

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.


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

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


>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

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?

> 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

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?

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


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

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

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


I don't see a new one, but am hoping a UB of cpPan~ is sitting 

I don't see a new one, but am hoping a UB of cpPan~  is sitting  
somewhere sub-google....

YOu really should check out the thing I posted

>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

In the time that you were searching, couldn't you make a constant

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.

> I got a bunch of patches that use cpPan~

> I don't see a new one, but am hoping a UB of cpPan~ is sitting

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.

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


On 4/8/07 9:51 PM, "keith manlove" wrote:

> In the time that you were searching, couldn't you make a constant

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

>> I got a bunch of patches that use cpPan~

>> I don't see a new one, but am hoping a UB of cpPan~ is sitting

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

As someone else mentioned, it's in the Granular Tookit download at 

Also, although I've not tested this personally, it should be more 

efficient than the computation below, because it uses table lookups...

At 8:51 PM -0500 4/8/07, keith manlove wrote:

>In the time that you were searching, couldn't you make a constant

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

>>I got a bunch of patches that use cpPan~

>>I don't see a new one, but am hoping a UB of cpPan~ is sitting

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

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

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
http://www.jackosx.com


On Apr 8, 2007, at 10:32 PM, Gary Lee Nelson wrote:

Gary is correct. It is part of the Granular Toolkit download. 

Available at the URL below. If someone really needs it as a separate 

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
http://www.nathanwolek.com

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

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

> As someone else mentioned, it's in the Granular Tookit download at 

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

FM matrices: feedback