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: Nicola Doebelin
Subject: Re: [Traverso-devel] Fades: keys and behaviour
Date: Tue, 13 Feb 2007 22:08:46 +0100
User-agent: KMail/1.9.3

Am Dienstag, 13. Februar 2007 21:41 schrieb Remon:
> > - 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.

Not here. Bending and Strength are 0 in a new fade. Switching mode always 
results in a linear fade.

> > - the <E> dialog has no functionality anymore, so we should get rid of it
>
> Removing the entry from the keymap will do ..

No code cleanup?

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

Checked again, it definitely moves.

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

Hm, don't you think we should somehow avoid situations as shown in the 
attachment? Maybe instead of changing the fade length permanently, it should 
be overridden and squashed as long as there isn't enough space for the entire 
fade. But if the clip length is increased, it should revert to the previous 
length. Kind of like elastic when it bumps into the opposite clip edge. Do 
you get what I mean?

> > And while we're at it: I would prefer if dragging edge behavour would be
> > a bit different. 

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

Almost. But dragging clips shouldn't ;-) Let's say drag/move actions which 
change a numerical value should hold the cursor, but actions where something 
follows the cursor (dragging clips, edges, fade lengths) should not.

Best,
Nic

Attachment: screenshot3.png
Description: PNG image


reply via email to

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