diff --git a/doc/devel/uml/class128261.html b/doc/devel/uml/class128261.html index 8a3d60f2c..57cb19580 100644 --- a/doc/devel/uml/class128261.html +++ b/doc/devel/uml/class128261.html @@ -19,7 +19,7 @@

Declaration :

Relation tracks (<directional aggregation by value>)

Declaration :

-
Relation timeline (<directional aggregation by value>)

Declaration :

+
Relation timeline (<directional aggregation by value>)

Declaration :

Operation getPlaylistForRender

Declaration :

Operation getAutomation

Declaration :

All public operations : getAutomation , getPlaylistForRender

diff --git a/doc/devel/uml/class128645.html b/doc/devel/uml/class128645.html index d3b580350..975e79097 100644 --- a/doc/devel/uml/class128645.html +++ b/doc/devel/uml/class128645.html @@ -16,11 +16,11 @@ -

Declaration :

Directly inherited by : Allocation DirectPlacement ExplicitePlacement RelativePlacement

+

Declaration :

Directly inherited by : Allocation DirectPlacement ExplicitPlacement RelativePlacement

Relation subject (<association>)

Declaration :

-
Operation resolve

Declaration :

create an actual (explicite) placement while trying to satisfy the network of adjacent objects and placements.

+
Operation resolve

Declaration :

create an actual (explicite) placement while trying to satisfy the network of adjacent objects and placements.

All public operations : resolve

diff --git a/doc/devel/uml/class129285.html b/doc/devel/uml/class129285.html index c4ee91833..a4f213f9c 100644 --- a/doc/devel/uml/class129285.html +++ b/doc/devel/uml/class129285.html @@ -16,7 +16,7 @@ -

Declaration :

+

Declaration :

All public operations : resolve

diff --git a/doc/devel/uml/class129797.html b/doc/devel/uml/class129797.html index f863d3689..d0cefbcfe 100644 --- a/doc/devel/uml/class129797.html +++ b/doc/devel/uml/class129797.html @@ -4,19 +4,19 @@ -Class ExplicitePlacement +Class ExplicitPlacement -
Class ExplicitePlacement
+
Class ExplicitPlacement

-

Declaration :

Directly inherited by : DirectPlacement

+

Declaration :

Directly inherited by : DirectPlacement

Attribut time
diff --git a/doc/devel/uml/class134149.html b/doc/devel/uml/class134149.html index 37603e12e..f35403102 100644 --- a/doc/devel/uml/class134149.html +++ b/doc/devel/uml/class134149.html @@ -16,7 +16,7 @@ -

Declaration :

Directly inherited by : NodeCratorTool SegmentationTool

+

Declaration :

Directly inherited by : NodeCreatorTool SegmentationTool

Operation treat

Declaration :

  • Uml : + treat(inout mElement : Buildable) :
  • C++ : public: treat()
diff --git a/doc/devel/uml/class134405.html b/doc/devel/uml/class134405.html index 410def53a..f53a95dd7 100644 --- a/doc/devel/uml/class134405.html +++ b/doc/devel/uml/class134405.html @@ -4,19 +4,19 @@ -Class NodeCratorTool +Class NodeCreatorTool -
Class NodeCratorTool
+
Class NodeCreatorTool

-

Declaration :

+

Declaration :

  • C++ : class NodeCreatorTool : public Tool
Operation treat

Declaration :

  • Uml : + treat(inout something : Buildable) :
  • C++ : public: treat()
Operation treat

Declaration :

  • Uml : + treat(inout clip : Clip) :
  • C++ : public: treat()
diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 0cbd755d2..1594de949 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -32,7 +32,7 @@ EDL Effect ExitNode -ExplicitePlacementinterface +ExplicitPlacementinterface Fixture Frameinterface FrameProviderboundaryNote: just a Placeholder for my design. Cehteh will ceratinly know much better how to organize this @@ -45,7 +45,7 @@ Mask Meta MObjectinterface -NodeCratorTool +NodeCreatorTool OpenGLPipe Parameter ParamProviderinterface diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 9fff2d2f3..dbc8e579d 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -33,7 +33,7 @@ EDL
Effect
ExitNode
-ExplicitePlacement
+ExplicitPlacement
Fixture
Frame
FrameProvider
@@ -46,7 +46,7 @@ Mask
Meta
MObject
-NodeCratorTool
+NodeCreatorTool
OpenGLPipe
Parameter
ParamProvider
diff --git a/doc/devel/uml/fig128005.png b/doc/devel/uml/fig128005.png index 2b684a6dd..c9bb37077 100644 Binary files a/doc/devel/uml/fig128005.png and b/doc/devel/uml/fig128005.png differ diff --git a/doc/devel/uml/fig128133.png b/doc/devel/uml/fig128133.png index dcf1a8bbe..492b47ee1 100644 Binary files a/doc/devel/uml/fig128133.png and b/doc/devel/uml/fig128133.png differ diff --git a/doc/devel/uml/fig128773.png b/doc/devel/uml/fig128773.png index 5c319eb1f..823e693ca 100644 Binary files a/doc/devel/uml/fig128773.png and b/doc/devel/uml/fig128773.png differ diff --git a/doc/devel/uml/fig128901.png b/doc/devel/uml/fig128901.png index f51123a7d..d9a5d8dc3 100644 Binary files a/doc/devel/uml/fig128901.png and b/doc/devel/uml/fig128901.png differ diff --git a/doc/devel/uml/fig129285.png b/doc/devel/uml/fig129285.png index a2c283712..73b415def 100644 Binary files a/doc/devel/uml/fig129285.png and b/doc/devel/uml/fig129285.png differ diff --git a/doc/devel/uml/fig129541.png b/doc/devel/uml/fig129541.png index 3152b1895..731ebdf44 100644 Binary files a/doc/devel/uml/fig129541.png and b/doc/devel/uml/fig129541.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index dfe93e7af..30542d780 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -119,7 +119,7 @@ Documentation
Class RelativePlacement
Class Allocation
Class Label
-
Class ExplicitePlacement
+
Class ExplicitPlacement
Class Auto
Class Wish
Class Constraint
@@ -216,7 +216,7 @@ Documentation
Class Buildable
Class Tool
Class SegmentationTool
-
Class NodeCratorTool
+
Class NodeCreatorTool
diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index 823186fe6..ab6f13363 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -31,7 +31,7 @@ Engine Workingsclass view establish partitioningexpansion region ExitNodeclass -ExplicitePlacementclass +ExplicitPlacementclass diff --git a/doc/devel/uml/index_78.html b/doc/devel/uml/index_78.html index 00c0937f1..046bbfb3c 100644 --- a/doc/devel/uml/index_78.html +++ b/doc/devel/uml/index_78.html @@ -17,7 +17,7 @@ - +
NameKindDescription
NodeCratorToolclass
NodeCreatorToolclass
diff --git a/doc/devel/uml/public_operations.html b/doc/devel/uml/public_operations.html index 7507b4058..4229c0a17 100644 --- a/doc/devel/uml/public_operations.html +++ b/doc/devel/uml/public_operations.html @@ -33,10 +33,10 @@ playRenderEngine prepareStreamFrameProvider resolvePlacementcreate an actual (explicite) placement while trying to satisfy the network of adjacent objects and placements. -treatNodeCratorTool -treatNodeCratorTool -treatNodeCratorTool -treatNodeCratorTool +treatNodeCreatorTool +treatNodeCreatorTool +treatNodeCreatorTool +treatNodeCreatorTool treatSegmentationTool treatSegmentationTool treatSegmentationTool diff --git a/uml/cinelerra3/128133.diagram b/uml/cinelerra3/128133.diagram index ef4661d53..784c2e36c 100644 --- a/uml/cinelerra3/128133.diagram +++ b/uml/cinelerra3/128133.diagram @@ -60,13 +60,13 @@ classcanvas 134405 class_ref 129669 // Label draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default xyz 439 483 2000 end -classcanvas 135429 class_ref 129797 // ExplicitePlacement +classcanvas 135429 class_ref 129797 // ExplicitPlacement draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 657 233 2004 + xyz 660 233 2004 end -classcanvas 135813 class_ref 129797 // ExplicitePlacement +classcanvas 135813 class_ref 129797 // ExplicitPlacement draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 463 807 2000 + xyz 466 807 2000 end classcanvas 136581 class_ref 129925 // Auto draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode default drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default @@ -170,9 +170,9 @@ relationcanvas 135685 relation_ref 130949 // no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 135941 relation_ref 131077 // - from ref 128261 z 1999 stereotype "<>" xyz 371 890 3000 to ref 135813 - role_a_pos 416 844 3000 no_role_b - multiplicity_a_pos 448 877 3000 no_multiplicity_b + from ref 128261 z 1999 stereotype "<>" xyz 372 889 3000 to ref 135813 + role_a_pos 419 843 3000 no_role_b + multiplicity_a_pos 451 876 3000 no_multiplicity_b relationcanvas 136069 relation_ref 131205 // from ref 135813 z 1999 to point 433 897 line 136197 z 1999 to ref 129925 diff --git a/uml/cinelerra3/128261 b/uml/cinelerra3/128261 index 5ccffb601..9fefa1555 100644 --- a/uml/cinelerra3/128261 +++ b/uml/cinelerra3/128261 @@ -1,6 +1,6 @@ format 38 "MObject" // ProcessingLayer::MObject - revision 10 + revision 12 modified_by 5 "hiv" // class settings //class diagram settings @@ -156,7 +156,7 @@ ${inlines} cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; " classrelation_ref 131717 // timeline () - b multiplicity "" parent class_ref 129797 // ExplicitePlacement + b multiplicity "" parent class_ref 129797 // ExplicitPlacement end operation 128645 "getPlaylistForRender" @@ -250,7 +250,7 @@ ${members}}; end operation 128005 "resolve" - public return_type class_ref 129797 // ExplicitePlacement + public return_type class_ref 129797 // ExplicitPlacement nparams 0 cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name}${(}${)}${const}${volatile}${throw}${abstract}; " @@ -390,7 +390,7 @@ ${inlines} a public cpp default "${type}" classrelation_ref 131461 // - b multiplicity "" parent class_ref 129797 // ExplicitePlacement + b multiplicity "" parent class_ref 129797 // ExplicitPlacement end end @@ -521,7 +521,7 @@ ${inlines} end end - class 129797 "ExplicitePlacement" + class 129797 "ExplicitPlacement" abstract visibility public stereotype "interface" cpp_decl "${comment}${template}class ${name}${inherit} { ${members}}; diff --git a/uml/cinelerra3/128773.diagram b/uml/cinelerra3/128773.diagram index 6bf42028f..28ef4578f 100644 --- a/uml/cinelerra3/128773.diagram +++ b/uml/cinelerra3/128773.diagram @@ -3,16 +3,16 @@ format 38 classinstance 128005 class_ref 128261 // Fixture xyz 65 271 2000 name "" end -classinstance 128133 class_ref 129797 // ExplicitePlacement - xyz 217 249 2000 name "" +classinstance 128133 class_ref 129797 // ExplicitPlacement + xyz 221 249 2000 name "" values attribute_ref 128261 // time "2" attribute_ref 128389 // track "video1" end -classinstance 128389 class_ref 129797 // ExplicitePlacement - xyz 332 249 2000 name "" +classinstance 128389 class_ref 129797 // ExplicitPlacement + xyz 335 249 2000 name "" values attribute_ref 128261 // time "2" @@ -60,7 +60,7 @@ objectlinkcanvas 129157 norel no_role_a no_role_b objectlinkcanvas 130565 norel geometry HVr - from ref 128133 z 1999 to point 268 167 + from ref 128133 z 1999 to point 269 167 line 81 z 1999 to ref 129029 no_role_a no_role_b objectlinkcanvas 130693 norel diff --git a/uml/cinelerra3/128901.diagram b/uml/cinelerra3/128901.diagram index e9d4b0200..470765f02 100644 --- a/uml/cinelerra3/128901.diagram +++ b/uml/cinelerra3/128901.diagram @@ -6,8 +6,8 @@ end classinstance 128133 class_ref 128389 // Track xyz 71 275 2000 name "audio1" end -classinstance 128389 class_ref 129797 // ExplicitePlacement - xyz 218 423 2000 name "" +classinstance 128389 class_ref 129797 // ExplicitPlacement + xyz 222 423 2000 name "" values attribute_ref 128261 // time "2" @@ -87,8 +87,8 @@ classinstance 132997 class_ref 129029 // Effect attribute_ref 128901 // plugID "\"Hue\"" end -classinstance 133125 class_ref 129797 // ExplicitePlacement - xyz 342 423 2000 name "" +classinstance 133125 class_ref 129797 // ExplicitPlacement + xyz 345 423 2000 name "" values attribute_ref 128261 // time "5" @@ -101,7 +101,7 @@ textcanvas 136197 "Video Clip anchored at a Label, with an attached HUE effect s xyzwh 524 565 2000 175 87 objectlinkcanvas 129413 norel geometry HVr - from ref 128389 z 1999 to point 269 341 + from ref 128389 z 1999 to point 270 341 line 129541 z 1999 to ref 128645 no_role_a no_role_b objectlinkcanvas 129797 norel diff --git a/uml/cinelerra3/5.session b/uml/cinelerra3/5.session index 61c58e0de..eea73075c 100644 --- a/uml/cinelerra3/5.session +++ b/uml/cinelerra3/5.session @@ -6,6 +6,10 @@ open package_ref 128645 // codegen + package_ref 129157 // BackendLayer + + package_ref 128261 // MObject + package_ref 128773 // GUI end end diff --git a/uml/cinelerra3/cinelerra3.prj b/uml/cinelerra3/cinelerra3.prj index 7cd510dca..b9dbce680 100644 --- a/uml/cinelerra3/cinelerra3.prj +++ b/uml/cinelerra3/cinelerra3.prj @@ -1,6 +1,6 @@ format 38 "cinelerra3" - revision 10 + revision 11 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 675dc9b61..45a35e9c0 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -756,7 +756,7 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS 
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 actuall performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &mdash; to pay in the Builder &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.
 
 [>img[Outline of the Build Process|uml/fig129413.png]]
