Re: [linux-audio-dev] Audio-related widgets with Qt ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Audio-related widgets with Qt ?
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Sep 17 2001 - 16:16:13 EEST


>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.

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

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.

>This sounds mildly complex. In reality it is even more complex - one has
>to guarantee that multiple threads are not accessing the sound files at
>the same time etc., etc., etc.... Frightful (!)

Welcome to the world of advanced linux audio programs, rather than the
many excellent and wonderful toys we've lived with so far :)

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Sep 17 2001 - 16:20:11 EEST