[LAD] [LAU] So what do you think sucks about Linux audio ?

[Dominique Michel]

Le Thu, 07 Feb 2013 21:21:59 +0100,
Kjetil Matheussen <k.s.matheussen at notam02.no> a écrit :

> William Light:
> > it's interesting to me that free (source and/or beer) music
> > software on
> > OSX and windows has come further than it has on Linux. off the top
> > of my head:
> >
> > http://psycle.pastnotecut.org/portal.php
> > http://www.buzzmachines.com/
> 
> I'm very interested in knowing what you're missing from Psycle and 
> Buzzmachines
> that Radium doesn't have...

This is not related to any of the software you mention, but what I am
really missing in linux audio is the ability to plug-in my guitar (or
another instrument), play some melody, and get the
corresponding MIDI notes messages in real-time. As the timbre will
differ from one instrument to another, and even from a player to
another, such a tool should provide a visual way to setup the
parameters, that in order to make it easily usable.

Is is a few applications that claim to be able to do that. By example
guitarix  http://linuxaudio.org/mailarchive/lau/2011/1/7/177338
but in practice, it is total unusable.
Quote: "Guitarix offers this, Given, you play with good intonation/a
well tuned instrument, it works OK."

I was never able to make it work even with a well tuned guitar.

In the past, I done such a rt conversion on a dsp. It was working very
well but need some parameters to be carefully chosen. The only way to
chose those parameters are with a visual signal analysis. The timbre of
an instrument is unique, vary with the time and with the play. I used a
memory oscilloscope to do this analysis.

I am a lazy bastard that also have a real life, so I never managed to
learn enough C/C++ in order to translate my dsp56k program into a
GNU/linux software. Some said this would be a piece of cake, but that's
not to me.

The algorithm is very simple. The incoming signal need to be rounded in
order to reject the false maximums that can arise (look at the signal
of a good simple humbuking microphone and you will show them) (this
will reject the high frequencies and is very simple and fast to
implement). This is done with a simple arithmetic mean on the successive
input samples. 1 parameter here: the samples number. Another and obvious
parameters is the input threshold level.

In order to easily adjust those 2 parameters, a visualisation GUI is
the best option. It have to show both the incoming signal and the
same signal after the average operation. It would be best if it would
work like a memory oscilloscope, that is define some threshold and
time period the user want to acquire when some incoming signal is
detected, acquire the samples into a ring buffer in a one shot way, and
display them with the ability to change the x axis period and offset.
As a bonus, this will be the best oscilloscope using an audio card on
linux. 

At that point, 2 separated software can even be made. And yes, I
am missing too a good memory oscilloscope using the audio card on
linux. I know an audio card will never provide the sampling frequency
of a LeCroy, but beside the sampling rate, a GNU/linux oscilloscope
using the audio card is able to provide a lot of the, if not all,
advanced features of a real memory oscilloscope.

After the average is done, and concurrently to it, the program find 2
consecutive maximums of same sign of the signal. A simple comparison (>
or < depending to the sign) of the consecutive samples is enough to do
that. The period of the signal is represented by the number of samples
that separate those 2 consecutive maximums. The program know the
sampling frequency, so, a table can be made with the values of the MIDI
notes for different sampling count intervals, and a simple read of
this table from the number of samples between 2 consecutive maximums
will give the corresponding MIDI note.

The worst case scenario depend on the lowest note that will be played.
The time to find the note = the period of the note + the time between
0 and the first maximum of the signal. I don't know any faster and
simpler algorithm to do that.

Dominique

P.S.: If you wait for me to adapt this software to GNU/linux, you will
wait much longer than if you, or someone else, do it. I try several
times, but I never managed to get enough time, to learn the C, and like
my life is going, both privately and professionally, this will
unfortunately not append in a foreseeable future.

> 
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


-- 
"We have the heroes we deserve."