Re: [Traverso-devel] 0.42 Issues

[ben levitt]

On Dec 27, 2007 9:53 AM, Remon <address@hidden> wrote:
> >  - 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.

Maybe this would also be a good time to reorganize the names of all of
the fade shape commands, which I think are currently confusing.  Right
now we have:

For a Clip:
 - Select Fade Shape (for in, or for out)
 - Reset Fade (For in, out, both, or closest)
 - Set Fade Range (for closest)

For a Fade
 - Set Mode
 - Strength
 - Bend


Maybe we could instead have:

For a Clip:
 - Adjust Fade Length (for closest)
 - Delete Fade (For in, out, both, or closest)  (Would really just
reset, but appears to a user to be like deleting)

For a Fade
 - Cycle Shape (was mode)
 - Adjust Strength
 - Adjust Bend
 - Select Preset (was select shape) (note this would move from a Fade
command to a clip command) (Maybe each preset should include the
mode?)

Now having <H> or <P> for cycle sHaPe could vaguely make sense. :)


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

Cool!  Maybe I'll look into how to make this trivial patch.  :)


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

Oops, yes [ D F ]   :)

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

I have only seen other apps allow hard-selecting lots of tracks and
dragging them all.
But I'm really excited about the idea of a toggle button to make it so
that dragging a clip does a  'drag-this-and-all-future-clips" by
default. ( [ D F ] for "Drag Future"?)  I guess this means it'll have
to be a setting that is used by the same drag command (the way snap is
a setting), and not a separate command...


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

It happens just about every time.  I have a mix-cd sheet that has
whole songs faded into each other sequentially. If I middle-click
(touch playhead) in the middle of a song that I haven't played since
starting up traverso, it will play silence until I seek a 2nd time.
Then that song will play fine until I restart traverso.  This seems to
happen for all clips.  At least long ones.


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

I will try 0.42...


> 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'll try to join on IRC and "help out" (give you more ideas, etc).  :)


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

Cool!  I like the optional plan. :)

Ben