On 10:49 Thu 24 Jul , Ichthyostega wrote:
>
> Hi Clay,
>
> there seems to be some uncertainty and misunderstanding, probably we are
> using some common terms with a slightly different meaning. On the whole,
> I get the impression we both want to express similar concepts. We are
> both searching ways of keeping the handling of the Application clear
> and understandable.
>
>
> > On 17:22 Sun 20 Jul, Ichthyostega wrote:
> >> 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).
> ...
>
> Clay Barnes schrieb:
> > 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:
> ...
>
> No, I don't think I am proposing a separate new grouping feature here.
>
> Besides the track-tree, which I thought was something obvious.
> Now, if I recall correct, we never actually discussed and considered
> if we want a track-tree, because it seemed obvious. I vaguely recall
> one of the first discussions with Cehteh somewhere in spring 2007.
> Someone of us said something like "and btw., as we are partially
> redoing things, of course we fix the tracks not being a tree"
>
> The fact that tracks are /not/ a tree (but rather a flat list) in many
> video editors, indeed today seems like a braindead design mistake.
>
> Actually, if you consider history, it isn't so silly. Rather, I'd call
> it "legacy". Remember, 20 years ago, many prominent people held up the
> statement that you can't do "real film" editing with computers, just
> "fastfood crap". You had to convince people to use computer based
> editing, and of course everyone strived to make it feel as much as
> possible like "real film". Thus we got "media bins", an "A roll" / "B
> roll" video track with transitions in between, and sound tracks are
> nicely arranged separately like on good old multitrack magnetic tape
> machines.
>
> Meanwhile, maybe we still stick to it just out of habbit, but there
> is not much technological reason for things being organized this way.
>
> Today, none of the structures we see in the GUI of a video editor, is
> actually involved in the technical process of rendering media data.
>
> - clips don't any longer "contain" the media, they only refer to it
> - tracks don't any longer "play back" the media, they are simply a
> place you can put things at.
> - the framerate is no longer built into the machine, rather it's just
> a property you choose for rendering.
> and so on....
>
> Thus, the following conclusions seem obvious to me:
> - Tracks can be nested like folders or other containers. They form a
> tree, can be collapsed and inherit relevant settings down to subtracks
> (lockining, enabled, output port, fader setting etc.)
> - a clip has start, length and source position and refers to some
> source media
> - media always inherently contains multiple channels, which are tied
> together and used in sync.
> - most of the "wiring" can be done automatically, simply by considering
> the stream type and mixing it into the appropriate output port. Only
> in special and rather rare cases the user needs to define the
> output/wiring explicitly.
> - there is no difference between a "normal" clip and a "meta clip". They
> just refer to a different kind of media (an external media file versus
> the output port of another timeline)
> - there is no technical reason why the program should inhibit the user
> in mixing clips with various different media types, frame rates,
> channel counts etc. on the same track, because the track doesn't
> "playback" the media.
> - there is no reason why you should be restricted to "apply" an effect
> only to an complete clip. Effects can span multiple clips and even be
> faded and crossfaded separately from the media.
I agree on all these points, and I think the UI we have thus far
discussed definitely meets every one naturally.
>
> Many of today's existing video editing applications get some or all of
> those points wrong, probably because of sticking to some legacy state
> of affairs. Indeed, any of those points enlisted above, if overlooked,
> can cause a lot of unneeded code complexity and force quite some amount
> of unnecessary and stupid work on user.
>
> In our case, having to edit a movie imposes quite a bit of essential
> complexity. You have to care for lots of details and consider some
> subtle points, otherwise the work isn't professional.
>
>
> Clay Barnes schrieb:
> > 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.
> I fully agree with the latter statement: a meta-clip should be opaque.
> I the user wants to edit its internals, (s)he should "open" the
> meta-clip which would just switch to another timeline window tab.
>
> I don't understand your argument at the beginning of the paragraph.
> Letting aside that it's never a good idea to design the UI such as to
> avoid implementation bugs, we simply aren't in the situation to decide
> on "limitations" here. What is needed is dictated by actual necessities.
> Regarding Effects:
> - you have effects in a global bus insert (e.g. global deinterlacer)
> - you have effects on some timespan, irrespective of the content. This
> kind of effects are very frequently combined with automation.
> - you have effects applied to a whole clip
> - you have effects which need to be applied to a specific source media
> - you have effects applied just to a part of a clip, typically with
> automation
> - you have the situation where an effect spans a transition.
>
> All of these cases are everyday situations. You do no one a favour if
> you try to inhibit some of those cases, you just force people to use
> workarounds, often with serious consequences on the whole project.
I am afraid my poor up-all-night authorship has obscured my meaning.
None of the rendering effects is at odds with my idea in the least,
though I need to work out a good representation of effects tied to the
absolute last output rather than any one meta-track (i.e. global
effects).
> > 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.
>
> You are asking the wrong question. Not "how can containers be made to
> behave somewhat similar to normal clips"? This way you are creating
> "accidental complexity".
>
> The right question is: "is there any difference between the handling
> of real clips and meta-clips? What has to behave different?"
> And the answer is: there is none.
> They are just using a different kind of source media, that's all.
> (you can "edit" this source media of the meta-clip in another timeline,
> while you can't "edit" the source media from a media file or life
> input). You can trim, splice, rearrange, and combine them like normal
> clips and all of this doesn't cost a single line of additional code.
>
Again, I blame my borderline unconsciousness---I agree that my
eventual conclusion was that at most, the difference between them be
no more than having faded-out continuations be visible by default for
containers but not streams, and that I didn't like horizontal (in
time, that is) stacking of containers.
However, I realize that the second of those is clearly not a
problem---correlation between each of their constituent streams is
entirely unnecessary.
> > 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.
>
> First of all, we should be careful with our terminology.
> A media doesn't contain "tracks", it contains N separate *streams*.
> Each stream has a stream-type.
>
> A track, on the contrary doesn't contain media data, it doesn't
> "playback" or "mix" media (the latter is the job of the render- or
> processing engine). Consequently, it doesn't, on itself, have a
> stream-type. A track is just a place to arrange clips and effects,
> nothing more. There is no reason why you should artificially limit
> the kind of clips which can be put next to one another.
Terms noted. Excuse my persistent errors therewith until now.
> There is a GUI design problem though: how to draw the visualisation
> or preview of the clips? Do we really need to see the various possible
> streams within a single clip displayed "inline", in the timeline view??
> While, for example, displaying a mono waveform is certainly helpful,
> showing 9 tiny, almost identical waveforms of an 2nd order Ambisoncs
> track is quite silly. For the purpose of editing, it would be fully
> sufficient to show the waveform of the W channel (sound pressure sum).
> Similar argument for a clip containing three video channels from
> a multi-camera setup.
>
> ...
> > 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.
>
> This sounds like a nice idea to me. Of course there is no reason why
> such a feature shouldn't be available for real clips too.
My reluctance stemmed from that overlap in the faded extensions which
would show up in most work flows. I suppose the low importance allows
us to just have them 'run into' each other at the halfway point.
> In a similar vein, do you know the "region transparency" in Ardour?
> In Ardour you can stack regions on top of each other as you like,
> but the topmost region always covers what's "below". But if you
> switch the region to "transparent", you can hear a mix of both
> and you can see the waveform of the region "below" shine through
> the transparent waveform of the "upper" region.
> (In Ardour, "region" denotes what we call a "clip")
I am not aware of it. I'll install Ardour and have a look this week.
> >> 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:....
>
> > 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:
>
> Well, I can't see any difference between both descriptions (besides
> the small implementation detail when to re-adjust the offset). So
> I take it that we both judge the situation similarly.
>
> >
> > 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.
>
> Yeah, sounds like a good way of visualizing this relationship.
> (ok, I am aware that implementing such behaviour may have some rough
> edges, but from a usage point of view its easy to grasp)
>
> 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
(text/plain)
