I'm fairly new to PD, and I noticed that fidle~, sigmund~ & friends weren't able to deal with bass pitch.

As I'm a glutton for punishment , I decided to have a go .. seemed I needed to make an external, and even that was prety tight.

Anyway, here is the compiled linux version..

http://www.pdpatchrepo.info/hurleur/basspitch~.pd_linux

Here we are .. version 0.3

Back to the original reporting rate, but have developed a more sophisticated mechanism for detecting attack & sustain.

I have also put in more comments for people who are interested in browsing the code

Edit: I'll throw in a Makefile .. basspitch~-help.pd can be found at the beginning of the thread

http://www.pdpatchrepo.info/hurleur/basspitch~.c

Here we are .. version 0.3

Back to the original reporting rate, but have developed a more sophisticated mechanism for detecting attack & sustain.

I have also put in more comments for people who are interested in browsing the code

Edit: I'll throw in a Makefile .. basspitch~-help.pd can be found at the beginning of the thread

http://www.pdpatchrepo.info/hurleur/basspitch~.c

yes, you had faster response but it was a bit unstable.
I was just thinking, maybe you can use some method implemented in aubio to help you with detecting the bass onsets after you filter the energy bands that you need.
I am trying to compile aubio on my machine but I have some error in pd: something related to flat name space. I suppose it doesn't find fftw3 correctly.

@dio_333 said:

..I am trying to compile aubio on my machine but I have some error in pd: something related to flat name space. I suppose it doesn't find fftw3 correctly.

I didn't have any trouble with it .. I managed to compile it, but noticed that while the aubio libs are well-maintained, the puredata implimentation needs a little 'tweaking', as they are only a subset of their functionality

I tried to compile this object using the .c you provided and the usual protocol available from: http://puredata.info/docs/developer/PdExternalsInXcode/?searchterm=xcode

It appears to compile without any issue, but when i try to call the object in Pd, I receive the following message:

/Users/graham-r9/Library/Pd/basspitch~/basspitch~.pd_darwin: dlopen(/Users/graham-r9/Library/Pd/basspitch~/basspitch~.pd_darwin, 10): no suitable image found. Did find:
/Users/graham-r9/Library/Pd/basspitch~/basspitch~.pd_darwin: mach-o, but wrong architecture
basspitch~

I presume I am missing something very obvious here. I would appreciate any direction you might have.

Cheers,

Ricky

ohh...I had the same problem when compiling an external.
so my mac is 64b and the Xcode offers by default to compile the external for 64. my pd was 32. you don't get any error when compiling but you get that error in pd.

actually because of this I couldn't compile aubio on my machine...

You beat me to it. Yes, it is a 32bit versus 64bit architecture problem. Simply change debug/active architecture to i386 instead of x86_64 in X Code.

Info: http://www.williamsylvester.com/2009/10/30/how-to-fix-mach-o-but-wrong-architecture-on-osx-snow-leopard-for-ruby-gems-bundle-files

Works like a charm. Darwin file attached.

R

http://www.pdpatchrepo.info/hurleur/basspitch~.pd_darwin

Hi Moog!

Is it possible to compile a version of [basspitch~] specifically for real-time tracking with reduced latency? I would be keen to learn if this would be possible.

Best,

Ricky

hmmm ... I think it's a tradeoff between frequency resolution and latency. moog tried to make it faster but finally he opted to leave it like that because it reported a lot of erroneous pitches.

but I will let the master speak

It would be nice to allow the user to configure chunk size parameter via a message, if possible?

@ricky said:

It would be nice to allow the user to configure chunk size parameter via a message, if possible?

What do you mean by 'chunk size' ? Do you mean 'block size' ?
What gain would there be from that? What are you trying to do?

The fft-size is very critical for accurate analysis, and it's already very tight .. of course, accuracy could be improved, but latency would suffer.

@moog1 said:

What do you mean by 'chunk size' ? Do you mean 'block size' ?

Yes, I mean block size.

@moog1 said:

What gain would there be from that? What are you trying to do?

It would make the object more dynamic in terms of allowing the user to specify accuracy of tracking versus latency. This would be useful when tracking different registers of different instruments.

@ricky said:

..It would make the object more dynamic in terms of allowing the user to specify accuracy of tracking versus latency.

Yes, I see .. except that as it's tracking bass, if you decreased the fft-block size (to obtain increased latency),
your output would be next to useless

If you observe the behaviour of fiddle~ or sigmund~, for example, they can't track bass at all !
That's why I had a go at my own..
I think any major improvements can only be made, out of a 'real-time' scenario .. but I might be wrong

@moog1 said:

Yes, I see .. except that as it's tracking bass, if you decreased the fft-block size (to obtain increased latency),
your output would be next to useless

You mean reduce latency? Just a suggestion, but it may prove useful to have the ability to fine-tune your object to attend to contrasting registers.

@moog1 said:

If you observe the behaviour of fiddle~ or sigmund~, for example, they can't track bass at all!

Yes, I had noticed this; and not so good for some higher registers too. Katja's [helmholtz~] seems more stable. Perhaps there is no solution given the current approaches to pitch tracking but I would like to track registers above 46.24 hz during a real-time performance.