Am Mittwoch, den 06.02.2008, 09:02 +0100 schrieb Richard Spindler: > I've made a little Picture about how I think the User Interface of a > yet to be named Video Editor could be presented. > > http://propirate.net/oracle/zipfiles/UI-concepts-CineTris.png > cehteh, ichthyo, do you think that the backend could be used with > such a frontend?
Hi Richard, the structure displayed in your drawing is to a large degree identical to the "high level model" I am currently developing in the Proc-Layer (middle Layer of the application). Besides, our design incorporates a Builder, which creates a uniform network of render nodes which will be implemented/driven by the backend. But the intention is to rather shield the user from the low level model while presenting him a view of the high level model. So, largely, you can take it as agreement. In the following I'll concentrate on differences in deail or on things I do a bit more flexible than in your proposal: *Tracks and Busses*: in the Proc-Layer, material on one track can connetct to several different Busses. I want to ged rid of this often very limiting "leftover" from the old analogue hardware, where each track corresponds to one reading/writing head and thus to one bus. Even in the simplest case, for me a "Clip" containts a video and an stereo audio stream and thus makes connection to two busses simulatnously. *Tracks are a Tree*: Tracks are nested right from start. You can attach properties on every level. Most important property of course is the output bus connection, further properties are layer ordering, sound PAN position, MIDI instrument/channel asignments. Each Clip searches the next-applicable properties he needs. (Here the rule-based aproach comes into play, but from users view, this is not immediatly obivious, because the application will come with a set of pretty much conventional rules). *One or multiple Timelines?*: The Proc-Layer has N distinct EDLs in the Session. Each EDL is a collection of objects placed in some way, but from users view it can appear as an separate timeline. Obviously each timeline can either be anchored at an absolute time or just use relative coordinates (it doesn't make any difference). An EDL can be placed in the form of a meta-clip in another EDL -- that's similar to the "sub-timeline" in your drawing. *basic building block = Pipeline*: We are using various names for the same concept: Node Graph, Bus, Scratch Bus in your drawing, "Port" in my design and implementation. I am trying to find a grippy name for this entity all the time, an currently I am geared to call it just "Pipeline". Other opinions or proposals? Some facts to further the discussion: - remember it's the high level model. Its an abstraction the user works with. You can expect this "Pipeline" to be translated into a chain of connected nodes in the low-level model, but it is not identical to this chain. - each clip is built round a Pipeline, containing the effects directly attached to the clip. At the source end, it will be connected either to a source reader + Codec, or recieve input from some other Pipeline. - we have global Pipelines ("Busses") forming a matrix similar to the mixer strips of a sound mixing console. As said, we can have attachement points to these global Pipelines at various levels in the tree of tracks, and in several EDLs simultanously, so each global pipeline can recieve input from different and varying sources. - an EDL which is a meta-clip can be configured either to connect to the global Pipelines directly, or it can connect to the local Pipeline of the meta-clip, where we could attach further effects and transitions. This configuration can even be mixed: e.g. route the sound directly but send the video through the meta-clip *limit the Pipelines to linear chains?*: I want to hear your opinion about limiting the individual pipeline to a strictly linear chain of nodes! The only exception would be "send nodes", which can make arbitrary conections to the input side of other Pipelines. The rationale is code simplicity. Having a tree or even network within each Pipeline makes building, addressing, processing and managing much more complicated without providing anything you could not get similar by connecting a "send node" or the exit point of a Pipeline to another Pipeline (which could be a global one, or just appear as clip somewhere in some EDL and thus add even the possiblility of changing the config in a time varying fashion). > There is no central notion of the camera/projector Model, which I think > could be added anywhere in the Graphs as a Node with an unlimited Number > of inputs. Agreed, I am following the same line of thought. Besides, I plan to make the default configuration rules such as to insert a "camera" node in case the source resolution is different of what can be derived for the Clip-Pipeline and similarily to insert a "projector" node automatically when the desired output canvas differs from what can be derived for the global Pipelines to be output. *Automation* will appear as separate objects (containing some curve, defined either mathematically or by a dataset). They will be connected and used by the same aproach any other connections are made: they can be either placed/attached directly or be discovered in the context by a rule-based aproach. Meaning you could have local automation following a individual clip, as well als global automation fixed relative to the timeline. Cheers, and have fun... Hermann V. _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra