9 May
2005
9 May
'05
6:19 p.m.
Hi, I'm extremely new to audio programming. I have a million questions, but the one
burning my brain now is how do I
get a program written with the qt widget library to display an audio waveform. Also, any
links to good documentation for
audio programming would be good.
Thanks
Mike Fisher
9 May
9 May
7:20 p.m.
On Monday 09 May 2005 21:19, Fisher, Michael R wrote:
Hi, I'm extremely new to audio programming. I
have a million
questions, but the one burning my brain now is how do I get a program
written with the qt widget library to display an audio waveform.
You could look at the trivial_sampler example plugin in the DSSI plugin
API distribution. That's a pretty simple bit of code that does (IMHO)
tolerable waveforms in a Qt window. The only problem is it's not
standalone so you'd need the plugin host as well.
http://dssi.sf.net/
Download it and have a look at examples/trivial_sampler_qt_gui.cpp.
It's the plugin in the front of the screenshot here:
http://dssi.sourceforge.net/plong.png
The black in the waveforms shows peaks, the grey averages.
And trivial_sampler is public domain, so it's legal to do anything you
want with the code. It's even legal to pretend you wrote it. Not that
anyone will believe you for long, after this discussion.
Chris
7:21 p.m.
Hi, I'm extremely new to audio programming. I have
a million questions, but the
one burning my brain now is how do I
get a program written with the qt widget library to display an audio waveform.
this is massively harder than you think, assuming you want to (a) do
it correctly and (b) offer zooming.
--p
7:26 p.m.
On Monday 09 May 2005 22:22, Paul Davis wrote:
Fortunately, if you don't care about doing it correctly or offering
zooming, it's quite simple.
Chris
Hi, I'm
extremely new to audio programming. I have a million
questions, but the one burning my brain now is how do I
get a program written with the qt widget library to display an audio
waveform.
this is massively harder than you think, assuming you want to (a) do
it correctly and (b) offer zooming. 
8:14 p.m.
Chris Cannam wrote:
On Monday 09 May 2005 22:22, Paul Davis wrote:
ROFL. :)
Well, I guess the way it's done in most audio editors is that you draw a
vertical line between the min and max (and maybe also the rms on top of
that), if a single pixel has to represent multiple samples, and the
usual connect-the-points-with-lines thingy (or splines, if you prefer
smooth curves), when zoomed in to the sample or sub-sample level. Is
there a better way?
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
this is massively harder than you think, assuming
you want to (a) do
it correctly and (b) offer zooming.
Fortunately, if you don't care about doing it correctly or offering
zooming, it's quite simple.
9:01 p.m.
Well, I guess the way it's done in most audio
editors is that you draw a
vertical line between the min and max (and maybe also the rms on top of
that), if a single pixel has to represent multiple samples, and the
usual connect-the-points-with-lines thingy (or splines, if you prefer
smooth curves), when zoomed in to the sample or sub-sample level. Is
there a better way?
the devil is in the details, as gerard and i found out to our mental
health with ardour recently.
if you allow arbitrary zoom scales, then the mapping between pixel
position on screen (or some notional "unit" position as offered by
canvas widgets) and a sample is non-integral, which implies
rounding. that in turn implies errors of several different kinds.
moreover, if you are displaying large audio files, reading the audio
data itself is excrutiatingly slow. hence, peakfiles.
all of this and more, in gruesome detail:
http://ardour.org/cgi-bin/viewcvs.cgi/*checkout*/ardour/gtk_ardour/canvas-w…
which is the canvas item used by ardour to draw waveforms. its
lightning fast and awesomely headache inducing.
--p
9:29 p.m.
On Monday 09 May 2005 19:02, Paul Davis wrote:
if you allow arbitrary zoom scales, then the mapping
between pixel
position on screen (or some notional "unit" position as offered by
canvas widgets) and a sample is non-integral, which implies
rounding. that in turn implies errors of several different kinds.
moreover, if you are displaying large audio files, reading the audio
data itself is excrutiatingly slow. hence, peakfiles.
And here's another one in Qt, from Rivendell's Marker Editor:
http://www.salemradiolabs.com/rivendell/
Unpack the tarball and look in rdlibrary/edit_audio.cpp.
Paul is quite right about all the round-off and peak-file issues. Rivendell
handles that by assuming that the smallest atom of audio is always 1152
samples long -- which just happens to be the standard MPEG sample block size.
This gives acceptable precision for the marker editor, but would probably not
be adequate in a general purpose editor. Even the 'simplified' version is
quite headache-inducing enough, however... :)
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| Never worry about theory as long as the machinery does what it's |
| supposed to do. |
| -- Robert A. Heinlein |
|-------------------------------------------------------------------------|
9:03 p.m.
On Tue, May 10, 2005 at 12:23:50AM +0200, Albert Graef wrote:
Well, I guess the way it's done in most audio
editors is that you draw a
vertical line between the min and max (and maybe also the rms on top of
that), if a single pixel has to represent multiple samples, and the
usual connect-the-points-with-lines thingy (or splines, if you prefer
smooth curves), when zoomed in to the sample or sub-sample level. Is
there a better way?
I've been thinking about a JA-scope companion to JAAA for some months
now, and it's by no means trivial to get something that even starts
to approach an analog scope.
First, if you want to display the real analog waveform (and that's
what users will expect), you have to interpolate to at least 1/4
sample. To have good triggering, again more interpolation to find
the exact time the waveform crosses the trigger level. Then again
interpolate to find the y-values corresponding to the pixel positions.
--
FA
6950
days inactive
6950
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
6 participants
participants (6)
-
Albert Graef -
Chris Cannam -
Fisher, Michael R -
Fons Adriaensen -
Fred Gleason -
Paul Davis