Forums > MaxMSP

FM matrices: feedback

April 8, 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


April 8, 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
> –
> http://www.myspace.com/binray


April 8, 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)


April 8, 2007 | 7:22 pm

hi, bin
use send~ and receive~


April 8, 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


April 9, 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.


April 9, 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…


April 9, 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


April 9, 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… — http://www.myspace.com/binray
>
>


April 9, 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

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 143 295 14 196617 1;
#P message 267 296 14 196617 3;
#P message 205 294 14 196617 2;
#P newex 248 135 53 196617 tapout~ 0;
#P newex 248 92 47 196617 tapin~ 0;
#P newex 145 185 62 196617 selector~ 3;
#P user ezdac~ 68 229 112 262 0;
#P newex 85 60 49 196617 saw~ 50;
#P newex 165 137 59 196617 receive~ x;
#P newex 165 94 45 196617 send~ x;
#P connect 2 0 3 0;
#P connect 2 0 4 1;
#P connect 2 0 0 0;
#P connect 2 0 5 0;
#P connect 8 0 4 0;
#P connect 7 0 4 0;
#P connect 9 0 4 0;
#P connect 1 0 4 2;
#P connect 6 0 4 3;
#P connect 4 0 3 1;
#P connect 5 0 6 0;
#P window clipboard copycount 10;


April 9, 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



kp*
April 9, 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


April 9, 2007 | 1:33 am

YOu really should check out the thing I posted


April 9, 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


April 9, 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
>
>
>


April 9, 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
http://www.timara.oberlin.edu/GaryLeeNelson


April 9, 2007 | 11:34 am

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…

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

http://www.jackosx.com


April 9, 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

http://www.nathanwolek.com


April 9, 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

http://www.nathanwolek.com



kp*
April 9, 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


Viewing 20 posts - 1 through 20 (of 20 total)