diff --git a/doc/devel/uml/fig1.png b/doc/devel/uml/fig1.png index 337145bff..c9bb37077 100644 Binary files a/doc/devel/uml/fig1.png and b/doc/devel/uml/fig1.png differ diff --git a/doc/devel/uml/fig2.png b/doc/devel/uml/fig2.png index 4ec6d5a39..ce4be60b2 100644 Binary files a/doc/devel/uml/fig2.png and b/doc/devel/uml/fig2.png differ diff --git a/doc/devel/uml/fig4.png b/doc/devel/uml/fig4.png index e49a9ce36..bcec5c41c 100644 Binary files a/doc/devel/uml/fig4.png and b/doc/devel/uml/fig4.png differ diff --git a/doc/devel/uml/fig7.png b/doc/devel/uml/fig7.png index 330bb9a3e..9192da11b 100644 Binary files a/doc/devel/uml/fig7.png and b/doc/devel/uml/fig7.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index 15c783bc5..7fffc372d 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -49,10 +49,10 @@ Documentation
Component Dispatcher
Component Engine
-

Depends on Stream Provider

+

Depends on Frame (Stream) Provider

-
Component Stream Provider
+
Component Frame (Stream) Provider

Depends on Cache

@@ -146,7 +146,7 @@ Documentation
Node pnode
-
Node mStream
+
Node Frame
Node State
diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index c59d89abd..c330b9cbf 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -20,7 +20,9 @@ Fixtureclass Fixturecomponent fixturerelation +Framenode Frameclass +Frame (Stream) Providercomponent FrameProviderclassNote: just a Placeholder for my design. Cehteh will ceratinly know much better how to organize this diff --git a/doc/devel/uml/index_77.html b/doc/devel/uml/index_77.html index fc50e0afc..4a17d4334 100644 --- a/doc/devel/uml/index_77.html +++ b/doc/devel/uml/index_77.html @@ -21,7 +21,6 @@ Metaclass MObjectpackage MObjectclass -mStreamnode diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index 2a62511af..9526c66f0 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -27,7 +27,6 @@ startattributebegin of the timerange covered by this processor Statenode StateProxyclass -Stream Providercomponent subjectrelation diff --git a/uml/cinelerra3/128005 b/uml/cinelerra3/128005 index 48da8f34d..b4a91c47a 100644 --- a/uml/cinelerra3/128005 +++ b/uml/cinelerra3/128005 @@ -1,6 +1,6 @@ format 38 "design" // design - revision 4 + revision 5 modified_by 5 "hiv" // class settings //class diagram settings @@ -71,11 +71,11 @@ Not a real code package, rather a container for design drafts, specifications, d component 128901 "Engine" simplerelation 128133 -_-> - on component_ref 129029 // Stream Provider + on component_ref 129029 // Frame (Stream) Provider end end - component 129029 "Stream Provider" + component 129029 "Frame (Stream) Provider" simplerelation 128005 -_-> on component_ref 129157 // Cache diff --git a/uml/cinelerra3/128005.diagram b/uml/cinelerra3/128005.diagram index 6dd14ad62..cf8cad386 100644 --- a/uml/cinelerra3/128005.diagram +++ b/uml/cinelerra3/128005.diagram @@ -45,7 +45,7 @@ componentcanvas 129797 component_ref 128773 // Dispatcher componentcanvas 129925 component_ref 128901 // Engine draw_component_as_icon default show_component_req_prov default show_component_rea default xyzwh 118 602 2010 235 176 -componentcanvas 130053 component_ref 129029 // Stream Provider +componentcanvas 130053 component_ref 129029 // Frame (Stream) Provider draw_component_as_icon default show_component_req_prov default show_component_rea default xyzwh 121 876 2005 229 69 componentcanvas 130181 component_ref 129157 // Cache @@ -56,7 +56,7 @@ note 131717 "Coordinates Playback and Rendering" note 131845 "border of the low-level, performance-critical part of the system" xyzwh 666 450 2006 167 84 note 131973 "just works, never decides" - xyzwh 316 668 2010 110 59 + xyzwh 317 668 2015 110 59 note 132101 "codecs, stream I/O here" xyzwh 647 904 2005 166 39 simplerelationcanvas 131205 simplerelation_ref 128005 diff --git a/uml/cinelerra3/128005_5.d b/uml/cinelerra3/128005_5.d new file mode 100644 index 000000000..cf8cad386 --- /dev/null +++ b/uml/cinelerra3/128005_5.d @@ -0,0 +1,73 @@ +format 38 + +fragment 128005 "UI Layer" + xyzwh 321 22 2000 829 100 +end +fragment 128133 "Processing Layer" + xyzwh 64 156 2000 1089 655 + separator 4833 +end +fragment 128261 "Backend Layer" + xyzwh 64 848 2000 1089 105 +end +packagecanvas 128389 + package_ref 128133 // AssetManager + xyzwh 561 201 2005 252 214 +packagecanvas 128517 + package_ref 128261 // MObject + xyzwh 94 201 2006 458 335 +packagecanvas 128645 + package_ref 128389 // RenderEngine + xyzwh 94 551 2005 458 235 +componentcanvas 128773 component_ref 128005 // Builder + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 121 419 2015 229 105 +componentcanvas 128901 component_ref 128133 // Session + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 122 243 2011 323 156 +componentcanvas 129029 component_ref 128261 // Controller + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 372 419 2011 175 105 +componentcanvas 129157 component_ref 128389 // EDL + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 288 302 2016 143 79 +componentcanvas 129285 component_ref 128517 // Fixture + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 124 319 2016 143 69 +note 129541 "Structures edited by the User" + xyzwh 43 269 2016 181 41 +componentcanvas 129669 component_ref 128645 // AssetManagement + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 577 241 2010 208 159 +componentcanvas 129797 component_ref 128773 // Dispatcher + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 406 31 2005 179 69 +componentcanvas 129925 component_ref 128901 // Engine + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 118 602 2010 235 176 +componentcanvas 130053 component_ref 129029 // Frame (Stream) Provider + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 121 876 2005 229 69 +componentcanvas 130181 component_ref 129157 // Cache + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 391 876 2005 179 69 +note 131717 "Coordinates Playback and Rendering" + xyzwh 483 494 2016 149 63 +note 131845 "border of the low-level, performance-critical part of the system" + xyzwh 666 450 2006 167 84 +note 131973 "just works, never decides" + xyzwh 317 668 2015 110 59 +note 132101 "codecs, stream I/O here" + xyzwh 647 904 2005 166 39 +simplerelationcanvas 131205 simplerelation_ref 128005 + from ref 130053 z 2004 to ref 130181 +simplerelationcanvas 131333 simplerelation_ref 128133 + from ref 129925 z 2004 to ref 130053 +line 130309 -_-_ + from ref 129797 z 2004 to ref 128901 +line 130821 -_-_ geometry HVr + from ref 129797 z 2004 to point 493 469 + line 130949 z 2004 to ref 129029 +line 131077 -_-_ + from ref 129797 z 2004 to ref 129669 +end diff --git a/uml/cinelerra3/128261 b/uml/cinelerra3/128261 index 0ca47fe6e..cd1316f5f 100644 --- a/uml/cinelerra3/128261 +++ b/uml/cinelerra3/128261 @@ -1,6 +1,6 @@ format 38 "MObject" // MObject - revision 7 + revision 8 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/128261.diagram b/uml/cinelerra3/128261.diagram index d86a21a4f..7bc995b82 100644 --- a/uml/cinelerra3/128261.diagram +++ b/uml/cinelerra3/128261.diagram @@ -12,7 +12,7 @@ end componentcanvas 128517 component_ref 128901 // Engine draw_component_as_icon default show_component_req_prov default show_component_rea default xyzwh 95 318 2000 487 323 -componentcanvas 128645 component_ref 129029 // Stream Provider +componentcanvas 128645 component_ref 129029 // Frame (Stream) Provider draw_component_as_icon default show_component_req_prov default show_component_rea default xyzwh 254 711 2005 180 160 deploymentnodecanvas 128901 deploymentnode_ref 128005 // timeline @@ -41,7 +41,7 @@ deploymentnodecanvas 131077 deploymentnode_ref 128517 // pnode xyzwh 318 544 2005 56 36 deploymentnodecanvas 131205 deploymentnode_ref 128517 // pnode xyzwh 317 584 2005 56 36 -deploymentnodecanvas 133125 deploymentnode_ref 128645 // mStream +deploymentnodecanvas 133125 deploymentnode_ref 128645 // Frame xyzwh 309 800 2010 70 36 deploymentnodecanvas 134021 deploymentnode_ref 128517 // pnode xyzwh 442 503 2005 56 36 diff --git a/uml/cinelerra3/128261_5.d b/uml/cinelerra3/128261_5.d new file mode 100644 index 000000000..7bc995b82 --- /dev/null +++ b/uml/cinelerra3/128261_5.d @@ -0,0 +1,81 @@ +format 38 + +componentcanvas 128133 component_ref 128005 // Builder + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 117 113 2000 204 156 +componentcanvas 128261 component_ref 128261 // Controller + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 573 100 2000 166 82 +fragment 128389 "Backend Layer" + xyzwh 89 690 2000 632 188 +end +componentcanvas 128517 component_ref 128901 // Engine + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 95 318 2000 487 323 +componentcanvas 128645 component_ref 129029 // Frame (Stream) Provider + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 254 711 2005 180 160 +deploymentnodecanvas 128901 deploymentnode_ref 128005 // timeline + xyzwh 142 3 2000 323 90 +hubcanvas 129157 xyz 192 63 2005 +hubcanvas 129285 xyz 222 62 2005 +hubcanvas 129413 xyz 255 62 2005 +hubcanvas 129541 xyz 290 62 2005 +deploymentnodecanvas 130053 deploymentnode_ref 128261 // playlist + xyzwh 148 389 2005 401 80 +deploymentnodecanvas 130181 deploymentnode_ref 128389 // proc + xyzwh 178 435 2010 97 69 +deploymentnodecanvas 130309 deploymentnode_ref 128389 // proc + xyzwh 424 430 2010 97 69 +deploymentnodecanvas 130437 deploymentnode_ref 128517 // pnode + xyzwh 202 507 2005 56 36 +deploymentnodecanvas 130565 deploymentnode_ref 128517 // pnode + xyzwh 201 546 2005 56 36 +deploymentnodecanvas 130693 deploymentnode_ref 128517 // pnode + xyzwh 201 585 2005 56 36 +deploymentnodecanvas 130821 deploymentnode_ref 128517 // pnode + xyzwh 318 505 2005 56 36 +deploymentnodecanvas 130949 deploymentnode_ref 128389 // proc + xyzwh 294 433 2010 97 69 +deploymentnodecanvas 131077 deploymentnode_ref 128517 // pnode + xyzwh 318 544 2005 56 36 +deploymentnodecanvas 131205 deploymentnode_ref 128517 // pnode + xyzwh 317 584 2005 56 36 +deploymentnodecanvas 133125 deploymentnode_ref 128645 // Frame + xyzwh 309 800 2010 70 36 +deploymentnodecanvas 134021 deploymentnode_ref 128517 // pnode + xyzwh 442 503 2005 56 36 +deploymentnodecanvas 134149 deploymentnode_ref 128517 // pnode + xyzwh 411 548 2005 56 36 +deploymentnodecanvas 134277 deploymentnode_ref 128517 // pnode + xyzwh 466 548 2005 56 36 +deploymentnodecanvas 134405 deploymentnode_ref 128517 // pnode + xyzwh 467 586 2005 56 36 +componentcanvas 135045 component_ref 129285 // RenderPathManager + draw_component_as_icon default show_component_req_prov default show_component_rea default + xyzwh 505 222 2000 165 65 +deploymentnodecanvas 136069 deploymentnode_ref 128773 // State + xyzwh 703 226 2000 83 52 +textcanvas 136325 "Render Engine carries out the actual processing by pulling output from the aprropriate processor " + xyzwh 615 363 2000 135 89 +note 136453 "Input for Builder" + xyzwh 125 83 2005 104 36 +note 136581 "Output of Builder" + xyzwh 119 350 2005 104 36 +note 136709 "optimizes" + xyzwh 616 286 2000 75 35 +packagecanvas 136837 + package_ref 129029 // Controller + xyzwh 486 68 1994 326 228 +textcanvas 136965 "Builder is instructed by Controller and transforms given timeline into a Render Engine, i.e.a network of processing nodes" + xyzwh 326 196 2005 160 101 +simplerelationcanvas 128773 simplerelation_ref 128133 + from ref 128517 z 1999 to ref 128645 +line 129925 ---- + from ref 129157 z 2004 to ref 129541 +line 133765 ---- + from ref 130949 z 2009 to ref 133125 +simplerelationcanvas 134533 simplerelation_ref 128261 geometry HVr + from ref 128261 z 1999 to point 653 188 + line 134789 z 1999 to ref 128133 +end diff --git a/uml/cinelerra3/128389 b/uml/cinelerra3/128389 index d46a3e0ee..7748a20d7 100644 --- a/uml/cinelerra3/128389 +++ b/uml/cinelerra3/128389 @@ -1,6 +1,6 @@ format 38 "RenderEngine" // RenderEngine - revision 5 + revision 6 modified_by 5 "hiv" // class settings //class diagram settings @@ -48,7 +48,7 @@ format 38 deploymentnode 128517 "pnode" end - deploymentnode 128645 "mStream" + deploymentnode 128645 "Frame" end deploymentnode 128773 "State" @@ -194,7 +194,6 @@ ${inlines} classrelation_ref 132869 // b multiplicity "" parent class_ref 131717 // ProcNode end - end class 131717 "ProcNode" @@ -296,7 +295,6 @@ ${inlines} classrelation_ref 133509 // b multiplicity "" parent class_ref 131845 // Trafo end - end class 132357 "Mask" diff --git a/uml/cinelerra3/128901.diagram b/uml/cinelerra3/128901.diagram index 9d8326da8..ea7958855 100644 --- a/uml/cinelerra3/128901.diagram +++ b/uml/cinelerra3/128901.diagram @@ -97,7 +97,7 @@ classinstance 133125 class_ref 129797 // ExplicitePlacement end note 135941 "actually the same object" xyzwh 635 341 2004 148 41 -textcanvas 136197 "Video Clip anchored at a Label, with an attached HUE effect starting 3 frames after beginn" +textcanvas 136197 "Video Clip anchored at a Label, with an attached HUE effect starting 3 frames after begin" xyzwh 524 565 2000 175 87 objectlinkcanvas 129413 norel geometry HVr @@ -153,7 +153,7 @@ objectlinkcanvas 133381 norel objectlinkcanvas 135685 rel relation_ref 128645 // from ref 132997 z 1999 to point 600 432 line 135813 z 1999 to ref 132357 - role_a_pos 612 276 3000 role_b_pos 444 540 3000 + role_a_pos 612 276 3000 role_b_pos 413 543 3000 line 134149 -_-_ from ref 131717 z 1993 to ref 132869 line 134277 -_-_ diff --git a/uml/cinelerra3/cinelerra3.prj b/uml/cinelerra3/cinelerra3.prj index c1d5d5379..3039fb175 100644 --- a/uml/cinelerra3/cinelerra3.prj +++ b/uml/cinelerra3/cinelerra3.prj @@ -1,6 +1,6 @@ format 38 "cinelerra3" - revision 6 + revision 7 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/ichthyo-draft.html b/wiki/ichthyo-draft.html index 572c95f54..39ee7072b 100644 --- a/wiki/ichthyo-draft.html +++ b/wiki/ichthyo-draft.html @@ -747,13 +747,17 @@ 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, to pay in the Builder 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[Colaborations in the Build Process|uml/fig5.png]]
+[img[Colaborations in the Build Process|uml/fig5.png]] +
-
-
This 'index.html' becomes the entry point of some tiddlywikis managed under git. There is a 'empty.html' in the same folder serving as template for generating new wikis. Please refrain from editing it.
+
+
The Builder takes some MObject/[[Placement]] information (called Timeline) and generates out of this a Render Engine configuration able to render this Objects. It does all decisions and retrieves the current configuration of all objects and plugins, so the Render Engine can just process them stright forward.
+
+The Builder is part of the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]
+
Background: #fefefd
@@ -772,25 +776,85 @@ TertiaryMid: #99a
 TertiaryDark: #667
 Error: #f88