-The building itself will be broken down into several small tool application steps. Each of this steps has to be mapped on the MObjects found in the [[Timeline]]. Remember: the idea is that this so called "[[Fixture]]" contains only [[ExplicitePlacement]]s which in turn link to MObjects like Clips, Effects and Automation. So it is sufficient to traverse this list and map the build tools on the elements. Each of this build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
+The building itself will be broken down into several small tool application steps. Each of this steps has to be mapped on the MObjects found in the [[Timeline]]. Remember: the idea is that this so called "[[Fixture]]" contains only [[ExplicitPlacement]]s which in turn link to MObjects like Clips, Effects and Automation. So it is sufficient to traverse this list and map the build tools on the elements. Each of this build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
 * find the "Segments", i.e. the locations where the overall configuration changes
 * for each segment: generate a ProcNode for each found MObject and wire them accordingly
 Note, //we have still to work out how exactly building, rendering and playback work// together with the backend-design. But the build process as such doesnt't overly depend on this decisions, it is easy to reconfigure this process. For example, it would be possible as well to build for each frame separately (as Cinelerra2 does), or to build one segment covering the whole timeline (and handle everything via [[Automation]]
@@ -788,7 +788,7 @@ This programming technique is often refered to as //double dispatch// or //visit
 
 [img[Entities cooperating in the Builder|uml/fig129285.png]]
-
+
Background: #fefefd
 Foreground: #000
 PrimaryPale: #8fb
@@ -816,7 +816,7 @@ Error: #f88
As allways, the main goal is //to cut down complexity// by the usual aproach to separate into small manageable chunks.
 
-To achieve this, here we try to separate ''Configuration'' from ''Processing''. Further, on Configuration we try to separathe the ''high level view'' (users view when editing) from the ''low level view'' (the actual configuration effective for the calculations). And finally, we try to factor out and encapsulate ''State'' in order to make State explicite.
+To achieve this, here we try to separate ''Configuration'' from ''Processing''. Further, on Configuration we try to separathe the ''high level view'' (users view when editing) from the ''low level view'' (the actual configuration effective for the calculations). And finally, we try to factor out and encapsulate ''State'' in order to make State explicit.
 
 The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder. Make the actual processing nodes Template classes, parametrized by the color model and number of components. Make all Nodes of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. Make the OpenGL rendering into alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering out of the implementation of the actual processing. Introduce separate control data connections for the automation data, separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes using the same automation data).
 
@@ -832,7 +832,7 @@ In this usage, the EDL is almost synonymous to the ''Session'', just the latter
-
The &raquo;Timeline&laquo; is a sequence of ~MObjects -- here clips -- together with an ExplicitePlacement, locating each clip at a given time and track. (Note: I simplified the time format and wrote frame numbers to make it more clear)
+
The &raquo;Timeline&laquo; is a sequence of ~MObjects -- here clips -- together with an ExplicitPlacement, locating each clip at a given time and track. (Note: I simplified the time format and wrote frame numbers to make it more clear)
 [img[Example1: Objects in the EDL/Fixture|uml/fig128773.png]]
 
 ----
