Pitch Extraction

RunBeerRun2 · 16 Apr 2011

Works very well, low on latency and fast tracking. Tracks my whole guitar's range, on a bass only down to the E which is the guitar's low E(7th fret A string).

I've exported it for MIDI output use, in Reaper on my dual core it runs at a nice minimal 2.6% cpu.

Thanks, it's really cool!

oddson · 16 Apr 2011

RunBeerRun2 wrote: Tracks my whole guitar's range, on a bass only down to the E which is the guitar's low E(7th fret A string).

I think it's bottom end is set in the filter value it starts with...

I still don't get how it works... ASDF is clearly an auto-correlation method (and I get that part) but I can't quite figure how it's implemented here (although i just now opened it up!)

It looks like you check four candidates but I'm not sure how that gets you a specific MIDI let alone track pitch bend:S

martinvicanek · 17 Apr 2011

Thanks for your comments, guys.

Yes, the option to set the pitch detection range is there but clearly it has to be accessible from the GUI. I'll post an update soon.

ASDF is indeed very similar to autocorrelation based pitch detection. Basically one compares the original audio signal with a delayed signal. They will be equal for periodic input if the delay time matches the period. Now if you have an array of delays tuned to semitones, all you need to do is pick the best match. In my scheme I use 4 octaves packed in Mono4 for efficiency, so in the first step I have 4 candidates, one from each octave.

The next step is to pick from these four. Note that there is an ambiguity because you will have matches for multiples of the period (at the fundamental frequency, 1/2 the frequency, 1/3 etc.). To pick the right candidate I add a little bias to give preference to the higher octaves.

Once you have the best matching semitone, you can estimate pitch bending from the two neighbors' values.

One nice bonus is that ASDF gives you a measure for voiced (= periodic) vs. unvoiced input. That can be used for a gate function to prevent the device from trying to extract a single pitch when in fact there is none (try playing chords!).

Hope that explains it a bit. Martin

trogluddite · 17 Apr 2011

Welcome to the forum, Martin. Thanks for the schematic, and the good explanation too. I've been looking at correlation type pitch-detecting for a while, trying to improve the tracking on GRRRrrr, but gave up because I couldn't find a way get a reasonable CPU load - yours uses about a quarter of the CPU of my best efforts. I'll definitely be playing with this some more, and having a poke around inside for some inspiration - so thanks again for sharing. Had a quick look through the code, and it looks as if there could be some reasonable CPU savings still to be had. The SM code for accessing arrays is particularly inefficient - so you should see some good savings in the ASDF module by replacing the 14 item arrays with discrete variables - untidy, I know, but since your loops are already unrolled, quite easy to do.

oddson · 17 Apr 2011

martinvicanek wrote: ...Now if you have an array of delays tuned to semitones, all you need to do is pick the best match...

Holy crap... I'm starting to get it but that's massively daunting -- all those fractional delays!

It would take me ages just to understand how you've done this...

But I do have a question from what little of this I think I'm starting to understand:

Why do you need to calc delays in stage 2? Aren't these values constants. Even at ~10 Hz that's a lot of calculation.

martinvicanek · 17 Apr 2011

Thanks Trog, I replaced the indexed arrays by fixed variables, not sure if it makes a huge difference. Anyway, I updated the file at the top of this thread. It also has a range selector for guitar or bass.

Oddson, the delay constants are calculated in stage(2) so the user can switch the tonal range without having to restart. At hop(4096) it does not hurt. The number crunching part is really the fractional delay calculation itself (yes, they have to be fractional) plus the lowpass for each semitone. However, it turns out that it is perfectly feasible (using Mono4 and hop(8) though).

Martin

BertAnt · 17 Apr 2011

martinvicanek wrote: Thanks Trog, I replaced the indexed arrays by fixed variables, not sure if it makes a huge difference. Anyway, I updated the file at the top of this thread. It also has a range selector for guitar or bass.

Oddson, the delay constants are calculated in stage(2) so the user can switch the tonal range without having to restart. At hop(4096) it does not hurt. The number crunching part is really the fractional delay calculation itself (yes, they have to be fractional) plus the lowpass for each semitone. However, it turns out that it is perfectly feasible (using Mono4 and hop(8) though).

Martin

hello martin, it's really cool that you've finally done your amazing code in SM ! 😀 for me it'll be much easier to understand (i hope 😕 ) because there's no 'language gap' anymore like with the one you did in SE 🙂

