Hi there,

I am wondering whether it would be possible to create a test following a [fiddle] (or what will be proposed here) to analyse incoming audio and test in realtime whether this is 'noise' (far-from-harmonic audio) or 'instrument' (rather harmonic audio).
I'd see it as a rough evaluation of the 'quality' of the signal in terms of harmonicity leading to a numeric value that I could test to finally reduce it to a binary result : 'sufficiently harmonic' / 'insufficiently harmonic'.

When I midify audio with Pd, I read what [spigot] outputs (every 10ms for example) and convert it to a noteout midi message. As the audio is my violin playing realtime, it happens that between (rather) clean notes transitory audio (bow direction change, or any noise catched by the piezo transducer) is handled by [spigot] and a (hazardous) fundamental frequency is outputted. This leads to kinds of 'jitter' in the midi playing, with clean notes sometimes separated by very short but irritating 'random' (often high) notes .

So my (stupid ?) strategy would be to avoid those 'silly' notes to be sent, using the test idea described above to drive another [spigot].

Of course the 'harmonicity' test is only an idea. Other strategies welcome !

Any idea ?

thanx,

Nau

I've had this problem with analyzing guitar pitch (are you using [fiddle]?). The pick noise tends to be interpreted as very high notes. What you might want to try is to filter out the outliers. You can try and filter them using a running median of the MIDI notes (see [median_n] from mapping). Longer "n" leads to better filtering, but more delay. Probably worth a look before resorting to spectral analysis.

Yes Maelstorm, I use [fiddle] (edited initial post, sorry).

I'm already filtering notes higher then a given value, while the 'median' strategy is too 'unmusical' to me (it's not rare to play a bunch of low-pitched-close notes and then 'jump up' two octaves or so to play a couple of notes and then come back down...), and latency has to be maintained short.

I could have said I already filter audio with a (40hz-5000hz) bandpass, also.

Thank you anyway,

Nau

@Maelstorm said:

Probably worth a look before resorting to spectral analysis.

Would pitchnoise~ be any good as a sort of spectral prefilter? http://crca.ucsd.edu/~jsarlo/pd/

Harmonic/inharmonic monophonic timbre separator. Pitchnoise~ basically separates the "pitched" part of a sound from the "noisey" part of a sound.

...or maybe thresher~ from fftease http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/FFTease/

Also, if your problem is mainly choppy data you might want to try sigmund~ for pitch tracking, as it has more features for addressing this than fiddle~.

Thanx Lead !

I'll check this this evening, for sure !

Nau

@nau said:

... while the 'median' strategy is too 'unmusical' to me (it's not rare to play a bunch of low-pitched-close notes and then 'jump up' two octaves or so to play a couple of notes and then come back down...), and latency has to be maintained short.

I agree that using a running median is a bit cumbersome in terms of latency, but [fiddle~] outputs MIDI notes as a steady stream. So unless you're playing notes faster than [fiddle~]'s hop size, they shouldn't disappear. Maybe the first number in the stream will be ignored, but once it's repeated it should be considered a hit. And if you're playing that fast, pitch tracking is going to be a pain in the ass.

Thanx Maelstorm for your intervention, it seems that I discarded too fast the 'median' strategy. I trust your skills, so I will start this 'Pd evening' with it.

Of course the latency issue remains, but it is also probably much less cpu-intensive than frequency domain computations.

Nau

euh, when I try to create a [pitchnoise~] object, I get those error lines :

/usr/lib/pd-extended/extra/pitchnoise/pitchnoise~.pd_linux: /usr/lib/pd-extended/extra/pitchnoise/pitchnoise~.pd_linux: wrong ELF class: ELFCLASS32
pitchnoise~
... couldn't create

I guess this is because I use 64bit TangoStudio distribution and not 32bit, and that I will have to compile the sources for my architecture...

I will definitely go on playing with [median_n] tonite

Nau

Ok, [median_n 3] gives decent filtering, but in my case as my [fiddle~] uses a window of 1024 (G string of my violin is midi 55 and this sets the limit to 45), a note value is outputted every 11.6 ms.
So 3 hops are a lot of time ... for live perf purpose.

Another thing : Lead advised me to look at [sigmund~]. So this becomes my next strategy (I see that hop size seems to be set by user independently from npts).

I'll try 'frequency domain filtering' later.

Thanx

Do post your patch when done, would be useful to a few people i'm sure - - attached is a simple noise gate I often put first in the signal chain, maybe it'll be helpful.

edit: Ah, attachments not working for some reason, so here it is via sendspace http://www.sendspace.com/file/5r7hpu

Oh and PS there's a noise reducer in hardoff's DIY2 pack http://puredata.hurleur.com/sujet-1982-diy2-effects-sample-players-synths-sound-synthesis

thanx lead, I'll check this ... but I don't have no time these days

Nau

Heeyaaa,

I've been playing with [sigmund~] for some hours to discover it's 'special mojo', and I must thank Lead for his advice.
Now I know that [sigmund~] is more efficient than [fiddle~]. So I could replace one by the other and the result was so much better that my first 'filtering' idea becomes much less urgent.

Here is a test bench for this audio to midi conversion. Five instances of [sigmund~] are paralleled so you can switch from one to another and hear the 'accuracy' of the operation. It also uses what I would call 'the [poly 1 1] trick' that replaces manual noteoff handling as infinite notes must be avoided. (found in this forum)

The parameters you'll find in the first instance of [sigmund~] work rather well when I play violin live. But for testing purposes a 'not so in-tune not so dynamic not so precise violin sample' can be sent to the bench and gives a reference for the tests.

I was surprised by the fact that a rather good pitch recognition can be achieved with 'hop' and 'npts' sizes theorically too small for the lowest frequency to be found . And thus was surprised to be able to lower latency more than expected ! Flirting with Shannon's limit ?!

Just open audio2midi_testbench.pd and then the [essai_sigmund_flow] object that lies in it.

To be continued ...

Nau

where can i find audio2midi_testbench.pd

oops ... seems the attached file can't be found !
I'll try to send it again tonight.

Nau

Seems that the file attachment still fails !

Would there be a size limit ?
As I included a .wav sample the size is 2.5Mb

Nau

Just upload it on sendspace with no recipient and post the link here, attachments aren't working for me either.

@nau said:

Seems that the file attachment still fails !

Would there be a size limit ?
As I included a .wav sample the size is 2.5Mb

Nau

Yeah, this forum doesn't like large files. If you need to share audio, you should put it up somewhere else and link to it.

The essai_simund_flow abstraction wouldn't load for me, neither would vectorize. Not sure why, any help?

What a shame !

I'm so sorry, I just posted bad files ... now here are the good ones !

http://www.sendspace.com/file/71xm3r

Nice work dude - plus your violin playing is now my test file

Made this autotune type patch for singing.
I've only tried it on the computer mic so far without accompaniment, so haven't really tested it for accuracy, although it seems to work with my bad singing along to things...

It does however have a super simple noise/singing gate based around spectral brightness (you need the TimbreID library) so I thought I'd post it in case others were working on something similar.

edit: Attachments still not working, here it is via sendspace
http://www.sendspace.com/file/at5s4l
(now with optional "antitune" for the pitch correction, heh)