WIP output mapping draft (#716)

src/proc/mobject/output-designation.hpp

@@ -0,0 +1,53 @@
+/*
+  OUTPUT-DESIGNATION.hpp  -  specifying a desired output destination
+ 
+  Copyright (C)         Lumiera.org
+    2010,               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 PROC_MOBJECT_OUTPUT_DESIGNATION_H
+#define PROC_MOBJECT_OUTPUT_DESIGNATION_H
+
+#include "proc/asset/pipe.hpp"
+
+
+namespace mobject {
+  
+  
+  
+  /**
+   * Descriptor to denote the desired target of produced media data.
+   * OutputDesignation is always an internal and relative specification
+   * and boils down to referring a asset::Pipe by ID. In order to get
+   * actually effective, some object within the model additionally
+   * needs to \em claim this pipe-ID, meaning that this object
+   * states to root and represent this pipe. When the builder
+   * encounters a pair of (OutputDesignation, OutputClaim),
+   * an actual stream connection will be wired in the
+   * processing node network.
+   */
+  class OutputDesignation
+    {
+    public:
+    };
+  
+  
+  
+} // namespace mobject
+#endif

src/proc/mobject/output-mapping.hpp

@@ -0,0 +1,53 @@
+/*
+  OUTPUT-MAPPING.hpp  -  generic interface for translation of output designations
+ 
+  Copyright (C)         Lumiera.org
+    2010,               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 PROC_MOBJECT_OUTPUT_MAPPING_H
+#define PROC_MOBJECT_OUTPUT_MAPPING_H
+
+#include "proc/mobject/output-designation.hpp"
+
+
+namespace mobject {
+  
+  
+  
+  /**
+   * OutputMapping is a facility to resolve output designations.
+   * For a given specification, resolution to the desired
+   * target specification may be derived. Here, the 
+   * type of the target specification is defined 
+   * through the type parameter.
+   * 
+   * This is an Interface, intended to be used in the signature
+   * of API functions either providing or requiring a Mapping.
+   */
+  template<class FUNC>
+  class OutputMapping
+    {
+    public:
+    };
+  
+  
+  
+} // namespace mobject
+#endif

src/proc/mobject/parameter.cpp

@@ -21,19 +21,20 @@
 * *****************************************************/
 
 
+#include "lib/error.hpp"
 #include "proc/mobject/parameter.hpp"
 #include "proc/mobject/paramprovider.hpp"
 
