I use my electric guitar to generate a tone (done with fiddle~). This works perfectly. Now, I want to make it so that every separate tone triggers a specific event. eg, when the tone is 50, a bang is sent to object 1, when the tone is 51, a bang is sent to object 2, and so on. 

I already tried to do this with == objects. I had a == 50 object and a == 51 object, but it is giving bangs out constantly, even when I'm not touching a guitar string.

My goal is to make a guitar-keyboard, so that every tone is generating a letter on the keyboard. (done with osc and a separate custom program)

Can someone give me advice what to do now?

I use my electric guitar to generate a tone (done with fiddle~). This works perfectly. Now, I want to make it so that every separate tone triggers a specific event. eg, when the tone is 50, a bang is sent to object 1, when the tone is 51, a bang is sent to object 2, and so on. 
I already tried to do this with == objects. I had a == 50 object and a == 51 object, but it is giving bangs out constantly, even when I'm not touching a guitar string.

My goal is to make a guitar-keyboard, so that every tone is generating a letter on the keyboard. (done with osc and a separate custom program)
Can someone give me advice what to do now?

guitar-tone-fiddle-etc

[select] works well, only the problem now is when i ring a note on the guitar, i still get a string of bangs. I want only the first value that appears in the tone-box, after ringing one note, to be the one that is registered. This has to be done with the attack message probably, but i don't understand how.

Quote: PaulvP wrote on Thu, 28 December 2006 06:40

----------------------------------------------------

> [select] works well, only the problem now is when i ring a note on the guitar, i still get a string of bangs. I want only the first value that appears in the tone-box, after ringing one note, to be the one that is registered. This has to be done with the attack message probably, but i don't understand how. 

I took your patch, cleaned it up a bit and altered it some. Does this help? Notice the attack bang out of fiddle~ allows you to play the same note several times in a row but the change object prevents the repeated bangs problem you were having. I'm sure others have better (more elegant) solutions to this problem too....

Quote: PaulvP wrote on Thu, 28 December 2006 06:40
----------------------------------------------------
> [select] works well, only the problem now is when i ring a note on the guitar, i still get a string of bangs. I want only the first value that appears in the tone-box, after ringing one note, to be the one that is registered. This has to be done with the attack message probably, but i don't understand how. 
>
> here's my patch, I hope you can help
----------------------------------------------------

I took your patch, cleaned it up a bit and altered it some.  Does this help?  Notice the attack bang out of fiddle~ allows you to play the same note several times in a row but the change object prevents the repeated bangs problem you were having.  I'm sure others have better (more elegant) solutions to this problem too....

Thanks man, that really helped. It now works like I want it to. (and it looks a bit cleaner as well ;-)

Do you know if there's a faster pitch/frequency tracker than fiddle~ ?

Do you know if there's a faster pitch/frequency tracker than fiddle~ ?
In Ircam's collection maybe... ?

Quote: Philippe Gruchet wrote on Thu, 28 December 2006 15:32

> Do you know if there's a faster pitch/frequency tracker than fiddle~ ?

I know that there's pitch~ which is based on the fiddle~ algo:

It has fewer "features" than fiddle~ and tracks lower pitches so it may be faster but I've not actually implemented it in this type of situation and don't know for sure. I bet the author(s) could/will comment? :)

Quote: Philippe Gruchet wrote on Thu, 28 December 2006 15:32
----------------------------------------------------
> Hi,
>
> Do you know if there's a faster pitch/frequency tracker than fiddle~ ?
----------------------------------------------------

I know that there's pitch~ which is based on the fiddle~ algo:  

It has fewer "features" than fiddle~ and tracks lower pitches so it may be faster but I've not actually implemented it in this type of situation and don't know for sure.  I bet the author(s) could/will comment?  :)

Yes, I'm also using it for its extra-features. Not yet UB for Mac, btw.

For FFT processing, I get the same latency since it embeds the code of fiddle~

I bet the author(s) could/will comment? :)

I'm not sure that the full code of fiddle has been *fully* Altivec optimized with vDSP, vecLib and Accelerate framework.

About the UB version, I don't think it has been SSE optimized at all for x86 CPU.

(Sorry if I'm wrong, but I think I'm right cause of the latency: fully optimized-rewritten, it should then work at a much lower latency.)

Do you know if there's a faster pitch/frequency tracker than fiddle~ ?
----------------------------------------------------

I know that there's pitch~ which is based on the fiddle~ algo:
http://web.media.mit.edu/~tristan/

Yes, I'm also using it for its extra-features. Not yet UB for Mac, btw.
For FFT processing, I get the same latency since it embeds the code of fiddle~
(the fiddle~ algo is an old boy now ;-)
For the rest, it works fine.

I bet the author(s) could/will comment?  :)

