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

@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)

Hi,

happy to see that this is useful to someone ...

It's incredible how sometimes a patch can end up in a simple form, far from the initial much more complicated layout.

I'll check your patch, Lead. Thanx !

Nau

Hi everyone, I'm also interested in noise/harmonic sound detection, and can't find any external or object that does this kind of analysis...

I'm very happy to see you've been working on it, and I would love to try the patches discussed here, but sendspace erased the files uploaded!!!!

I wonder if you could send upload them again, or at least put them somewhere in this forum or somewhere for people to download it??? It's a shame not to have attachments allowed....

Thanks a lot!!!

Martin

Hi metronomme84,

as the switching from [fiddle~] to [sigmund~] nearly solved my problem, I didn't take the time to go further in this 'harmonicity testing'. I'd be still interrested though.

All I can give to you is the 'audiotomidi' testbench allowing to 'midify' an incoming musical mono signal (the one posted month ago). I propose a set of 'good parameters values' when I play violin in it, and you'll find 3 more 'slots' ready to receive the 'parameters values you'd want to test. It is then easy to switch from one to the other (but they work in parallel and thus eat up four times the cpu of a single [sigmund~] instance) and compare results.

http://www.sendspace.com/file/qq8i0b

Make sure you set the midi channel feeding the right inlet of [essai_sigmund_flow] with an integer.

Have a nice day

Nau

Back to this "harmonicity" test ...
There's a "coherence" spectral test in I09.sheep.from.goats.pd , might be useful.