Bass pitch tracker
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..
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.
Works like a charm. Darwin file attached.
R
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.
Oops! Looks like something went wrong!