edit : it's confusing as well apparently 😕 i see that you've integrate the LPF with the delay in one code..

martinvicanek · 19 Apr 2011

Hey Bert,

good to meet you here! Yes, I stuffed all I could in code. I just love the SM code module! 😉 The reason why I haven't broken it down in smaller parts was mainly to avoid unnecessary I/O (better performance?). I tried to use comments to make it readable for others, but I guess it is always harder to read other people's code than your own. If you have specific questions I'll be happy to respond.

Martin

TomC · 19 Apr 2011

martinvicanek wrote: Since this is my first SM project, I am looking forward to receiving comments and suggestions from the gurus 🙂

A division is MUCH more expensive (CPU-wise) than a multiplication. After a quick look I've found several places where you can remove them:

- Bandpass module: instead of feeding "SampRat" into the code-primitive use "1/SampRat" and replace the "whatever/samplerate" statements by "whatever*samplerate" statements. I recommend to rename "samplerate" appropriate (I used "invsamplerate") to avoid confusion.

- ASDF module: do the same for "basefreq". Additionally you use about one zillion divisions with the variable "semi". Do the same here, replace "float semi=1.059463094359;" by "float invsemi=0.9438743126819565;" (that's the result of 1/1.059463094359) and use multiplications instead. If the original "semi" is not used anymore after that you can delete its definition.

I only had a quick look, so if there are more avoidable divisions somewhere else you know now what to do 🙂 You'll save tons of CPU-cycles this way.

Tom

TomC · 19 Apr 2011

martinvicanek wrote: Oddson, the delay constants are calculated in stage(2) so the user can switch the tonal range without having to restart. At hop(4096) it does not hurt.

At higher sampling rates (where your CPU is fighting anyway) it WILL hurt. Compute the delays in GREEN and update the results only when the user actually changes the tonal range. That's only ONE single computation per tonal range change.

Tom

martinvicanek · 20 Apr 2011

Many thanks, Tom! Yes, divisions are expensive. I tried not to use them in the "inner loop" (the part of the code that is executed frequently) but you are right, they could be avoided at the other places, too. Thank you!

Martin

RunBeerRun2 · 20 Apr 2011

I like the new bass guitar range, works pretty well!

I added an E0 on the note selector, my 5-string tuned down to F# tracks well w/it.

martinvicanek · 22 Apr 2011

RunBeerRun, good to hear that it works for you, too! If you really like bass, you can also mix the original sound with an octave down synthesized sound. Actually it was the search for a decent octave effect that started the whole project.

mccy · 12 May 2011

Great! Tested it today. Couldn't decide if I like Grrrr better or thisone, but thisoe has Midi 🙂. Tried it with Saxophone-Playing and I think I will use it occasionally to transfer saxplaying to midi when I don't wnt to use a keybord. It works really well!

All one would need now is a decent pitch modifyer to get some autotuner and Midi Harmonizer stuff. There was one in the "Adern" Modular Package for Scope... Is there something usable for Synthmaker?

Martin

EDIT: Found Ssambeans and MyCos and the reaktor Stuff. Very impressed. A harmonizer shouldn't be a problem. I once tried to build an autotuner on Scopes SDK, so that could be harder, although I think SMs possibilities are superior.

martinvicanek · 12 May 2011

Hey Martin,

good to know it works for sax! Actually I am not entirely satisfied with the MIDI conversion - it is not as responsive as the analog synth. I suspect it has to do with the stream-to-green conversion, which apparently cannot be done faster in SM than using the tick100 module.

I have a pitch shifter with autotune function ready, I just need a quiet moment to put it up. Bear with me, or should I say "stay tuned"?

Martin

mccy · 12 May 2011

GRRRRREAT! I've done a quick MIDI shifter (which did not need any of your modules of course, but it was the first step to build an autotuner I thought ...) (It's fun to play ones own voice as a harmony to your own singing!!!), but faild with the autotuner, my first quick build just jumped wildly arround which was a quite funny effect 😉.

P.S. I've read somewhere, that someone did a module to devide the Tick100 into a faster one (even a 1000?)... can't remember exacly if it worked well or not.

1000 Thanks

Martin

EDIT: Know now, what I did wrong in the autotuner. I'll give it a second try, even if it will be worthless compared to a solution of a real coder.

trogluddite · 12 May 2011

mccy wrote: Tick100 into a faster one (even a 1000?)

