Few questions: 
  - why break "multiplication by two" compatibility? just 'do the right
thing' and keep the compatibility by doing multiplication when reading
from file and division when writing
  - the  changing should also be available in the "?" window in the
compositor

While you are doing all these changes you can maybe also scratch my
itch: add "alt" keyboard modifier that would restrict auto dragging to
the vertical movements - without moving the point trough time...



bye
andraz

On pon, 2006-06-05 at 21:23 +0200, Ichthyostega wrote:
> Hi all,
> 
> find attached a WIP-verson of my patch to enhance the bézier feature of 
> cinelerra.
> This patch is /against Version 797/ of Cin-SVN, it is almost feature-complete 
> and
> "worksforme" on AMD64 X2 running Debian testing/unstable.
>  still...
>   - the auto tangent feature dosn't work correct when deleting an automation 
> node
>     and when "setting keyframes while tweeking".
>   - when looking close, I am not content with the display of the handles
>   - I am considering to add a variant of "free" mode, so we can have a 
> /single/
>     editable tangent on a node.
>   - I am considering to enable ctrl-drag from a auto-smoothed node to switch 
> it
>     to manual editing of tangent
>   - I may have missed some tabs/spaces in indentation of code
> 
> 
>  what this patch does (without going to technical details):
>   * it doesn't change the way smooth automation curves are calculated. This 
> means,
>     after migration (when first openig them with the patched version), 
> automation
>     data in old session files will work 100% the same as before (note: you 
> can open
>     new fomat session files with old versions of cinelerra, but then the 
> control
>     point values will be misinterpreted by a factor 2).
>   * the behaviour of the gui for editing autmation curves is changed, so to 
> reflect
>     exactly the mathematical properties of the used bézier function. The 
> current
>     version of cinelerra here has some oddities:
>     - it seems you can drag the ctrl points feely, esp. it seems you can drag 
> them
>       in horizontal direction. The horizontal coordinates of ctrl points are 
> even
>       persisted in session XML but -- they are really thrown away and never 
> used
>       in calculating the bézier function. (I don't see a easy way to /use/ 
> this
>       information given the way the calculations are done, either). But the 
> fact
>       this x-coordinates are not used in calculation is in no way evident for
>       the user. Now, I made this show up clearly.
>     - it internally stretches the y-coords of the ctrl points by a factor of 
> two.
>       Maybe the rationale of this was to make the curves "feel more 
> responsive",
>       especially in low zoom factors. I removed this factor, so now you are
>       editing the real bézier control points.
>     Together, this two destroyed the "tangent property of control points": any
>     bézier curve is completely contained in the convex hull of its control 
> points,
>     and esp. this means the "in" and "out" ctrl points define the tangent of 
> the
>     curve at a node. We should consider, nowadays erveryone with some 
> experience
>     in graphics or audio software knows intuitively how to handle bézier 
> curves
>     and this should't defeated by some unanticipated behaviour  -- indeed
>     software tools shouldn't ever surprise their users.
>   * the patch addes a »tangent mode« to every automation node and builds a
>     auto tangent feature on top of this. You can set the mode by the popup
>     menu of the node to be "smooth", "linear", or "free" (editable). If you
>     set two adjacent automation nodes to mode "linear", you get a linear
>     connection in between.
>   * it uses a special rule to calculate the tangents for "smooth" mode, so
>     the curve doesn't overshot the values set by the nodes, if the direction
>     of the overall curve changes. So we e.g. could set smoothed keyframes
>     automatically by the fader and the fade curve would stay between 0 and
>     100 nevertheless. (I write "could", because at the moment there is still
>     a bug to be fixed here, but if you set the generated nodes manually to
>     mode "free" and then back to mode "smooth", you see what I intended)
> 
> In spite of its not-quite-done state I provide the patch for the curious
> and look ahead at any coments, hints, notes, ....
> 
> Cheers,
> Hermann Vosseler


_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to