Electronic Guitar Tuners

keskiviikko, 22. elokuuta 2012 7.56.37 UTC+3 rickman kirjoitti:
> On 8/21/2012 10:41 AM, kalvin.news@gmail.com wrote:
> 
> > tiistai, 21. elokuuta 2012 16.27.20 UTC+3 rickman kirjoitti:
> 
> >>
> 
> >> Yes, I thought of that, but to make it as general as possible it would
> 
> >> need to accommodate alternate tunings.  I would like to make this a
> 
> >> chromatic tuner capable of tuning to any note on the scale.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Rick
> 
> >
> 
> > The notes are at discrete frequencies anyway, so getting a coarse frequency from the highest FFT peak and then setting an appropriate (pre-computed, lookup-table) band-pass filter coeffs to the specific note. You would be able to attenuate noise and harmonics, and get a more sine-like signal which may be easier to analyse. Just an idea.
> 
> >
> 
> > - Calvin
> 
> 
> 
> Yes, but knowing which of the peaks is the fundamental is not so easy. 
> 
> The fundamental is not always the highest.  It would be better to find 
> 
> multiple peaks and find the common divisor.
> 
> 
> 
> Rick

Disclaimer: I am not familiar with the guitar (or any other instrument) vibration characteristics.

If you know that you what instrument you are tuning, maybe you can assume something about the fundamental's and the harmonics' relative characteristics and the set the bandpass filter to correct frequency in order to make the frequency analysis a bit easier.

- Calvin

On 8/13/2012 6:52 PM, rickman wrote:
> I am being asked to design a gadget that has some special features, but
> also includes a guitar tuner. I have looked at the web a bit, but not
> found any good references that show exactly how a tuner works. One paper
> I found talked about a rather complex "constant Q transform". I just
> don't think the $10 tuner I have uses anything that complex. I'm
> thinking they are doing a PLL sync to the input or something more like
> that.
>
> One reference I found talks about using a peak detect to measure period
> rather than frequency like an FFT. I would think the FFT has too little
> resolution unless it is very long.
>
> Anyone know how the commercial low end gadgets really work? Maybe I'll
> take mine apart, but my bet is they are using chip on board with the die
> under a dab of black goo.
>
> Rick

I've run some simulations on using auto-correlation to detect the pitch 
and it has some very desirable properties.  It seems to be relatively 
immune from noise and out of band signals.  It is not as sensitive to 
the exact frequency as I would like, but likely this is more a 
fundamental limitation of measuring frequency with a short time sequence.

I am going to try the measurement over a longer multiple of the 
frequency of interest.  I should be able to reason out the result, but 
it is easier to just give it a try...

Rick