@@ -841,9 +841,9 @@ After beeing processed by the Builder, we get the following Render Engine config
-
This Example showes the //high level// EDL as well. This needs to be transformed into a Fixture by some facility still to be designed. Basically, each [[Placement]] needs to be queried for this to get the corresponding ExplicitePlacement. The difficult part is to handle possible Placement constraints, e.g. one clip can't be placed at a timespan covered by another clip on the same track. In the current Cinelerra2, all of this is done directly by the GUI actions.
+
This Example showes the //high level// EDL as well. This needs to be transformed into a Fixture by some facility still to be designed. Basically, each [[Placement]] needs to be queried for this to get the corresponding ExplicitPlacement. The difficult part is to handle possible Placement constraints, e.g. one clip can't be placed at a timespan covered by another clip on the same track. In the current Cinelerra2, all of this is done directly by the GUI actions.
 
-The &raquo;Timeline&laquo; is a sequence of ~MObjects -- note: using the same Object instances -- but now with the calculated ExplicitePlacement, locating the clip at a given time and track. The effect is located absolutely in time as well, but because it is the same Instance, it has the pointer to the ~RelativePlacement, wich basically attaches the effect to the clip. This structure may look complicated, but is easy to process if we go "backward" and just rely on the information contained in the ExplicitePlacement.
+The &raquo;Timeline&laquo; is a sequence of ~MObjects -- note: using the same Object instances -- but now with the calculated ExplicitPlacement, locating the clip at a given time and track. The effect is located absolutely in time as well, but because it is the same Instance, it has the pointer to the ~RelativePlacement, wich basically attaches the effect to the clip. This structure may look complicated, but is easy to process if we go "backward" and just rely on the information contained in the ExplicitPlacement.
 [img[Example2: Clip with Effect and generated Fixture for this EDL|uml/fig128901.png]]
 
 ----
@@ -855,7 +855,7 @@ It has to be segmented at least at every point with changes in the configuration
 

 
= MObject assembly =
 To make the intended use of the classes more clear, consider the following two example Object graphs:
-* a video clip and a audio clip placed (explicitely) on two tracks &rarr;[[Example1]]
+* a video clip and a audio clip placed (explicitly) on two tracks &rarr;[[Example1]]
 * a video clip placed relatively, with an attached HUE effect &rarr;[[Example2]]
 

 

@@ -863,15 +863,15 @@ To make the intended use of the classes more clear, consider the following two e
 
a special ProcNode which is used to pull the finished output of one Render Pipeline (Tree or Graph). This term is already used in the Cinelerra2 codebase. I am unsure at the moment if it is a distinct subclass or rahter a specially configured ProcNode (a general design rule tells us to err in favour of the latter if in doubt).
-
-
A special kind (subclass) of [[Placement]]. As such it is allways linked to a //Subject//, i.e. a MObject. In addition to the properties of a (unspecific) Placement, the ExplicitePlacement specifies a absoloute time and track position for locating the Subject
+

+
A special kind (subclass) of [[Placement]]. As such it is allways linked to a //Subject//, i.e. a MObject. In addition to the properties of a (unspecific) Placement, the ExplicitPlacement specifies a absoloute time and track position for locating the Subject
 

 

 

 
a specially configured EDL
  * all MObjects have their position, length and configuration set up ready for rendering.
- * all MObjects are associated with a ExplicitePlacement
- * this ~ExplicitePlacements are contained in a ordered List called the Timeline
+ * all MObjects are associated with a ExplicitPlacement
+ * this ~ExplicitPlacements are contained in a ordered List called the Timeline
 
 //My intention is to create this Fixture out of the editing operations done by the user//
 

@@ -1343,7 +1343,7 @@ see also: RenderEntities
 [img[Overview: Components of the Renderengine|uml/fig128261.png]]
