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

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

Ok, so Strenght should be set to 1 on creation, right? [ S ] works again, so < 
M > should work as well :)


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

It's mostly empty right now, but I thought, it would be good to have it around 
for a while, we do want to use this kind of dialog for the equalizer right ?
If so, the classes can be re-used, only renaming needed.

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

Hmm, not sure, will think about it some more. Don't mind the drawing messed up 
like in the screenshot, it's easy to solve, just setting a clipping rectangle 
on the painter.

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

Exactly!


Greetz,

Remon