define details of binding and mapping

wiki/renderengine.html

@@ -1000,49 +1000,40 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 }
 //}}}</pre>
 </div>
-<div title="BindingMO" modifier="Ichthyostega" modified="201007110149" created="200905210144" tags="def design discuss SessionLogic" changecount="17">
-<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.
-* When connecting a [[Sequence]] to a certain [[Timeline]], we also establish 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.
+<div title="BindingMO" modifier="Ichthyostega" modified="201011170334" created="200905210144" tags="def design discuss SessionLogic" changecount="22">
+<pre>Binding-~MObjects are used to associate two entities within the high-level model.
+More specifically, such a binding serves 
+* to outfit any top-level [[Timeline]] with real content, which is contained within a [[Sequence]]
+* to build a VirtualClip, that is to link a complete sequence into another sequence, where it appears like a new virtual media or clip.
 
 !Properties of a Binding
-Binding is a relation entity, maintaining a link between parts of the session. This 1:1 relation may be part of a n:1 (or maybe even n:m?) relation. In addition to representing this link, a binding allows to maintain a set of ''mappings'' attached to this link.
-
-This creates a typing related problem: In order to maintain the link and the mappings, in each case we need a common denominator to subsume the elements to be maintained.
-* in the case of the basic link, this common denominator is given by the basic structure of the HighLevelModel: ~MObjects attached by Placements. Consequently, the link maintained through a binding is limited to linking together first-class entities within the model, and the implementation is tied into the existing mechanisms for associating Placements (&amp;rarr; PlacementScope and PlacementIndex)
-* in the case of the attached mappings it seems we're best off limiting ourselves to symbolic mappings (ID mappings). Because, going beyond that would either create sub-groupings (based on varying target types to be mapped), or push the »everything is an object« approach beyond the beneficial level.
-
-!Critique {{red{WIP 12/09}}}
-Now I'm in doubt if there is any point in treating the &quot;binding&quot; in a abstract fashion. Is there any common denominator? It seems there is just a common conceptional pattern, but mapping this pattern onto distinct types (classes) seems unnecessary. Rather, we have three very similar kinds of ~MObjects:
-* ModelRootMO
-* BindingMO
-* [[Track]]
-While each of these actually represents a high-level concept (the session, the timeline(s) the sequence(s)) and moreover links to other parts and provides mappings, it seems there is no re-usable similarity at the code level.
-//According to this reasoning, I should proceed rather with these three distinct entities and postpone any search for similarities to a later refactoring round.//
+Binding is a relation entity, maintaining a link between parts of the session. Actually this link is achieved somewhat indirect: The binding itself is an MObject, but it points to a [[sequence asset|Sequence]]. Moreover, in case of the (top-level) timelines, there is a timeline asset acting frontend for the ~BindingMO. 
+* the binding exposes special functions needed to implement the timeline {{red{planned as of 11/10}}}
+* similarily, the binding exposes functions allowing to stand-in for a regular clip (when acting as VirtualClip).
+* the Bining holds an OutputMapping &amp;mdash; allowing to specify, resolve and remember [[output designations|OutputDesignation]]
 
+Note: there are other binding-like entities within the model, which are deliberately not subsumed below this specification, but rather implemented stand alone.
 &amp;rarr; see also SessionInterface
 
-!Problems and Questions {{red{WIP 3/10}}}
-Meanwhile I've settled down on implementing the [[top-level entities|Timeline]] as façade assets, backed by a {{{Placement&lt;Binding&gt;}}}. But the addressing and mapping of media channels still remains unsettled. Moreover, what happens when binding the sequence into a VirtualClip?
-* because a Binding was assumed to link two entities, I concluded that the binding is dependent on those entities
-* but then the two cases don't match:
-** Timeline is an asset, not an MObject. Having a Timeline MObject would clearly be redundant. But then, consequently, //binding has to provide the global pipes,// because we need the possibility to attach effects to them (by placing the effects into the binding's scope)
-** to the contrary, a VirtualClip requires somehow a ClipMO, which then in turn would need a channel configuration
-*** so either, we could rework the clip asset into such a channel configuration (it looks pretty much redundant otherwise)
-*** or the binding could take on the role of the channel configuration (which would be more in-line with the first case)
-** unfortunately, both solutions bring the binding rather on the level of an asset (a media or channel configuration).
-* //multiplicity// is yet another open question:
-** can multiple placements refer to the same binding?
-** what would be the semantics or such an arrangement?
-** if we decide against it, what happens if we nevertheless encounter this situation?
 
-&amp;harr; related to the handling of MultichannelMedia, which likewhise needs to be re-adjusted meanwhile!
-
-&amp;rArr; {{red{rework of the model 6/10}}} taking these problems into account. Mostly cleanup and straightening. See AssetModelConnection
 
 !Implementation
 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)
