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..
..and help file..
I can post the source if anybody's interested..
Katjav? :-D
I'm sure you could suggest or make some improvements, and compile it for other OS
Thanks
I've cleaned the source up a bit, and included it in the zip..
I'm not set up for cross-compiling .. no way of testing, anyhow
It tracks quite well at medium tempo, but as it's in 'real time', can't cope with more than about 150bpm
Hello moog1, where's the makefile, I want to do OSX and Windows build so we can compare with [snac~] and maybe combine good elements from both.
By the way, how long did it take you to find out about the peculiar organisation of imaginary coefficients in mayer_realfft()? Think this stuff has bogged me down for at least half a day, I was totally puzzled by the nonsense output of my object.
Katja
Sorry .. no makefile..
I used a script:-
#!/bin/sh
gcc -g -Wall -W -fPIC -O3 -funroll-loops -fomit-frame-pointer -c basspitch~.c
gcc -g -Wl,--export-dynamic -shared -fPIC basspitch~.o -o basspitch~.pd_linux
which includes debug symbols in the executable.
Re imaginary coeffs. it drove me up the wall .. I had many hours of bug chasing .. I finally realised when reading the rfft~ object code, carefully scrutinising it.
Finally got time to compile [basspitch~] on OSX. Initially, there was this kind of compiler warnings:
basspitch~.c:34: warning: declaration of 'pow' shadows a global declaration
...
/usr/include/architecture/i386/math.h:352: warning: shadowed declaration is here
So I changed all occurrences of variable 'pow' into 'power'.
I had a hard time trying to understand what the code exactly does. But it seems to work (partly, see below). It's interesting that a period longer than the fft framesize can be tracked. A 512 point fft at SR 44100 corresponds to ~86 Hz, and [basspitch~] tracks down to 40 Hz. That is because the second harmonic is sometimes taken to represent the pitch? It is a great advantage because of reduced latency.
It is a nice bass tuner now, but it could be more. You did not test the output as a pitch controller for synthesis, I'm sure! It jumps from tone to tone if you sweep the input frequency. Probably the culprit is this line in perform method:
outlet_float(x->freq, sys_getsr()/(512*16) * fracbin);
This should not be in perform. Instead, you should use a message clock and bind it to a separate method where outlet_float is called. That makes sure every call is indeed executed. Examples can be found in other classes which have signal inlet and message outlet(s).
Katja
Edit: I didn't upload the binary since you may want to correct the code first.
Moog1,
I've inserted the clock_delay thing for the messages, see attached. Unfortunately it did not help to get a better message output rate.
Could you comment a bit on your approach? It seems like you're shifting frequencies in time domain before they go into the fft. What's the theory behind it? It would be great to get it working properly, and see if the good elements of our pitch trackers can be combined.
Edit (after looking a bit better at code and output): seems more like you downsample the signal before it goes in the fft. The message output interval is almost 200 milliseconds. The 512 point fft is done for every 8192 input samples? In that case, it works like it should, apologies for my critic. Still I would love to hear your explanation.
Katja
Mmm .. I see you added a 'clock' .. I'm not quite sure what it does..
Yes, you're right .. downsampled by factor of 16, and a 512 point windowed fft can be done which is quicker than doing an 8192, as only bass freq needed.
Quadratic interpolation is then performed, but not as accurate as your snac~ 
Seems to be enough for midi (just about)
The first section of the file is probably what confused you .. it's just a rough 512 fft to decide whether to trigger the 8192 .. it's all a bit tight really.. not to bad for a first attempt, although it took me many, many hours..
Maybe, trying to track bass when just learning was rather ambitious.
Still, I learnt somewhat .. and enjoyed it really
Moog1, clock_delay() is the official route to get values out of a perform method to message outlets. This is how Pd schedules all message calls to happen inbetween dsp ticks.
You're right it's better to do a 512 pt fft than 8192 pt if only low frequencies are to be tracked. Long fft's can cause buffer underruns, specially if there are many in the same dsp tick. Downsampling is the obvious approach indeed. It's just that I overlooked the few lines of code where it happens.
I'm planning to write (one day, not today or tomorrow) a multirate decimator class in C++, which should do downsampling and filtering in one process. Like you've done it in [basspitch~], but for arbitrary FIR filter kernels. To be combined with several analysis classes for pitch tracking and transient detection. When skipping redundant calculations, decent FIR filtering shouldn't be too expensive in the downsampling case. Maybe we can cooperate on this, if you like.
Did you try [helmholtz~] with bass? I'm curious to know, got no bass guitar around here and test tones are not the same as the real thing. [helmholtz~] should be able to track bass with 2048 pt at samplerate 44100, or 512 pt in a subpatch with resample factor 0.25. In that case, if you use 4 times overlap, you'd have a much better message output rate. I should do a patch where the actual message interval is tested using the [realtime] object.
Katja
I haven't tried it on bass yet .. naturally, if it's much better (which it looks like it probably will be), I will use it instead.
I'm not upset about it .. as I say, it's all about learning for me
I see what you mean about the 'clocking', yet as there is 200ms between each float value output, it's not necessary in this instance..
PS. I'm actually running a Pentium II (Deschutes) on Debian Lenny (5.0), so I have to do 'a bit extra' to keep up
@katjav said:
.. [helmholtz~] should be able to track bass with 2048 pt at samplerate 44100, or 512 pt in a subpatch with resample factor 0.25. In that case, if you use 4 times overlap, you'd have a much better message output rate..
Mmm .. that's very interesting..
Unfortunately, [helmholtz~] does not in itself track bass very well when playing with other instruments.
[basspitch~] seems to perform quite well on my "Mp3's" (not without error), and is probably due to the fact that I designed it for the purpose.
However, after playing around with my low speed spectral analysis patch (uploaded yesterday), I have some good ideas for improvement which is possible due to using the snac's advantageous relatively small framesize. This gives opportunity for further analysis, and increasing the output rate at the same time
hello!
I tested your object for various instruments, routing audio from garage band into the bass pitch help patch with jackaudio and it performs quite well.
It gives worse results with guitar that is playing lower octaves but it makes sense, right?
and I am not sure how it will work for faster tempos...with the frame/hop size that you are using.
maybe you could have some imputs in which the user could set a trade off between speed and accuracy.
I compiled this on a macos 10.7 using Xcode 4.2
great job! thank you!
@dio_333 said:
It gives worse results with guitar that is playing lower octaves but it makes sense, right?
I suppose .. I think we should be able to improve it with a little thought .. I was having a break
Thanks for your feedback
and I am not sure how it will work for faster tempos...with the frame/hop size that you are using.
Good point .. if you look back later, I will post modified object code for a hop size that will double the output rate (by shifting the buffer by 4096 twice every 8192 samples)
You might have done it already, I don't know
There seems plenty of spare 'cpu' .. atm
There are some other issues which pertain to accuracy that I'm researching / experimenting with .. it's coming on .. the 'good old' transient problem being one, and a more refined approach to octave choosing another
Here it is version 0.2
The cpu load is still very low, but the report rate has been doubled..
I still intend to work on the other factors I mentioned yesterday
I don't like version 0.2
The orig. zip file of version 0.1 reports more accurately and is far less chaotic
I think that a report rate of 5 times a second (rather than 10) is better .. why?
Well ..
1. we have to detect an 'attack' in the correct freq band
2. we need to find the freq and I think we need the full 8192 window (starting from the attack) to do that reliably, in a polyphonic situation
It's true, that we could look for our next attack in an overlapping window, but do we really gain anything substantial? Probably not, in the case of bass, but I might come back to the issue later.
Version 0.3 should be coming very soon .. I'm improving the trigger mechanism on version 0.1
I'm looking for accuracy .. the original intention was for basspitch~ to reveal reasonable bass scores for any multi-instrumental audio input.
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
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
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...
Oops! Looks like something went wrong!
