Dimitrios wrote:
It is true, cinelerra is not user friendly and the learning curve is indeed steep. I also believe that starting over isn't doable. Lets face it, cinelerra is beign developed by a small group of developers, there just isn't time, money and resources to redesign cinellera from scratch.
Bradley A. Hare wrote:
I have traced through the code, and quite frankly it scares me. Billions and billions of threads - not quite a recipe for determinism. My impression right now is that the giu is probably usable as is, but the core needs to be rewritten. I am particularly interested in native DV and and HDV workflow, so I have been looking at the design from that perspective (that should explain my previous comment about a rewrite).
Herman Robak wrote:
Things that Cinelerra could advertise better: * Which tracks are affected by a selection or operation; different highlighting of armed and unarmed tracks, and maybe a short flash in the patchbay to remind the user "these are the armed tracks". * The consequences of "arming/disarming" tracks. For example, if you drag a video to the timeline, and there are not enough armed sound tracks to receive all the audio channels in that video, some status bar or tooltip should say that. * Current resolution, aspect ratio and framerate * Current colour format (yuv, rgb, float, with or without alpha) * Current audio rate and resolution; give the user a hint if all the resources have a sample rate that is different from the project rate.
Herman,
I completely agre with you such features would be desirable (and
helpful for advanced users too). In larger projects, the cinelerra
gui is tiresome in many regards.
But frankly, I see no way to get such features with the current code base.
Such would be a recipe for desaster. (and much many large multi million dollar
projects completely failed by going this way, because some influencal person
said "it has to work because it couldn't be so difficult and we want it
and we pay for it")
I don't even see the possibility of having two different GUIs using
the same core video and audio engine.
Pls. understand I don't want to offend anyone or to talk the achievements
of other people down. But the current code base of cinelerra is lacking
explicit architecture, clear separation into different layers (engine,
ui logic, presentation). Way to much things are hard wired and done
by »if it just works it's okay«
To give a counter example, look at ECLIPSE. There you have this sort of
application
capable of doing any sort of advanced things. It is plugin based, you have lots
of different view components and any change in any part immedately is reflected
by all other views, menu selection states and even mouse-over help. And it works
reasonably fast in spite of beeing completely implemented in java. But then,
look
at the daunting amount of internal architecture, internal abstraction, dynamic
service discovery, extension points and the large suite of test cases used
to assure this constant high quality.
You see: the real problem is, everyone takes such things for granted and
considers
this complexity as "natural". ("if I drag this X, why doesn't this fucking Y just
follow")
So, to conlude, I think we should be happy with what we have and try to find
out the
small and pragmatic improvements, which could make working more smooth and
intuitive
or solve the most noticable known problems (e.g. the fader lines overshooting)
without
endangering stability or overloading internal interdependencies. I don't
consider it
right to invent a new "killer feature" every half year and I don't like
cinelerra
fighting a competitive war against other video editing products, because I want
it to stay what it is: a working tool for advanced users, enabling almost
unlimited
editing possibilities if you know what you want and how to achieve it.
Cheers,
Hermann Vosseler
signature.asc
Description: OpenPGP digital signature
