Re: [Traverso-devel] 0.42 Issues

[Remon]

Hi Ben,

> Happy Winter Holidays to all you Traversoers,  (are you all in the
> northern hemisphere?)

Thanks, you 2!

> I've been using 0.42 a whole bunch for the last couple weeks to get
> real work done (yay!) and also to look for usability issues, and here
> are some things I noticed:

Cool!

> - When middle-clicking, or pressing Shift to touch the playhead, I
> noticed that traverso would sometimes stop moving the playhead, but
> not jump it to where I had touched.  It turned out that DragPlayHead
> didn't work right if it started and finished without any jog events in
> between, so I fixed that.
>
>  - There was a similar problem when middle-clicking/Shifting on a
> Marker.  If you were quick, it would correctly set the playhead to the
> marker's position, but if you were a bit slow, it would set the marker
> to the mouse position.  This has now been fixed in cvs.

OK, can't reproduce the problem though, so I'm not sure what exactly happens 
(or is supposed to happen). Will look at your patch, maybe that will help to 
understand :)

>  - I also noticed that while trying to place markers (< M >), I
> sometimes changed a fade mode instead.  :P  (Especially since markers
> often go right near fades, at the edges of clips.)  I propose using a
> different key for changing the fade mode.  < P > for shaPe?  This
> would conflict with Pan ([ P ]), but that seems like a less common
> command, and one that's not focused on edges...  Any other key
> suggestions?

Ah yes, a nasty one. Well, changing the shape of a Fade isn't a very important 
action (?), so we could use the right hand part of the keyboard for that. 
After all, people most likely will use the menu to change the fade shape mode 
anyways.
The < M > key for Fade Mode setting is wrong anyways, since it behaves like a 
toggle with more then 2 states. So using < T > for Toggle would make more 
sense ? < T > for 'Toggle Mode'
Or [ M ] for mode selection, showing a combox selector or something similar. 

>  - I kept wanting the arrow keys to auto-repeat.  Holding down an
> arrow key should either scroll continuously or in steps, but it
> shouldn't just move one step and then be done.  Remon, any suggestions
> on the best way to implement this?  A separate hold command that
> animates a smooth scroll until the hold finishes?

Hmyeah, it's only an issue with the arrow keys, right ? Or would there be 
scenarios where other keys also would have to honor auto-repeat ?
A separate hold command for this then would indeed be perfect. (Starting the 
shuttle, rather trivial to implement)

>  - While dragging a clip, we really need a way to also move all the
> clips on the right of that clip.  Remon and I were talking about using
> < D F > for this.  

[ D F ] you mean ?

> I was also thinking about adding a toggle button 
> (next to Snap, AutoScroll) that would make this the default behavior
> on a drag.  

Hmm, yeah, dunno. How to other programs deal with this ?

> Remon pointed out that we should also have a way to move 
> all clips to the left of the current clip while dragging.  It makes
> sense in terms of maintaining symmetry, but I couldn't actually think
> of a real need for this since Shets in traverso are left-aligned...
> Remon, do you have specific use cases in mind for that?

No, just had the symmetry in mind, but there probably is indeed no use for it.

> And I also found two pretty bad bugs:
>
>  - Often when playing a clip for the first time, it fails to actually
> play(!)  Especially when starting it from the middle with a seek.

Can you reproduce it, and can you tell me then ?

>  - Zooming into micro-mode crashes me on AudioClipView.cpp:463.  In the
> line: m_polygontop.append( QPointF(x, -scaleFactor *
> pixeldata[chan][bufferPos++]) );
>    Could this be related to the new caching?

Curious, dunno if it has to do with the caching, could be.
Will see if I can reproduce and debug it. Perhaps you should try release 
0.42.0, which doesn't have that caching thing? It was just a proof of 
concept, only to see by how much the painting was speed up.


Really nice you could work with Traverso the last days, I propose we (or I 
lol) implement that clip dragging thing, work on the audioclip painting, that 
is, I'm in the middle of reverting back to painting all pixels, not skipping 
all odd ones. That means re-introducing line based painting, of course it'll 
be optional to use line based painting vs polygon based. or when I have 
inspiration I'll write a simple test case, to autodetect the fastest way, 
line based or polygon based painting. (It'll really depend on your graphics 
card and drivers)

Best wishes,

Remon