+
+Binding can be considered an implementation object, rarely to be created direcly. Yet it is part of the high-level model
+{{red{WIP 11/10}}}: it is likely that BindingMO becomes a subclass (mix-in) of {{{mobject::session::Clip}}}
+
+!!!channel / output mapping
+The Binding-~MObject stores an OutputMapping. Basically this, together with OutputDesignation, implements the mapping behaviour
+* after a build process, all unresolved connection requests are announced to the next enclosing binding {{red{TODO: just an idea as of 11/10}}}
+* a relative output designation (the N^^th^^ channel of this kind) is just carried over to the target binding.
+* a direct output designation gets connected to a global pipe in the binding.
+* when the binding is used to implement a virtual clip, then after resolving all connection requests...
+** a relative output designation (the N^^th^^ channel of this kind) is just carried over to the target scope and re-resolved there.
+** a direct output designation specicfiation yields a summation pipe at the binding, i.e. a position corresponding to the global pipes when using the same sequence as timeline.
+** The output of this summation pipe is treated like a media channel
+*** now, if a distinct output designation can be determined at this placement of the virtual clip, it will be used for the further routing
+*** otherwise, we try to //carry over//&amp;nbsp; the original output designation (which has led to the summation bus on the binding for the meta-clip). Thus, routing will be done as if the original output designation was given at this placement of the virtual clip.
 </pre>
 </div>
 <div title="BindingScopeProblem" modifier="Ichthyostega" modified="201010021417" created="200910181435" tags="SessionLogic spec" changecount="20">
@@ -2894,7 +2885,7 @@ The operation point is provided by the current BuilderMould and used by the [[pr
 This is possible because the operation point has been provided (by the mould) with informations about the media stream type to be wired, which, together with information accessible at the [[render node interface|ProcNode]] and from the [[referred processing assets|ProcAsset]], with the help of the [[connection manager|ConManager]] allows to figure out what's possible and how to do the desired connections. Additionally, in the course of deciding about possible connections, the PathManager is consulted to guide strategic decisions regarding the [[render node configuration|NodeConfiguration]], possible type conversions and the rendering technology to employ.
 </pre>
 </div>
-<div title="OutputDesignation" modifier="Ichthyostega" modified="201009242320" created="201006220126" tags="Model draft design discuss" changecount="42">
+<div title="OutputDesignation" modifier="Ichthyostega" modified="201011132128" created="201006220126" tags="Model draft design discuss" changecount="44">
 <pre>__6/2010__: an ever recurring (and yet unsolved) problem in the design of Luimiera's ~Proc-Layer is how to refer to output destinations, and how to organise them.
 To get ahead with this problem, I'll start collecting observations, relations and drafts on this tiddler.
 
@@ -2932,11 +2923,12 @@ The immediate consequence is that a [[Pipe]] with the given ID exists as an acco
 &amp;rarr; OutputManagement
 
 !Mapping of output designations
-An entire sequence can be embedded within another sequence as a VirtualClip. While for a simple clip there is a Clip-~MObject placed into the model, holding an reference to a media asset, in case of a virtual clip an BindingMO takes on the role of the clip object. Note that BindingMO also acts as [[Timeline]] implementation &amp;mdash; indeed the same sequence might be bound simultaneously as a timeline and into a virtual clip. This flexibility creates a special twist, as the contents of this sequence have no way of finding out if they're used as timeline or embedded virtual clip. So parts of this sequence might mention a OutputDesignation which, when using the sequence as virtual clip, needs to be translated into a virtual media channel, which can be treated in the same fashion as any channel (video, audio,...) found within real media. Especially, a new output designation has to be derived in a sensible way, which largely depends on how the original output designation has been specified
-* a direct output designation specicfiation from within the sequence is captured and translated into a summation pipe at a position corresponding to the global pipes when using the same sequence as timeline. The output of this summation pipe is treated like a media channel
-** now, if a distinct output designation can be determined at this placement of the virtual clip, it will be used for the further routing
-** otherwise, the routing will be done as if the original output designation was given at this placement of the virtual clip.
-* a relative output designation (the N^^th^^ channel of this kind) is just carried over to the enclosing scope.
+An entire sequence can be embedded within another sequence as a VirtualClip. While for a simple clip there is a Clip-~MObject placed into the model, holding an reference to a media asset, in case of a virtual clip an BindingMO takes on the role of the clip object. Note that BindingMO also acts as [[Timeline]] implementation &amp;mdash; indeed the same sequence might be bound simultaneously as a timeline and into a virtual clip. This flexibility creates a special twist, as the contents of this sequence have no way of finding out if they're used as timeline or embedded virtual clip. So parts of this sequence might mention a OutputDesignation which, when using the sequence as virtual clip, needs to be translated into a virtual media channel, which can be treated in the same fashion as any channel (video, audio,...) found within real media. Especially, a new output designation has to be derived in a sensible way, which largely depends on how the original output designation has been specified.
+&amp;rarr; see OutputMapping regarding details and implementation of this mapping mechanism
+
+!Output designation definition
+OutputDesignation is a handle, denoting a target [[Pipe]] to connect.
+It exposes a function to resolve to a Pipe, and to retrieve the StreamType of that resolved output. It can be ''defined'' either explicitly by ~Pipe-ID, or by an indirect or relative specification. The later cases are resolved on demand only (which may be later and might change the meaning depending on the context). It's done this way intentionally to gain flexibility and avoid hard wiring (=explicit ~Pipe-ID)
 
 !Using output designations
 While actually data frames are //pulled,// on a conceptual level data is assumed to &quot;flow&quot; through the pipes from source to output. This conceptual (&quot;high level&quot;) model of data flow is comprised of the pipes (which are rather rigid), and flexible interconnections. The purpose of an output designation is to specify where the data should go, especially through these flexible interconnections. Thus, when reaching the exit point of a pipe, an output designation will be //queried.// Finding a suitable output designation involves two parts: