[Top][All Lists]
[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
screenshot3.png
Description: PNG image