[Top][All Lists]
[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