I'm not sure that the full code of fiddle has been *fully* Altivec optimized with vDSP, vecLib and Accelerate framework.
About the UB version, I don't think it has been SSE optimized at all for x86 CPU.
(Sorry if I'm wrong, but I think I'm right cause of the latency: fully optimized-rewritten, it should then work at a much lower latency.)

> I know that there's pitch~ which is based on the fiddle~ algo:

> Yes, I'm also using it for its extra-features. Not yet UB for Mac, btw.

analyser~ has the functions of pitch~ built in. I did make a UB version of pitch~ for Tristan, but it seems he hasn't posted it yet. Maybe if you ask him.

> I know that there's pitch~ which is based on the fiddle~ algo:
> http://web.media.mit.edu/~tristan/
>
> Yes, I'm also using it for its extra-features. Not yet UB for Mac, btw.

analyser~ has the functions of pitch~ built in.  I did make a UB version of pitch~ for Tristan, but it seems he hasn't posted it yet.  Maybe if you ask him.

>> I know that there's pitch~ which is based on the fiddle~ algo:

>> Yes, I'm also using it for its extra-features. Not yet UB for Mac, 

> analyser~ has the functions of pitch~ built in. I did make a UB 

> version of pitch~ for Tristan, but it seems he hasn't posted it 

Btw, could you tell me if MaxMSP supports the Accelerate framework 

(vDSP especially) for writing an external?

I just got a very fast pitch tracker with vDSP everywhere, and I'd 

>> I know that there's pitch~ which is based on the fiddle~ algo:
>> http://web.media.mit.edu/~tristan/
>>
>> Yes, I'm also using it for its extra-features. Not yet UB for Mac,  
>> btw.
>
> analyser~ has the functions of pitch~ built in.  I did make a UB  
> version of pitch~ for Tristan, but it seems he hasn't posted it  
> yet.  Maybe if you ask him.

Nice!
Btw, could you tell me if MaxMSP supports the Accelerate framework  
(vDSP especially) for writing an external?
I just got a very fast pitch tracker with vDSP everywhere, and I'd  
like to try it inside MaxMSP.
Thanks!

