Re: [Traverso-devel] Following the playhead

[Remon]

Hi,

> I would like to post some ideas regarding the "Viewport follows playhead"
> feature I came up with in a previous thread.

Nice, thanks!

> 1) The simplest solution is of course to flip the page as soon as the play
> head leaves the viewport. Since this is the least expensive solution in
> terms of CPU consumption, I would definitely add it as an option for users
> with slow computers.

Sure, it would be the start point, any suggestions how to turn this behaviour 
on/off ? 

> 2) Smooth scrolling: The play head is always in the center of the viewport,
> and the tracks scroll smoothly. While this looks cool, I usually find it
> hard to recognize details in the wave forms when they are moving. The
> motion is never completely free of jittering. And everyone who has tried to
> read a web page while the browser is smooth-scrolling can confirm that it
> is *extremely* tiring to follow the writing. Nevertheless there may be
> users who prefer this mode, so why not add it anyway?

it's actually rather simple to hack this into the existing code, I did so some 
time ago, just for the fun of it :-)
However, although it looks very cool, it's indeed not easy on the eyes.
It might be a solution though for very low zoomlevels. The playcursor is 
moving at such a speed then, that it'll create at least some sort of jitter, 
or just make some kind of blur.
Scrolling continuously could improve the user experience quite a lot I think. 
Let's test it out !

>
> 3) Periodical smooth shift: Remon suggested to smoothly scroll the tracks
> if the playhead reaches the margin of the viewport. This is kind of like a
> combination of the two solutions above, and it sounds pretty cool.
> Scrolling should start shortly before the play head reaches the right
> margin. 

I like the idea a lot, the focus will/can be all the time on the playcursor, 
without the jumpiness when just flipping a page. There's a bit more processor 
usage involved indeed, though only the new exposed area's will be painted!

> My only concern is that it periodically causes high CPU load, which 
> could be dangerous while recording.

Don't do that ;-)
Traverso seperates gui and audio processing a 100%. The audio processing 
thread runs with real time priority, so there is _no_way_ that the gui thread 
can ever disrupt the workflow of the audio thread, neither during playback or 
record!!!!
IF  you get get buffer underruns on high cpu load, the linux kernel is to 
blame**, nothing else, and you might consider using a kernel with the real 
time patches applied from I. Molnar and crew.


> - No matter how high CPU usage is, scrolling should not cause dropouts
> during playback or recording.

See above (and **)

> - When zooming into the wave form, the play head can become *very* fast. In
> case of solution 3) it can be faster than the smooth scrolling speed. This
> should not cause any undesired behaviour.

Indeed. In this case, like I suggested above, we can default to continuous 
scroll, with the playhead centered, what do you think ?

> Comments are welcome :-)

Likewise ;-)

Greetings,

Remon

** In short, the audio thread sits idle, until the audio card signals that it 
has room for another piece of audio, or that it captured a certain amount of 
audio. It does so by generating an interrupt request.
It's now the kernels responsability to serve this interrupt, and to  wake the 
process that 'listens' to the audio cards interrupt.
The time it takes from the interrupt, preempting running processes to waking 
up the listening process should be as short as possible, and is something we 
can't do anyting about. If this takes to long, we get xruns, simple as that.
Note that it doesn't matter if a cpu is at full load or not, it's the kernels 
ability to preempt what it was doing, and how long that takes before 
assigning the audio thread to the cpu ....