diff --git a/doc/devel/uml/fig131333.png b/doc/devel/uml/fig131333.png new file mode 100644 index 000000000..2b4a00db7 Binary files /dev/null and b/doc/devel/uml/fig131333.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index c8908c30e..6d7dfdc87 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -112,7 +112,7 @@ Documentation
Artifact Cinelerra3

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, vrender, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, tool, segmentationtool, aframe, assembler, trafo

+

executable associated with : mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, tool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, vrender

Artifact main

Artifact source

@@ -801,6 +801,23 @@ reuse exiting Engine

Selection :

Transformation
Class RenderState
+ +

2.2.4 Use Case View config examples

+
+ +

+

multichannel clip



+ +
Class instance

type :Clip

+
Class instance

type :CompoundMedia

+
Class instance

type :Media

+
Class instance

type :Media

+
Class instance

type :Media

+
Class instance

type :CompoundClip

+
Class instance

type :SimpleClip

+
Class instance

type :SimpleClip

+
Class instance

type :SimpleClip

+
Class instance

type :Placement

2.3 Package RenderEngine

diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index 198d3e6c7..f3abdcc6c 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -29,24 +29,34 @@ checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging Cinelerra3artifactthe main executable to be built cinelerra3package +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance class instanceclass instance class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance clearoperationclear current session contents
without resetting overall session config.
Afterwards, the session will contain only one
empty EDL, while all Assets are retained.
Clipclassbookkeeping (asset) view of a media clip. clipartifactbookkeeping (asset) view of a media clip. @@ -69,6 +79,7 @@ compoundmediaartifacta special clip as a compound of several elementary media tracks,
e.g. the individual media streams found in one media file ConditionclassI provided a reworked Condition class in my cinelerra2 repository Configclass +config examplesuse case view configureoperation configure Renderactivity configure Toolsopaque activity action @@ -78,8 +89,8 @@ connectopaque activity action Constraintclass Controllercomponent -controllerpackagesourcecode package

The Processing and Render Controller,
located within the MObject Subsystem Controllerpackage +controllerpackagesourcecode package

The Processing and Render Controller,
located within the MObject Subsystem Controller Entitiesclass diagram Controller Workingsclass view ControllerFacadeclassProvides unified access to the Proc-Subsystem Controller. Especially, this Facade class provides the functions to get a render engine to carry out actual renderings. diff --git a/doc/devel/uml/index_77.html b/doc/devel/uml/index_77.html index 997d703b9..775e82c1e 100644 --- a/doc/devel/uml/index_77.html +++ b/doc/devel/uml/index_77.html @@ -39,6 +39,7 @@ mobjectpackagesourcecode package

MObject Subsystem
including the Session (EDL), Builder and Processing Controller MObjectpackage MObjectclass +multichannel clipobject diagram MutexclassI provided a reworked Mutex class in my cinelerra2 repository diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index eb3719cf0..d8d717c8e 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -21,8 +21,8 @@ saveoperationcreate a complete, serialized representation
of the current session config and contents.
@todo how to serialize, prameters, return value? Schedulerclass segmentartifactSegment of the Timeline.
Used at the moment (7/07) for partitioning the timeline/fixture into segments
to be rendered by a specialized render node network for each, without the need
to change any connections within a given segment.
Note this concept may be superfluos alltogether; is a draft and the real
use still needs to be worked out... -Segmentclass segment Toolactivity object +Segmentclass SegmentationToolclassTool implementation for deriving a partitioning of the current timeline such, that each segement has a constant configuration. "Constant" means here, that any remaining changes over time can be represented by automation solely, without the need to change the node connections. segmentationtoolartifactTool for creating a partitioning of the current timeline segmentsactivity object @@ -31,8 +31,8 @@ Service Componentsclass view Sessioncomponent sessionartifactInterface: the session edited by the user -Sessionclass view sessionpackagesourcecode package

