WIP reworked approach for clip-to-clipAsset relation.

(compiler errors spotted a design problem)

src/proc/asset/clip.cpp

@@ -51,7 +51,7 @@ namespace asset
         {
           return mobject::MObject::create(
                      AssetManager::instance()
-                               .getAsset (mediaID));
+                               .getAsset (mediaID));  //////TODO: to service the new session::Clip ctor, somehow have to solve the "shared ptr from this" problem
         }
     }
   
@@ -77,9 +77,7 @@ namespace asset
   Clip::createClip ()
   {
     if (!clipMO_)
-      clipMO_ = mobject::MObject::create(
-                  AssetManager::instance()
-                     .getAsset (this->getID()));
+      clipMO_ = createClipMO (this->getID());
     
     return clipMO_;
   }

src/proc/mobject/placement.cpp

@@ -0,0 +1,41 @@
+/*
+  Placement  -  Key Abstraction: a way to place and locate a Media Object
+ 
+  Copyright (C)         CinelerraCV
+    2007,               Christian Thaeter <ct@pipapo.org>
+ 
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of the
+  License, or (at your option) any later version.
+ 
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+ 
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ 
+* *****************************************************/
+
+
+#include "proc/mobject/placement.hpp"
+#include "proc/mobject/explicitplacement.hpp"
+
+namespace mobject
+  {
+
+
+  /** */
+  template<class MO>
+  ExplicitPlacement
+  Placement<MO>::resolve ()  const 
+    { 
+      return ExplicitPlacement (*this, chain.resolve()); 
+    }
+
+
+
+} // namespace mobject

src/proc/mobject/session/clip.cpp

@@ -22,6 +22,8 @@
 
 
 #include "proc/mobject/session/clip.hpp"
+#include "proc/asset/media.hpp"
+#include "proc/asset/clip.hpp"
 
 namespace mobject
   {
@@ -31,10 +33,13 @@ namespace mobject
     /** new clip-MO linked with the given asset::Clip.
      *  Initially, this clip will cover the whole source media length. 
      */
-    Clip::Clip (PClipAsset& mediaDef)
+    Clip::Clip (PMedia& mediaDef, PClipAsset& clipRef)
       : start_(0),
-        mediaDef_(mediaDef)
+        mediaDef_(mediaDef),
+        clipRef_(clipRef)
     {
+      REQUIRE (mediaDef_);
+      REQUIRE (clipRef_);
       setupLength();
     }
     
@@ -56,6 +61,15 @@ namespace mobject
       UNIMPLEMENTED ("calculate the length of a clip and set length field");
       // will use mediaDef to query media parameters....
     }
+    
+    
+    PMedia 
+    Clip::getMedia ()  const                        
+    { 
+      UNIMPLEMENTED ("how to relate MObjects and media assets...");
+      return mediaDef_->getMedia();
+    }
+
 
 
 

src/proc/mobject/session/clip.hpp

@@ -63,9 +63,10 @@ namespace mobject
 
         //TODO: where to put the duration ???
         
-        PClipAsset mediaDef_;
+        PMedia mediaDef_;
+        PClipAsset clipRef_;
 
-        Clip (PClipAsset& mediaDef);
+        Clip (PMedia& mediaDef, PClipAsset& clipRef);
         friend class MObjectFactory;
         
         
@@ -75,11 +76,7 @@ namespace mobject
         virtual bool isValid()  const;
         
         /** access the underlying media asset */
-        virtual PMedia getMedia ()                        
-          { 
-            UNIMPLEMENTED ("how to relate MObjects and media assets...");
-            //return AssetManager::instance().getAsset(IDA(0)); // KABOOM! (just to make it compile)
-          }
+        virtual PMedia getMedia ()  const;
         
       };
       

src/proc/mobject/session/mobjectfactory.cpp

@@ -46,9 +46,9 @@ namespace mobject
      *  @todo implement creation of multichannel CompoundClip
      */
     Placement<Clip>   
-    MObjectFactory::operator() (PClipAsset& mediaDef)
+    MObjectFactory::operator() (PMedia& mediaDef, PClipAsset& clipRef)
     {
-      return Placement<Clip> (*new Clip (mediaDef), &deleterFunc);
+      return Placement<Clip> (*new Clip (mediaDef,clipRef), &deleterFunc);
     }
     
     
@@ -56,7 +56,7 @@ namespace mobject
     Placement<Effect>
     MObjectFactory::operator() (asset::Effect processorDef)
     {
-      
+      UNDEFINED ("fabricate effect-MO");
     }
 
 

wiki/renderengine.html

@@ -1411,14 +1411,14 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 [[Admin]]
 &lt;&lt;fullscreen&gt;&gt;</pre>
 </div>
