Re: [Kdenlive-devel] Operators and Properties

[Jason W. <jas...@bl...>]

On Monday 04 Nov 2002 6:05 pm, Rolf Dubitzky wrote:
> On Monday 04 November 2002 03:47 pm, Jason Wood wrote:
> > You have essentially described what I consider to be a "scene" :-)
>
> [...]
>
> > Hopefully, you see that this is essentially just a "break down" of what
> > your idea is into smaller chunks, which can be just as easily merged
> > together again as they were to break up.
>
> Ok, just to make sure we are talking about the same thing. I am not talking
> about graphical representation. 

Neither am I, scenes are what I used within the cutting list specification. I 
used a screengrab of the timeline as a simply means of showing (I hope) how I 
would break down the graphical representation to create scenes.

> The GUI must look more or less like your
> example. A movie in a tree view is probably confusing. The representation
> in memory is a different issue. Even if the visualisation is somewhat
> serial (with a few layers) the representation in memory can be more
> efficient. 

I agree. Incidentally, there is going to be no track limit within Kdenlive 
except that imposed by MAX_INT. And if anyone reaches that limit... I would 
suggest that they break their project up a little to make it more maneagable 
;-)

>But also this arangement can give some ideas for the GUI. in you
> example, concider the second and third track as a small subproject as
> indicated by the black box around it in the modified scene_example.jpg
> (attached). In the tree you can just lock it and collaps the view to a
> single track if you like. It could even be prerendered to a cache. 

We have to stop having the same ideas :-) If you look in the kdenlive source, 
there is a (currently) skeleteon class called DocClipProject which will 
essentially become just that. Interface-wise, my plan is that you will select 
a number of clips on the timeline, select a "create compound clip" option, 
and all of the clips will become encapsulated into a single clip. Useful for 
tightly edited sequences which you then want to be able to move around 
without accidentally messing up the timing.

> From the
> implementation point of view, it is certainly easier, because if you drag
> it around, you can just insert a node a some place in the tree and attch
> it. Done. In a serial scenario as yours, you will have to rearange
> everything. Rearange horizontally and maybe also vertically. Anyway, my
> point is, that you only will only gain in complexity if you start speaking
> of individual scenes with overlapping content.

Ok, here is the way that I see it as working at present :

1. The Timeline is represented as shown, with tracks capable of sliding over 
each other, they can be resized, chopped up, have effects, applied, you name 
it.

2. When we want to render something (preview, production, etc.) We take this 
internal GUI representation and translate it into a number of scenes, which 
we then pass onto a scheduler.

3. The scheduler looks at the scenes that it has been asked to process, 
compares them to scenes that have already been processed, and substitutes in 
any pre-rendered caches that it has for scenes, or partial scene trees. The 
now-modified scenes get passed onto the the renderer(s) to be renderered.

(On a sidenote, it's hard to describe how the scheduler will work, but it 
effectively acts as a proxy between the GUI and the cutter(s), and is their 
to make the most effective usage of resources that it can. Essentially, it 
should be transparent to both GUI and the cutter.)

Just in case I am not clear about what a scene is, a scene itself is 
represented as a tree in the same way that you represent media elements, 
(operators, nodes, leaves, the lot) but they are strung together in serial 
fashion to make the entire movie.

If you like, a scene is a "building block" element for a movie. It describes a 
transition between two videos, or an effect of a part of a video, or just the 
playback of a single video, or it could describe how 30 seperate videos 
should be combined correctly to perform a complex effect. But it only 
describes one such thing, and then another scene takes care of the next bit 
of the movie.

As far as I can tell, this "should we break the tree up into chunks or not" is 
the only difference between your view of how the cutting list should work, 
and my view.

> > > In the timeline these property-nodes must be visible. You must be able
> > > to insert new nodes, delete old nodes and popup a window to edit the
> > > values for a node.
> >
> > Or in other words, I need to write a KeyFrame widget :-)
>
> KeyFrame?

A key frame is a term that I believe orginated in computer animation, but is 
used in similar applications which have a timeline.

Effectively, it is your idea of a PropertyNode. You specify "key frames", 
which are those frames where you specifically say "This property should be 
this value at this time", and you specify what interpolation needs to occur 
to get from one key frame to the next.

> > > The usual separation in "transitions" and "effects" makes sense with
> > > analog cutting mashines, it is just nonsense if you have a computer.
> >
> > Hmmm... It depends on what editing analogy you choose for the editor. I
> > haven't made that choice yet for Kdenlive. For instance, Adobe Premier
> > has a seperate "transition" line on the timeline (though I never enjoyed
> > that way of editing because it is awfully implemented). Whilst I can
> > envisage an interface which models a multicamera shoot such as you would
> > do whilst mixing a live show. In that case, having effects and
> > transitions seperate does make sense.
>
> Ok, you have a picture in picture operation. The initial width of the
> picture is 0, the maximum is full. Is this a transition or an effect?
> Probably you would call it transition.  If it just reaches 80% and gets
> smaller afterwards... No transition? Now it is an effect? My answer: its an
> operation with two frames, don't distinguish between transition and effect.
> UnaryOps might always be called effects, though.

I really don't think this is worth arguing over at this moment in time. Let's 
discuss again when we are implementing the interface for transitions.

Cheers,
Jason

p.s. I am now committing a fixed version of Kdenlive which does not have the 
crash-on-exit bug. I have also made use of those standard icons I was talking 
about before ;-)

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk