august schrieb:
> Hi,  is there any thought going into changing this in Lumiera?
that figures. Lumiera grew out of the difficulties when trying
to use Cinelerra in larger, professionally oriented projects.
I should add here that it's *not* the video/processing quality
which is lacking, its all those tiny little things which you
start noticing when you work with lots of footage and a
complicated production workflow to tight schedules.

> I see this as a general GUI design flaw.

I don't think it is a missdesign in the GUI. Rather, this is
a very deeply rooted design decision in the Cinelerra engine.
You can't change this basic handling of timings and frames
without touching pretty much anything in the existing engine
code. Trying just to hide it by manipulating the GUI will
just cause more problems (I am not sure if the unfortunate
behaviour when single-stepping is due to some attempt to
"fix" this behaviour).


> That kind of setting should apply to files on a track
> and not the entire track.
...which would require, that there was a notion of settings
and objects separate from the "processing" done by the tracks.
This whole kind of infrastructure is just plain lacking in
Cinelerra. That is understandable. If someone approaches the
matter in a pragmatic fashion, he (she/it) probably says
"hey, I wanna code a video editor, so lets start coding
video processing". "Hey wouldn't a backwards playing feature
be cool, so lets build it in". And so on. I think you get the
idea.

Look, to the contrary, for Lumiera we write a lot of code
which at first sight has not the slightest connection to
video processing. But we're in the favourable situation that
we can start with analysing the shortcomings of an existing
application, which indeed *can* be put into real-world use.

> Where a user would want to apply settings (camera, projector, color 
> correction, volume fade, alpha fade, etc) to an entire track, she could 
> simply select all files on a track and set them together.
I don't think this would be a good approach, because you'd loose the notion
that this is *one* setting, after having applied the changes. What if you
want to fine-tune your setting? I think, we just need to accept that there
*are* different ways of apply a setting: to the global busses, to a track
or group of tracks, to individual objects. It's not a good idea to try
to be clever and "simplify" this, because the real requirements driving
these needs just aren't simple.

> As an alternative, one could think of cascading the settings like in CSS
> from a global track perspective down to a local file perspective - where
> local overrides global.
Yeah, here you give sort-of a summary of what we're building in Lumiera.
Settings can be applied at multiple levels. These places, were settings
can be attached and objects can be placed are organised into a tree-like
structure of nested Scopes, with local settings shadowing global ones.
Automation data is just another kind of object and can be placed, attached
and arranged in the same way as clips, effects, labels

The processing is completely separated from the wiring, which in turn
is again completely separated from the model which the user manipulates.
We don't "pipe data through tracks" in Lumiera.

Cheers,
Hermann

_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to