-<div title="ManagementAssetRelation" modifier="Ichthyostega" modified="200710191600" created="200708100337" tags="impl" changecount="6">
+<div title="ManagementAssetRelation" modifier="Ichthyostega" modified="200711130118" created="200708100337" tags="impl" changecount="8">
 <pre>Problem is: when removing an Asset, all corresponding MObjects need to disappear. This means, besides the obvious ~Ref-Link (MObject referring to an asset) we need backlinks or a sort of registry. And still worse: we need to remove the affected MObject from the object network in the EDL and rebuild the Fixture...
 
 &amp;rarr; for a general design discussion see [[Relation of Clip and Asset|RelationClipAsset]]
 
 As a //first shot// Ichthyo considers the following approach:
 * all references between MObjects and Assets are implemented as __refcounting__ boost::shared_ptr
-* the opposite direction is also a __strong references__, effectively keeping the clip-MO alive even if it is no longer in use in the session (note this is a cyclic dependency that needs to be actively broken on deletion). This design decision is based on  logical considerations (&amp;rarr; see &quot;deletions, Model-2&quot; [[here|RelationClipAsset]]). The back-link is needed only for clean deletion of Assets and for GUI search functions.
+* the opposite direction is also a __strong reference__, effectively keeping the clip-MO alive even if it is no longer in use in the session (note this is a cyclic dependency that needs to be actively broken on deletion). This design decision is based on  logical considerations (&amp;rarr; see &quot;deletions, Model-2&quot; [[here|RelationClipAsset]]). This back-link is implemented by a Placement which is stored internally within the asset::Clip, it is needed for clean deletion of Assets, for GUI search functions and for adding the Clip to the EDL (again after been removed, or multiple times as if cloned).
 * MObjects and Assets implement an {{{unlink()}}} function releasing the internal links to other entities.
 * Instead of a delete, we call this unlink() function and let the shared_ptr handle the actual deletion.
 * we don't use a registry, rather we model the real dependencies by individual dependency links. So a MediaAsset gets links to all Clips created from this Asset and by traversing this tree, we can handle the deletion
@@ -1494,24 +1494,24 @@ So, when creating a clip out of such a compound media asset, the clip has to be
 * we distinguish elementay (non-compound) Clips from compound clips by concrete subtype. The builder can only handle elementary clips, because he needs to build a separate pipeline for every output channel. So the work of splitting common effect stacks for clips with several channels needs to be done when calculating the Fixture for the current EDL. The Builder expects to be able to build the render nodes corresponding to each entity found in the Fixture one by one.
 * the Builder gets at the ProcPatt (descriptor) of the underlying media for each clip and uses this description as a template to build the render pipeline. That is, the ProcPatt specifies the codec asset and maybe some additional effect assets (deinterlace, scale) necessary for feeding media data corresponding to this clip/media into the render nodes network.</pre>
 </div>
-<div title="ObjectCreation" modifier="Ichthyostega" modified="200710090219" created="200709030139" tags="impl design" changecount="15">
+<div title="ObjectCreation" modifier="Ichthyostega" modified="200711130113" created="200709030139" tags="impl design" changecount="17">
 <pre>We have to consider carefully how to handle the Creation of new class instances. Because, when done naively, it can defeat all efforts of separating subsystems, or &amp;mdash; the other extreme &amp;mdash; lead to a //switch-on-typeID//  programming style. We strive at a solution somewhere in the middle by utilizing __Abstract Factories__ on Interface or key abstraction classes, but providing specialized overloads for the different use cases. So in each use case we have to decide if we want to create a instance of some general concept (Interface), or if we have a direct collaboration and thus need the Factory to provide a more specific sub-Interface or even a concrete type.
 
 !Object creation use cases
 !![[Assets|Asset]]
 |!Action|&gt;|!creates |
 |loading a media file|asset::Media, asset::Codec| |
-|viewing media|asset::Clip| for the whole Media, if not already existent|
-|mark selection as clip|asset::Clip| doesn't add to EDL|
+|viewing media|asset::Clip, session::Clip and Placement (on hold)| for the whole Media, if not already existent|
+|mark selection as clip|asset::Clip, session::Clip, Placement with unspec. LocatingPin| doesn't add to EDL|
 |loading Plugin|asset::Effect| usually at program startup|
 |create Session|asset::Track, asset::OutPort| |
 &amp;rarr; [[Creating and registering Assets|AssetCreation]]
 
 !![[MObjects|MObject]]
-|add media to EDL|asset::Clip, session::Clip, FixedPlacement| creating whole-media clip on-the-fly |
-|add Clip|session::Clip, FixedPlacement| |
-|attach Effect|session::Effect, RelativePlacement| |
-|start using Automation|session::Auto, asset::Dataset, RelativePlacement| |
+|add media to EDL|asset::Clip, session::Clip, Placement with unspecified LocatingPin| creating whole-media clip on-the-fly |
+|add Clip to EDL|copy of Placement| creates intependent Placement of existing ~Clip-MO|
+|attach Effect|session::Effect, Placement with RelativeLocation| |
+|start using Automation|session::Auto, asset::Dataset, RelativeLocation Placement| |
 
 !Invariants
 when creating Objects, certain invariants have to be maintained. Because creating an Object can be considered an atomic operation and must not leave any related objects in an inconsistent state. Each of our interfaces implies some invariants: