20 Oct
2011
20 Oct
'11
1:46 p.m.
Hi LAU,
spectrojack is a little program to display sonogram/audiogram
(however that's called) in a jack setup.
You need gtk 2 to compile it.
It is at: http://sed.free.fr/spectrojack/spectrojack-0.4.tar.gz
(no web page yet, sorry).
If you are adventurous, Lorenzo Sutton says he has
problems with the colormaps' browser in a 32b ubuntu host.
I can't reproduce the bug. If you have it...
(open the menu, "colormaps" then browse to spectrojack-0.4/colormaps
and click on default.txt, the colormaps should be loaded; Lorenzo
sees an error for each colormap, screenshot at
http://sed.free.fr/spectrojack/lorenzo.png)
(that bug is weird) (these are the Italians :))
Apart from that, the display might not be accurate. It's a simple STFT and
maybe I do everything wrong in there. Take it as not-even-beta thing.
Regards,
Cédric.
PS: CC me, I don't read the list for the moment.
20 Oct
20 Oct
10 p.m.
On 20/10/2011 13:46, Cedric Roux wrote:
Hi LAU,
spectrojack is a little program to display sonogram/audiogram
(however that's called) in a jack setup.
You need gtk 2 to compile it.
It is at: http://sed.free.fr/spectrojack/spectrojack-0.4.tar.gz
(no web page yet, sorry).
If you are adventurous, Lorenzo Sutton says he has
problems with the colormaps' browser in a 32b ubuntu host.
I can't reproduce the bug. If you have it...
(open the menu, "colormaps" then browse to spectrojack-0.4/colormaps
and click on default.txt, the colormaps should be loaded; Lorenzo
sees an error for each colormap, screenshot at
http://sed.free.fr/spectrojack/lorenzo.png)
(that bug is weird) (these are the Italians :))
Eh eh :) But it does work very well on my debian amd64 machine ;)
And I'm happy Cédric decide it to release it even if an alpha, as AFAIK
this is the only (open source) realtime spectrogram application for jack
on linux.
Lorenzo.
Apart from that, the display might not be accurate. It's a simple STFT and
maybe I do everything wrong in there. Take it as not-even-beta thing.
Regards,
Cédric.
PS: CC me, I don't read the list for the moment.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:03 p.m.
On Thu, Oct 20, 2011 at 10:00:52PM +0200, Lorenzo Sutton wrote:
There are some weird things in the Makefile, like
LDFLAGS += -L/home/cro/fftw/lib
CFLAGS += -I/home/cro/fftw/include
PKG_CONFIG_PATH=/home/cro/guitarx/i2/lib/pkgconfig:/home/cro/guitarx/lib/pkgconfig
but it compiles and even works.
I don't think that the DSP code is doing what the parameters
would suggest - the visual results don't match.
Could it be that 'l' sets the window size ? It shouldn't,
the window size should be the fft size. Then, if you have
both 'l' and 's', then both together determine the overlap,
so this can't be a separate parameter.
Also, with just a 1 kHz sine as the input, I'd expect all
spectra to be identical, but they are not...
Ciao,
--
FA
(that bug is
weird) (these are the Italians :))
Eh eh :) But it does work very well on my debian amd64 machine ;)
21 Oct
21 Oct
10:03 a.m.
----- Original Message -----
From: "Fons Adriaensen"
<fons(a)linuxaudio.org>
I don't think that the DSP code is doing what the parameters
would suggest - the visual results don't match.
Could it be that 'l' sets the window size ? It shouldn't,
the window size should be the fft size. Then, if you have
both 'l' and 's', then both together determine the overlap,
so this can't be a separate parameter.
Also, with just a 1 kHz sine as the input, I'd expect all
spectra to be identical, but they are not...
that's a bit unfortunate...
I'll have a look at all this, thanks to report.
for s, l and overlap:
s is the fft size (let's say 1024 for an example)
l is the sample count, if set at 512 we compute an fft
each 512 samples. Since fft size is 1024, we append with 512 zeros.
Overlap is how much we advance the input to compute the
next fft. In our example: set to 0, at time 0 we compute with input[0..511]
and next iteration we compute with x[512..1023].
Set to 0.5, next iteration is computed with x[256..767].
Set to 1, next iteration would compute with x[1..512] (normally it should
not advance at all, so setting to 1 is in fact setting to 1-epsilon with
epsilon such that we advance by 1 sample)
The window is computed on the l samples.
I guess all this is not done the standard way... (and I hope
the code does what I say above...)
For your 1k sine, I'll have a look. If you have some time,
it would be great to have a screenshot just
to be sure I see the same thing than you?
And thanks for the testing. The code does not crash on at least
three and half computers! that's great.
Regards,
Cédric.
10:53 a.m.
Bonjour Cedric,
On 10/21/2011 10:03 AM, Cedric Roux wrote:
----- Original Message -----
You can compare it to http://www.baudline.com/ which can also provide
some inspiration on default settings. jaaa and japa may come in handy to
verify the math.
From: "Fons Adriaensen"
<fons(a)linuxaudio.org>
I don't think that the DSP code is doing what the parameters
would suggest - the visual results don't match.
Could it be that 'l' sets the window size ? It shouldn't,
the window size should be the fft size. Then, if you have
both 'l' and 's', then both together determine the overlap,
so this can't be a separate parameter.
Also, with just a 1 kHz sine as the input, I'd expect all
spectra to be identical, but they are not...
that's a bit unfortunate...
I'll have a look at all this, thanks to report.
for s, l and overlap:
s is the fft size (let's say 1024 for an example)
l is the sample count, if set at 512 we compute an fft
each 512 samples. Since fft size is 1024, we append with 512 zeros.
Overlap is how much we advance the input to compute the
next fft. In our example: set to 0, at time 0 we compute with input[0..511]
and next iteration we compute with x[512..1023].
Set to 0.5, next iteration is computed with x[256..767].
Set to 1, next iteration would compute with x[1..512] (normally it should
not advance at all, so setting to 1 is in fact setting to 1-epsilon with
epsilon such that we advance by 1 sample)
The window is computed on the l samples.
I guess all this is not done the standard way... (and I hope
the code does what I say above...)
For your 1k sine, I'll have a look. If you have some time,
it would be great to have a screenshot just
to be sure I see the same thing than you? And thanks for the testing. The code does not crash on
at least
three and half computers! that's great.
Many thanks for taking up that task. A FLOSS version of baudline has
been on my wishlist for a while.
Cheers!
robin
11:10 a.m.
If you are adventurous, Lorenzo Sutton says he has
problems with the colormaps' browser in a 32b ubuntu host.
I can't reproduce the bug. If you have it...
(that bug is weird) (these are the Italians :))
mystery solved. It's a locale issue. I KNEW THESE WERE
THE ITALIANS! :-)
So do an "export LANG=C" before running spectrojack or
use a locale where 1/2 as a float is written as 0.5
and not 0,5 or any other esoteric format. Internally
I use sscanf to parse those numbers.
Sorry for the noise.
4784
days inactive
4785
days old
linux-audio-user@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Cedric Roux -
Fons Adriaensen -
Lorenzo Sutton -
Robin Gareus