Guitar tone, Fiddle~ etc.
Hello,
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?
Paul
[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
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
----------------------------------------------------
Hey Paul,
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 ;-)
Paul
Hi,
Do you know if there's a faster pitch/frequency tracker than fiddle~ ?
In Ircam's collection maybe... ?
Any insight welcome.
Thanks!
Regards,
Philippe
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~ ?
----------------------------------------------------
Philippe,
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? :)
Paul,
Glad to hear that helped!
Lewis
Hi Lewis,
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? :)
Let's try with this 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.)
More info:
Bye ;-)
Philippe
> 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.
mz
>> 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!
Philippe
Philippe GRUCHET wrote:
> 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.
> 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...
Olaf
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?
(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
>> 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."
> 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?
Cheers;-)
Philippe
Please read:
#include
And not:
#include
Sorry to onboard readers,
Philippe
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.
Olaf
>> would you like to take a look inside?
> Sure, just send it my way and I'll see what I can do.
Thanks Olaf!
See you soon,
Philippe