-namespace mobject
-  {
-
+namespace mobject {
+  
+  
   template<class VAL>
   VAL
   Parameter<VAL>::getValue ()
   {
-    ////////////TODO
+    UNIMPLEMENTED ("Any idea how to handle various kinds of parameter types");
   }
-
-
-
+  
+  
+  
 } // namespace mobject

src/proc/mobject/parameter.hpp

@@ -21,18 +21,17 @@
 */
 
 
-#ifndef MOBJECT_PARAMETER_H
-#define MOBJECT_PARAMETER_H
+#ifndef PROC_MOBJECT_PARAMETER_H
+#define PROC_MOBJECT_PARAMETER_H
 
 
 
 
-namespace mobject
-  {
-
+namespace mobject {
+  
   template<class VAL> class ParamProvider;
-
-
+  
+  
   /**
    * Descriptor and access object for a plugin parameter.
    * Parameters may be provided with values from the session,
@@ -43,13 +42,13 @@ namespace mobject
     {
     public:
       VAL getValue () ;
-
+      
     protected:
       ParamProvider<VAL>* provider;
-
+      
     };
-
-
-
+  
+  
+  
 } // namespace mobject
 #endif

wiki/renderengine.html

@@ -2964,6 +2964,31 @@ Any external output sink is managed as a [[slot|DisplayerSlot]] in the ~OutputMa
 → see also the PlayerDummy
 </pre>
 </div>
+<div title="OutputMapping" modifier="Ichthyostega" modified="201011080347" created="201011080238" tags="Model spec draft" changecount="11">
+<pre>An output mapping serves to //resolve//&amp;nbsp; [[output designations|OutputDesignation]].
+
+!Mapping situations
+;external outputs
+:external outputs aren't addressed directly. Rather we set up a default (channel) mapping, which then can be overridden by local rules.
+:Thus, in this case we query with an internal OutputDesignation as parameter and expect an OutputManager //slot//
+;viewer connections
+:any Timeline produces a number of [[model ports|ModelPort]]. On the other hand, any viewer exposes a small number of output designations, representing the image and sound output.
+:Thus, in this case we query //in reverse direction// &amp;mdash; given a viewer pipe we expect the model port (again denoted as ~Pipe-ID)
+;switch board
+:a viewer might receive multiple outputs and overlays, necessitating a user operated control to select what's actually to displayed
+:Thus, in this case we similarly need a backwards resolution, linking together parts of the output network with some model ports
+;virtual media
+:when binding a Sequence as VirtualClip, a mapping from output designations used within the Sequence to virtual channels is required
+:Thus, in this case we need to associate output designations with ~Pipe-IDs encountered in the context 
+
+!Questions {{red{WIP 11/10}}}
+* shall we rely on ~Pipe-IDs as an uniform designator for various kinds of //further connection?//
+* and then &amp;mdash; wouldn't that immediately necessitate yet another mapping?
+* can output mapping be considered a //substantial concept// &amp;mdash; or is it rather void of specific meaning?
+* are output mappings to be extended? do they include an automatic resolution step in case of non existant mapping?
+* for any given situation, is there just //one mapping// &amp;mdash; or can there be multiple mappings, to be handled like values?
+</pre>
+</div>
 <div title="Overview" modifier="Ichthyostega" modified="200906071810" created="200706190300" tags="overview img" changecount="13">
 <pre>The Lumiera Processing Layer is comprised of various subsystems and can be separated into a low-level and a high-level part. At the low-level end is the [[Render Engine|OverviewRenderEngine]] which basically is a network of render nodes cooperating closely with the Backend Layer in order to carry out the actual playback and media transforming calculations. Whereas on the high-level side we find several different [[Media Objects|MObjects]] that can be placed into the session, edited and manipulated. This is complemented by the [[Asset Management|Asset]], which is the &quot;bookkeeping view&quot; of all the different &quot;things&quot; within each [[Session|SessionOverview]].
 
@@ -6625,7 +6650,7 @@ In case it's not already clear: we don't have &quot;the&quot; Render Engine, rat
 The &amp;raquo;current setup&amp;laquo; of the objects in the session is sort of a global state. Same holds true for the Controller, as the Engine can be at playback, it can run a background render or scrub single frames. But the whole complicated subsystem of the Builder and one given Render Engine configuration can be made ''stateless''. As a benefit of this we can run this subsystems multi-threaded without the need of any precautions (locking, synchronizing). Because all state information is just passed in as function parameters and lives in local variables on the stack, or is contained in the StateProxy which represents the given render //process// and is passed down as function parameter as well. (note: I use the term &quot;stateless&quot; in the usual, slightly relaxed manner; of course there are some configuration values contained in instance variables of the objects carrying out the calculations, but this values are considered to be constant over the course of the object usage).
 </pre>
 </div>
-<div title="Wiring" modifier="Ichthyostega" modified="201011072303" created="201009250223" tags="Concepts Model design draft" changecount="27">
+<div title="Wiring" modifier="Ichthyostega" modified="201011080237" created="201009250223" tags="Concepts Model design draft" changecount="28">
 <pre>within Lumiera's ~Proc-Layer, on the conceptual level there are two kinds of connections: data streams and control connections. The wiring details on how these connections are defined and controlled, how they are to be detected by the builder and finally implemented by links in the render engine.
 &amp;rarr; see OutputManagement
 &amp;rarr; see OutputDesignation
@@ -6639,7 +6664,7 @@ A stream connection should result in media data traveling from a source to a sin
 * there are flexible interconnections or ''routing links'', including the ability to sum or overlay media streams, and the possibility of stream type conversions. They are controlled by the OutputDesignation (&quot;wiring plug&quot;), to be queried from the placement at the source side of the interconnection (i.e. at the exit point of a pipe)
 Please note, the high-level model comprises a blue print for constructing the render engine. There is no data &quot;flowing&quot; through this model, thus any &quot;wiring&quot; may be considered conceptual. Any wiring specifications here just express the intention of getting things connected in a given way. Like e.g. a clip may find out (through query of his placement) that he's intended to produce output for some destination / bus / subgroup called &quot;XYZ&quot;
 
-The builder to the contrary considers matters locally. He's confined to a given set of objects handed in for processing, and during that processing will collect all [[plugs|WiringPlug]] and [[claims|WiringClaim]] encountered. While the former denote the desired //destination//&amp;nbsp; of data emerging from a pipe, the wiring claim expresses the fact that a given object //claims to be some output destination.// Typically, each [[global pipe or bus|GlobalPipe]] raises such a claim. Both plugs and claims are processed on a &quot;just in case they exist&quot; base: When encountering a plug and //resolving//&amp;nbsp; the corresponding claim, the builder drops off a WiringRequest accordingly. Note the additional resolution, which might be necessary due to virtual media and nested sequences (read: the output designation might need to be translated into another designation, using the media/channel mapping created by the virtual entity &amp;rarr; see [[mapping of output designations|OutputDesignation]])
+The builder to the contrary considers matters locally. He's confined to a given set of objects handed in for processing, and during that processing will collect all [[plugs|WiringPlug]] and [[claims|WiringClaim]] encountered. While the former denote the desired //destination//&amp;nbsp; of data emerging from a pipe, the wiring claim expresses the fact that a given object //claims to be some output destination.// Typically, each [[global pipe or bus|GlobalPipe]] raises such a claim. Both plugs and claims are processed on a &quot;just in case they exist&quot; base: When encountering a plug and //resolving//&amp;nbsp; the corresponding claim, the builder drops off a WiringRequest accordingly. Note the additional resolution, which might be necessary due to virtual media and nested sequences (read: the output designation might need to be translated into another designation, using the media/channel mapping created by the virtual entity &amp;rarr; see [[mapping of output designations|OutputMapping]])
 
 Processing the wiring request drives the actual connection step. It is conducted by the OperationPoint, provided by and executing within a BuilderMould and controlled by a [[processing pattern|ProcPatt]]. This rather flexible setup allows for wiring summation lines, include faders, scale and offset changes and various overlay modes. Thus the specific form of the connection wired in here depends on all the local circumstances visible at that point of operation:
 * the mould is picked from a small number of alternatives, based on the general wiring situation.
@@ -6655,7 +6680,7 @@ On a more global level, this LowLevelModel within the engine exposes a number of
 * output designation is just a ~Pipe-ID, actually a thin wrapper to make the intention explicit
 * claims and plugs are to be implemented as LocatingPin
 * as decided elsewhere, we get a [[Bus-MObject|BusMO]] as an attachment point
-* we need [[Mapping]] as a new generic interface, allowing us to define ~APIs in terms of mappings
+* we need OutputMapping as a new generic interface, allowing us to define ~APIs in terms of mappings
 * builder moulds, operation point and processing patterns basically are in place, but need to be shaped
 * the actual implementation in the engine will evolve as we go; necessary adaptations are limited to the processing patterns (which is intentional)