linuxaudio.org

Le Fri, 12 Nov 2010 00:54:58 -0500,

"Tim E. Real"  a écrit :
> On November 11, 2010 11:06:10 pm Dominique Michel wrote:

quoted text
> > Le Thu, 11 Nov 2010 16:43:41 -0300,

> >

> > Camilo Polymeris  a écrit :

> > > >> For me, a stand alone pitch detection application would be

> > > >> better :

> > > >>

> > > >> audio in -> pitch detect -> midi out

> > > >>

> > > >> You plug the instrument into the audio in, connect the midi

> > > >> out to any midi in in qjackctl, and it is just to play some

> > > >> melody.

> > > >>

> > > >> Ciao,

> > > >> Dominique

> > > >

> > > > There is aubionotes (http://aubio.org/aubionotes.html), which

> > > > claims to do exactly what you want. Don't know how well,

> > > > though. I am trying to connect it to PianoBooster, to see if

> > > > that could be a solution. WaoN could also be an option, I'll

> > > > try that next. Eventually, I'd like an integrated app.

> > > >

> > > > Greetings,

> > > > Camilo

> >

> > Thanks for the tip !

> >

> > > Ok. If someone is interested: I can report that aubionotes works

> > > quite well for the samples I tried (brass mostly, all

> > > monophonic). WaoN is similar, maybe even better, but doesn't work

> > > realtime, it handles pre-recorded samples, only.

> >

> > Same thing here. I think that it must use some kind of fft. The

> > problem with fft and realtime is not the processing power but the

> > time it take before you get a sufficient amount of samples in order

> > to be able to run the fft.

> >

> > Ciao,

> > Dominique

>

> Exactly. I was going to start a thread asking about this. Mind if I

> pitch in? Difference between lowest note on a guitar and next note is

> very small, requiring large number of FFT bins. (If you play a flute,

> you're lucky.) You can put a crappy time domain style pitch shifter

> ahead of the converter to reduce this. (A good freq domain PS may

> have more latency.) It's fun. With practice a normal guitar becomes a

> piano etc...

>

> I've seen polyphonic products advertised claiming zero or near zero

> latency. How do they do it? 

I don't know. If you take a guitar synthesizer, it have a polyphonic

mic, that is one mic per cord (similar to a simple humbucking per note).

They certainly make 6 monophonic note extractions.
Guitar mics take in account only the vertical movements of the cords,

the output signal is the derivative of this movement.
Also, the harmonic content of a guitar note is not constant. During the

attack, the value of the fundamental is the most important signal in

the note, but during the sustain, the value of the fundamental decrease

very fast and the second harmonic become the highest tone in the note.

It is even more complicated when the cord touch the frets because you

will get false maximums of the signal. You can also get hum with a

simple humbucking, and you will get saturation with a double humbucking.
>

quoted text
> I've used FFT, but when told of this delay problem, my friend keeps

>  telling me no, use Laplace transforms. When I studied them (looong

> ago), I could not fully understand how to apply the knowledge.

> Is there a Laplace library out there?

I am not sure, but the FFT is a particular case of the bipolar Laplace

transformation, so I don't think than the necessary time to get enough

samples in order to get a reliable result would be better. The worst

case scenario depend on the lowest note you will able take in account.
>

quoted text
> Wavelets? I studied those as well, but my meagre brain could not

> cement.

If it is what I call "filtre en peigne" in French (comb filter), it can

be an alternative. It is DSP algorythms for them, but I don't know if it

is something for a PC processor.
>

quoted text
> To catch the higher notes first, how about n FFTs with n samplers

> driven by n separate even-tempered clocks, where n is the desired

> number of notes? For ex. 3 octaves, 36 FFTs. I forget why, but I

> think that didn't work out. I think the pesky relation giving the

> delay kept getting in the way. You increase the sample rate and you

> just end up increasing the delay because you need more freq bins for

> the same given resolution. The delay is really governed by the

> smallest difference in notes you want to detect. In guitar's case, I

> found it just passes as acceptable.

>

> Tim.

The fastest algorithm would be to find the maximums of the signal.

The time between 2 consecutive maximums = the period of the note.

The delay would not be constant, but it would not exceed 1+1/2 periods

of the note in the worst case. In practice, it would be something

between 1 and 1+1/4 periods of the note in most (all?) cases.
This will be very easy with an instrument like a flute, but much more

difficult with an instrument like a guitar, because you will have to

take in account the false maximums possibility (when you play very

hard on the cords or when you have a not so good guitar) and the

sustain of the note.
Ciao,

Dominique
--

"We have the heroes we deserve."

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev