add new kind of MObject (Binding) to express special scopes

src/proc/Makefile.am

@@ -145,6 +145,7 @@ liblumiprocmobjectsession_la_SOURCES =					\
 	$(liblumiprocmobjectsession_la_srcdir)/abstractmo.cpp		\
 	$(liblumiprocmobjectsession_la_srcdir)/allocation.cpp		\
 	$(liblumiprocmobjectsession_la_srcdir)/auto.cpp			\
+	$(liblumiprocmobjectsession_la_srcdir)/bindingl.cpp		\
 	$(liblumiprocmobjectsession_la_srcdir)/clip.cpp			\
 	$(liblumiprocmobjectsession_la_srcdir)/compoundclip.cpp		\
 	$(liblumiprocmobjectsession_la_srcdir)/constraint.cpp		\

src/proc/mobject/placement-index.cpp

@@ -60,12 +60,28 @@ namespace mobject {
   /** */
   
   
+  PlacementIndex::PlacementMO&
+  PlacementIndex::getRoot()  const
+  {
+    UNIMPLEMENTED ("managing the implicit root context within a scope hierarchy");
+  }
+  
+  
   size_t
   PlacementIndex::size()  const
   {
     return pTab_->size() - 1;
   }
-
+  
+  
+  bool
+  PlacementIndex::contains (PlacementMO&)  const
+  {
+    UNIMPLEMENTED ("containment test: is the given Placement known within this index");
+    return false;
+  }
+  
+  
   
   
   /** @internal factory function for creating a placement index for tests.

src/proc/mobject/placement.hpp

@@ -110,7 +110,7 @@ namespace mobject {
       
       
       /** interface for defining the kind of placement
-       *  to employ, and for controling any additional
+       *  to employ, and for controlling any additional
        *  constraints and properties. 
        */
       session::LocatingPin chain;

src/proc/mobject/session/binding.cpp

@@ -0,0 +1,33 @@
+/*
+  Binding  -  an association between session entities, constituting a scope
+ 
+  Copyright (C)         Lumiera.org
+    2009,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  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/session/binding.hpp"
+
+namespace mobject {
+namespace session {
+  
+  /** */
+  
+
+
+}} // namespace mobject::session

src/proc/mobject/session/binding.hpp

@@ -0,0 +1,52 @@
+/*
+  BINDING.hpp  -  an association between session entities, constituting a scope
+ 
+  Copyright (C)         Lumiera.org
+    2009,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  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.
+ 
+*/
+
+
+#ifndef MOBJECT_SESSION_BINDING_H
+#define MOBJECT_SESSION_BINDING_H
+
+#include "proc/mobject/session/meta.hpp"
+
+
+
+namespace mobject {
+namespace session {
+  
+  
+  /**
+   * Association of two entities within the Session
+   * deliberately linked together, thereby carrying additional mappings
+   * between properties or facilities within the entities to be linked together.
+   * An example would be the situation when a Sequence is linked either into
+   * a Timeline or MetaClip. Usually, the Placement holding such a Binding
+   * also constitutes a scope containing other nested objects.
+   */
+  class Binding : public Meta
+    {
+    public:
+      
+    };
+
+
+
+}} // namespace mobject::session
+#endif

src/proc/mobject/session/clip.hpp

@@ -47,7 +47,7 @@ namespace mobject
      * sequence of media data loaded as Asset into the current Session.
      * As such, it is a virtual (non destructive) cut or edit of the 
      * source material and can be placed into the EDL to be rendered
-     * into the ouput. The actual media type of a clip will be derived
+     * into the output. The actual media type of a clip will be derived
      * at runtime by resolving this reference to the underlying Asset.
      * 
      * @todo define how to denote Time positions /lengths. This is tricky,

tests/components/proc/mobject/placement-index-test.cpp