On 8/21/2012 1:41 PM, robert bristow-johnson wrote:
> On 8/21/12 9:31 AM, rickman wrote:
>> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>>> On 8/18/12 10:50 PM, rickman wrote:
>>>>
>>>> My current thinking is that no matter what method I go with, it
>>>> needs to
>>>> be very high "performance", meaning highly accurate and reasonably
>>>> fast.
>>>> I believe the market is not large for this particular device. So better
>>>> to go Cadillac and charge a price premium than to try to find a spot in
>>>> a crowded, high volume market.
>>>
>>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what you'll
>>> want to do.
>>
>> I'll have to lookup the AMDF and ASDF.
>>
>
> Average Magnitude/Squared Difference Function
>
>
>>
>>>> So that means, will an auto-corr approach do a good job of resolving a
>>>> fraction of a cent for a tuner in less than say the two or three
>>>> seconds
>>>> a note will sustain? I would have to consider just how accurate the
>>>> auto-corr might be.
>>>
>>> pretty accurate, but *any* pitch detector *can* possibly have octave
>>> errors (it's what can happen if you have inaudible sub-harmonics). then
>>> you need to program the thing to have a little bit of common sense to
>>> avoid some of the dumber octave errors. i think that looking for energy
>>> at the frequency of the fundamental is a dumb octave error because there
>>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>>> alg might think that either of those is the fundamental frequency.
>>
>> Yes, but the harmonics will fall at certain ratios which won't match if
>> you pick a harmonic in place of the fundamental. Also, won't the energy
>> of the harmonics add into the lag for the fundamental?
>
> then you'll be sweeping some kinda comb on the data.
>
>>> does your DSP or whatever processor have conditional branch
>>> instructions? you don't need to compute the whole autocorrelation (all
>>> of the lags) for each and every sample. in fact, you might just compute
>>> *one* lag per sample and have a couple of special states where you set
>>> up the autocorrelation and where you process or scan the results of the
>>> autocorrelation to come up with a period length. and you can do some
>>> interpolation-like stuff to get the period to a precision of a fraction
>>> of a sample period. i.e. look for the peak where it falls between two
>>> integer lags. it's not hard.
>>
>> I get the interpolation thing, that's fairly obvious, but I don't
>> understand the comment about the one lag per sample and special states.
>
> it's a programming issue. some samples you will compute *one* point of
> the autocorrelation. and when you have filled up the table, you need to
> examine what you computed, that is a special mode of your program and
> you won't have time to compute a new point of autocorrelation and you
> won't need to. it's a manner to distribute the work over many different
> sampling periods to reduce the worst-case timing cost.
>
>> The problem with interpolation is that it can only interpolate to some
>> extent. Essentially this is a method of measuring the period of signals.
>
> yup and that period may very well not be an integer number of samples.

I did some simulations looking at a tone in the presence of harmonics 
and in the presence of noise using the autocorr, the ASDF and the AMDF 
with the sample rate far above what is required by the Nyquist 
criterion.  The autocorr gives big fat peaks that are hard to pinpoint. 
  The ASDF has somewhat fat valleys but is not much disturbed by the 
noise.  The AMDF without noise has very sharp valleys which are very 
easy to pinpoint, but with noise these get rounded.  But with even high 
amplitude noise the valleys of the AMDF are easier to distinguish than 
the ASDF.

I read somewhere here that another poster preferred the ASDF in the 
presence of noise.  The values of the AMDF are more affected by the 
noise than in the ASDF, but it looks to me like pinpointing the proper 
peak (or is it anti-peak?) value is easier with the AMDF even with the 
noise.  I still have some other testing to do.

Meanwhile I expect my customer to pick the low cost spread and not do 
the tuner option at all.  But who knows?  Customers can be strange beasts.

Rick

rickman skrev 2012-09-05 22:13:
> On 8/21/2012 1:41 PM, robert bristow-johnson wrote:
>> On 8/21/12 9:31 AM, rickman wrote:
>>> On 8/18/2012 11:40 PM, robert bristow-johnson wrote:
>>>> On 8/18/12 10:50 PM, rickman wrote:
>>>>>
>>>>> My current thinking is that no matter what method I go with, it
>>>>> needs to
>>>>> be very high "performance", meaning highly accurate and reasonably
>>>>> fast.
>>>>> I believe the market is not large for this particular device. So
>>>>> better
>>>>> to go Cadillac and charge a price premium than to try to find a
>>>>> spot in
>>>>> a crowded, high volume market.



