Hi Leo, Hi Pierre,
the last weeks, I spent quite some time on implementing a patch for an
issue closely related to this. So, I think it's great you want to
participate, and maybe we can join forces or at least I could assist
in understanding the code involved in rendering and manipulation of
the automation curves. :-)
To recap, I am in the middle of a large editing project and bound to
use the automation feature rather heavily, and I found it quite
cumbersome to use. It is nice we can have fades and pans, but given
professional needs, I found myself hand-editing the tangent of
almost every automation node, because some of the behaviour of them
is annoying at least. So I started a patch to improve handling of
bezier automation curves. See the Threads called "Bezier curve
alternative?" and "Bezier automation" about a month ago.
Meanwhile, I got interrupted by two sound recording jobs I had to
do, but today my patch is »almost done« and just needs some
polishing. Last week on irc, Johannes Sixt asked me if I could
port it over immediately to Cinelerra 2.1, so I didn't publish
anything new. But, of course, if there is interest, I could
produce a patch based on the "latest Version of Cin 2.0-CV"
(which is r836 in Subversion, IIRC), before the merging up
to Cinelerra 2.1 started.
Pierre Dumuid wrote:
> What really annoys me is at the moment, the ranges of the all
> automation curves (that control floating point variables) are
> currently shared, (i.e. the range for an audio track, typically need
> values from -80 to 6 dB), projector / camera zoom ranges are ALWAYS
> positive, and generally go from .0001 to 10, and projector / camera
> translation control are generally of the order of -1024 to 1024
> (depending on your image size).
...
> This I consider is the most annoying feature about automation curves
> and the one that should be tackled first. My proposed solution is as
> follows:
...
> dropdown text box button
> [type] [ -100 to 100][log/lin]
>
> With this idea, each curve is of a type (zoom, translation,
> audiofade), and the range used on the track depends on the type.
I completely agree with you this is very annoying behaviour; basically
it hinders gaining any profit of the fact that several overlay curves
are sharing the same screen real estate: most of the time their scales
don't match and we are forced to display only one curve at a time.
But I'm rather sceptical if your poposal will make things better. Having
to navigate with the mouse down to the statusbar and selecting a type
and entering Values into the text box can be cumbersome as well.
Even the current solution seems more steamlined: We have the "overlays"
window with checkboxes for every overlay type and we have keybindings
for toggeling the most common curves. And we have the ALT-f key, which
even works in conjunction with the current selection in a track, i.e.
it bases the new automation vertical zoom range on the current visible
curves within the selection of the first armed track.
Pierre Dumuid wrote:
> I do want to say, that I currently LOVE the ability to manually set
> the limits of the ranges by typing the values in.
Absolutely. This is a strength of Cinelerra not to be sacrified.
E.g in ardour, the current value of an automation node or segment
is shown as a hint while dragging, and the values are quantized to
0.1dB. Getting a segment constant to say exactly to -6dB can be
quite a challenge...
Leo germani wrote:
> Plan A:
> Build Ardour-like automation tracks: it means you would have,
> on the left panel, the option to show or hide the automation tracks
> of your choice, wich would be subTracks of the track you are working
> in. On this track all you see is the automation line of the selected
> automation (fade, CameraX, etc...). You would be able to see one or
> as many automation tracks as you like at a time. I think this is the
> best way cause also opens the door for, later on, someone add all the
> effects to this. For example, the PluginKey frames could migrate to
> the automatinoLine style. So I could automate, lets say, the HUE
> parameter of the Color Balance effect.
And we should add, the handling of the mouse wheel in conjunction
with SHIFT, ALT and CTRL is very nicely done in ardour.
But, without wanting to dilute your proposal in any way, we should note
this approach gets cumbersome rather quickly at larger projects. Given a
typical Session (classical music, medium sized orchestra, some singers),
I find myself soon scrolling up and down through tons of automation
tracks, either beeing forced to orient myself all the time ("what the
heck is the track I'm currently in here), or forced to decode which
parameter of which plugin to select and to show and hide, beeing rather
distracted from listening and working with the sound altogether.
What I am dreaming of would be sort of "View Combinations"
(similar to the free combinations of stops found on large pipe organs):
They would be freely configurable and could be bound to key shortcuts.
Invoking such a "View Combination" would (every item optional and
switchable)
- set the vertical and horizontal zoom
- navigate the viewport intelligentely (to a mark, to the locator)
- select a object snap-to mode
- open/collapse/arrange tracks
- and even bind some parameters flexibly to some events on an
external MIDI control surface...
But with this, there is a minor problem....
> Since we dont know how hard is to do this we have a second option:
> Plan B:
Yes, it /is hard/
Given the way automation and gui handling are implemented in Cinelerra,
the "Architecture" so to say, I wouldn't mandate to target such
advanced gui features without a major overhaul of the whole gui code.
Please don't get me wrong: The code is quite bug free and consitent
in style (the functions handling the automation and the gui events I
looked into), but literally every method is public, almost no internal
APIs, no encapsulation, application logic tangled with event handling
and basic gui features all over, and the like.
But let's face the facts. Current gui toolkits aren't quite there
either (just think at the GKT-1 problems in ardour or have a look
at the XaraLX people porting over their application to wxWidgets
at the moment), and here in the Cinelerra communitiy, we simply
don't have the manpower for implementing a custom toolkit from
scratch on any reasonable timescale.
In spite of this, I think we should continue to discuss
"how things should be" in the Cinelerra gui and maybe
target improvements that could be done
Cheers,
Hermann Vosseler
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
