Subject: Re: [linux-audio-dev] Audio-related widgets with Qt ?
From: Tommi Ilmonen (tilmonen_AT_cc.hut.fi)
Date: Mon Sep 17 2001 - 17:13:18 EEST
On Mon, 17 Sep 2001, Paul Davis wrote:
> >I know that waveforms are difficult. That is why have not tried them at
> >all :-) What I had in mind is probably similar to what you described.
> >In more detail:
> >
> >A) An object that calculates the previews in a background thread (and
> >serializes the requests). This thing would not have to bew very
> >Qt-specific.
>
> Calculates the view of an 2GB file in the background? Seriously? This
> stuff needs to live on disk for any work on real songs rather than
> just short samples. When I fire up Ardour, I'm sometimes viewing 16GB
> of audio data at one time. You cannot possibly compute peakviews on
> that much data "on demand" - the disk read time alone is prohibitive.
I am not sure if I understand you. My basic approach would go like this:
1) Somehow a new audio file "foo.wav" is brought to an app (recorded,
imported etc).
2) When the app wants to show the file it needs a preview of the file. The
previews live in other files "foo.wav-preview-10", "foo.wav-preview-100"
and "foo.wav-preview-1000". These files have 10, 100 and 1000 times
compressed images of the peaks of the original file.
3) If the preview file that is needed does not exist, then it is created
in the background. If it exists and it is newer that the sound file, then
we are happy, we can use the existing preview files. The stuff needs to be
threaded so the application does not halt while peak-files are being
generated (like boring Logic Audio does and nice Sonic Foundry does not).
4) The calculations in 3 could be done automatically or they could be
done at the time the app needs to show a waveform. So the peak-files can
be calculated on-demand (in the first time), but usually they will be
available.
5) The Qt-specific part renders the waveform on some area. With some
method. It could be highly specific method or not.
> >B) A collection of functions/classes that can render the waveform. I am
> >not talking about a "waveform widget", but about a piece of code that
> >would be able to render specified part of the waveform on any given area
> >on any given widget.
>
> That means defining what a "widget" is.
>
> In gtk-ardour right now, there is a GtkCanvasItem called a
> GtkCanvasWaveView which works in the way you describe, using direct
> in-memory RGBA-pixel drawing techniques to draw the waveform. (it
> currently computes the peak view too, but thats an internal detail
> that will go away once ardour generates them on disk by itself). Its
> extremely efficient, in part because the Canvas is double-buffered,
> allowing the GtkCanvasWaveView to write into memory rather than use
> XDrawLine or its toolkit-specific equivalent (the Canvas flushes
> itself to X just once per redraw, as a pixmap).
Ummm. Mustajuuri uses similar techniques. Whenever speed is really needed
I drop to the method of using the XDrawLine -approach. Flushing pixmaps to
the screen across the X-socket is heavier than drawing a few lines.
Depends of course on how may lines there are. The pixmap-approach is
denitively in if you want to do shaded stuff or some other
uber-cool OpenGLish thing that requires most pixels to be explicitly set
(I have seldom if ever seen this in audio waveform displays).
Or is the Canvas so clever that is uses genuine double buffering
(bypassing the usual socket transmission) ?
> However, as happy (and slightly proud) as I am about the item, it
> would be essentially useless outside the context provided by
> GtkCanvas. Would it work for a regular GtkWidget? No. Thats what I
> mean by it being really hard to do this in a generic way.
That is true. I do not assume it "completely" generic (such things do not
exist), but reasonably so -- in a way that it could be used in more than
one app. In the end it may well be dependent on some specific Qt widget,
but such is life.
> Welcome to the world of advanced linux audio programs, rather than the
> many excellent and wonderful toys we've lived with so far :)
Yep.
Tommi.
This archive was generated by hypermail 2b28 : Mon Sep 17 2001 - 17:11:10 EEST