There's no way to do it internally in SM, though many people have tried using lots of different methods - there just seems to be an inherent limit to how many you can generate. Nix has been developing a very sneaky method, by sending fast MIDI events into SM plugins from an external 'Tick Generator' made using MAX/MSP. You can see his post HERE. It is very promising, but it does require some extra software, and setting up some special routing in SM/sequencer to make it work.

nix · 13 May 2011

It seems to go up to 22050 hz, which is the limit of MAX /msp 'bangs'. Let me know how many hz you need and I'll bang(hehe) out an.exe if you want to pursue this avenue. I'll make it adjustable actually soon. It is very close to sample accurate on my machine(actually, I'll do some tests and post up), but it failed miserably on AngularMomentum's system.

mccy · 13 May 2011

Here comes a combination of your and MyCos Work... You can play your own voice autotuned via keyboard in realtime as a second voice to your (untuned) voice.

Have fun!

Martin

EDIT: Trying a faster version: Tried it with the fast Power Module, but didn't get it to work. Is there a MONO fast Power module anywhere? I bet it's a problem with poly... ...EDIT: Ah, got it, there is a stream power 🙂, should work, will try later...

mccy · 13 May 2011

Fast version...

mccy · 13 May 2011

EASY AUTOMATIC TUNER, working great !!!

martinvicanek · 14 May 2011

Nice integration job, mccy!

trogluddite · 26 Jun 2011

Here's the results (so far) of some experiments I've been doing using a variation on Martin's correlation method. In this case it is a 'mutated' idea stolen from the way FFTs work. Rather than auto-correlating with a delayed copy of the original signal, the audio is correlated with a bank of quadrature oscillators - i.e. the combined correlation with both the sine and cosine function of the desired frequencies. I chose this because the quadrature oscillators can be programmed with a very small chunk of code (as long as the sines/cosines are calculated in green) - it's using about 2-3% of my Q6700 CPU to scan 8 octaves of semitones, despite using no hopping at all.

So far, I'm just using the correlates to drive a funky frequency display - I need more time to study martin's clever code for deriving the root frequency using the weightings and interpolation. You'll also see that there is an audio output. As the design is based around FFT ideas, I wondered whether the inverse function could be calculated to reconstruct the original signal. It works surprisingly well, despite not using sub-harmonics of the sample rate (as a true FFT would do). It can even make a very crude polyphonic pitch shifter - though a bit noisy (I think because the quadratures are not locked in phase to the sample rate?) Still needs some work - the quadrature oscillators are free running, so the accumulation of rounding errors eventually makes it unstable (watch your speakers/ears!!) - when you see the Freq display start to get a bit random, you can press the PANIC button to reset the oscillators. The main module has 3 other inputs... -Base Frequency. The lowest freq shown on the display -Averaging. Scale up the time that the correlation is averaged over - can get some nice 'harmonic resonator' sounds with long settings. -Scale. Magnifies the display.

Next thing I'm looking into is using the proper FFT sub-harmonics - I think a very efficient sin/cos lookup-table should be possible, knowing that the table would always be indexed in integer numbers of samples, which ought to solve the instability problems. Still not as efficient as a true FFT, don't think, but at least it could be done all in streams.

martinvicanek · 28 Jun 2011

Amazing stuff, Trog!

As to your free running oscillators, a possible remedy could be to use Goertzel's algorithm or some sliding-window variation of it? Actually I am experimenting with this method to build a chord analyzer. So far I have a setup for three octaves, so you clearly beat me there. 🙂

Surprising how well the re-synthesis works for zero pitch shift (less so for nonzero shifts). Did you realize that when you feed in a sine you get a distribution of detected frequencies with considerable side lobes? This is inherent to all short-time FT (physicists call it uncertainty principle: you can't determine both frequency and time simultaneously). My guess is that this is the reason for the "noisiness" in pitch shifting.

Oh, the method I use for interpolating the root frequency is quite straight forward: take the semitone delay with the smallest autocorrelation. Evaluate also the autocorrelation for the two neighbors. Assume that the autocorrelation is a quadratic function of delay, i.e. draw a parabola through the three points. Now find the minimum to locate the best matching frequency. It is not a big deal to work out the maths, only slightly complicated by the progressive spacing between semitones in the delay time domain.

trogluddite · 28 Jun 2011

Thanks for the tips and ecouragement - the Goertzel algorithm looks very economical, I shall have to give it a try.

After some tests with sine sweeps etc., I managed to work out empirically what was going on with the side bands - having played around with FM and ring modulation so much in the past, I feel a bit dumb for not recognising the problem! I suppose that the big issue is that the side bands retain their linear difference from the detection/reconstruction frequencies (i.e. they are frequency shifted rather than pitch shifted).

I'm hoping that a little extra tuition from a maths grad' friend will get me a bit more up to speed with the equations - resonating quadrature filters just about makes sense to my engineer brain, but most of the articles on FFT, wavelets etc. that I've read look like secret codes of the illuminati to me!. Still, the empirical experiments are keeping me entertained with their strange 1950's sci-fi noises in the meantime!

P.S.) Interesting too, to see Heisenberg come up in a DSP context - I'd always associated the uncertainty principle with quantum physics. I always felt that we are too much a society of 'specialists', so I'm always fascinated by these little examples of the 'holostic-ness' of science and technology.

BertAnt · 3 Jul 2011

martinvicanek wrote: As to your free running oscillators, a possible remedy could be to use Goertzel's algorithm or some sliding-window variation of it? Actually I am experimenting with this method to build a chord analyzer. So far I have a setup for three octaves, so you clearly beat me there. 🙂

thats what i have in mind too, using single goertzel as a detector for each semitone instead of doing FFT for the whole audio, can make the polyphonic pitch extraction much easier... it's pretty much the same concept with the previous multitap cancellation delay i guess, only with goertzel, there shouldn't be problems with polyphony 😉

i've done some tryouts too in reaktor, but so far i found sometimes it still responds too long on low notes, which makes it difficult to play in realtime... but the 'sensitivity' of it is very promising, it can detect notes within a chord quite accurately...

martinvicanek · 3 Jul 2011

Polyphonic pitch extraction would be very cool, but I doubt it can be done in real time. Consider this:

We can do monophonic pitch extraction by autocorrelation (or AMDF, it does not matter at this level). After one cycle the signal starts folding back on itself, and after two cycles the correlation is complete, so by that time we can be sure what the fundamental frequency is. Two cycles for a low E string (guitar) are 24ms, which is just about what you can still tolerate for live performances. So this works OK, provided the signal is actually monophonic.

Now if you go for poly pitch extraction, you have to somehow decompose the signal into single frequencies (STFFT, Goertzel, again it does not matter). For semitone resolution, you would have to analyze 17 cycles (two adjacent semitones differ by 6% in their frequencies). So now we are talking about 200ms! If you apply a windowing function (there are good reasons to do that), the figure gets even worse by a factor of 2 to 3. (You'd still have to separate harmonics from real notes, but that is another consideration, not a fundamental latency limit.)

I find myself trapped in this general reasoning, so I'd love to see someone prove me wrong. At any rate, even a near-real time poly pitch extraction is useful, if not for live performance then perhaps for chord analysis.

trogluddite · 4 Jul 2011

Thanks to Martin's Hilbert port, I managed to fix my oscillator instability problem. Doubt it's very technically accurate, but by using the Hilbert to 'complexify' the input, I can correlate using only one sine wave per frequency band. Not quite as CPU lite as before, but much better than having to generate both sine and cosine for every band, and a least it's now stable!! I've posted it as a 'Graphics' project (HERE) - as Martin has pointed out, the time constants are just too long for pitch extraction with 1-semi resolution at low frequencies, but it works fast enough to make a pretty waterfall style frequency plot.

BertAnt · 5 Jul 2011

martinvicanek wrote: Polyphonic pitch extraction would be very cool, but I doubt it can be done in real time....

what i'm thinking is, if only we could 'model' a proper sensor for 'each' semitones (like 1 channel of the cancellation delay for example) there should be no problem of that excessive latency, given that the sensor works fast and accurate enough.

that way, there's no need to decompose the signal like you said...the sensor would recognize what note present in the audio instantly. and seems like, 1 goertzel per semitones should do fine in theory, considering that it only reacts if the audio contains its frequency (from what was said on wiki : the Goertzel algorithm looks at specific, predetermined frequencies.) 😉

dont know how to achieve it in SM though, but in reaktor you could manipulate polyphony easily so that you could use an 48 voices component instead of using 48 of them for example - which is a huge advantage in CPU usage.

trogluddite · 5 Jul 2011

BertAnt wrote: the sensor would recognize what note present in the audio instantly

From what I've gathered so far,(mostly just looking at the results from what I've so far been able to build), that is not really so easy. The fastest method I've found to date is counting the zero crossings - certainly no use for anything polyphonic, but detection reliably takes one cycle of the input waveform. FFT, Goertzel, and the examples I posted before, all essentially do the same thing - correlation with sine/cosine functions, and their precision is always a function of the size of the window. For sure, the peak of the response will be at the desired frequency, but another note close by and lower in volume could easily be masked if the window is too short.

The way I think of it is like detuning oscillators until you can hear that lovely slow beating as they drift in and out of phase - now imagine listening to a very short burst of that sound, just a few cycles. How sure could you be that there are two frequencies and not just one? You might even catch the point of cancellation and hear almost nothing! The beating between the notes is what gives you the extra information telling you that there are two tones very close together - and for that, you need to hear a longer section of the waveform.

If you have a look at the 'waterfall plot' schematic that I noted earlier, it has an input for changing the averaging time, and it makes a huge difference to the shape of the plot - a setting of one approximates to just a couple of cycles (if I got my maths right) and all you see then are big round fuzzy lumps; multiply the time by five, and you can start to pick out individual notes and their harmonics. At twenty you can discern notes within chords, but the display is looking decidedly sluggish by this point! The correlations I've used and the Goertzel algorithm are pretty much just different forms of the same thing in principle, and the response I got with a Goertzel were very much the same. (I ditched it in the end, the need to 'bin' the results every N samples oddly made it less CPU efficient - SSE assembly makes arbitrary length loops a little tricky)

From what I've read about quality 'Gutar to MIDI' convertors, they attain a fast response by analysis of the picking transient of the string (a variation of physical modelling I assume) - but I never saw any detail in the public domain about the algorithms, and of course, it would be of no use for anything other than plucked strings.

datsound · 26 Jan 2012

You could do some very good polyphonic pitch extraction in real time IMHO.

I dont know anything about the FFT and the maths functions for this, so i did my silly pitch extraction program once based on simple modules, but it worked pretty well!!! (except for pitches under 200hz that are slower to detect of course)

Ok here is the magic idea: (drumroll)

Take a bandpass filter, arrange it with a very narrow range, sweep it in pitch range from C1 to C10 in a continuous sweep, so that every second it scans through the entire range and sends big peak information on the audio frequences that are present.... from my experience you can detect a regular instrument, such as guitar, piano, or whistle about 4 times a second from one bandpass filter, and you can draw a pretty accurate graph of the pitches being played.

so you can use 10 filters, and it is pretty computationally efficent.

Here is a photo of frequency detection using a sweeping bandpass filter: the sound is a high pitched sine wave. also cant you just use FFT?

i did a frequency detector for whistling anyway and it was vaguely accurate, enough to write some midi, and that was only with 2 BP filters to collect the data...

floranicolas · 6 Feb 2012

"Average Magnitude Difference Function" (AMDF) or the similar average squared difference function (sometimes called "ASDF") or autocorrelation. these methods make no assumptions regarding the signal other than that there is some degree of periodicity. they are mostly equivalent to each other in theory (the ASDF hits a minimum exactly where the autocorrelation hits a max).

nix · 6 Feb 2012

0 crossing doesn't go any faster than 2000 samples on MIDI note 28 @44,100 hz samplerate I was wondering, hmm, so could we take the most common value before 2000 samples? Say if we take the first MIDI note that occurs 8 times- reading the values at samplerate- can we correlate our data like that to increase speed? Cheers

Chaoslala · 20 Apr 2012

Don't know how much latency it could take but i experiment with the FFT display module.

Three note played and visible in the graph. Try to extract the max value and his index of the array. It works for the first pitch. I could extract the segond one but with some bug. trying to erase the first note from the array.. Must continue later..

trogluddite · 20 Apr 2012

nix wrote: I was wondering, hmm, so could we take the most common value before 2000 samples?

This depends a lot on the input waveform - it can be prone to octave errors. For example, I have experimented a lot with tracking of guitar signals, where very often the first harmonic (2 * pitch) is dominant. To some extent this can be made better by careful filtering of the input signal, or by multiplying the FFT values by weighting constants to shift the "focus" of the algorithm to lower frequencies. Another method uses the fact that harmonic peaks must be separated by multiples of the root frequency. So you can look at several peaks in the FFT, and determine the common factor that separates them - though even this may be fooled by waves that contain e.g. only odd harmonics.

nix · 26 Apr 2012

Thanks Trog, I loaded up a display and looked at the first values of the 0 crossing pitch detection method. The same numeber recurs at a high multiple of times, as I was watching at samplerate- so u r soon dealing with quite a lot of values.

I hope yous find this interesting, there is a sample of some playing at the end of the thread. This is my home-made polyphonic synth guitar.

The hex pickup was made by ubertar, and Oddson wrote the counter-> http://www.kvraudio.com/forum/viewtopic.php?t=323713

oddson · 27 Apr 2012

nix wrote: Oddson wrote the counter->

I did? What counter?

nix · 27 Apr 2012

Yep, It was my first SM project, apart from 3 osc VA. Here's the thread: Pitch to midi in SM? You built the 0 crossing counter, which I modded a little(the .osm was called 'zx'). I took out a stabilising variable. I'm loving this iteration, which doesn't trigger MIDI, just drives the osc freq input. There is no noticeable latency.

RunBeerRun2 · 16 Jun 2012

Wow the feel of this when used to control an internal synth (not by MIDI output) is very good! I've started an audio triggered synth for my bass guitar, not only does it track fast but very accurately.

mccy · 25 Jul 2012

Yes, the same here. Today I realized a thing that was in my head for a longer time now and ended up... yes, in a bass/guitar synth. These are the coolest bass sounds I've ever played. There is this new (was it new, or did I just found it?) Surfer EQ, which does exactly what is possible with Martins pitc hrecognition and which was the second thing which came into my mind when I found it here. It's just great to get that combined with synth sounds & original bass sound... WOW!!!! For now it takes way too much DSP, but is in no way optimized. 10000000000THANKS for this wonderfull modul!!!!!!!

trogluddite · 26 Jul 2012

mccy wrote: For now it takes way too much DSP, but is in no way optimized

Strange that this should come up right now. Philter prompted me to have another look at my old 'GRrr' pitch-follow synth. I've been trying to improve the tracking for the last couple of weeks (it was only a basic "zero crosser"); but all my attempts at other methods were no better. So I thought I would give up trying to stretch my head around the maths, and have a go at optimising this one - as you both say, nothing else can seem to manage to track a bass guitar as well as this does. I have about half the code converted to assembly already - no optimisation yet, but I can see plenty of places that some CPU cycles can be saved. I'll post up anything that looks like progress.

Wonder what it is that attract so many bass players to this? Guess we must be more adventurous than our stick-in-the-mud short-necked brethren! 😈 😉

oddson · 27 Jul 2012

trogluddite wrote: I've been trying to improve the tracking for the last couple of weeks (it was only a basic "zero crosser"); but all my attempts at other methods were no better.

nix wrote: ... There is no noticeable latency.

Yeah... it tracks OK (although prone to octave error) but it doesn't matter if it's off base (bass?) in the first milliseconds as your brain takes longer to track the pitch than it does. Low frequency fundamentals have a longer theoretical limit for pitch detection but I think the brain v. machine match-up is more favourable at low frequency.

mccy · 27 Jul 2012

I finally decided to post 'my' basssynth (too simple to call it a synth somehow, but I love it) in the registrated users forum. It's not really my work, I just took, what I found in this place and combined it for a good idea. All the real coding others did. Anyway, I don't want to see thisone get a free vst for now, but I wanted to thank this GREAT community and not allways hide away with my output.

I would love to see a cooperation to make this thing (maybe nobody will need it anyway, when trog will release his new Grrrr) THE basssynth. I love the attempt of the hamonics dialing EQs & next simple step will be to make all EQs working with Attack & release for cool Wah sounds!

1000 thanks to dozius, exo & martinvicanek - hope I did not forget anyone!!!!

nix · 27 Jul 2012

oddson wrote: trogluddite wrote: I've been trying to improve the tracking for the last couple of weeks (it was only a basic "zero crosser"); but all my attempts at other methods were no better.

nix wrote: ... There is no noticeable latency.

Yeah... it tracks OK (although prone to octave error) but it doesn't matter if it's off base (bass?) in the first milliseconds as your brain takes longer to track the pitch than it does. Low frequency fundamentals have a longer theoretical limit for pitch detection but I think the brain v. machine match-up is more favourable at low frequency.

The bass pitches are noticeably laggy for MIDI. It is 1600 samples for high e, and 2600 for low e(@44100). The mind registers this. With the direct freq conversion it's sweet, just like playing guitar. I'm getting it better all the time. Will post up some demos soon. BTW, I am doing it polyphonically, as I have 2 guitars with hex pickups. I have heaps of smoothing tricks in there, can share the .osm with you oddson, if u would like it.