I've been working on waveforms for audio clips. It's not quite usable yet: having these waveforms slows down re-drawing considerably, which brings the entire GUI to a screeching halt. At least I was able to get this screenshot, which looks like progress to me.
11 comments:
cool.
can some sort of threading be done, so that this happens on another CPU core?
Hi,
to speed up Wave-Form rendering, I recommend to generate some kind of reduced index over the whole audio-file, where you only save to MAX value of several audio samples combined. This will be accurate enough, if you are at a reasonable zoom level, and it will be MUCH faster. Also if you zoom in further you can still switch to using the original sample data.
Also, you may want to ask the Ardour Devs, how they accelerate wav-form drawing:
ardour.org
Cheers
-Richard
(Open Movie Editor Dev. ;-))
that's a good idea.
Nice!
On avid, the waveform viewing can be turned off because it is indeed dead slow. Maybe the ardour team did tackle it, but I wouldn't use it that much except for maybe when I have to sync a peak with a certain frame. Therefor, Avid has a setting: display waveforms only for the mark-in/mark-out region. Good idea?
Fantastic! Can't wait for the next stable release.
Jokosher has waveform rendering that is quite fast and which looks quite good too.
Surely it would be possible to write an algo to only do the math for rendering a waveform at the current resolution. You shouldn't have to do lots and lots of really expensive math if you aren't zoomed in all the way. Audacity does a reasonable job of this.
You might also consider doing some of it in C and using liboil:
http://liboil.freedesktop.org/wiki/
Just a few random thoughts.
There two separate problems with drawing waveforms: extracting the sample points, and then actually plotting the waveform. At the very least, I've solved the first problem.
As for the second problem, I have to admit, I'm a little bit stumped. When you load a file, the waveforms appear on the clip almost instantly. When you go to drag one of the clips is when the gui freezes up. I'm only drawing about 1/1000 sample points in that screenshot (so ~440 or so), and I think the issue is that goocanvas continually recomputes the entire path every time the clip moves a few pixels. So part of it is an inefficient drawing framework. In order to fix that, I have to override the do_paint(), and do_update() methods rather than just the do_simple_create_path() method. The first time I tried to do this, PiTiVi just crashed right away.
In any case, I put in a lot of time on this last week, and I have a midterm coming up this week. I'll come back to this in a few days.
Um, have you considered that you might need a bitmap cache for that?
You only compute the bitmap once, and then use that to draw the clip.
Of course, resizing the clip would need a more advanced cache, like having an array of "computed" and "uncomputed" pixel columns.
Of course, but that just makes everything more complicated, and I like to take things one step at time. Step 1) draw a wave form, somehow. Step 2) THE WORLD!
Post a Comment