On 17:22 Sun 20 Jul , Ichthyostega wrote: > 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?
Perhaps I misunderstood your previous paragraph, but I think you're
proposing a 'parent track'/'grouping track' separate from the
multi-track container. I am resistant to add the visual and
operational complexity distinguishing them in the interface would
entail. I think that having only four components in the timeline
would still be fully expressive of any desired edits:
* Media file (video, audio, image)
* Media container (containing media files and/or other media
containers)
* Filters/Effects (Which are only allowed to be applied to media files
or entire media containers within their level of their container)
* Compound Filters/Effects (Same application rules as simple
Filters/Effects)
Note the parallel between simple media/simple effects and the media
container/compound filters. I like the symmetry. :-D
The limitation of inputs for the (compound)filters to entire media
containers and media files on the same level provides a substantial
reduction in visual/code complexity, resolves some nasty potential
graph cycle bugs, and heads off some hard questions about edits that
involve the contents of both unlocked and locked media containers. I
think the very small reduction in flexibility is a blessing---the
whole point of the media container concept is to 'encapsulate' their
contents, so interaction with them that deals with the sub-objects or
crosses their boundaries is actually confusing/counterintuitive to
users.
Extending this primitives, the logical 'true' nature of a meta-clip
(i.e. the entire currently visible timeline) is that it is simply a
media container itself. This means we can apply effects to 'entire'
meta-clips exactly the same way as to media containers. Highly
complex media containers (as are the common consequence of long-term
or multiple-editor projects) can easily be opened in a new
timeline/tab for edits focused entirely therein.
Sudden idea: As a parallel to the idea of cuts in source media, the
corresponding effect (crop off the ends) should be easily performed on
the media containers, too. Note that two media containers cannot
share the same track (unlike dropping one video after another on the
same video track)---trying to do so ends up with a mess whenever there
are different numbers of content tracks for each container. This
exclusion, however, leaves room for an important enhancement over
simple media crops: before the beginning crop and after the end crop,
all of the content of the media container can still be seen and
edited, but it is faded to indicate the 'invisibility' of that
content. Some users might adapt this feature by making containers for
single media clips just to have a different tool for adjusting
interactions between media edits, start/end crop points, and adjacent
media overlaps.
> 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.
Since it's past 5 A.M. and I haven't thought about that topic before,
I'm going to have to get some sleep before I delve into it. However,
my initial impression is that it's a very powerful idea.
> 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....
See above paragraph. :-P
> > 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.
I am either misreading your text or I think you might have made some
small media reference errors, below is my interpretation of your
intended meaning:
( Locked media clip "L" and unlocked media clip "U" )
Case 1: Position of L was defined relative to U. While L remains
locked, moving U should adjust the offset that defines L's position
from U. Once L is unlocked, moving U shifts L as though the original
relative position were originally defined with the offset resultant
from moving L when it was still locked.
Case 2: Position of clip U was defined relative to L. Moving U
changes the offset for that relative position the same as if L weren't
locked.
I agree that this is a good handling of relative placement
interactions with locked tracks. The visual cue for Case 1 should be
the same one used by Case 2 (and the default relative motion case). I
am imagining something like a red line with text indicating the time
of the relative offset bracketed by the related track's defining
edges. An image of an anchor (the nautical tool) on the end of the
track that defines the relative placement would clearly show
directionality of the relationship.
>
>
> Cheers,
> Hermann V.
>
--
Clay Barnes
Website:
http://www.hci-matters.com
GPG Public Key (Fingerprint 0xBEF1 E1B8 3CC8 4F9E 65E):
http://www.hci-matters.com/keys/robertclaytonbarnes_public_key_until20130101.gpg
https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0xE1B83CC84F9E65E8
signature.asc
Description: Digital signature
