traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] Fades: keys and behaviour


From: Remon
Subject: Re: [Traverso-devel] Fades: keys and behaviour
Date: Tue, 13 Feb 2007 21:41:03 +0100
User-agent: KMail/1.9.6

> Only tested on PPC, please confirm if you experience the same problems:

Shouldn't matter which pc it was :)

> - as you say, painting is pretty botchy ATM

Known problem, is being worked on, locally it's getting better, though I still 
need to figure out a consistent way to propagate height/zoomfactor changes 
for viewitems...

> - [S] to change the "strength" value doesn't work

Funy, a bug in the keymap file, took me few moments to get the clue :-)
Fixed in cvs

> - set "strength" to 1.0 by default, since changing mode from linear to
> long/bended/s-shape should immediately change the shape. (As long as
> strength is 0, all modes are linear)

Is't that the case?
The shape changes indeed on < M > so that's fine. 

> - the <E> dialog has no functionality anymore, so we should get rid of it

Removing the entry from the keymap will do ..

> - the cursor should not move while changing values, because it quickly
> leaves the fade area, which feels confusing (mainly if the it enters
> another fade area).

I thought I had made this change, perhaps it got lost

> - it should be more robust in critical situations:
>       - if the clip becomes shorter than the fade, the length of the fade 
> should
>         start to shrink (the upper fade points (at 0 dB) should never lie
> outside of the clip)

Do you really think so ?
Rather annoying if you accidently moved a clip edge to far, your fade edit 
will become screwed ?

>       - fade-in and fade-out should not be able to overlap (see fade 
> attachment)

Why not?


> > Another 'problem', by how much should the fade range grow/shrink ?
> > By 1 pixel at a time, by xx seconds, or ?
> > Currently they move by some fixed amount of samples, RFC please.
>
> I would say it should follow exactly the movement of the mouse cursor. It's
> a bit hard to make long fades at the moment.

OK

>
> And while we're at it: I would prefer if dragging edge behavour would be a
> bit different. See attached edge1.png for an explanation. Any comments on
> that suggestion are welcome.

Sure, I think all drag/move actions should have this behaviour, right ?

Greetz,

Remon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]