Everything concerning the EDL and Session, within the MObject Subsystem +Sessionclass view SessionclassPrimary Interface for all editing tasks.
The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered. Session structureclass diagram sessionimplartifactholds the complete session data to be edited by the user diff --git a/doc/devel/uml/objectdiagrams.html b/doc/devel/uml/objectdiagrams.html index febb4a426..e45e944d2 100644 --- a/doc/devel/uml/objectdiagrams.html +++ b/doc/devel/uml/objectdiagrams.html @@ -20,6 +20,7 @@ EDL Example2More complex example showing the Object graph in the EDL and how it is linked into the Fixture to yield the actual locations. In this example, an HUE Effect is applied on a part of the Clip Engine Example1Example1 (from EDL) continued: here the RenderEngine to be created by the Builder from the Input shown in Example1 Engine Example2Example2 (from EDL) continued: notably in this RenderEngine the Effect has been partitioned into 2 segments with constant configuration. +multichannel clip diff --git a/src/common/time.hpp b/src/common/time.hpp index e434d27ed..1e94effb7 100644 --- a/src/common/time.hpp +++ b/src/common/time.hpp @@ -40,10 +40,10 @@ namespace cinelerra */ class Time { - int dummy; + long dummy; public: - Time(int dum=0) : dummy(dum) {} - operator int () { return dummy; } + Time(long dum=0) : dummy(dum) {} + operator long () { return dummy; } }; } // namespace cinelerra diff --git a/src/proc/mobject/placement.hpp b/src/proc/mobject/placement.hpp index 77e38174b..57722a6ad 100644 --- a/src/proc/mobject/placement.hpp +++ b/src/proc/mobject/placement.hpp @@ -73,7 +73,12 @@ namespace mobject class ExplicitPlacement; - + /** + * A refcounting Handle to an MObject of type MO, + * used to constrain or explicitly specify the + * location where the MObject is supposed to + * be within the Session/EDL + */ template class Placement : protected shared_ptr { diff --git a/src/proc/mobject/session/fixedlocation.cpp b/src/proc/mobject/session/fixedlocation.cpp index 08c19aa24..df5164c43 100644 --- a/src/proc/mobject/session/fixedlocation.cpp +++ b/src/proc/mobject/session/fixedlocation.cpp @@ -29,6 +29,22 @@ namespace mobject { /** */ + + void + FixedLocation::intersect (LocatingSolution& solution) const + { + REQUIRE (!solution.is_definite() && !solution.is_overconstrained()); + + TODO ("either set position or make overconstrained"); + if (solution.minTime <= this.time_) + solution.minTime = this.time_; + else + solution.impo = true; + if (solution.maxTime >= this.time_) + solution.maxTime = this.time_; + else + solution.impo = true; + } diff --git a/src/proc/mobject/session/fixedlocation.hpp b/src/proc/mobject/session/fixedlocation.hpp index e3a51056b..55f5a043d 100644 --- a/src/proc/mobject/session/fixedlocation.hpp +++ b/src/proc/mobject/session/fixedlocation.hpp @@ -37,9 +37,15 @@ namespace mobject * The most common case of positioning a MObject * in the EDL: directly specifying a constant position. */ - class FixedLocation : public LocatingPing + class FixedLocation : public LocatingPin { - /////////// + Time time_; + Track track_; + + protected: + FixedLocation (Time ti, Track tra) : time_(ti), track_(tra) {}; + + virtual void intersect (LocatingSolution&) const; }; diff --git a/src/proc/mobject/session/locatingpin.cpp b/src/proc/mobject/session/locatingpin.cpp index be9b2863c..6e27298e0 100644 --- a/src/proc/mobject/session/locatingpin.cpp +++ b/src/proc/mobject/session/locatingpin.cpp @@ -21,15 +21,144 @@ * *****************************************************/ -#include "proc/mobject/session/locatingpin.hpp" #include "proc/mobject/placement.hpp" +#include "proc/mobject/session/locatingpin.hpp" +#include "proc/mobject/session/fixedlocation.hpp" +#include "proc/mobject/session/relativelocation.hpp" namespace mobject { namespace session { - /** */ + /** it's OK to copy a LocainngPin, + * causing duplication of any chained lPins + */ + LocatingPin::LocatingPin (const LocatingPin& other) + : next_(other.next_) + { } + + + LocatingPin& + LocatingPin::operator= (const LocatingPin& other) + { + if (this!=other) + this.next_.reset (other.next_); + return *this; + } + + + LocatingPin& + LocatingPin::addChain (LocatingPin newLp) + { + REQUIRE (newLp); + REQUIRE (!newLp->next_, "can insert only single LocatingPins"); + + if (next_ && newLp->getPrioLevel() > next_->getPrioLevel()) + return next_->addChain (newLp); + else + { + scoped_ptr tmp_next (newLp); + tmp_next->next_.reset(this.next_); + this.next_.swap(tmp_next); + return *newLp; + } + } + + + /** implementing the core Placement functionality. + * By combining all the chained locating pins, try + * to get at a definite position (for this chain and + * consequently for the MObject handled by the enclosing + * Placement object). + * @todo this could/should be replaced by a full-blown + * constraint solver at some point in the future + */ + const FixedLocation + LocatingPin::resolve () const + { + LocatingSolution solution; + resolve (solution); + return FixedLocation (solution.getTime(), solution.getTrack()); + } + + + void + LocatingPin::resolve (LocatingSolution& solution) const + { + if (solution.is_definite() || solution.is_impossible()) + return; + this.intersect (solution); + if (this.next_ && + !(solution.is_definite() || solution.is_impossible()) + ) + next_->resolve(solution); + } + + + void + LocatingPin::intersect (LocatingSolution& solution) const + { + REQUIRE (!solution.is_definite() && !solution.is_impossible()); + // base class Implementation is NOP... + } + + + /** get some time value which could stand in for this + * solution. This doesn't imply this value is a solution, + * It's just a value we can use. At the moment (10/07), + * LocatingSolution is implemented as interval, and + * we return the lower bound here. + */ + LocatingPin::Time + LocatingPin::LocatingSolution::getTime() + { + return minTime; + } + + LocatingPin::Track + LocatingPin::LocatingSolution::getTrack() + { + UNIMPLEMENTED ("get effective Track number of Solution"); + } + + + bool + LocatingPin::LocatingSolution::is_definite() ///< found a solution? + { + return (minTime == maxTime && minTrack == maxTrack); + } + + bool + LocatingPin::LocatingSolution::is_impossible() + { + if (minTime > maxTime) impo = true; + TODO ("track???"); + return impo; + } + + + + + + + /* === Factory functions for adding LocatingPins === */ + + FixedLocation& + LocatingPin::operator() (Time, Track) + { + return static_cast + (this.addChain (*new FixedLocation (Time, Track))); + } + + + RelativeLocation& + LocatingPin::operator() (PMO refObj, Time offset=0) + { + return static_cast + (this.addChain (*new RelativeLocation (Time, Track))); + } + diff --git a/src/proc/mobject/session/locatingpin.hpp b/src/proc/mobject/session/locatingpin.hpp index 9d372111d..1637aa48f 100644 --- a/src/proc/mobject/session/locatingpin.hpp +++ b/src/proc/mobject/session/locatingpin.hpp @@ -21,6 +21,23 @@ */ +/** @file locatingpin.hpp + ** Implementing the Placement mechanics. The various specifications how + ** some MObject is to be placed (logically) within the EDL are given by small + ** LocatingPin objects forming a chain. For resolving the actual position, at the + ** moment (10/07) we use a preliminary implementation to support the most common + ** Placement types (fixed and relative). It is comprised of the nested LocatingSolution + ** and the functions FixedLocation#resolve(LocatingSolution&) and + ** RelativeLocation#resolve(LocatingSolution&) etc. If this is to be extended, + ** we'll need a real spacial discrete constraint solver (and it probably should be + ** a library implementation, because the problem is everything but trivial). + ** + */ + + + + + #ifndef MOBJECT_SESSION_LOCATINGPIN_H #define MOBJECT_SESSION_LOCATINGPIN_H @@ -42,22 +59,78 @@ namespace mobject class RelativeLocation; - struct LocatingPin + /** + * Positioning specification, possibliy chained + * to further specifications. The base class LocatingPin + * is a "no-op" specification which doesn't constrain the + * possible locations and thus can be embedded into pristine + * Placement by default. The Functor operators provide a + * way to add concrete positioning specifications, thereby + * defining the position of the MObject to be placed. + */ + class LocatingPin { protected: - typedef cinelerra::Time Time; - typedef session::Track* Track; + typedef cinelerra::Time Time; + typedef session::Track* Track; /** next additional Pin, if any */ - scoped_ptr next; - public: + scoped_ptr next_; - /* Factory functions for adding LocationPins */ + /** order to consider when resolving. 0=highest */ + virtual int getPrioLevel () const { return 0; } + + LocatingPin& addChain (LocatingPin); + void resolve (LocatingSolution&) const; + virtual void intersect (LocatingSolution&) const; + + public: + const FixedLocation resolve () const; + + /* Factory functions for adding LocatingPins */ FixedLocation& operator() (Time, Track); RelativeLocation& operator() (PMO refObj, Time offset=0); - + + LocatingPin (const LocatingPin&); + LocatingPin& operator= (const LocatingPin&); + virtual ~LocatingPin() {}; + + protected: + LocatingPin () {}; + + /** + * @internal helper for the (preliminary) + * position resolve() implementation. + * @todo we can't sensibly reason about tracks, + * because at the moment (10/07) we lack a track implementation... + */ + struct LocatingSolution + { + Time minTime; + Time maxTime; + Track minTrack; + Track maxTrack; + bool impo; + + LocatingSolution () + : minTime(-1e15), // TODO: better implementation of "unspecified..." + maxTime(+1e15), + minTrack(0), // TODO + maxTrack(0), + impo(false) + { } + + Time getTime(); + Track getTrack(); + + bool is_definite(); + bool is_impossible(); + }; }; + + + } // namespace mobject::session diff --git a/src/proc/mobject/session/relativelocation.cpp b/src/proc/mobject/session/relativelocation.cpp index 6fd934f12..a0e0daa25 100644 --- a/src/proc/mobject/session/relativelocation.cpp +++ b/src/proc/mobject/session/relativelocation.cpp @@ -1,5 +1,5 @@ /* - RelativePlacement - Placement implemnetaion providing various ways of attaching a MObject to another one + RelativeLocation - Placement implementation attaching MObjects relative to another one Copyright (C) CinelerraCV 2007, Christian Thaeter @@ -21,7 +21,7 @@ * *****************************************************/ -#include "proc/mobject/session/relativeplacement.hpp" +#include "proc/mobject/session/relativelocation.hpp" #include "proc/mobject/mobject.hpp" namespace mobject @@ -29,7 +29,15 @@ namespace mobject namespace session { + void + RelativeLocation::intersect (LocatingSolution& solution) const + { + REQUIRE (!solution.is_definite() && !solution.is_overconstrained()); + + TODO ("either set position or make overconstrained"); + } + } // namespace mobject::session } // namespace mobject diff --git a/src/proc/mobject/session/relativelocation.hpp b/src/proc/mobject/session/relativelocation.hpp index 577c741f3..1c2003e22 100644 --- a/src/proc/mobject/session/relativelocation.hpp +++ b/src/proc/mobject/session/relativelocation.hpp @@ -49,14 +49,17 @@ namespace mobject }; protected: - MObject* anchor; + Placement anchor; ////////////TODO: ooooops, this is a nasty design problem!!! /** the kind of relation denoted by this Placement */ RelType relType; /** Offset the actual position by this (time) value relative to the anchor point. */ - cinelerra::Time offset; + Time offset; //TODO: suitable representation? + + + virtual void intersect (LocatingSolution&) const; }; diff --git a/uml/cinelerra3/128261 b/uml/cinelerra3/128261 index 9925728b7..10080e773 100644 --- a/uml/cinelerra3/128261 +++ b/uml/cinelerra3/128261 @@ -1,6 +1,6 @@ format 40 "MObject" // ProcessingLayer::MObject - revision 26 + revision 27 modified_by 5 "hiv" // class settings //class diagram settings @@ -1107,4 +1107,99 @@ ${inlines} package_ref 128901 // Builder package_ref 129029 // Controller + + usecaseview 128261 "config examples" + //use case diagram settings + package_name_in_tab default show_context default auto_label_position default draw_all_relations default shadow default + //sequence diagram settings + show_full_operations_definition default write_horizontally default class_drawing_mode default drawing_language default draw_all_relations default shadow default + //collaboration diagram settings + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + //object diagram settings + write_horizontally default package_name_in_tab default show_context default auto_label_position default draw_all_relations default shadow default + objectdiagram 131333 "multichannel clip" + write_horizontally default package_name_in_tab default show_context default auto_label_position default draw_all_relations default shadow default + size A4 + end + + classinstance 134661 "" + type class_ref 137349 // Clip + attributes + end + relations + end + end + + classinstance 134789 "" + type class_ref 138501 // CompoundMedia + attributes + end + relations + end + end + + classinstance 134917 "" + type class_ref 136709 // Media + attributes + end + relations + end + end + + classinstance 135045 "" + type class_ref 136709 // Media + attributes + end + relations + end + end + + classinstance 135173 "" + type class_ref 136709 // Media + attributes + end + relations + end + end + + classinstance 135301 "" + type class_ref 138629 // CompoundClip + attributes + end + relations + end + end + + classinstance 135429 "" + type class_ref 138885 // SimpleClip + attributes + end + relations + end + end + + classinstance 135557 "" + type class_ref 138885 // SimpleClip + attributes + end + relations + end + end + + classinstance 135685 "" + type class_ref 138885 // SimpleClip + attributes + end + relations + end + end + + classinstance 135813 "" + type class_ref 128645 // Placement + attributes + end + relations + end + end + end end diff --git a/uml/cinelerra3/129285 b/uml/cinelerra3/129285 index ec9e7d7fc..551a99b4b 100644 --- a/uml/cinelerra3/129285 +++ b/uml/cinelerra3/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 5 + revision 6 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/131333.diagram b/uml/cinelerra3/131333.diagram new file mode 100644 index 000000000..c53581101 --- /dev/null +++ b/uml/cinelerra3/131333.diagram @@ -0,0 +1,62 @@ +format 40 + +classinstancecanvas 128005 classinstance_ref 134661 // + xyz 233 116 2000 + end +classinstancecanvas 128133 classinstance_ref 134789 // + xyz 297 53 2000 + end +classinstancecanvas 128261 classinstance_ref 134917 // + xyz 335 112 2000 + end +classinstancecanvas 128389 classinstance_ref 135045 // + xyz 335 144 2000 + end +classinstancecanvas 128517 classinstance_ref 135173 // + xyz 335 177 2000 + end +fragment 128773 "" + xyzwh 311 90 1994 83 139 +end +classinstancecanvas 129157 classinstance_ref 135301 // + xyz 65 116 2000 + end +classinstancecanvas 129285 classinstance_ref 135429 // + xyz 95 176 2000 + end +classinstancecanvas 129413 classinstance_ref 135557 // + xyz 95 208 2000 + end +classinstancecanvas 129541 classinstance_ref 135685 // + xyz 95 241 2000 + end +fragment 129669 "" + xyzwh 70 153 1994 93 136 +end +classinstancecanvas 129925 classinstance_ref 135813 // + xyz 75 33 2000 + end +fragment 130181 "EDL" + xyzwh 12 12 2000 167 305 +end +fragment 130437 "asset management" + xyzwh 221 12 2005 184 236 +end +objectlinkcanvas 128645 norel + from ref 128133 z 1999 to ref 128261 + no_role_a no_role_b +objectlinkcanvas 128901 norel + geometry VH + from ref 128005 z 1999 to point 256 64 + line 129029 z 1999 to ref 128133 + no_role_a no_role_b +objectlinkcanvas 129797 norel + from ref 129157 z 1999 to ref 129285 + no_role_a no_role_b +objectlinkcanvas 130053 norel + from ref 129925 z 1999 to ref 129157 + no_role_a no_role_b +objectlinkcanvas 130309 norel + from ref 129157 z 1999 to ref 128005 + no_role_a no_role_b +end diff --git a/uml/cinelerra3/cinelerra3.prj b/uml/cinelerra3/cinelerra3.prj index 62217077f..78317c6ff 100644 --- a/uml/cinelerra3/cinelerra3.prj +++ b/uml/cinelerra3/cinelerra3.prj @@ -1,6 +1,6 @@ format 40 "cinelerra3" - revision 35 + revision 36 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/renderengine.html b/wiki/renderengine.html index c68c94676..384c32e10 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -1459,7 +1459,7 @@ For the case in question this seems to be the ''resource allocation is construct And, last but not least, doing all actual allocations is the job of the backend. Exceptions being long-lived objects, like the Session or the EDL, which are created once and don't bear the danger of causing memory pressure. Besides that, the ProcLayer code shouldn't issue "new" and "delete", rather it should use some central [[Factories]] for all allocation and freeing, so we can redirect these calls down to the backend, which may use pooling or special placement allocators or the like. The rationale is, for modern hardware/architectures, care has to be taken with heap allocations, esp. with many small objects and irregular usage patterns. -
+
Based on practical experiences, Ichthyo tends to consider Multichannel Media as the base case, while counting media files providing just one single media stream as exotic corner cases. This may seem counter intuitive at first sight; you should think of  it as an attempt to avoid right from start some of the common shortcomings found in many video editors, especially
 * having to deal with keeping a "link" between audio and video clips
 * silly limitations on the supported audio setups (e.g. "sound is mono, stereo or Dolby-5.1")
