WIP: link between asset::Proc and the Build process, allowing to resolve the processing function

src/proc/asset/effect.hpp

@@ -36,7 +36,21 @@ namespace asset
    */
   class Effect : public Proc
     {
+    
+    public:
+      /** resolve any plugin and configuration info
+       *  to yield the actual media data processing function.
+       *  @return a function ready to be invoked; either the 
+       *          "real thing" or a suitable placeholder.
+       *  @throw lumiera::error::Fatal if unable to provide
+       *         any usable function or placeholder. This case
+       *         can be considered exceptional and justifies a
+       *         subsystem failure.
+       */
+      ProcFunc*
+      resolveProcessor();
       
+
     };
     
     

src/proc/asset/proc.hpp

@@ -39,6 +39,7 @@
 
 #include "proc/asset.hpp"
 #include "lib/factory.hpp"
+#include "lib/streamtype.hpp"
 
 
 
@@ -76,6 +77,11 @@ namespace asset {
           return static_cast<const ID<Proc>& > (Asset::getID()); 
         }
       
+      typedef lumiera::StreamType::ImplFacade::DataBuffer Buff;
+      typedef Buff* PBuff;
+      typedef void (ProcFunc) (PBuff);
+      
+      
     protected:
       Proc (const Asset::Ident& idi) : Asset(idi) {}  //////////////TODO
       friend class ProcFactory;

src/proc/engine/procnode.hpp

@@ -44,6 +44,7 @@
 
 #include "proc/common.hpp"
 #include "proc/state.hpp"
+#include "proc/asset/proc.hpp"
 #include "proc/mobject/parameter.hpp"
 #include "lib/frameid.hpp"
 #include "lib/refarray.hpp"
