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.