-
+
<!--{{{-->
 <div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
 	<div class='headerShadow'>
@@ -1891,7 +1891,7 @@ DAMAGE.
 ***/
-
A Placement represents a //relation:// it is always linked to a //Subject// (this beeing a [[Media Object|MObject]]) and has the meaning to //place// this Subject in some manner, either relatively to other Media Objects, or by some Constraint or simply absolute at (time,track). The latter case is especially important and represented by a special [[Sub-Interface|ExplicitePlacement]]
+
A Placement represents a //relation:// it is always linked to a //Subject// (this beeing a [[Media Object|MObject]]) and has the meaning to //place// this Subject in some manner, either relatively to other Media Objects, or by some Constraint or simply absolute at (time,track). The latter case is especially important and represented by a special [[Sub-Interface|ExplicitPlacement]]
@@ -2183,9 +2183,6 @@ The design of Cinelerra 2 basically follows this design, but __fails because of 
<<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options ยป" "Change TiddlyWiki advanced options">>
-
-
{{red{killme}}}
-
some aspects of Cinelerra-3 design
@@ -2273,7 +2270,7 @@ Instead, we should try to just connect the various subsystems via Interfaces and * to shield the rendering code of all complexities of Thread communication and synchronization, we use the StateProxy
-
+
/*{{{*/
 /* a contrasting background so I can see where one tiddler ends and the other begins */
 body {
@@ -3483,7 +3480,7 @@ function addKeyDownHandlers(e)
 
http://tiddlywiki.com/
-
Timeline is the name of a specific facility located in the [[Fixture]] (EDL): It is a ordered list of ExplicitePlacement.s of MObjects. By traversing the Playlist you get at all elements actually to be rendered; the [[Builder]] uses this Timeline-list to construct actual Render Engine configurations to carry out the calculations.
+
Timeline is the name of a specific facility located in the [[Fixture]] (EDL): It is a ordered list of ExplicitPlacement.s of MObjects. By traversing the Playlist you get at all elements actually to be rendered; the [[Builder]] uses this Timeline-list to construct actual Render Engine configurations to carry out the calculations.
@@ -3493,7 +3490,7 @@ function addKeyDownHandlers(e) !!!!Starting Point Design is an experiment to find out how things are related, we can't //plan// a Design top down, rather we have to start at some point with some hypothesis and look how it works out. The point of origin for Ichthyo's design is the observation that the Render Engine needs some Separation of Concerns to get the complexity down. And especially, this design ''uses three different Levels'' or Layers within the Render Engine and EDL. * the __high level__ within the EDL uses uniformely treated MObjects which are assembled/glued together by a network of [[Placements|Placement]].<br> It is supposed that the GUI will present this and //only this view //to the user, giving him the ability wo work with this objects -* the __builder level__ works on a stripped-down subset of this ~MObject network: it uses the //same Object instances// but only assembled by [[Explicite Placements|ExplicitePlacement]] which locate the objects //on a simple (track, time) grid.// Its the job of the builder to create out of this simplified Network the Configuration of [[Render Nodes|ProcNode]] needed to do the actual rendering +* the __builder level__ works on a stripped-down subset of this ~MObject network: it uses the //same Object instances// but only assembled by [[Explicit Placements|ExplicitPlacement]] which locate the objects //on a simple (track, time) grid.// Its the job of the builder to create out of this simplified Network the Configuration of [[Render Nodes|ProcNode]] needed to do the actual rendering * the __engine level__ uses solely [[Render Pipeline Nodes|ProcNode]], i.e. a Graph of interconnected processing nodes. The important constraint here is that //any decisions are ruled out//. The core Render Engine with all its nodes is lacking the ability to do any tests and checks and has no possibility to branch or reconfigure anything. (this is an especially important lession I draw from studying the current Cinelerra source code) !!!!Performance Considerations @@ -3504,18 +3501,18 @@ Design is an experiment to find out how things are related, we can't //plan// a !!!!Concepts and Interfaces This design strives to build each level and subsystem around some central concepts, which are direcly expressed as Interfaces. Commonly used Interfaces clamp the different layers. * MObject gives an uniform view on all the various entities to be arranged in the EDL. -* all the arranging and relating of ~MObjects is abstracted as [[Placement]]. The contract of a Placement is that it always has a related Subject, that we can call some test methods on it (still to be defined), and, finally, that we can get an ExplicitePlacement from it. -* albeit beeing a special form of a Placement, the ExplicitePlacement is treated as a separate concept. With respect to edit operations within the EDL, it can stand it for any sort of Placement. On the other hand the Builder takes a list of ~ExplicitePlacements as input for building up the Render Engine(s). This corresponds to the fact that the render process needs to organize the things to be done on a simple two dimensional grid of (output channel / time). The (extended) contract of an ~ExplicitePlacement provides us with this information (track,time). +* all the arranging and relating of ~MObjects is abstracted as [[Placement]]. The contract of a Placement is that it always has a related Subject, that we can call some test methods on it (still to be defined), and, finally, that we can get an ExplicitPlacement from it. +* albeit beeing a special form of a Placement, the ExplicitPlacement is treated as a separate concept. With respect to edit operations within the EDL, it can stand it for any sort of Placement. On the other hand the Builder takes a list of ~ExplicitPlacements as input for building up the Render Engine(s). This corresponds to the fact that the render process needs to organize the things to be done on a simple two dimensional grid of (output channel / time). The (extended) contract of an ~ExplicitPlacement provides us with this information (track,time). * on the lower end of the builder, everything is organized around the Concept of a ProcNode, which enables us to //pull// one (freely addressible) Frame of calculated data. Further, the ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]] * the various types of data to be processed are abstracted away under the notion of a [[Frame]]. Basically, a Frame is an Buffer containing an Array of raw data and it can be located by some generic scheme, including (at least) the absolute starting time (and probably some type or channel id). * All sorts of (target domain) [[Parameters]] are treated uniformely. There is an distinction between Parameters (which //could// be variable) and Configuration (which is considered to be fixed). In this context, Automation just apeares as a special kind of ParamProvider. * and finally, the calculation //process// together with its current state is represented by a StateProxy. I call this a "proxy", because it should encapsulate and hide all tedious details of communication, be it even asychronous communication with some Controller or Dispatcher running in another Thread. In order to maintain a view on the current state of the render process, it could eventually be necessary to register as an observer somewhere or to send notifications to other parts of the system. !!!!Handling Diversity -An important goal of this aproach is to be able to push down the treatment of variations and special cases. We don't need to know what kind of Placement linkes one MObject to another, because it is sufficient for us to get an ExplicitePlacement. The Render Engine doesn't need to know if it is pulling audio Frames or video Frames or GOPs or OpenGL textures. It simply relies on the Builder wiring together the correct node types. And the Builder in turn does so by using some overloaded function of an iterator or visitor. There is no need for the video [[ProcNodes|ProcNode]] to test for the colormodel on every screen line, because the Data Frame can be a Template parametrized by the colormodel. All of this reduces complexity and quite some misconceptions can be detected alredy by the compiler. +An important goal of this aproach is to be able to push down the treatment of variations and special cases. We don't need to know what kind of Placement linkes one MObject to another, because it is sufficient for us to get an ExplicitPlacement. The Render Engine doesn't need to know if it is pulling audio Frames or video Frames or GOPs or OpenGL textures. It simply relies on the Builder wiring together the correct node types. And the Builder in turn does so by using some overloaded function of an iterator or visitor. There is no need for the video [[ProcNodes|ProcNode]] to test for the colormodel on every screen line, because the Data Frame can be a Template parametrized by the colormodel. All of this reduces complexity and quite some misconceptions can be detected alredy by the compiler. -!!!!Explicite structural differences -In case it's not already clear: we don't have "the" Render Engine, rather we construct a Render Engine for each structurally differing part of the timeline. (please relate this to the current Cinelerra code base, which constructs and builds up the render pipeline for each frame separately). No need to call back from within the pipeline to find out if a given plugin is enabled or to see if there are any automation keyframes. So we don't need to pose any constraints on the structuring of the objects in the EDL, besides the requirement to get an ExplicitePlacement for each. We could even loosen the use of the common mataphor of placing media sequences on fixed tracks, if we want to get at a more advanced GUI at some point in the future. +!!!!Explicit structural differences +In case it's not already clear: we don't have "the" Render Engine, rather we construct a Render Engine for each structurally differing part of the timeline. (please relate this to the current Cinelerra code base, which constructs and builds up the render pipeline for each frame separately). No need to call back from within the pipeline to find out if a given plugin is enabled or to see if there are any automation keyframes. So we don't need to pose any constraints on the structuring of the objects in the EDL, besides the requirement to get an ExplicitPlacement for each. We could even loosen the use of the common mataphor of placing media sequences on fixed tracks, if we want to get at a more advanced GUI at some point in the future. !!!!Stateless Subsystems The &raquo;current setup&laquo; of the objects in the EDL 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 benifit of this we can run this subsystems multithreaded 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 this term in the usual, slightly relaxed manner; of course there are some configuration values contained in instance variables of the objects carying out the calculations, but this values are considered to be constant over the course of the object usage).