@@ -75,7 +76,7 @@ namespace engine {
       lib::RefArray<ChannelDescriptor>& out;
       lib::RefArray<InChanDescriptor>&  in;
       
-      typedef void (ProcFunc) (BuffHandle::PBuff);
+      typedef asset::Proc::ProcFunc ProcFunc;
       
       ProcFunc* procFunction;
       

src/proc/mobject/session/effect.hpp

@@ -24,9 +24,11 @@
 #ifndef MOBJECT_SESSION_EFFECT_H
 #define MOBJECT_SESSION_EFFECT_H
 
-#include <string>
 
 #include "proc/mobject/session/abstractmo.hpp"
+#include "proc/asset/effect.hpp"
+
+#include <string>
 
 
 using std::string;
@@ -42,6 +44,8 @@ namespace session {
       /** Identifier of the Plug-in to be used */
       string pluginID;
       
+    public:
+      
     };
   
   

wiki/renderengine.html

@@ -2227,8 +2227,18 @@ 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="NodeCreatorTool" modifier="Ichthyostega" modified="200810170222" created="200712100626" tags="def" changecount="2">
-<pre>~NodeCreatorTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the NodeCreaterTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the NodeCreaterTool creates and wires the necessary [[nodes|ProcNode]]</pre>
+<div title="NodeConfiguration" modifier="Ichthyostega" modified="200909041807" created="200909041806" tags="spec Builder Rendering" changecount="2">
+<pre>Various aspects of the individual [[render node|ProcNode]] are subject to configuration and may influence the output quality or the behaviour of the render process.
+* the selection //what// actual implementation (plugin) to used for a formally defined &amp;raquo;[[Effect|EffectHandling]]&amp;laquo;
+* the intermediary/common StreamType to use within a [[Pipe]]
+* the render technology (CPU, hardware accelerated {{red{&amp;rarr; Future}}})
+* the ScheduleStrategy (possibly subdividing the calculation of a single frame)
+* if this node becomes a possible CachePoint or DataMigrationPoint in RenderFarm mode
+* details of picking a suitable [[operation mode|RenderImplDetails]] of the node (e.g. utilitsing &quot;in-place&quot; calculation)
+</pre>
+</div>
+<div title="NodeCreatorTool" modifier="Ichthyostega" modified="200909041744" created="200712100626" tags="def" changecount="3">
+<pre>~NodeCreatorTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the ~NodeCreatorTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the NodeCreaterTool creates and wires the necessary [[nodes|ProcNode]]</pre>
 </div>
 <div title="NodeFrameNumbering" modifier="Ichthyostega" modified="200810160129" created="200810140254" tags="spec draft" changecount="3">
 <pre>!Problem of Frame identification
@@ -2298,12 +2308,12 @@ But because I know the opinions on this topc are varying (users tend to be delig
 My proposed aproach is to treat OpenGL as a separate video raw data type, requiring separete and specialized [[Processing Nodes|ProcNode]] for all calculations. Thus the Builder could connect OpenGL nodes if it is possible to cover the whole render path for preview and fall back to the normal ~ProcNodes for all relevant renders
 </pre>
 </div>
-<div title="OperationPoint" modifier="Ichthyostega" modified="200908291632" created="200805270334" tags="def impl Builder" changecount="7">
+<div title="OperationPoint" modifier="Ichthyostega" modified="200909041742" created="200805270334" tags="def impl Builder" changecount="8">
 <pre>A low-level abstraction within the [[Builder]] &amp;mdash; it serves to encapsulate the details of making multi-channel connections between the render nodes: In some cases, a node can handle N channels internally, while in other cases we need to replicate the node N times and wire each channel individually. As it stands, the OperationPoint marks the ''borderline between high-level and low-level model'': it is invoked in terms of ~MObjects and other entities of the high-level view, but internally it manages to create ProcNode and similar entities of the low-level model.
 
 The operation point is provided by the current BuilderMould and used by the [[processing pattern|ProcPatt]] executing within this mould and conducting the current build step. The operation point's interface allows //to abstract//&amp;nbsp; these details, as well as to //gain additional control//&amp;nbsp; if necessary (e.g. addressing only one of the channels). The most prominent build instruction used within the processing patterns (which is the instruction {{{&quot;attach&quot;}}}) relies on the aforementioned //approach of abstracted handling,// letting the operation point determine automatically how to make the connection.
 
-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 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.
+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 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="Overview" modifier="Ichthyostega" modified="200906071810" created="200706190300" tags="overview img" changecount="13">
@@ -2879,6 +2889,9 @@ DAMAGE.
 &lt;html&gt;&lt;sub&gt;&lt;a href=&quot;javascript:;&quot; onclick=&quot;scrollAnchorVisible('Top',null, event)&quot;&gt;[Top]&lt;/sub&gt;&lt;/a&gt;&lt;/html&gt;
 ***/</pre>
 </div>
+<div title="PathManager" modifier="Ichthyostega" created="200909041748" tags="def Builder" changecount="1">
+<pre>Facility guiding decisions regarding the strategy to employ for rendering or wiring up connections. The PathManager is querried through the OperationPoint, when executing the connection steps within the Build process.</pre>
+</div>
 <div title="Pipe" modifier="Ichthyostega" modified="200804110301" created="200801062110" tags="def decision" changecount="6">
 <pre>Pipes play an central role within the Proc Layer, because for everything placed and handled within the EDL, the final goal is to get it transformed into data which can be retrieved at some pipe's exit port. Pipes are special facilities, rather like inventory, separate and not treated like all the other objects.
 We don't distinguish between &quot;input&quot; and &quot;output&quot; ports &amp;mdash; rather, pipes are thought to be ''hooks for making connections to''. By following this line of thought, each pipe has an input side and an output side and is in itself something like a ''Bus'' or ''processing chain''. Other processing entities like effects and transitions can be placed (attached) at the pipe, resulting them to be appended to form this chain. Likewise, we can place [[wiring requests|WiringRequest]] to the pipe, meaning we want it connected so to send it's output to another destination pipe. The [[Builder]] may generate further wiring requests to fulfil the placement of other entities.