+
+
Here, in the context of the Render Engine, the Controller component is responsible for managing the global playback state, for triggering the build process and for activating the backend and the Render Engine configuration created by the Builder to carry out the actual rendering. So you can expect the Controller to encompass a State Machine.
+
+
RenderEngine
-
+
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.
 
 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).
 
-Another pretinent theme is to make the basic building blocks more simple, while on the other hand gaining much more flexibility for combining these building blocks. For example we try to unfold any "internal-multi" effects into separate instances (e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks. Similarily, we treat the Objects in the EDL in a more uniform manner and gain the possibility to [[place|Placements]] them in various ways.
+Another pretinent theme is to make the basic building blocks more simple, while on the other hand gaining much more flexibility for combining these building blocks. For example we try to unfold any "internal-multi" effects into separate instances (e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks. Similarily, we treat the Objects in the EDL in a more uniform manner and gain the possibility to [[place|Placement]] them in various ways. + 
''EDL'' is a short-hand for __E__dit __D__ecision __L__ist. The use of this term can be confusing; for the usual meaning see the definition in [[Wikipedia|http://en.wikipedia.org/wiki/Edit_decision_list]]
 
 Cinelerra uses this term in a related manner but with a somewhat shifted focus (and we just stick to this usage here): In Cinelelrra the EDL is comprised of the whole set of clips and other media objects parametrized and placed onto the tracks by the user. It is the result of the user's //editing efforts.//
 
-In this usage, the EDL is almost synonymous to the ''Session'', just the latter emphasizes more the state aspect, as it can be thought as a current state of the EDL contained in a file or data structure together with additional Option values and Sestings for the GUI. The Session is what you save and load, while the EDL rather denotes a structure of Objects placed in time.
+In this usage, the EDL is almost synonymous to the ''Session'', just the latter emphasizes more the state aspect, as it can be thought as a current state of the EDL contained in a file or data structure together with additional Option values and Sestings for the GUI. The Session is what you save and load, while the EDL rather denotes a structure of Objects placed in time. + +
+
+
The »Timeline« 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)
+[img[Example1: Objects in the EDL/Fixture|uml/fig3.png]]
+
+----
+After beeing processed by the Builder, we get the following Render Engine configuration
+[img[Example1: generated Render Engine|uml/fig9.png]]
+
+
+
+
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.
+
+The »Timeline« 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.
+[img[Example2: Clip with Effect and generated Fixture for this EDL|uml/fig4.png]]
+
+----
+After beeing processed by the Builder, we get a Render Engine configuration.<br>
+It has to be segmented at least at every point with changes in the configuration, but some variations are possible, e.g. we could create a Render Engine for every Frame (as Cinelerra2 does) or we could optimize out some configurations (for example the effect extended beyond the end of the clip)
+[img[Example2: generated Render Engine|uml/fig10.png]]
+
+
+
+
= 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 placed relatively, with an attached HUE effect &rarr;[[Example2]]
+
+
+
+
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 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
+
+//My intention is to create this Fixture out of the editing operations done by the user//
+
+
+
+
This term has //two meanings, //so care has to be taken for not confusing them.
+# in general use, a Frame means one full image of a video clip, i.e an array of rows of pixels. For interlaced footage, one Frame contains two halfimages, commonly called Fields. (Cinelerra2 confuses this terms)
+# here in this design, we use Frame as an abstraction for a buffer of raw media data to be processed. If in doubt, we should label this "Dataframe".
+#* one video Dataframe contains a single video frame
+#* one audio Dataframe contains a block of raw audio samples
+#* one OpenGL Dataframe could contain raw texture data (but I am lacking expertise for this topic)
+
/***
@@ -864,6 +928,14 @@ Slider.prototype.stop = function()
 }
 //}}}
+
+
__G__roup __of__ __P__ictures: several compressed video formats don't encode single frames. Normally, such formats are considered mere //delivery formates// but it was one of the key strenghts of Cinelrra from start to be able to do real non linear editing on such formats (like the ~MPEG2-ts unsed in HDV video). The problem of course is that the data backend needs to decode the whole GOP to be serve  single raw video frames.
+
+For this Cinelerra3 design, we could consider making GOP just another raw media data frame type and integrate this decoding into the render pipeline, similar to an effect based on several source frames for every calculated output frame.
+
+&rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
+
+
/***
 ''InlineJavascriptPlugin for ~TiddlyWiki version 1.2.x and 2.0''
@@ -1175,12 +1247,28 @@ config.formatters.push( {
 } )
 //}}}
-
-
The MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within it.
+

+
{{red{killme}}}

+

+

+
All sorts of "things" to be placed and manipulated by the user in the EDL. This interface abstracts the details and just provides
+* a duration
+* a [[Placement]]
+* {{red{and what else?}}}
+

+

+

+
The MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within it. Examples for [[MObjects|MObject]] being:
+* audio/video clips
+* effects and plugins
+* special facilities like mask and projector
+* [[Automation]] sets
+* labels and other (maybe functional) markup
 
-This Design strives to achieve a StrongSeparation between the low-level Structures used to carry out the actual rendering and the high level Entities living in the EDL and being manipulated by the user. In this high level view, the Objects are grouped and located by [[Placements]], providing a flexible and open way to express different groupings, locations and ordering constraints between the Media Objects.
+This Design strives to achieve a StrongSeparation between the low-level Structures used to carry out the actual rendering and the high level Entities living in the EDL and being manipulated by the user. In this high level view, the Objects are grouped and located by [[Placements|Placement]], providing a flexible and open way to express different groupings, locations and ordering constraints between the Media Objects.
 
-[img[Classess related to the EDL|uml/fig2.png]]

+[img[Classess related to the EDL|uml/fig2.png]]
+
''[[Cinelerra3|index.html]]''
@@ -1196,18 +1284,35 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>My TiddlyWiki</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>
-
-
[img[Block Diagram|uml/fig1.png]]
+
+
Cinelerra2 introduced OpenGL support for rendering previews. I must admit, I am very unhappy with this, because
+* it just supports some hardware
+* it makes building difficult
+* it can't handle all color models Cinelerra is capable of
+* it introduces a separate codepath including some complicated copying of video data into the textures (and back?)
+* it can't be used for rendering
+
+So my judgement would be: in contrary to a realtime/gaming application, for quality video editing it is not worth the effort implementing OpenGL support in all details and with all its complexity. I would accept ~OpenGL as an option, if it could be pushed down into a Library, so it can be handled and maintained transparently and doesnt bind our limited developer manpower.
+
+But because I know the opinions on this topc are varying (users tend to be delighted if they hear "~OpenGL", because it carries notion of "fast" and "power" todays) &mdash; I try to integrate ~OpenGL as apossibility into this design of the Render Engine. Obviousely, I have the hard requirement that it //must not jeopardize the code structure.//
+
+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
+
-
-
Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configured Render Engine //for every// RenderProcess. Before doing so, he queries from the Session (or, to be more precise, from the [[Fixture]] within the current Session) all necessary Media Object Placement information. The [[Builder]] then derives from this information the actual assembly of ProcessingNodes comprising the Render Engine. Thus:
- * the source of the build process is a sequence of absolute (explicit) [[Placements]] called the [[Playlist]]
+

+
[img[Block Diagram|uml/fig1.png]]
+

+

+

+
Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configured Render Engine //for every// RenderProcess. Before doing so, he queries from the Session (or, to be more precise, from the [[Fixture]] within the current Session) all necessary Media Object Placement information. The [[Builder]] then derives from this information the actual assembly of [[Processing Nodes|ProcNode]] comprising the Render Engine. Thus:
+ * the source of the build process is a sequence of absolute (explicit) [[Placements|Placement]] called the [[Playlist]]
  * the [[build process|BuildProcess]] is driven, configured and controlled by the [[Controller]] subsystem component. It encompasses the actual playback configuration and State of the System.
- * the resulting Render Engine is a list of [[Processors]], each configured to calculate a segment of the timeline with uniform properties. Each of these Processors in turn is a graph of interconnected ProcessingNodes.
+ * the resulting Render Engine is a list of [[Processors]], each configured to calculate a segment of the timeline with uniform properties. Each of these Processors in turn is a graph of interconnected ProcNode.s.
 
 see also: RenderEntities
 
-[img[Overview: Components of the Renderengine|uml/fig7.png]]

+[img[Overview: Components of the Renderengine|uml/fig7.png]]
+
<!--{{{-->
@@ -1236,6 +1341,27 @@ see also: RenderEntities
 <!--}}}-->
+
+
A ParamProvider is the counterpart for (one or many) Parameter instances. It implements the value access function made available by the Parameter object to its clients.
+
+To give a concrete example: 
+* a Fade Plugin needs the actual fade value for Frame t=xxx
+* the Plugin has a Parameter Object (from which we could query the information of this parameter beeing a continuous float function)
+* this Parameter Object provides a getValue() function, which is internally linked (i.e. by configuration) to a //Parameter Provider//
+* the actual object implementing the ParamProvider Interface could be a Automation MObject located somewhere in the EDL and would do bezier interpolation on a given keyframe set.
+* while building the Render Engine configuration actually at work, the Builder would have to setup this link between the Plugin Parameter Object and the ParamProvider; he can do so, because he sees the link between the Automation MObject and the corresponding Effect MObject
+
+
+
+
Parameters are all probably variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application state to take effect.
+
+A ''Parameter Object'' provides a descriptor of the kind of parameter, together with a function used to pull the //actual value// of this parameter. Here, //actual// has a two-fold meaning:
+* if called without a time specification, it is either a global (but variable) system or session parameter or a default value for automated Parameters. (the intention is to treat this cases uniformly)
+* if called with a time specification, it is the query for an &mdash; probably interpolated &mdash; [[Automation]] value at this absolute time. The corresponding ParamProvider should fall back transparently to a default or session value if no time varying data is available
+
+{{red{TODO: define how Automation works}}}
+
+
/***
 |<html><a name="Top"/></html>''Name:''|PartTiddlerPlugin|
@@ -1734,6 +1860,34 @@ DAMAGE.
 <html><sub><a href="javascript:;" onclick="scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>
 ***/
+
+
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]]
+
+
+
+
Playlist 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 Playlist to construct actual Render Engine configurations to carry out the calculations.
+
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
a data processing node within the Render Engine. Its key feature is the possibility to pull from it one (freely addressible) [[Frame]] of calculated data. Further, each ~ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
+
+
+
+
a given Render Engine configuration is a list of Processors. Each Processor in turn contains a Graph of ProcNode.s to do the acutal data processing. In order to cary out any calculations, the Processor needs to be called with a StateProxy containing the state information for this RenderProcess
+
+
/***
 |''Name:''|RSSReaderPlugin|
@@ -1944,73 +2098,7 @@ config.macros.rssFeedUpdate = {
 //}}}
-
-
//last update: RSSReaderPlugin v 1.1.1//
-
-!Description
-This plugin provides a RSSReader for TiddlyWiki
-* It accesses asynchronously an RSSFeed
-*Depending on the chanel item format, each item could be written as :
-**simple text wikified
-**html
-
-!Usage
-{{{
-<<rssReader noDesc|asHtml|asText rssUrl ['filtering string']>>
-	noDesc: only title of item is printed
-
-	asHtml: if you know that description contain html (links, img ...), 
-		the text is enclosed with <html> </html> tags
-
- 	asText: if the description should not be interpreted as html the 
-		description is wikified
-
-	rssUrl: the rssFeed url that could be accessed. 
-	
-	'filtering string': if present, the rssfeed item title must contained 
-		this string to be displayed. 
-		If 'filering string' contained space characters only, the tiddler 
-		title is used for filtering.
-
-}}}
-
-For security reasons, if the TiddlyWiki is accessed from http, a ProxyService should be used to access an rssFeed from an other site.
-
-!examples
-| !reader | !RSSFeed type | !working from |
-| BidiXTWRSS | Description asHtml | file: or tiddlywiki.bidix.info |
-| [[Le Monde]] | Description asText | file: or tiddlywiki.bidix.info using proxy |
-| YahooNewsSport | Description asHtml | file: or tiddlywiki.bidix.info using proxy |
-| TiddlyWikiRSS | Description asHtml | file: or tiddlywiki.bidix.info using proxy |
-| [[Libération]] | noDesc | file: or tiddlywiki.bidix.info using proxy |
-| [[TestComment]] | asText and filters | file: or tiddlywiki.bidix.info using proxy |
-see : <<tag RSSFeed>> for the full list.
-
-!Revision history
-* V1.1.0 (2207/04/13)
-**No more import functions
-* V1.0.0 (2006/11/11)
-**refactoring using core loadRemoteFile function
-**import using new tiddlywiki:tiddler element
-**import and presentation preserved without EricShulman's NestedSliderPlugin
-**better display of items 
-* v0.3.0 (24/08/2006)
-** Filter on RSS item title
-** Place to display redefined for asynchronous processing
-* v0.2.2 (22/08/2006)
-**Haloscan feed has no pubDate.
-* v0.2.1 (08/05/2006)
-* v0.2.0 (01/05/2006)
-**Small adapations for del.icio.us feed
-* v0.1.1 (28/04/2006)
-**Bug : Channel without title 
-* v0.1.0 (24/04/2006)
-** initial release
-
-
-
-
-
+
The Render Engine is the part of the application doing the actual video calculations. Its operations are guided by the Objects and Parameters edited by the user in [[the EDL|EDL]] and it retrieves the raw audio and video data from the [[Data backend|backend.html]]. Because the inner workings of the Render Engine are closely related to the structures used in the EDL, this design covers [[this aspect|MObjects]] as well.
 
 The key idea of Ichthyo's Design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. 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.
@@ -2022,37 +2110,59 @@ The design of Cinelerra 2 basically follows this design, but __fails because of
 # far too much back-coupling to the internals of the [[EDL]], forcing a overly rigid structure on the latter
 
 !Try to learn from this
-* build up an NodeAbstraction powerful enough to express //all necessary Operations// without the need to recure on the actual object type
+* build up an [[Node Abstraction|ProcNode]] powerful enough to express //all necessary Operations// without the need to recure on the actual object type
 * need to redesign the internals of the EDL in a far more open manner. See MObjects
 * strive at a StrongSeparation between EDL and Render Engine
 
 !!see also
 &rarr; [[Overview]] of Subsystems and Components, and DesignGoals
-&rarr; [[An Introduction|WalkThrough]] discussing the key features {{red{TODO}}}
+&rarr; [[An Introduction|WalkThrough]] discussing the key features
 &rarr; [[Overview Render Engine|OverviewRenderEngine]]
 &rarr; BuildProcess
 &rarr; RenderProcess
-&rarr; [[Two Examples|Examples]] (Object diagrams) {{red{TODO: write explanation for the drawings in UML}}}
+&rarr; [[Two Examples|Examples]] (Object diagrams) +&rarr; how [[Automation]] works {{red{to be defined}}} +
-
-
The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of ProcessingNodes discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
+

+
The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of [[Processing Nodes|ProcNode]] discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
 
-[img[Entities comprising the Render Engine|uml/fig8.png]]

+[img[Entities comprising the Render Engine|uml/fig8.png]]
+
-
-
''TODO'' describe the Render Process.
+

+
{{red{TODO: describe the Render Process.}}}
 
- * see also the [[Entities invoved in Rendering|RenderEntities]]

+ * see also the [[Entities invoved in Rendering|RenderEntities]]
+
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
<<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">>
+
+
{{red{killme}}}
+
some aspects of Cinelerra-3 design
Draft
+
+
{{red{killme}}}
+
/***
 
@@ -2111,6 +2221,26 @@ if (oldText.indexOf("SplashScreen")==-1)
 }
 //}}}
+
+
An Object representing a //Render Process// and containing associated state information.
+* it is created in the Controller subsystem while initiating the BuildProcess
+* it is passed on to the generated Render Engine, which in turn passes it down to the individual Processors
+* moreover, it contains methods to communicate with other state relevant parts of the system, thereby shielding the rendering code from any complexities of Thread communication if necessary. (thus the name Proxy)
+
+
+
+
This design lays great emphasis on separating all those components and subsystems, which are considered not to have a //natural link// of their underlying concepts. This often means putting some additional constraints on the implementation, so basically we need to rely on the actual implementation to live up to this goal. In many cases it may seem to be more natural to "just access the necessary information". But on the long run this coupling of not-directly related components makes the whole codebase monolithic and introduces lots of //accidental complexity.//
+
+Instead, we should try to just connect the various subsystems via Interfaces and &mdash; instead of just using some information, rather use some service to be located on an Interface to query other components for this information. The best aproach of course is allway to avoid the dependency alltogether.
+
+!Examples
+* There is a separation between the __high level [[EDL]] view__ and the [[Fixture]]: the latter only accesses the MObjects and the Placement Interfaces.
+* same holds true for the Builder: it just uses the same Interfaces. The actual coupling is done rather //by type//, i.e. the Builder relies on several types of MObjects to exist and treats them via overloaded methods. He doesn't rely on a actual object structure layout in the EDL besides the requirement of having a [[Playlist]]
+* the Builder itself is a separation layer. Neither do the Objects in the EDL access directly [[Render Nodes|ProcNode]], nor do the latter call back into the EDL. Both connections seem to be necessary at first sight, but both can be avoided by using the Builder Pattern
+* another separation exists between the Render Engine and the individual Nodes: The Render Engine doesn't need to now the details of the data types processed by the Nodes, it relies on the Builder having done the correct connections and just pulles out the calculated results. If there needs to be additional controll information to be passed, then I would prefere to do a direct wiring of separate control connections to specializied components, which in turn could instruct the controller to change the rendering process.
+* 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 */
@@ -3178,6 +3308,18 @@ Portions written by Luke Blanshard are hereby released into the public domain.
 <!--}}}-->
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
+
+
{{red{killme}}}
+
/***
 ''TextAreaPlugin for TiddlyWiki version 2.0''
@@ -3305,13 +3447,16 @@ function addKeyDownHandlers(e)
 }
 //}}}
-
+
+
http://tiddlywiki.com/
+
+
The Intention of this text is to help you understanding the design and to show some notable details.
 
 !!!!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]].<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 ExplicitePlacements 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 __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 __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
@@ -3330,13 +3475,14 @@ This design strives to build each level and subsystem around some central concep
 * 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 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 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.
 
 !!!!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.
 
 !!!!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).
+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). +