>>>>
>>>> then i'm pretty sure that autocorrelation or AMDF or ASDF is what
>>>> you'll
>>>> want to do.
>>>
>>> I'll have to lookup the AMDF and ASDF.
>>>
>>
>> Average Magnitude/Squared Difference Function
>>
>>
>>>
>>>>> So that means, will an auto-corr approach do a good job of resolving a
>>>>> fraction of a cent for a tuner in less than say the two or three
>>>>> seconds
>>>>> a note will sustain? I would have to consider just how accurate the
>>>>> auto-corr might be.
>>>>
>>>> pretty accurate, but *any* pitch detector *can* possibly have octave
>>>> errors (it's what can happen if you have inaudible sub-harmonics). then
>>>> you need to program the thing to have a little bit of common sense to
>>>> avoid some of the dumber octave errors. i think that looking for energy
>>>> at the frequency of the fundamental is a dumb octave error because
>>>> there
>>>> could be more energy at the 2nd harmonic or the 3rd harmonic and your
>>>> alg might think that either of those is the fundamental frequency.
>>>
>>> Yes, but the harmonics will fall at certain ratios which won't match if
>>> you pick a harmonic in place of the fundamental. Also, won't the energy
>>> of the harmonics add into the lag for the fundamental?
>>
>> then you'll be sweeping some kinda comb on the data.
>>
>>>> does your DSP or whatever processor have conditional branch
>>>> instructions? you don't need to compute the whole autocorrelation (all
>>>> of the lags) for each and every sample. in fact, you might just compute
>>>> *one* lag per sample and have a couple of special states where you set
>>>> up the autocorrelation and where you process or scan the results of the
>>>> autocorrelation to come up with a period length. and you can do some
>>>> interpolation-like stuff to get the period to a precision of a fraction
>>>> of a sample period. i.e. look for the peak where it falls between two
>>>> integer lags. it's not hard.
>>>
>>> I get the interpolation thing, that's fairly obvious, but I don't
>>> understand the comment about the one lag per sample and special states.
>>
>> it's a programming issue. some samples you will compute *one* point of
>> the autocorrelation. and when you have filled up the table, you need to
>> examine what you computed, that is a special mode of your program and
>> you won't have time to compute a new point of autocorrelation and you
>> won't need to. it's a manner to distribute the work over many different
>> sampling periods to reduce the worst-case timing cost.
>>
>>> The problem with interpolation is that it can only interpolate to some
>>> extent. Essentially this is a method of measuring the period of signals.
>>
>> yup and that period may very well not be an integer number of samples.
>
> I did some simulations looking at a tone in the presence of harmonics
> and in the presence of noise using the autocorr, the ASDF and the AMDF
> with the sample rate far above what is required by the Nyquist
> criterion.  The autocorr gives big fat peaks that are hard to pinpoint.
>   The ASDF has somewhat fat valleys but is not much disturbed by the
> noise.  The AMDF without noise has very sharp valleys which are very
> easy to pinpoint, but with noise these get rounded.  But with even high
> amplitude noise the valleys of the AMDF are easier to distinguish than
> the ASDF.
>
> I read somewhere here that another poster preferred the ASDF in the
> presence of noise.  The values of the AMDF are more affected by the
> noise than in the ASDF, but it looks to me like pinpointing the proper
> peak (or is it anti-peak?) value is easier with the AMDF even with the
> noise.  I still have some other testing to do.
>
> Meanwhile I expect my customer to pick the low cost spread and not do
> the tuner option at all.  But who knows?  Customers can be strange beasts.
>
> Rick

Didn't see the beginning of the thread, but if anyone wants a Guitar
tuner you can get the PolyTune from TC Electronics.

http://www.tcelectronic.com/polytune.asp

It should retail below $100.

There is also an iPhone app at $3.99
http://www.tcelectronic.com/polytune-iphone-app.asp

TC Electronics is a professional audio company. (U2 is/was one of their
customers) so it is not a cheap gizmo.
They have applied for a lot of patents on this technology, which
you would want to avoid.

BR
Ulf Samuelsson

On 10/22/12 5:51 AM, Ulf Samuelsson wrote:
>
> TC Electronics is a professional audio company.

there is no doubt of that.

> (U2 is/was one of their
> customers) so it is not a cheap gizmo.
> They have applied for a lot of patents on this technology, which
> you would want to avoid.

the use of autocorrelation for pitch detection has existed long before 
TC existed as a company.  lotsa prior art.  but i believe, especially 
when they were involved with IVL and Helicon, that they developed some 
patented pitch detection techniques.

if anyone is experimenting with pitch detection, either with AMDF, ASDF, 
autocorrelation (which is ASDF turned upside down), feature detection 
and matching, zero-crossing (which i don't recommend), etc. there is 
little danger of stepping on someone else's *valid* patent.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."