> Btw, could you tell me if MaxMSP supports the Accelerate framework (vDSP 

No problem, you just have to add it to the Xcode project.

> I just got a very fast pitch tracker with vDSP everywhere, and I'd like 

Cool, I like new pitch trackers! - Played with pitch~ from jMax for a 

while now (made a version that uses Accelerate framework for FFT), but 

wasn't really happy with it either. It has more parameters to fiddle 

with than fiddle~, so pitch detection is slightly more relible (if you 

tweak the parameters long enough), but lowest detectable MIDI pitch is 

But to tell the truth, I haven't seen much speed gain from using the 

Accelerate framework. Maybe it was just running the scalar code because 

it didn't like the input I gave it, but the speed gain compared to 

old-school FFT code was only about 10%. Or maybe the rest of the code is 

what eats CPU, not just the FFT. Would be fun to convert everything to 

Philippe GRUCHET wrote:
> Btw, could you tell me if MaxMSP supports the Accelerate framework (vDSP 
> especially) for writing an external?

> I just got a very fast pitch tracker with vDSP everywhere, and I'd like 
> to try it inside MaxMSP.

Cool, I like new pitch trackers! - Played with pitch~ from jMax for a 
while now (made a version that uses Accelerate framework for FFT), but 
wasn't really happy with it either. It has more parameters to fiddle 
with than fiddle~, so pitch detection is slightly more relible (if you 
tweak the parameters long enough), but lowest detectable MIDI pitch is 
55, which is pretty high.
But to tell the truth, I haven't seen much speed gain from using the 
Accelerate framework. Maybe it was just running the scalar code because 
it didn't like the input I gave it, but the speed gain compared to 
old-school FFT code was only about 10%. Or maybe the rest of the code is 
what eats CPU, not just the FFT. Would be fun to convert everything to 
be accelerated...

>> Btw, could you tell me if MaxMSP supports the Accelerate framework 

>> (vDSP especially) for writing an external?

> No problem, you just have to add it to the Xcode project.

        // set up the vDSP split complex structure

        mSplitComplex.realp = mRealParts;

        mSplitComplex.imagp = mImagParts;

    // destructor clears the FFT coefficient setup

            vDSP_destroy_fftsetupD(mFFTSetup);

(I'll switch this topic to the Dev forum&mailing list.)

>> I just got a very fast pitch tracker with vDSP everywhere, and I'd 

> Cool, I like new pitch trackers! - Played with pitch~ from jMax for 

> a while now (made a version that uses Accelerate framework for 

> FFT), but wasn't really happy with it either. It has more 

> parameters to fiddle with than fiddle~, so pitch detection is 

> slightly more reliable (if you tweak the parameters long enough), 

> but lowest detectable MIDI pitch is 55, which is pretty high.

I'll check again the code, but I don't see a such limit.

> But to tell the truth, I haven't seen much speed gain from using 

> the Accelerate framework. Maybe it was just running the scalar code 

> because it didn't like the input I gave it, but the speed gain 

> compared to old-school FFT code was only about 10%.

No, more. You should get up to 40%. It was very probably running in 

"GCC offers a feature called auto-vectorization which supposedly 

automatically vectorizes your code, but it doesn't really achieve the 

amount of speedup you can get by manually implementing vector 

> Would be fun to convert everything to be accelerated...

Then, it's what I don't know yet: transposing a C++ into a Max 

Hey, would you like to take a look inside?

>> Btw, could you tell me if MaxMSP supports the Accelerate framework  
>> (vDSP especially) for writing an external?
>
> No problem, you just have to add it to the Xcode project.

		// set up the vDSP split complex structure
		mSplitComplex.realp = mRealParts;
		mSplitComplex.imagp = mImagParts;

	// destructor clears the FFT coefficient setup
		if(mFFTSetup != NULL) {
			vDSP_destroy_fftsetupD(mFFTSetup);

>> I just got a very fast pitch tracker with vDSP everywhere, and I'd  
>> like to try it inside MaxMSP.
>
> Cool, I like new pitch trackers! - Played with pitch~ from jMax for  
> a while now (made a version that uses Accelerate framework for  
> FFT), but wasn't really happy with it either. It has more  
> parameters to fiddle with than fiddle~, so pitch detection is  
> slightly more reliable (if you tweak the parameters long enough),  
> but lowest detectable MIDI pitch is 55, which is pretty high.

Yes, this is very high! :-(
I'll check again the code, but I don't see a such limit.

> But to tell the truth, I haven't seen much speed gain from using  
> the Accelerate framework. Maybe it was just running the scalar code  
> because it didn't like the input I gave it, but the speed gain  
> compared to old-school FFT code was only about 10%.

No, more. You should get up to 40%. It was very probably running in  
scalar code.
Note:
"GCC offers a feature called auto-vectorization which supposedly  
automatically vectorizes your code, but it doesn't really achieve the  
amount of speedup you can get by manually implementing vector  
operations and array alignment."

It took a while... and I got it :-)
Then, it's what I don't know yet: transposing a C++ into a Max  
external...
Hey, would you like to take a look inside?

>>> Btw, could you tell me if MaxMSP supports the Accelerate framework 

>>> (vDSP especially) for writing an external?

>> No problem, you just have to add it to the Xcode project.

> // set up the vDSP split complex structure

> // destructor clears the FFT coefficient setup

Sort of. You need the #include, and you have to vDSP_create_fftsetup(), 

the rest depends more or less how your code works.

And you have to add the frameworj to the Xcode project or you'd get 

> No, more. You should get up to 40%. It was very probably running in 

I know, I made a pitch scaler about two years ago that was completely 

altivectorised (also based on Bernsees code) and had about 35% speed 

gain compared to the plain scalar code when run on a G4.

>> Would be fun to convert everything to be accelerated...

> Then, it's what I don't know yet: transposing a C++ into a Max external...

> Hey, would you like to take a look inside?

Sure, just send it my way and I'll see what I can do.

Philippe GRUCHET wrote:
> Hi Olaf,
>
>>> Btw, could you tell me if MaxMSP supports the Accelerate framework 
>>> (vDSP especially) for writing an external?
>>
>> No problem, you just have to add it to the Xcode project.
>
> #include 
>
>         // set up the vDSP split complex structure
>         mSplitComplex.realp = mRealParts;
>         mSplitComplex.imagp = mImagParts;
>
> Yes?
>
>
>     // destructor clears the FFT coefficient setup
>         if(mFFTSetup != NULL) {
>             vDSP_destroy_fftsetupD(mFFTSetup);
>
> Really?

Sort of. You need the #include, and you have to vDSP_create_fftsetup(), 
the rest depends more or less how your code works.
And you have to add the frameworj to the Xcode project or you'd get 
undefined symbols when linking...

> No, more. You should get up to 40%. It was very probably running in 
> scalar code.

I know, I made a pitch scaler about two years ago that was completely 
altivectorised (also based on Bernsees code) and had about 35% speed 
gain compared to the plain scalar code when run on a G4.

>> Would be fun to convert everything to be accelerated...
>
> It took a while... and I got it :-)
> Then, it's what I don't know yet: transposing a C++ into a Max external...
> Hey, would you like to take a look inside?

> Sure, just send it my way and I'll see what I can do.

>> would you like to take a look inside?
> Sure, just send it my way and I'll see what I can do.

Guitar tone, Fiddle~ etc.