-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Clay Barnes schrieb:
> I was planning on mulling over this question then spouting something
> deeply insightful. I mulled too long, and I think the general points
> have been addressed, though for the sake of getting everyone on the
> same page, I'll rehash them here.
Hi Clay,
thanks for this good summary of the discussion. On the whole, I agree
with you. One important consequence I see is that we should *not*
support the locking of an individual media object (clip, effect)
as a feature accessible by the user. The rationale is (as you and
Percival Tiglao pointed out), that this either creates some quite
bewildering consequences or leads to the lock not being airtight.
Thus far, we have discussed two mechanisms for protecting finished
parts of the session:
- - lock a (leaf) track or a subtree of tracks
- - create a meta-clip out of an arbitrary selection.
Note we don't need a locking feature for meta-clips, because they are
"locked" naturally simply because you have to switch to another tab
in the interface with a separate timeline in order to edit their
contents.
Note further that I have assumed you can put clips on leaf tracks only.
If you group together some tracks, this creates a group head track
(parent track). I don't think this parent tracks should be first
class (you can't put clips on them). They should be used only for
locking, enabling/disabling and configuration of placement (output,
pan, layer). In the UI, such a head track doesn't need to require
much screen space. There was the proposal be able to show a cached
preview thumbnail on such a group head track
(I think that's a good idea)
But if I consider it in more detail, there are two additional questions
regarding tracks and group-head tracks:
- - how to handle track-global effects?
- - where to put chunks of automation?
To detail on these, often one needs to apply some effects simply
on "a part of the timeline". Brightness/Contrast, Scale/Offset
and colour correction being common examples. You don't want to
apply these to individual clips (in the case in question, that is)
and you don't want to apply them to some global bus (which is allways
another possibility, but also not the point in question here). Rather,
you deliberately want to apply such effects to a certain range of the
timeline, irrespective of what's there in this range.
An obvious solution would be to allow to place such effects directly
on any track, even a group-head track. The builder would wire them
in accordingly. What's your opinion?
Regarding automation, I want to do two things better in Lumiera:
1) I'd like automation to be a first class kind of media object.
2) I deliberately want to encapsulate the way automation is implemented.
The first would mean that we won't have a magical global per track "fade
curve" or the like, and also no magical "default keyframe", rather an
automation data set would be an object which is attached by a placement,
as any media object is, either fixed at a given time, or relative in
time position to another media object, label or source location, or,
as a third possibility, using a stick-to placement directly attached to
a clip or effect.
Point 2) above would mean that we don't assume to have "bezier curves",
and -- most important -- don't assume on the *interface level* that
automation is organized by nodes and control points. Each automation
dataset object should just provide a *function* which yields "values
over time", obviously with some typing (toggle, quantized values,
float values within (min,max) range, colour) -- and that's all of it.
Obviously, a rubber-like, editable curve would be an important
implementation of this concept, but also we could have interpolating
data sets, beat loops, mathematical functions (sine oscillations) or
even fractal noise patterns. These would be added as plugins, of course.
These considerations may seem off-topic, but automation plays an
important role when trying to get the locking right. A good deal of
the work on any more advanced editing session is done on the automation
- -- thus automation needs to be locked/protected too.
Clay Barnes schrieb:
> A simple, consistent, and logical selection model would be a selection
> on a per-track basis when tracks ends are clicked; alternatively when
> clicking/dragging across clips in the timeline those clips are
> selected, along with---this is important---all filters/media that
> interacts with them. This will very visibly and gently tell the user
> that if they want to protect those clips, then they will either need
> to also protect this related media further out or slice the related
> media to ensure consistency.
...and this would mean: such a "select connected" would have to select
all connected automation too. As well as any clips/effects connected
by directly explicit wiring. There should be a clear visual clue of
such a selection and probably it's a good idea to give a visual clue
if this selection extends beyond the visible range of the timeline.
Btw, I didn't say anything about how automation will be *displayed*
in the UI (separate tracks, as overlay etc.). That's a another question
we'd have to work out....
> Other thoughts: I agree that locking should be really solid. I also
> think that a good 'collapsed' tree design (including that in collapsed
> view the track can only be moved/etc. as a single block) would allow a
> simple way to do things like re-arrange finished sections, adjust times
> and so on without 'ruining' our lock's purpose. I think that
> anchoring the locked clips to their start time is the most
> understandable paradigm for users---I know there are some ideas about
> pure relative positioning that have been discussed before, but in the
> GUI this should probably not apply to locked entities.
- From the implementation side this fits in nicely --
just I don't know if it's so obvious from a users point of view.
Lets assume you lock a track containing an media object "A".
Lets further assume there is another object "B" placed on another track
Case 1: A was placed with a position relative to B.
Now the lock simply creates a tie ("LocatingPin") with a
higher priority, thus overruling the relative placement.
If you remove the lock, the still existing relative locating
pin regains control. (probably we should re-set the relative
offset the moment we remove the lock-created tie, otherwise
object A could make a jump to the position dictated by the
relative placement, if B had been moved while A was locked.
Case 2: B was placed with a position relative to A.
As B isn't locked, you can still move it, which has the
same effect as if A weren't locked: if you move B, you
adjust the relative offset between A and B which is stored
in the placement of B. As B isn't locked, there is no
contradiction.
Cheers,
Hermann V.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIg1hPZbZrB6HelLIRAlnDAJ4k/ofwiLFHhZjq6KMx5U+nnOZ+GQCeOzLw
LJeFw37jqMovjQgZnY0mNNI=
=DoaK
-----END PGP SIGNATURE-----
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
