Re: [Traverso-devel] Accuracy of waveform drawing, and performance

[Remon]

Hello Nicola,

> It's nice to see that you could speed up the wave form drawing. However,
> since mixing on a DAW is also a visual process, you should be careful not
> to hide the wrong features of the wave form. I'm thinking of clicks from LP
> recordings, or single-sample spikes from poor digital connections etc. Such
> details should be visible from all zoom levels, and not just appear when
> zooming in. 

The current implementation does it like this:
Get for zoomlevel x the peak data for zoomlevel x + 1, and stretch by a factor 
2, so basically nothing changed, but the waveform might appear a little 
smoothed out, but still, the _real_ peak data is used, so spikes will still 
be visible.

Hmm, I think it might be most usefull to load some audiofiles with known 
patterns, spikes, things like that, and load them into traverso and see if 
the waveform still tells you what you think it should tell you :)

> It is also important that the highest level touches the 0 db 
> line at all zoom levels when normalized. Otherwise users would start to
> push the gain and overload the output even though there already was a peak
> reaching 0 db.

Good point, there is no 0 dB line atm, should I add it as a dashed line, 
or .... ?
The waveform vertical scaling is indeed a bit of 'don't paint beyond the 0 dB 
line, but we don't know where the 0 dB line is.....


> If the optimized drawing still allows to see such critical features, I'm
> all for performance optimisations. What is the most expensive part, the
> building of the polygon or the painting? If it's the painting, maybe you
> could use some semi-intelligent code to further reduce the number of nodes,
> e.g. by checking for constant slopes over several pixels, or ignoring peak
> differences of 1 pixel etc. What do you think?

It's definitely the painting, most of the time is spend there.
It would of course be much easier and simple if we just could use one pixel 
per node, the big issue is that opengl seems not be able to cope with that.
And, just adding each and every pixel does seem like overkill anyways...

On my PIII 800 Mhz (Windows), using opengl, the cpu load dropped to ~ 10% for 
moving a clip, and without opengl ~ 50%, and that's with a pci graphicscard, 
perhaps comparable with a low end geforce 3 card...

It would be great if you guys could load some audio data with known 'issues' 
to see if they are painted in a way you was used to!
Or send me the files, so I can play with it..

Greetings,

Remon

P.S.
The latest uploaded binary can be used if you don't have time or know how to 
build traverso...
You need libraptor and librdf btw to be able to run the latest binary since it 
has lv2 compiled in....