@@ -75,19 +75,19 @@ namespace test    {
       checkSimpleInsert (PIdx index)
         {
           PMO clip = TestClip::create();
-//        PMO& root = index->getRoot();
+          PMO& root = index->getRoot();
           
           ASSERT (0 == index->size());
-//        ASSERT (!index->contains (clip));
+          ASSERT (!index->contains (clip));
           
 //        index->insert (clip, root);
           ASSERT (1 == index->size());
-//        ASSERT ( index->contains (clip));
+          ASSERT ( index->contains (clip));
           
 //        index->remove(clip);
           ASSERT (0 == index->size());
-//        ASSERT (!index->contains (clip));
-//        ASSERT ( index->contains (root));
+          ASSERT (!index->contains (clip));
+          ASSERT ( index->contains (root));
         }
     };
   

wiki/renderengine.html

@@ -758,6 +758,15 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 }
 //}}}</pre>
 </div>
+<div title="BindingMO" modifier="Ichthyostega" modified="200905210149" created="200905210144" tags="def design discuss SessionLogic" changecount="2">
+<pre>Sometimes, two entities within the [[Session]] are deliberately associated, and this association has to carry some specific mappings between properties or facilities within the entities to be linked together. When this connection isn't just the [[Placement]] of an object, and isn't just a logical or structural relationship either &amp;mdash; then we create an explicit Binding object to be stored into the session.
+* Connecting a [[Sequence|EDL]] gets connected to a certain [[Timeline]] also establishes a mapping between the possible media stream channels produced by the sequence and the real output slots found within the timeline.
+* similarly, using a sequence within a [[meta-clip|VirtualClip]] requires to remember such a mapping.
+* another example is the root [[scope|PlacementScope]], which (conceptually) is a link between the definition part of the Session and the graph of MObjects, which are the session's contents.
+
+On the implementation side, we use a special kind of MObject, acting as an anchor and providing an unique identity. Like any ~MObject, actually a placement establishes the connection and the scope, and typically constitutes a nested scope (e.g. the scope of all objects //within// the sequence to be bound into a timeline)
+</pre>
+</div>
 <div title="BuildProcess" modifier="Ichthyostega" modified="200805300042" created="200706190658" tags="dynamic Builder" changecount="29">
 <pre>All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actual performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &amp;mdash; to pay in the Builder &amp;mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
 
@@ -2801,7 +2810,7 @@ Placements have //value semantics,// i.e. we don't stress the identity of a plac
 
 </pre>
 </div>
-<div title="PlacementIndex" modifier="Ichthyostega" modified="200905120331" created="200905090053" tags="SessionLogic spec impl draft" changecount="8">
+<div title="PlacementIndex" modifier="Ichthyostega" modified="200905192358" created="200905090053" tags="SessionLogic spec impl draft" changecount="10">
 <pre>An implementation facility used to keep track of individual Placements and their relations.
 Especially, the [[Session]] maintains such an index, allowing to use the (opaque) PlacementRef tags for referring to a specific &quot;instance&quot; of an MObject, //placed// in a unique way into the current session. And, moreover, this index allows for one placement referring to another placement, so to implement a //relative// placement mode. Because there is an index behind the scenes, it is possible to actually access such a referral in the reverse direction, which is necessary for implementing the desired placement behaviour (if an object instance used as anchor is moved, all objects placed relatively to it have to move accordingly, which necessiates finding those other objects).
 
@@ -2809,11 +2818,11 @@ Especially, the [[Session]] maintains such an index, allowing to use the (opaque
 What implementation approach to take for the index. This of course largely depends on the usage pattern, which in turn is not-yet existant. To start with, we need a preliminary implementation!
 
 Using a ''flat hashtable'' would allow to access a Placement denoted by ID in O(1). This way we could get the Placement, but nothing more. So, additionally we'd have to set up an data record holding additional information:
-* the scope containing this placement
+* the [[scope|PlacementScope]] containing this placement
 * especially the path &quot;up&quot; from this scope, which is used for resolving any queries
 * relations to other placements
 
-Alternatively, we could try to use a ''structure based index''. Following this idea, we could try to avoid the mntioned description record by folding any of the contained informations into the surrounding datastructure:
+Alternatively, we could try to use a ''structure based index''. Following this idea, we could try to avoid the mentioned description record by folding any of the contained informations into the surrounding datastructure:
 * the scope would be obvious from the index, resp. from the path used to resolve this index
 * any other informations, especially the relations, would be folded into the placement
 * this way, the &quot;index&quot; could be reduced to being the session datastructure itself.
@@ -2833,24 +2842,24 @@ The placement index is utilized by editing operations, by executing the build pr
 On second sight, this problem seems to be quite nasty, because either we have to keep a second indext table for the reversed lookup (memory address -&gt; ID), or have to tie the placement by a backlink when adding it to the index/session datastructure, or (at least) it forces us to store a copy of the ID //within// the placement itself. The last possibility seems to create the least impact; but implementing it this way effectively gears the implementation towards a hashtable based approach.
 </pre>
 </div>
-<div title="PlacementRef" modifier="Ichthyostega" modified="200905091516" created="200905090032" tags="def spec draft" changecount="2">
+<div title="PlacementRef" modifier="Ichthyostega" modified="200905192350" created="200905090032" tags="def spec draft" changecount="3">
 <pre>A generic reference mechanism for Placements, as added to the current session.
 While this reference itself is not tied to the actual memory layout (meaning it's //not// a disguised pointer), the implementation relies on a [[placement index facility|PlacementIndex]] for tracking and retrieving the actual Placement implementation object.
 
 !questions {{red{WIP}}}
-Currently (5/09) ichthyo is in doubt what implementation to use best. It is clear that the PlacementRef needs to incorporate as the only actual data in memory, so it can be downcasted to a POD and passed as such via LayerSeparationInterfaces. And, of course, this ID tag should be the one used by PlacementIndex for organising the Placement index entries, thus enabling the PlacementRef to be passed immediately to the underlying index for resolution. Thus, the design decision boils down to the question how to implement the ID tag.
+Currently (5/09) ichthyo is in doubt what implementation to use best. It is clear that the PlacementRef needs to incorporate a simple ID as the only actual data in memory, so it can be downcasted to a POD and passed as such via LayerSeparationInterfaces. And, of course, this ID tag should be the one used by PlacementIndex for organising the Placement index entries, thus enabling the PlacementRef to be passed immediately to the underlying index for resolution. Thus, the design decision boils down to the question how to implement the ID tag.
 * a flat random hash, e.g. using a {{{LUID}}}?
 * a structure based index, which also denotes the position in the (tree like) datastructure (Sequences within the session)?
 </pre>
 </div>
-<div title="PlacementScope" modifier="Ichthyostega" modified="200905120348" created="200905120304" tags="SessionLogic spec draft" changecount="4">
+<div title="PlacementScope" modifier="Ichthyostega" modified="200905210132" created="200905120304" tags="SessionLogic spec draft" changecount="5">
 <pre>MObjects are attached into the [[Session]] by adding a [[Placement]]. Because this especially includes the case of //grouping or container objects,// e.g. tracks or [[meta-clips|VirtualClip]], any placement may optionally define and root a scope, and every placement is at least contained in one encompassing scope &amp;mdash; of course with the exception of the absolute top level, which can be thought off as being contained in a scope of handling rules.
 
 Thus, while the [[sequences (former called EDL)|EDL]] act as generic container holding a pile of placments, actually there is a more fine grained structure based on the nesting of the tracks, which especially in Lumiera's HighLevelModel belong to the sequence (they aren't a property of the top level timeline as one might expect). Building upon these observations, we actually require each addition of a placement to specify a scope. The implementation of this tie-to-scope is provided by the same mechanism as utilized for relative placements, i.e. an directional placement relation.
 
 !Kinds of scopes
 There is only a limited number of situations constituting a scope
-* conceptually, the very top level is a scope of general rules (but it is hard-wired, not implemented as placement) {{red{really?}}}
+* conceptually, the very top level is a scope of general rules. It is implemented as {{{Placement&lt;Binding&gt;}}}, where [[the binding|BindingMO]] is a meta-object representing the relation.
 * similarily, the link binding a [[Sequence|EDL]] into either a (top-level) timeline or as virtual media into a VirtualClip is rather special.
 * each sequence has at least one (manadtory) top-level placement holding its root track
 * tracks may contain nested sub tracks.