@@ -1467,6 +1467,7 @@ And, last but not least, doing all actual allocations is the job of the backend.
 * inability to edit stereoscopic (3D) video in a natural fashion
 
 !Compound Media
+[>img[Outline of the Build Process|uml/fig131333.png]]
 Basically, each [[media asset|MediaAsset]] is considered to be a compound of several elementary media (tracks), possibly of various different media kinds. Adding support for placeholders (''proxy clips'') at some point in future will add still more complexity (because then there will be even dependencies between some of these elementary media). To handle, edit and render compound media, we need to impose some structural limitations. But anyhow, we try to configure as much as possible already at the "asset level" and make the rest of the proc layer behave just according to the configuration given with each asset.
 
 So, when creating a clip out of such a compound media asset, the clip has to be a compound of elementary clips mirroring the given media asset's structure. Besides, it should be possible to //detach// and //attach// elementary clips from a compound clip. On the other hand, the [[Fixture]] created from the current state of the [[EDL]] is explicit to a great extent. So, in the Fixture we deal only with elementary clips placed to absolute positions, and thus the builder will see only simple non-compound clips and translate them into the corresponding source reading nodes.
@@ -2398,7 +2399,7 @@ config.macros.rssFeedUpdate = {
 //}}}
-
+
What is the Role of the asset::Clip and how exactly are Assets and (Clip)-MObjects related?
 
 First of all: ~MObjects are the dynamic/editing/manipulation view, while Assets are the static/bookkeeping/searching/information view of the same entities. Thus, the asset::Clip contains the general configuration, the ref to the media and descriptive properties, while all parameters being "manipulated" belong to the session::Clip (MObject). Besides that, the practical purpose of asset::Clip is that you can save and remember some selection as a Clip (Asset), maybe even attach some informations or markup to it, and later be able to (re)create a editable representation in the Session (the GUI could implement this by allowing to drag from the asset::Clip GUI representation to the timeline window)
@@ -2413,9 +2414,9 @@ When the Asset or the corresponding asset::Media is deleted, the dependant clip-
 In either case, we have to solve the ''problem of clip asset proliferation''
 
 !!multiplicity and const-ness
-The link between ~MObject and Asset should be {{{const}}} in both directions (to enforce the separation of concerns). So the Asset can't //edit// the clip and the clip can't change the media parameters.
-
-The relation logical relation, but it is not strictly 1:1 because typical media are [[multichannel|MultichannelMedia]]. Even if the media is compound, there is //only one asset::Clip//, because in the logical view we have only one "clip-thing". On the other hand, in the Session/EDL, we have a compound clip ~MObject comprised of several elementary clip objects, each of which will refer to its own sub-media (channel) within the compound media (and don't forget, this structure can be tree-like)
+The link between ~MObject and Asset should be {{{const}}}, so the clip can't change the media parameters. Because of separation of concerns, it would be desirable that the Asset can't //edit// the clip either (meaning {{{const}}} in the opposite direction as well). But unfortunately the asset::Clip is in power to delete the clip-MO and, moreover, handles out a smart ptr ([[Placement]]) referring to the clip-MO, which can (and should) be used to place the clip-MO within the EDL and to manipulate it consequently...
+[>img[Outline of the Build Process|uml/fig131333.png]]
+At first sight the link between asset and clip-MO is a simple logical relation between entities, but it is not strictly 1:1 because typical media are [[multichannel|MultichannelMedia]]. Even if the media is compound, there is //only one asset::Clip//, because in the logical view we have only one "clip-thing". On the other hand, in the Session/EDL, we have a compound clip ~MObject comprised of several elementary clip objects, each of which will refer to its own sub-media (channel) within the compound media (and don't forget, this structure can be tree-like)
 {{red{open question:}}} do the clip-MO's of the individual channels refer directly to asset::Media? does this mean the relation is different from the top level, where we have a relation to a asset::Clip??