diff --git a/doc/devel/uml/class128005.html b/doc/devel/uml/class128005.html index 524fbb0ac..06db277ae 100644 --- a/doc/devel/uml/class128005.html +++ b/doc/devel/uml/class128005.html @@ -20,7 +20,7 @@
Relation edls (<directional aggregation by value>)

Declaration :

Relation theFixture (<unidirectional association>)

Declaration :

-
Relation ports (<directional aggregation>)

Declaration :

the global ports (busses) of the session

+
Relation pipes (<directional aggregation>)

Declaration :

the global ports (busses) of the session

All public operations : currEDL , getFixture

diff --git a/doc/devel/uml/class130053.html b/doc/devel/uml/class130053.html index a7a18ffb9..d7b63f4a7 100644 --- a/doc/devel/uml/class130053.html +++ b/doc/devel/uml/class130053.html @@ -17,7 +17,7 @@

Declaration :

Directly inherited by : Plug

-
+

Artifact : wish

All public operations : get_repr

diff --git a/doc/devel/uml/class130181.html b/doc/devel/uml/class130181.html index 1d050e694..5fed79b9b 100644 --- a/doc/devel/uml/class130181.html +++ b/doc/devel/uml/class130181.html @@ -16,7 +16,7 @@ -

Declaration :

+

Declaration :

Artifact : constraint

All public operations : get_repr

diff --git a/doc/devel/uml/class136965.html b/doc/devel/uml/class136965.html index a7c9937ee..b705413c0 100644 --- a/doc/devel/uml/class136965.html +++ b/doc/devel/uml/class136965.html @@ -16,7 +16,7 @@ -

Declaration :

Directly inherited by : Port ProcPatt Track

+

Declaration :

Directly inherited by : Pipe ProcPatt Track

key abstraction: structural asset

Artifact : struct

All public operations : enable , getDependant , getParents , isActive

diff --git a/doc/devel/uml/class138117.html b/doc/devel/uml/class138117.html index a635bbfb4..a0c0efcf7 100644 --- a/doc/devel/uml/class138117.html +++ b/doc/devel/uml/class138117.html @@ -4,19 +4,19 @@ -Class Port +Class Pipe -
Class Port
+
Class Pipe

-

Declaration :

structural asset corresponding to some port for building a processing chain and generating media output

Artifact : outport

+

Declaration :

  • C++ : class Pipe : public Struct

structural asset representing a basic building block within the high level model: a port for building a processing chain and generating media output

Artifact : pipe

Relation wiringTemplate (<unidirectional association>)

Declaration :

  • Uml : # wiringTemplate : ProcPatt, multiplicity : 0..1
  • C++ : protected: ProcPatt* wiringTemplate

All public operations : enable , getDependant , getParents , isActive

diff --git a/doc/devel/uml/class140421.html b/doc/devel/uml/class140421.html index 9fefd2ebb..0d3267c6e 100644 --- a/doc/devel/uml/class140421.html +++ b/doc/devel/uml/class140421.html @@ -16,9 +16,9 @@ -

Declaration :

  • C++ : class Plug : public Wish
+

Declaration :

  • C++ : class Plug : public Wish

Artifact : plug

-
Relation outPort (<unidirectional association>)

Declaration :

  • Uml : # outPort : Port
  • C++ : protected: Port* outPort

the Port this MObject wants to be conected to

+
Relation outPort (<unidirectional association>)

Declaration :

  • Uml : # outPort : Pipe
  • C++ : protected: Pipe* outPort

the Port this MObject wants to be conected to

All public operations : get_repr

diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 861c332cc..48c1ea2d6 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -91,10 +91,10 @@ ParameterDescriptor and access object for a plugin parameter. Parameters may be provided with values from the session, and this values may be automated. ParamProviderinterfaceA facility to get the actual value of a plugin/effect parameter PathManagerWhile building a render engine, this Strategy class decides on the actual render strategy in accordance to the current controller settings (system state) +Pipestructural asset representing a basic building block within the high level model: a port for building a processing chain and generating media output Placementinterfaceused to specify the position of a MObject in the EDL. This can be done in various ways (absolute, relative).
Placement at the same time acts as (refcounting) smart pointer for accessing the MObject. Plug PluginAdapterAdapter used to integrage an effects processor in the render pipeline -Portstructural asset corresponding to some port for building a processing chain and generating media output Prefetch Previewalternative version of the media data, probably with lower resolution Prockey abstraction: data processing asset diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 9b03604d3..41655bf32 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -92,10 +92,10 @@ Parameter
ParamProvider
PathManager
+Pipe
Placement
Plug
PluginAdapter
-Port
Prefetch
Preview
Proc
diff --git a/doc/devel/uml/fig128133.png b/doc/devel/uml/fig128133.png index 8b525effd..089545c76 100644 Binary files a/doc/devel/uml/fig128133.png and b/doc/devel/uml/fig128133.png differ diff --git a/doc/devel/uml/fig128389.png b/doc/devel/uml/fig128389.png index 36521dc8a..c6a57b857 100644 Binary files a/doc/devel/uml/fig128389.png and b/doc/devel/uml/fig128389.png differ diff --git a/doc/devel/uml/fig129285.png b/doc/devel/uml/fig129285.png index 20e099fca..d8f8bec2e 100644 Binary files a/doc/devel/uml/fig129285.png and b/doc/devel/uml/fig129285.png differ diff --git a/doc/devel/uml/fig130309.png b/doc/devel/uml/fig130309.png index b485d3dcc..d2e8f3f81 100644 Binary files a/doc/devel/uml/fig130309.png and b/doc/devel/uml/fig130309.png differ diff --git a/doc/devel/uml/fig131205.png b/doc/devel/uml/fig131205.png index 91a2d89e2..f80a5c619 100644 Binary files a/doc/devel/uml/fig131205.png and b/doc/devel/uml/fig131205.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index e623f8fd7..3853e7c4f 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -112,7 +112,7 @@ Documentation
Artifact Cinelerra3

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, vrender, mobject, source, frame, placement, sessionimpl, builderfacade

+

executable associated with : main, conmanager, clip, meta, fixedlocation, relativelocation, vrender, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, exitnode, pathmanager, track, paramprovider, mask

Artifact main

Artifact source

@@ -261,9 +261,9 @@ Documentation

description of some media data decoder or encoder facility

Artifact source associated with : Codec

-
Artifact outport
+
Artifact pipe

structural asset corresponding to some port generating media output

-

Artifact source associated with : Port

+

Artifact source associated with : Pipe

Artifact track

structural asset holding the configuration of a track in the EDL

@@ -361,7 +361,7 @@ Documentation

Artifact source associated with : Segment

Artifact track
-

descriptor for one track in the Session

+

A grouping device within the EDL. The corresponding Placement
by which this Track object is refered defines fallback placing
properties to be used by all objects placed on this track in
case they don't specify more concrete placements.
Typically, tracks are used do make default Port connections,
define a layer or pan for sound and for for disabling groups
of clips. Note tracks are grouped in a tree like fashion.

Artifact source associated with : Track

Artifact abstractmo
@@ -402,6 +402,18 @@ Documentation
Artifact allocation

Artifact source associated with : Allocation

+ +
Artifact constraint
+

LocatingPin representing an directive by the user that
must not be violated

+

Artifact source associated with : Constraint

+ +
Artifact wish
+

LocatingPin representing a low-priority directive by the user,
to be fulfilled only if possible (and after satisfying the
more important LocatingPins)

+

Artifact source associated with : Wish

+ +
Artifact plug
+

LocatingPin for requesting connection to some Port

+

Artifact source associated with : Plug

Artifact label

Artifact source associated with : Label

@@ -612,7 +624,7 @@ Documentation
Class Effect
Class Codec
Class Track
-
Class Port
+
Class Pipe
Class ProcPatt
Class Dataset
Class DB
@@ -653,11 +665,11 @@ Documentation
Class Auto
Class Wish
Class Constraint
+
Class Plug
Class Parameter
Class ParamProvider
Class Interpolator
Class LocatingPin
-
Class Plug

2.2.2 Package Builder

diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index c41be7ee3..dfc4fc2d8 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -29,38 +29,38 @@ checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging Cinelerra3artifactthe main executable to be built cinelerra3package -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance +class instanceclass instance class instanceclass instance class instanceclass instance class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance class instanceclass instance class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance class instanceclass instance -class instanceclass instance -class instanceclass instance class instanceclass instance class instanceclass instance +class instanceclass instance +class instanceclass instance clearoperationclear current session contents
without resetting overall session config.
Afterwards, the session will contain only one
empty EDL, while all Assets are retained.
Clipclassbookkeeping (asset) view of a media clip. -clipartifactbookkeeping (asset) view of a media clip. clipartifacta Media Clip +clipartifactbookkeeping (asset) view of a media clip. Clipclass clipsrelation Codecclassdescription of some media data decoder or encoder facility @@ -87,6 +87,7 @@ conmanagerartifactmanages the creation of additional ProcNode connections for the Renderengine ConManagercomponent connectopaque activity action +constraintartifactLocatingPin representing an directive by the user that
must not be violated Constraintclass Controllercomponent Controllerpackage diff --git a/doc/devel/uml/index_68.html b/doc/devel/uml/index_68.html index 8f898d37f..68da1dfbd 100644 --- a/doc/devel/uml/index_68.html +++ b/doc/devel/uml/index_68.html @@ -28,8 +28,8 @@ designpackage designpackageAll things concering the big picture.
Not a real code package, rather a container for design drafts, specifications, decisions. detect Channelsuse case -determine Render Paramsexpansion region determine Render Paramsopaque activity action +determine Render Paramsexpansion region devnullclass instance Dispatchercomponent dispatchOpoperation diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index caf706b98..6ba353281 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -18,14 +18,14 @@ - + - + diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index b36d60aff..23907ab84 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -33,8 +33,8 @@ - + diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 798945020..93008767f 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -20,8 +20,8 @@ - + diff --git a/doc/devel/uml/index_79.html b/doc/devel/uml/index_79.html index 13aab1740..5446e9730 100644 --- a/doc/devel/uml/index_79.html +++ b/doc/devel/uml/index_79.html @@ -22,7 +22,6 @@ - diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index 9258e1132..2b01f816d 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -25,18 +25,20 @@ + + + + - - diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index 847236104..df33c880e 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -31,8 +31,8 @@ - + @@ -46,8 +46,8 @@ - + diff --git a/doc/devel/uml/index_84.html b/doc/devel/uml/index_84.html index b2f672c79..738749c2a 100644 --- a/doc/devel/uml/index_84.html +++ b/doc/devel/uml/index_84.html @@ -35,20 +35,20 @@ - + - - - - - + + + + +
NameKindDescription
edlartifactthe (high level) Edit Decision List within the current Session
EDLcomponent
EDLclass
EDLcomponent
EDL Example1object diagramA simple example showing how the actual objects are placed in the Fixture (=definitive playlist). It shows a Video and Audio clip placed on two tracks
EDL Example2object diagramMore complex example showing the Object graph in the EDL and how it is linked into the Fixture to yield the actual locations. In this example, an HUE Effect is applied on a part of the Clip
edlsrelation
EffectclassEffect or media processing component
effectartifactEffect or media processing component
effectartifactEDL representation of a pluggable and automatable effect.
effectartifactEffect or media processing component
Effectclass
elementsrelationrelevant MObjects comprising this segment. TODO: actually necessary??
enableoperationchange the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well
FixedLocationclass
Fixtureactivity object
fixtureartifactthe (low level) representation of the EDL with concrete placement data
Fixtureclass
Fixturecomponent
Fixtureclass
fork activity nodefork activity node
FrameclassFrames are just a low level lump of continous memory, most parts are opaque. Frames are memory sensitive, they will be small constant sized structures which can be efficently managed in a pool.
Framenode
idattributeAsset primary key.
In Memory Databaseclass diagram
inFixtureactivity action pin
inputclass instance
inputclass instance
inputclass instance
inputclass instance
instanceoperation
instructionsrelation
ouputclass instance
ouputclass instance
ouputclass instance
outportartifactstructural asset corresponding to some port generating media output
outPortrelationthe Port this MObject wants to be conected to
outputrelation
Overviewcomponent diagramThis drawing shows the top level compoents and relations
paramsrelation
PathManagerclassWhile building a render engine, this Strategy class decides on the actual render strategy in accordance to the current controller settings (system state)
pathmanagerartifactManager for deciding the actual render strategy
Pipeclassstructural asset representing a basic building block within the high level model: a port for building a processing chain and generating media output
pipeartifactstructural asset corresponding to some port generating media output
pipesrelationthe global ports (busses) of the session
placementartifactKey Abstraction: a way to place and locate a Media Object
Placementclassused to specify the position of a MObject in the EDL. This can be done in various ways (absolute, relative).
Placement at the same time acts as (refcounting) smart pointer for accessing the MObject.
playoperationTODO: will probably be handled differently (see Cehteh)
playlistnode
plugartifactLocatingPin for requesting connection to some Port
Plugclass
plugIDattributeIdentifier of the Plugin to be used
PluginAdapterclassAdapter used to integrage an effects processor in the render pipeline
pluginadapterartifactAdapter for integrating various Effect processors in the render pipeline
pnodenode
pointattributeidentifying the point where the nodes should be attached
Portclassstructural asset corresponding to some port for building a processing chain and generating media output
portsrelationthe global ports (busses) of the session
Posix Threads Abstractionclass viewC++ wrapers for pthreads
Prefetchclass
Previewclassalternative version of the media data, probably with lower resolution
Service Componentsclass view
Sessioncomponent
sessionartifactInterface: the session edited by the user
Sessionclass view
sessionpackagesourcecode package

Everything concerning the EDL and Session, within the MObject Subsystem
Sessionclass view
SessionclassPrimary Interface for all editing tasks.
The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered.
Session structureclass diagram
sessionimplartifactholds the complete session data to be edited by the user
SimpleClipclassElementary clip consisting of only one media stream
SmartPointerclass
SmartPointersclass view
sourcerelationthe media source this clip referes to
sourcerelationmedia source of this clip
sourcerelationthe media source this clip referes to
SourceclassSource Node: represents a media source to pull data from.
sourceartifactRepresentation of a Media source
Source Overviewdeployment diagram
trackattribute
trackrelation
trackartifactstructural asset holding the configuration of a track in the EDL
trackartifactdescriptor for one track in the Session
trackartifactA grouping device within the EDL. The corresponding Placement
by which this Track object is refered defines fallback placing
properties to be used by all objects placed on this track in
case they don't specify more concrete placements.
Typically, tracks are used do make default Port connections,
define a layer or pan for sound and for for disabling groups
of clips. Note tracks are grouped in a tree like fashion.
Trackclass
tracksrelationelementary media assets comprising this compound
Trafoclass
trafoartifacttransforming processing Node
treatoperation
treatoperationThis operation is to be overloaded for the specific MObject subclasses to be treated.
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
treatoperation
diff --git a/doc/devel/uml/index_86.html b/doc/devel/uml/index_86.html index 74937c93e..2429dd829 100644 --- a/doc/devel/uml/index_86.html +++ b/doc/devel/uml/index_86.html @@ -22,21 +22,21 @@ vframeartifacta buffer and render process holding a Video frame vid1class instance vid1class instance -vid_aclass instance vid_Aclass instance -vid_Aclass instance -vid_aclass instance +vid_aclass instance vid_Aclass instance +vid_aclass instance +vid_Aclass instance videoclass instance +videoclass instance videoclass instance videoclass instance -videoclass instance -video1class instance -video1class instance -video1class instance -video1class instance video1class instance +video1class instance video1class instance +video1class instance +video1class instance +video1class instance Visitableclass visitorpackagesub-namespace for visitor library implementation visitorartifactAcyclic Visitor library diff --git a/doc/devel/uml/index_87.html b/doc/devel/uml/index_87.html index 54f6d4f8c..748f57b37 100644 --- a/doc/devel/uml/index_87.html +++ b/doc/devel/uml/index_87.html @@ -20,6 +20,7 @@ whatoperation whatoperationthe base class of all exceptions thrown by the standard library wiringTemplaterelation +wishartifactLocatingPin representing a low-priority directive by the user,
to be fulfilled only if possible (and after satisfying the
more important LocatingPins) Wishclass write_bufferrelation WriteBufferclass diff --git a/uml/cinelerra3/128133 b/uml/cinelerra3/128133 index cb48c458d..fe9ce6164 100644 --- a/uml/cinelerra3/128133 +++ b/uml/cinelerra3/128133 @@ -1,6 +1,6 @@ format 40 "Asset" // ProcessingLayer::Asset - revision 17 + revision 18 modified_by 5 "hiv" // class settings //class diagram settings @@ -686,7 +686,7 @@ ${inlines} end end - class 138117 "Port" + class 138117 "Pipe" visibility package cpp_decl "${comment}${template}class ${name}${inherit} { @@ -697,7 +697,7 @@ ${inlines} idl_decl "" explicit_switch_type "" - comment "structural asset corresponding to some port for building a processing chain and generating media output" + comment "structural asset representing a basic building block within the high level model: a port for building a processing chain and generating media output" classrelation 141445 // relation 139653 ---|> a public diff --git a/uml/cinelerra3/128133.diagram b/uml/cinelerra3/128133.diagram index 0aa4daeb2..466c2ad1d 100644 --- a/uml/cinelerra3/128133.diagram +++ b/uml/cinelerra3/128133.diagram @@ -106,7 +106,7 @@ classcanvas 141317 class_ref 139909 // LocatingPin 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 518 239 2000 end -classcanvas 146053 class_ref 138117 // Port +classcanvas 146053 class_ref 138117 // Pipe 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 344 597 2004 end @@ -114,8 +114,8 @@ classcanvas 146437 class_ref 140421 // Plug 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 560 597 2000 end -textcanvas 146821 "global Port Asset" - xyzwh 299 569 2000 90 23 +textcanvas 146821 "global processing Pipe Asset" + xyzwh 271 568 2000 149 24 relationcanvas 128389 relation_ref 128005 // from ref 128005 z 1999 to ref 128133 role_a_pos 200 676 3000 no_role_b @@ -271,7 +271,7 @@ relationcanvas 145925 relation_ref 145413 // relationcanvas 146181 relation_ref 145541 // from ref 128005 z 1999 to point 311 616 line 146309 z 1999 stereotype "<>" xyz 103 649 3000 to ref 146053 - role_a_pos 308 594 3000 no_role_b + role_a_pos 307 594 3000 no_role_b multiplicity_a_pos 329 627 3000 no_multiplicity_b relationcanvas 146565 relation_ref 145669 // from ref 146437 z 1999 to ref 137221 diff --git a/uml/cinelerra3/128261 b/uml/cinelerra3/128261 index aea54b2f1..c30e7ce9e 100644 --- a/uml/cinelerra3/128261 +++ b/uml/cinelerra3/128261 @@ -1,6 +1,6 @@ format 40 "MObject" // ProcessingLayer::MObject - revision 28 + revision 29 modified_by 5 "hiv" // class settings //class diagram settings @@ -145,15 +145,15 @@ ${inlines} b multiplicity "" parent class_ref 139653 // Session end - classrelation 147717 // ports () + classrelation 147717 // pipes () relation 145541 o--> stereotype "vector" - a role_name "ports" multiplicity "*" protected + a role_name "pipes" multiplicity "*" protected comment "the global ports (busses) of the session" cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; " - classrelation_ref 147717 // ports () - b multiplicity "" parent class_ref 138117 // Port + classrelation_ref 147717 // pipes () + b multiplicity "" parent class_ref 138117 // Pipe end end @@ -1020,7 +1020,7 @@ ${inlines} cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; " classrelation_ref 147973 // outPort () - b multiplicity "" parent class_ref 138117 // Port + b multiplicity "" parent class_ref 138117 // Pipe end end diff --git a/uml/cinelerra3/128389 b/uml/cinelerra3/128389 index 35d64e6bd..52c1b5245 100644 --- a/uml/cinelerra3/128389 +++ b/uml/cinelerra3/128389 @@ -1,6 +1,6 @@ format 40 "RenderEngine" // ProcessingLayer::RenderEngine - revision 12 + revision 13 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/128389.diagram b/uml/cinelerra3/128389.diagram index b031adc09..5a6ad5049 100644 --- a/uml/cinelerra3/128389.diagram +++ b/uml/cinelerra3/128389.diagram @@ -84,6 +84,8 @@ classcanvas 139781 class_ref 135045 // CodecAdapter 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 599 621 2000 end +textcanvas 140037 "the »low level model«" + xyzwh 600 318 2000 105 18 relationcanvas 128261 relation_ref 131845 // from ref 128005 z 1999 stereotype "<>" xyz 178 278 3000 to point 216 200 line 137733 z 1999 to ref 128133 diff --git a/uml/cinelerra3/129285 b/uml/cinelerra3/129285 index 55db3685a..17a54b8b9 100644 --- a/uml/cinelerra3/129285 +++ b/uml/cinelerra3/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 11 + revision 12 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/130053 b/uml/cinelerra3/130053 index 73baabcbc..9e872a275 100644 --- a/uml/cinelerra3/130053 +++ b/uml/cinelerra3/130053 @@ -1,6 +1,6 @@ format 40 "asset" // design::codegen::proc::asset - revision 7 + revision 8 modified_by 5 "hiv" // class settings //class diagram settings @@ -508,7 +508,7 @@ ${namespace_end}" comment "description of some media data decoder or encoder facility" end - artifact 137605 "outport" + artifact 137605 "pipe" stereotype "source" cpp_h "/* ${NAME}.hpp - ${description} @@ -542,7 +542,7 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 138117 // OutPort + class_ref 138117 // Pipe end comment "structural asset corresponding to some port generating media output" end diff --git a/uml/cinelerra3/130309.diagram b/uml/cinelerra3/130309.diagram index 7de6c806f..9a3886bc4 100644 --- a/uml/cinelerra3/130309.diagram +++ b/uml/cinelerra3/130309.diagram @@ -55,7 +55,7 @@ classcanvas 132485 class_ref 137989 // Track 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 614 445 2000 end -classcanvas 132613 class_ref 138117 // Port +classcanvas 132613 class_ref 138117 // Pipe 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 682 445 2000 end diff --git a/uml/cinelerra3/131205.diagram b/uml/cinelerra3/131205.diagram index 6b22db552..822bc1982 100644 --- a/uml/cinelerra3/131205.diagram +++ b/uml/cinelerra3/131205.diagram @@ -15,7 +15,7 @@ classcanvas 128389 class_ref 138757 // ProcPatt 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 408 249 2000 end -classcanvas 128517 class_ref 138117 // Port +classcanvas 128517 class_ref 138117 // Pipe 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 240 168 2000 end diff --git a/uml/cinelerra3/5.session b/uml/cinelerra3/5.session index d8ab0b626..af98eb2ed 100644 --- a/uml/cinelerra3/5.session +++ b/uml/cinelerra3/5.session @@ -3,9 +3,9 @@ diagrams classdiagram_ref 130309 // Asset Kinds 860 633 100 4 158 0 classdiagram_ref 128133 // Session structure - 860 633 100 4 462 0 + 860 633 100 4 289 0 classdiagram_ref 128389 // Render Entities - 743 538 100 4 0 0 + 743 538 100 4 184 0 active classdiagram_ref 131205 // Struct-Asset Relations 555 620 100 4 0 0 end @@ -13,12 +13,10 @@ show_stereotypes selected package_ref 129 // cinelerra3 open - - package_ref 128005 // design + deploymentview_ref 128645 // gen class_ref 137477 // Unknown class_ref 137605 // Preview class_ref 137989 // Track - class_ref 138117 // Port class_ref 128005 // SessionImpl class_ref 128133 // EDL class_ref 128261 // Fixture diff --git a/uml/cinelerra3/cinelerra3.prj b/uml/cinelerra3/cinelerra3.prj index f342468f2..9873f26df 100644 --- a/uml/cinelerra3/cinelerra3.prj +++ b/uml/cinelerra3/cinelerra3.prj @@ -1,6 +1,6 @@ format 40 "cinelerra3" - revision 41 + revision 42 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/renderengine.html b/wiki/renderengine.html index ded8d9eb3..5bc243c00 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -536,7 +536,7 @@ Some software component able to work on media data in the Cinelerra Render engin &rarr; ProcAsset {{red{to be defined}}} !Structural Asset -Some of the building blocks providing the framework for the objects placed into the current Session. Notable examples are Input/Output channels (Ports), Viewer attachment points, Tracks, etc. +Some of the building blocks providing the framework for the objects placed into the current Session. Notable examples are [[processing pipes|Pipe]] within the high-level-model, Viewer attachment points, Tracks, etc. * __outward interface operations__ include... * __inward interface operations__ include... &rarr; StructAsset {{red{to be defined}}} @@ -565,7 +565,7 @@ For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from 
The Asset Manager provides an Interface to some internal Database holding all Assets in the current Session and System state. It may be a real Database at some point (and for the moment it's a Hashtable). Each [[Asset]] is registered automatically with the Asset Manager; it can be queried either by it's //identification tuple// or by it's unique ID.
-
Placing an MObject relatively to another object such that it should be handled as //attached // to the latter results in several implementation problems. The typical use case is that of an effect attached to a clip or port.
+
Placing an MObject relatively to another object such that it should be handled as //attached // to the latter results in several implementation problems. The typical use case is that of an effect attached to a clip or processing pipe.
 * this attachment is not a globally fixed relation, rather, it typically exists only for some limited time span (e.g. the duration of the basic clip the effect is attached to)
 * the order of attachment is important and the attached placement may create a fork in the signal flow, so we need a way for specifying reproducibly how the resulting wiring should be
 * when building, we access the information in reversed direction: we have the target object and need to query for all attachements
@@ -579,7 +579,7 @@ The first step towards an solution is to isolate the problem; obviously we //nee
-
Starting out from the concepts of Objects, Placement to Tracks, Ports and connection properties (&rarr; see [[here|TrackPortEDL]]) within the EDL, we can identify the elementary operations occuring within the Builder. Overall, the Builder is organized as application of //visiting tools// to a collection of objects, so finally we have to consider some object kind appearing in the working function of the given builder tool, which holds at this moment some //context//. The job now is to organize this context such as to create a predictable build process from this //event driven// approach.
+
Starting out from the concepts of Objects, Placement to Tracks, render Pipes and connection properties (&rarr; see [[here|TrackPipeEDL]]) within the EDL, we can identify the elementary operations occuring within the Builder. Overall, the Builder is organized as application of //visiting tools// to a collection of objects, so finally we have to consider some object kind appearing in the working function of the given builder tool, which holds at this moment some //context//. The job now is to organize this context such as to create a predictable build process from this //event driven// approach.
 
 !Builder working Situations
 # any ''Clip'' (which at this point has been reduced already to a part of a simple elementary media stream &rarr; see [[Fixture]])
@@ -589,31 +589,31 @@ The first step towards an solution is to isolate the problem; obviously we //nee
 ##* effectively this is an application of effects
 ## at this point we have to process (and maybe generate on-the-fly) the [[source port of this clip|ClipSourcePort]]
 ##* the output of the source reading and preprocessing defined thus far is delivered as input to this port, which is done by a ~WiringRequest (see below)
-##* as every port, the source port has a processing pattern, normally inserting the camera (transformation effect) at this point
+##* as every port, it is the entry point to a [[processing pipe|Pipe], thus the source port has a processing pattern, typically inserting the camera (transformation effect) at this point
 ## followed by the application of effects
 ##* separately for every effect chain rooted (placed) directly onto the clip
 ##* and regarding the chaining order
-## next we have to assess the [[ports|Port]] to which the clip has been placed
-## producing a [[wiring request|WiringRequest]] for every pair {{{(chainEndpoint, port)}}}
-# [>img[draw/Proc.builder1.png]]   attaching an ''Effect'' is actually always an //insertion operation// which is done by //prepending// to the previously built nodes. Effects may be placed as attached to clips and ports, which causes them to be included in the processing chain at the given location. Effects may as well be placed at an absolute time, which means they are to be applied to every clip that happens to be at this time &mdash; but this usecase will be reolved when creating the Fixture, causing the effect to be attached to the clips in question. The same holds true for Effects put on tracks.
+## next we have to assess the [[pipes|Pipe]] to which the clip has been placed
+## producing a [[wiring request|WiringRequest]] for every pair {{{(chainEndpoint, pipe)}}}
+# [>img[draw/Proc.builder1.png]]   attaching an ''Effect'' is actually always an //insertion operation// which is done by //prepending// to the previously built nodes. Effects may be placed as attached to clips and pipes, which causes them to be included in the processing chain at the given location. Effects may as well be placed at an absolute time, which means they are to be applied to every clip that happens to be at this time &mdash; but this usecase will be reolved when creating the Fixture, causing the effect to be attached to the clips in question. The same holds true for Effects put on tracks.
 # treating an ''wiring request'' means
 ## detecting possible and impossible connections
 ## deriving additional possible "placement dimensions" generated by executing such an connection (e.g. connecting a mono source to a spatial sound system bus creates panning possibilities)
 ##* deriving parameter sources for this additional degrees of freedom
 ##* fire off insertion of the necessary effects to satisfy this connection request and implement the additional "placement dimensions" (pan, layer order, overlay mode, MIDI channel selection...)
-# processing effects and further placements ''attached to a Port'' behaves identical to the processing done with all attachments to individual clips.
+# processing the effects and further placements ''attached to a Pipe'' is handled identical to the processing done with all attachments to individual clips.
 # ''Transitions'' are to be handled differently according to their placement (&rarr; more on [[Transitions|TransitionsHandling]])
 #* when placed normally to two (or N) clips, they are inserted at the exit node of the clip's complete effect chain.
-#* otherwise, when placed to the source port(s) or when placed to some other ports they are inserted at the exit side of those ports effect chains. (Note: this puts additional requirements on the transition processor, so not every transition can be placed this way)
+#* otherwise, when placed to the source port(s) or when placed to some other pipes they are inserted at the exit side of those pipe's effect chains. (Note: this puts additional requirements on the transition processor, so not every transition can be placed this way)
 After consuming all input objects and satisfying all wiring requests, the result is a set of [[exit nodes|ExitNode]] ready for pulling data. We call the network reachable from such an exit node a [[Processor]], together all processors of all segments and output data types comprise the render engine.
 
 !!!dependencies
-Ports need to be there first, as everything else will be placed to a port at some point. The same holds true for tracks. But, on the other hand, both are optional. We can have ~EDLs with ~MObjects without configuring ports (but won't be able to build any render processor of course). And we could have an EDL without any track, if we place every ~MObject within this EDL directly to some port.
+Pipes need to be there first, as everything else will be plugged (placed) to a pipe at some point. The same holds true for tracks. But, on the other hand, both are optional. We can have ~EDLs with ~MObjects without configuring pipes (but won't be able to build any render processor of course). And we could have an EDL without any track, if we place every ~MObject within this EDL directly to some pipe.
 
-Effects can be attached only to already existing pipelines, starting out at some port or clip. Besides that, all further parts can be built in any order and independent of each other. This is made possible by using [[wiring requests|WiringRequest]], which can be resolved later on. So, as long as we start out with the tracks (to resolve any port they are placed to), and further, if we manage to get any effect placed to some clip-MO //after// setting up and treating the clip, we are fine and can do the building quasi event driven.
+Effects can be attached only to already existing pipelines, starting out at some pipes entry port or the source port of some clip. Besides that, all further parts can be built in any order and independent of each other. This is made possible by using [[wiring requests|WiringRequest]], which can be resolved later on. So, as long as we start out with the tracks (to resolve any pipe they are placed to), and further, if we manage to get any effect placed to some clip-MO //after// setting up and treating the clip, we are fine and can do the building quasi event driven.
 
 !!!building and resolving
-Building the network for the individual objects thus creates a queue of wiring requests. Some of them may be immediately resolvable, but detecting this correctly can be nontrivial, and so it seems better to group all wiring requests based on the port and treat them groupwise. Because &mdash; in the most general case &mdash; connecting includes the use of transforming and joining nodes, which can create additional wiring requests (e.g. for automation parameter data connections). Finally, if the network is complete, we could perform [[optimisations|RenderNetworkOptimisation]]
+Building the network for the individual objects thus creates a queue of wiring requests. Some of them may be immediately resolvable, but detecting this correctly can be nontrivial, and so it seems better to group all wiring requests based on the pipe and treat them groupwise. Because &mdash; in the most general case &mdash; connecting includes the use of transforming and joining nodes, which can create additional wiring requests (e.g. for automation parameter data connections). Finally, if the network is complete, we could perform [[optimisations|RenderNetworkOptimisation]]
@@ -756,7 +756,7 @@ As the builder has to create a render node network implementing most of the feat * the [[Proc-Layer-Controller|Controller]] initiates the BuildProcess and does the overall coordination of scheduling edit operations, rebuilding the fixture and triggering the Builder * to carry out the building, we use several tools (SegmentationTool, NodeCreaterTool,...), which are supplied by the [[tool factory|BuilderToolFactory]] * the actual building (i.e. the application of those tools to the timeline) is done by the [[Assembler|BuilderAssembler]], which is basically a collection of functions (but has a small amount of global configuration state) -* any non-trivial wiring of render nodes, tracks, ports and automation is done by the services of the [[connection manager|ConManager]] +* any non-trivial wiring of render nodes, tracks, pipes and automation is done by the services of the [[connection manager|ConManager]]
@@ -793,16 +793,16 @@ TertiaryDark: #667 Error: #f88
-
Configuration Queries are requests to the system to "create or retrieve an object with //this and that // capabilities". They are resolved by a rule based system ({{red{planned feature}}}) and the user can extend the used rules for each Session. Syntactically, they are stated in ''prolog'' syntax as a conjunction (=logical and) of ''predicates'', for example {{{stream(mpeg), port(myPort)}}}. Queries are typed to the kind of expected result object: {{{Query<Port> ("stream(mpeg)")}}} requests a port excepting/delivering mpeg stream data &mdash; and it depends on the current configuration what "mpeg" means. If there is any stream data producing component in the system, which advertises to deliver {{{stream(mpeg)}}}, and a port can be configured or connected with this component, then the [[defaults manager|DefaultsManagement]] will create/deliver a [[Port|PortHandling]] object configured accordingly.
+
Configuration Queries are requests to the system to "create or retrieve an object with //this and that // capabilities". They are resolved by a rule based system ({{red{planned feature}}}) and the user can extend the used rules for each Session. Syntactically, they are stated in ''prolog'' syntax as a conjunction (=logical and) of ''predicates'', for example {{{stream(mpeg), pipe(myPipe)}}}. Queries are typed to the kind of expected result object: {{{Query<Pipe> ("stream(mpeg)")}}} requests a pipe excepting/delivering mpeg stream data &mdash; and it depends on the current configuration what "mpeg" means. If there is any stream data producing component in the system, which advertises to deliver {{{stream(mpeg)}}}, and a pipe can be configured or connected with this component, then the [[defaults manager|DefaultsManagement]] will create/deliver a [[Pipe|PipeHandling]] object configured accordingly.
 &rarr; [[Configuration Rules system|ConfigRules]]
-
+
Many features can be implemented by specifically configuring and wiring some unspecific components. Rather than tie the client code in need of some given feature to these configuration internals, in Cinelerra-3 the client can //query // for some kind of object providing the //needed capabilities. // Right from start (summer 2007), Ichthyo had the intention to implement such a feature using sort of a ''declarative database'', e.g. by embedding a Prolog system. By adding rules to the basic session configuration, users should be able to customize the semi-automatic part of Cinelerra's behaviour to great extent.
 
 [[Configuration Queries|ConfigQuery]] are used at various places, when creating and adding new objects, as well when building or optimizing the render engine node network.
-* Creating a [[port|PortHandling]] queries for a default port or a port with a certain stream type
-* Adding a new [[track|TrackHandling]] queries for some default placement configuration, e.g. the port.
+* Creating a [[pipe|PipeHandling]] queries for a default pipe or a pipe with a certain stream type
+* Adding a new [[track|TrackHandling]] queries for some default placement configuration, e.g. the pipe it will be plugged to.
 * when processing a [[wiring request|WiringRequest]], connection possibilities have to be evaluated.
 * actually building such a connection may create additional degrees of freedom, like panning for sound or layering for video.
 
@@ -816,6 +816,8 @@ Actually posing such an configuration query, for example to the [[Defaults Manag
 !Implementation
 At start and for debugging/testing, there is an ''dummy'' implementation using a map with predefined queries and answers. But for the real system, the idea is to embed a ''YAP Prolog'' engine to run the queries. This includes the task of defining and loading a set of custom predicates, so the rule system can interact with the object oriented execution environment, for example by transforming some capability predicate into virtual calls to a corresponding object interface. We need a way for objects to declare some capability predicates, together with a functor that can be executed on an object instance (and further parameters) in the cause of the evaluation of some configuration query. Type safety and diagnostics play an important role here, because effectively the rule base is a pool of code open for arbitray additions from the user session.
 &rarr; [[considerations for a Prolog based implementation|QueryImplProlog]]
+&rarr; see {{{src/common/query/mockconfigrules.cpp}}} for the table with the hard wired (mock) answers
+
@@ -833,12 +835,12 @@ This is an very important external Interface, because it links together all thre * completely hide the Session object behind a ''~PImpl'' smart pointer, so the session object can be switched when reloading. * the [[Fixture]] acts as isolation layer, and all objects refered from the Fixture are refcounting smart pointers. So, even when the session gets switched, the old objects remain valid as long as needed.
-
-
RenderEngine
+

+
[[ProcLayer and Engine]]
 

 

 

-
For several components and properties there is an implicit default value or configuration; it is stored alongside with the session. The intention is that defaults never create an error, instead, they are to be extended silently on demand. Objects configured according to this defaults can be retrieved at the [[Session]] interface by a set of overloaded functions {{{Session::current->default(Query<TYPE> ("query string"))}}}, where the //query string // defines a capability query similar to what is employed for ports, stream types, codecs etc. The Queries are implemented by [[configuration rules|ConfigRules]]
+
For several components and properties there is an implicit default value or configuration; it is stored alongside with the session. The intention is that defaults never create an error, instead, they are to be extended silently on demand. Objects configured according to this defaults can be retrieved at the [[Session]] interface by a set of overloaded functions {{{Session::current->default(Query<TYPE> ("query string"))}}}, where the //query string // defines a capability query similar to what is employed for pipes, stream types, codecs etc. The Queries are implemented by [[configuration rules|ConfigRules]]
 

 

 

@@ -846,13 +848,13 @@ This is an very important external Interface, because it links together all thre
 
 ''Everything is an object'' &mdash; of course, that's a //no-brainer // todays. Rather, important is what is not "an object", meaning it can't be arranged arbitrarily
 * we have one and only one global [[Session]] which directly contains a collection of multiple [[EDLs|EDL]] and is associated with a globally managed collection of [[assets|Asset]] (no, we don't have scoped variables here; if e.g. a media has been "opened", it is just plain globally known as asset.)
-* we have some global [[ports|Port]], which are treated in a unique manner and don't behave like other objects (e.g. effects)
+* we have some global [[pipes|Pipe]], which are treated in a unique manner and don't behave like other objects (e.g. effects)
 * we have a [[Fixture]] which acts as isolation layer towards the render engine and is (re)built automatically.
 
-We ''separate'' processing (rendering) and configuration (building). We have a [[Builder]] which creates a network of [[render nodes|ProcNode]], to be processed by //pulling data // from some [[Port]]
+We ''separate'' processing (rendering) and configuration (building). We have a [[Builder]] which creates a network of [[render nodes|ProcNode]], to be processed by //pulling data // from some [[Pipe]]
 
 ''Objects are [[placed|Placement]] rather'' than assembled, connected, wired, attached. This is more of a rule-based approach and gives us one central metaphor and abstraction, allowing us to treat everything in an uniform manner. You can place it as you like, and the builder tries to make sense out of it, silently disabling what doesn't make sense.
-An [[EDL]] is just a collection of configured and placed objects (and has no additional, fixed structure). [[Tracks|Track]] form a mere organisational grid, they are grouping devices not first-class entities (a track doesn't "have" a port or "is" a video track and the like; it can be configured to behave in such manner by using placements though). [[Ports|Port]] are hooks for making connections and are the only facility to build processing chains. We have global ports, and each clip is built around a lokal [[source port|ClipSourcePort]] &mdash; and that's all. No special "media viewer" and "arranger", no special role for media sources, no commitment to some fixed media stream types (video and audio). All of this is sort of pushed down to be configuration, represented as asset of some kind. For example, we have [[processing pattern|ProcPatt]] assets to represent the way of building the source network for reading from some media file (including codecs treated like effect plugin nodes)
+An [[EDL]] is just a collection of configured and placed objects (and has no additional, fixed structure). [[Tracks|Track]] form a mere organisational grid, they are grouping devices not first-class entities (a track doesn't "have" a pipe or "is" a video track and the like; it can be configured to behave in such manner by using placements though). [[Pipes|Pipe]] are hooks for making connections and are the only facility to build processing chains. We have global pipes, and each clip is built around a lokal [[source port|ClipSourcePort]] &mdash; and that's all. No special "media viewer" and "arranger", no special role for media sources, no commitment to some fixed media stream types (video and audio). All of this is sort of pushed down to be configuration, represented as asset of some kind. For example, we have [[processing pattern|ProcPatt]] assets to represent the way of building the source network for reading from some media file (including codecs treated like effect plugin nodes)
 
 ''State'' is rigorously ''externalized'' and operations are to be ''scheduled'', to simplify locking and error handling. State is either treated similar to media stream data (as addressable and cacheable data frame), or is represented as "parameter" to be served by some [[parameter provider|ParamProvider]]. Automation is just another kind of parameter, i.e. a function, and how this function is calculated is an encapsulated implementation detail (we don't have "bezier automation", and then maybe a "linear automation", a "mask automation" and yet another way to handle transitions)
@@ -890,7 +892,7 @@ In this usage, the EDL in most cases will be almost synonymous to the [[Session| The EDL within the Session is just a //logical grouping//, allowing for lots of flexibility. Actually, we can have several ~EDLs within one Session, and these ~EDLs can be linked together or not, they may be in sequence or may constitue a logical grouping of clips used simultanously in compositional work etc. Multiple ~EDLs can use the same or different tracks, and tracks as well are only an organisational (grouping) device. But at any time, we have exactly one [[Fixture]], derived automatically from all ~EDLs and containing the content actually to be rendered. -&rarr; see considerations about [[the role of Tracks and Ports in conjunction with the EDL|TrackPortEDL]] +&rarr; see considerations about [[the role of Tracks and Pipes in conjunction with the EDL|TrackPipeEDL]]
@@ -957,7 +959,7 @@ To make the intended use of the classes more clear, consider the following two e 
A special kind (subclass) of [[Placement]]. As such it is always linked to a //Subject//, i.e. a MObject. In addition to the properties of a (unspecific) Placement, the ExplicitPlacement specifies a absolute time and track position for locating the Subject
-
+
We use Factories
 * for centralizing [[memory management|MemoryManagement]]
 * to support polymorphism (of course...)
@@ -1109,7 +1111,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
 &rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
-
+
This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Cinelerra Renderengine, the Builder and the related parts.
 
 * [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@@ -1121,9 +1123,9 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
 * [[Handling of the current Session|CurrentSession]]
 * [[collecting Ideas for Implementation Guidelines|ImplementationGuidelines]]
 * [[using the Visitor pattern?|VisitorUse]] &mdash; resulting in [[»Visiting-Tool« library implementation|VisitingToolImpl]]
-* [[Handling of Tracks and Ports in the EDL|TrackPortEDL]]. [[Handling of Tracks|TrackHandling]] and [[Ports|PortHandling]]
+* [[Handling of Tracks and render Pipes in the EDL|TrackPipeEDL]]. [[Handling of Tracks|TrackHandling]] and [[Pipes|PipeHandling]]
 * [[getting default configured|DefaultsManagement]] Objects relying on [[rule-based Configuration Queries|ConfigRules]]
-* [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreaterTool]]
+* [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreatorTool]]
 * [[how to handle »attached placement«|AttachedPlacementProblem]]
@@ -1524,9 +1526,9 @@ This Design strives to achieve a StrongSeparation between the low-level Structur [img[Classess related to the EDL|uml/fig128133.png]]
-
+
''[[Cinelerra3|index.html]]''
-[[RenderEngine]]
+[[Proc-Layer|ProcLayer and Engine]]
 [[MObjects]]
 [[Implementation|ImplementationDetails]]
 [[Admin]]
@@ -1630,7 +1632,7 @@ So, when creating a clip out of such a compound media asset, the clip has to be
 |viewing media|asset::Clip, session::Clip and Placement (on hold)| for the whole Media, if not already existent|
 |mark selection as clip|asset::Clip, session::Clip, Placement with unspec. LocatingPin| doesn't add to EDL|
 |loading Plugin|asset::Effect| usually at program startup|
-|create Session|asset::Track, asset::OutPort| |
+|create Session|asset::Track, asset::Pipe| |
 &rarr; [[Creating and registering Assets|AssetCreation]]
 
 !![[MObjects|MObject]]
@@ -2260,7 +2262,7 @@ afterwards.
 
 !!!prerequisites
 * Session and ~EDLs exist.
-* Ports exist and are configured
+* Pipes exist and are configured
 
 !!!postconditions
 * the Fixture contains one sorted timeline of ExplicitPlacement instances
@@ -2268,7 +2270,7 @@ afterwards.
 * {{red{TODO: how to store and group the effects?}}}
 * any meta-clips or other funny things have been resolved to normal clips with placement
 * any multichannel clips has been broken down to elementary clips {{red{TODO: what is "elementary". e.g. stereo sound streams?}}}
-* any globally or otherwise strangely placed effects have been attached either to a clip or to some port
+* any globally or otherwise strangely placed effects have been attached either to a clip or to some pipe
 * we have one unified list of tracks
 
 <<tasksum start>>
@@ -2281,7 +2283,7 @@ afterwards.
 <<task>>what data collections to build?
 
 !!treating a Track
-<<task>>work out how to refer to ports and do other config
+<<task>>work out how to refer to pipes and do other config
 <<task>>get some uniqe identifier and get relevant properties
 
 !!treating a {{{Placement<Clip>}}}
@@ -2298,24 +2300,24 @@ afterwards.
 <<tasksum end>>
-
+
//This page is a scrapbook for working out the implementation of the builder//
 
 * NodeCreaterTool is a [[visiting tool|VisitorUse]]
 * the render engine to be built is contained as state within this tool object while it is passed around
 !!!prerequisites
 * Session and ~EDLs exist.
-* Ports exist and are configured
+* Pipes exist and are configured
 * Fixture contains ExplicitPlacement for every MObject to be rendered, and nothing else
 
 <<tasksum start>>
 <<taskadder>>
 
 !!preparing
-We need a way of addressing existing [[ports|Port]]. Besides, as the Ports and Tracks are referred by the Placements we are processing, they are guaranteed to exist.
+We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes and Tracks are referred by the Placements we are processing, they are guaranteed to exist.
 
-!!treating a Port
-<<task>>get the [[processing pattern|ProcPatt]] of the port by accessing the underlying port asset.
+!!treating a Pipe
+<<task>>get the [[processing pattern|ProcPatt]] of the pipe by accessing the underlying pipe asset.
 <<task>>process this ProcPatt recursively
 
 !!treating a processing pattern
@@ -2326,19 +2328,19 @@ We need a way of addressing existing [[ports|Port]]. Besides, as the Ports and T
 <<task>>process the ProcPatt recursively
 <<task>>access the ClipSourcePort (which may be created on-the-fly)
 <<task>>enqueue an WiringRequest for connecting the source pipeline to the source port
-<<task>>process the source port recursively (thus adding the camera etc.)
-<<task>>enqueue an WiringRequest for any placement to some port for this clip.
+<<task>>process the clip's render pipe recursively (thus adding the camera etc.)
+<<task>>enqueue an WiringRequest for any placement to some pipe for this clip.
 * __note__: we suppose
 ** all wiring requests will be done after the processing of entities
 ** all effects placed to this clip will be processed after this clip (but before the wiring requests)
 
 !!treating an {{{Placement<Effect>}}}
-<<task>>{{red{how to assure that effecs are processed after clips/ports??}}}
+<<task>>{{red{how to assure that effecs are processed after clips/pipes??}}}
 <<task>>find out the application point
 <<task>>build a transforming node for the effect and insert it there
 
 !!postprocessing
-<<task>>sort and group the assembled list of [[wiring requests|WiringRequest]] by ports
+<<task>>sort and group the assembled list of [[wiring requests|WiringRequest]] by pipes
 
 <<tasksum end>>
@@ -2349,31 +2351,32 @@ We need a way of addressing existing [[ports|Port]]. Besides, as the Ports and T //Note, we have yet to specify how exactly the building and rendering will work together with the backend. There are several possibilities how to structure the Playlist//
-
-
Ports 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 port. Ports are special facilities, rather like inventory, separate and not treated like all the other objects.
-We don't distinguish between "input" and "output" ports &mdash; rather, ports are thought to be ''hooks for making connections to''. By following this line of thought, each port has an input side and an output side and is in itself something like a ''Bus'' or the starting point for building a ''processing chain''. Other processing entities like effects and transitions can be placed (attached) at the port, resulting them to be appended to form this chain. Likewise, we can place [[wiring requests|WiringRequest]] to the port, meaning we want it connected to another destination port. The [[Builder]] may generate further wiring requests to fulfil the placement of other entities.
-Thus Ports are the basic building blocks of the whole render network. We distinguish ''global available'' Ports, which are like the sum groups of a mixing console, and the ''lokal port'' or [[source port|ClipSourcePort]] of the individual clips, which exist only within the duration of the corresponding clip. The design //limits the possible kinds of ports // to these two types &mdash; thus we can build local processing chains at clips and global processing chains at the global ports of the session and that's all we can do. (because of the flexibility which comes with the concept of [[placements|Placement]], this is no real limitation)
+

+
+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 "input" and "output" ports &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.
+Thus //Pipes are the basic building blocks// of the whole render network. We distinguish ''global available'' Pipes, which are like the sum groups of a mixing console, and the ''lokal pipe'' or [[source port|ClipSourcePort]] of the individual clips, which exist only within the duration of the corresponding clip. The design //limits the possible kinds of pipes // to these two types &mdash; thus we can build local processing chains at clips and global processing chains at the global pipes of the session and that's all we can do. (because of the flexibility which comes with the concept of [[placements|Placement]], this is no real limitation)
 
-The GUI can connect the viewer(s) to some port (and moreover can use [[probe points|ProbePoint]] placed like effects and connected to some port), and likewise, when starting a ''render'', we get the opportunity to specify the ports to pull the data from. Pulling data from some port is the (only) way to activate the render nodes network reachable from this port.
+The GUI can connect the viewer(s) to some pipe (and moreover can use [[probe points|ProbePoint]] placed like effects and connected to some pipe), and likewise, when starting a ''render'', we get the opportunity to specify the pipes to pull the data from. Pulling data from some pipe is the (only) way to activate the render nodes network reachable from this pipe.
 
 &rarr; [[Handling of Tracks|TrackHandling]]
-&rarr; [[Handling of Ports|PortHandling]]
+&rarr; [[Handling of Pipes|PipeHandling]]
 
 

 

-

+

 
!Identification
-Ports are distinct objects and can be identified by their asset ~IDs. Besides, as for all [[structural assets|StructAsset]] there are extended query capabilities, including a symbolic port-id and a media (stream) type id. Any port can accept and deliver exactly one media stream kind (which may be inherently structured though, e.g. spatial sound systems or stereoscopic video)
+Pipes are distinct objects and can be identified by their asset ~IDs. Besides, as for all [[structural assets|StructAsset]] there are extended query capabilities, including a symbolic pipe-id and a media (stream) type id. Any pipe can accept and deliver exactly one media stream kind (which may be inherently structured though, e.g. spatial sound systems or stereoscopic video)
 
-!creating ports
-Port assets are created automatically by being used and referred. The [[Session]] holds a collection of global ports, and further ports can be created by using an new port reference in some placement. Moreover, every clip has an (implicit) [[source port|ClipSourcePort]], which will appear as port asset when first used (referred) while [[building|BuildProcess]].
+!creating pipes
+Pipe assets are created automatically by being used and referred. The [[Session]] holds a collection of global pipes, and further pipes can be created by using an new pipe reference in some placement. Moreover, every clip has an (implicit) [[source port|ClipSourcePort]], which will appear as pipe asset when first used (referred) while [[building|BuildProcess]].
 
 !removal
-Deleting a Port is an advanced operation, because it includes finding and "detaching" all references, otherwise the port will leap back into existence immediately. Thus, global port entries in the Session and port references in [[locating pins|LocatingPin]] within any placement have to be removed, while clips using a given source port will be disabled. {{red{todo: implementation deferred}}}
+Deleting a Pipe is an advanced operation, because it includes finding and "detaching" all references, otherwise the pipe will leap back into existence immediately. Thus, global pipe entries in the Session and pipe references in [[locating pins|LocatingPin]] within any placement have to be removed, while clips using a given source port will be disabled. {{red{todo: implementation deferred}}}
 
-!using Ports
-there is not much you can do directly with a port asset. It is an point of reference, after all. Any connection to some port is only temporarily done by a placement in some part of the timeline, so it isn't stored with the port. You can edit the (user visible) description an you can globally disable a port asset. The port's ID and media stream type of course are fixed, because any connection and referral (via the asset ID) is based on them. Later on, we should provide a {{{rewire(oldPort, newPort)}}} to search any ref to the {{{oldPort}}} and try to rewrite it to use the {{{newPort}}}, possibly with a new media stream type.
-Ports are integrated with the [[management of defaults|DefaultsManagement]]. For example, any port uses implicitly some [[processing pattern|ProcPatt]] &mdash; it may default to the empty pattern. This feature enables to apply some standard wiring to the ports (e.g a fader for audio, similar to the classic mixing consoles). This //is // a global property of the port, but &mdash; contrary to the stream type &mdash; this pattern may be switched
+!using Pipes
+there is not much you can do directly with a pipe asset. It is an point of reference, after all. Any connection to some pipe is only temporarily done by a placement in some part of the timeline, so it isn't stored with the pipe. You can edit the (user visible) description an you can globally disable a pipe asset. The pipe's ID and media stream type of course are fixed, because any connection and referral (via the asset ID) is based on them. Later on, we should provide a {{{rewire(oldPipe, newPipe)}}} to search any ref to the {{{oldPipe}}} and try to rewrite it to use the {{{newPipe}}}, possibly with a new media stream type.
+Pipes are integrated with the [[management of defaults|DefaultsManagement]]. For example, any pipe uses implicitly some [[processing pattern|ProcPatt]] &mdash; it may default to the empty pattern. This feature enables to apply some standard wiring to the pipes (e.g a fader for audio, similar to the classic mixing consoles). This //is // a global property of the pipe, but &mdash; contrary to the stream type &mdash; this pattern may be switched
 

 

 

@@ -2403,7 +2406,7 @@ Users accustomed with modern GUI applications typically expect that //everything
 !!Compound and Multiplicity
 Simple relations can be hard wired. But, on the contrary, it would be as naive to define a Clip as having a Video track and two audio tracks, as it would be naive to overlook the problem of holding video and corresponding audio together. And, moreover, the default case has to be processed in a //straight forward// fashion, with as few tests and decisions as possible. So, basically each component participating in getting the core processing done has to mirror the structure pattern of the other parts, so that  processing can be done without testing and forking. But this leaves us with the problem where to put the initial knowledge about the structural pattern used for building up the compound structures and &mdash; especially &mdash; the problem how to treat different kinds of structural patterns, how to detect the pattern to be applied and how to treat multiple instances of the same structural pattern.
 
-One example of this problem is the [[handling of multichannel media|MultichannelMedia]]. Following the above reasoning, we end with having a [["structural processing pattern"|ProcPatt]], typically one video stream with MPEG decoder and a pair of audio streams which need either to be routed to some "left" and "right" output ports, or have to be passed through a panning filter accordingly. Now the problem is: //create a new instance of this structure for each new media, or detect which media to subsume under a existing pattern instance.//
+One example of this problem is the [[handling of multichannel media|MultichannelMedia]]. Following the above reasoning, we end with having a [["structural processing pattern"|ProcPatt]], typically one video stream with MPEG decoder and a pair of audio streams which need either to be routed to some "left" and "right" output pipes, or have to be passed through a panning filter accordingly. Now the problem is: //create a new instance of this structure for each new media, or detect which media to subsume under a existing pattern instance.//
 
 !!Parallelism
 We need to work out guidelines for dealing with operations going on simultaneously. Certainly, this will divide the application in several different regions. As always, the primary goal is to avoid multithread problems altogether. Typically, this can be achieved by making matters explicit: externalizing state, make the processing subsystems stateless, queue and schedule tasks, use isolation layers.
@@ -2412,10 +2415,34 @@ We need to work out guidelines for dealing with operations going on simultaneous
 * all EditingOperations are not threadsafe intentionally, because they are [[scheduled|ProcLayerScheduler]]
-
+
+
The current Cinelerra-3 architecture separates functionality into three Layers: __GUI__, __Proc__ and __Backend__.
+
+While the Backend is responsible for Data access and management and for carrying out the computation intensive media opteratons, the middle Layer or ~Proc-Layer contains [[assets|Asset]] and [[Session]], i.e. the user-visible data model and provides configuration and behaviour for these entities. Besides, he is responsible for [[building and configuring|Builder]] the [[render engine|RenderEngine]] based on the current Session state.
+
+
+
All Assets of kind asset::Proc represent //processing algorithms// in the bookkeeping view. They enable loading, browsing and maybe even parametrizing all the Effects, Plugins and Codecs available for use within the Cinelerra Session.
+
+Besides, they provide an important __inward interface__ for the [[ProcNode]]s, which will use these asset entries to dispatch the actual processing call when rendering. 
+
+{{red{todo: the naming scheme??}}}
+
+[img[Asset Classess|uml/fig131077.png]]
+
+
+
+
The middle Layer of our current Architecture plan, i.e. the layer managing all processing and manipulation, while the actual data handling is done in the backend and the user interaction belongs to the GUI Layer.
+
+&rarr; see the [[Overview]]
+
+
+
+
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 [[the aspect of objects placed into the EDL|MObjects]] as well.
 <<<
-''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a //first, draft, prototypical// implementation in C++
+''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a implementing the foundations and main structures in C++
+* basic AssetManager working
+* currently impmenenting the Builder (&rarr;[[more|PlanningNodeCreatorTool]])
 <<<
 
 !Summary
@@ -2434,23 +2461,6 @@ The system is ''open'' inasmuch every part mirrors the structure of correspondin
 &rarr; how [[Automation]] works  {{red{to be defined in more detail}}}
 &rarr; [[Problems|ProblemsTodo]] to be solved and notable [[design decisions|DesignDecisions]]
 &rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
-
-
-
-
All Assets of kind asset::Proc represent //processing algorithms// in the bookkeeping view. They enable loading, browsing and maybe even parametrizing all the Effects, Plugins and Codecs available for use within the Cinelerra Session.
-
-Besides, they provide an important __inward interface__ for the [[ProcNode]]s, which will use these asset entries to dispatch the actual processing call when rendering. 
-
-{{red{todo: the naming scheme??}}}
-
-[img[Asset Classess|uml/fig131077.png]]
-
-
-
-
The middle Layer of our current Architecture plan, i.e. the layer managing all processing and manipulation, while the actual data handling is done in the backend and the user interaction belongs to the GUI Layer.
-
-&rarr; see the [[Overview]]
-
@@ -2479,21 +2489,21 @@ Like all [[structural assets|StructAsset]], ~ProcPatt employs a special naming s The intention is to get much more readable ("declarative") and changeable configuration as by programming it directly within the implementation of some object. !Draft -As an example, specifying how a Track can be configured for connecting automatically to some "mpeg" bus (=port) +As an example, specifying how a Track can be configured for connecting automatically to some "mpeg" bus (=pipe) {{{ retrieve(O, Cap) :- find(O), capabilities(Cap). retrieve(O, Cap) :- make(O), capabilities(Cap). capabilities(Q) :- call(Q). -stream(T, mpeg) :- type(T, track), type(P, port), retrieve(P, stream(P,mpeg)), place_to(P, T). +stream(T, mpeg) :- type(T, track), type(P, pipe), retrieve(P, stream(P,mpeg)), place_to(P, T). }}} -Then, running the goal {{{:-retrieve(T, stream(T,mpeg)).}}} would search a Track object, try to retrieve a port object with stream-type=mpeg and associate the track with this Port. This relies on a predicate "stream(P,mpeg)" implemented (natively) for the port object. So, "Cap" is the query issued from calling code &mdash; here {{{stream(T,mpeg)}}}, the type guard {{{type(T, track)}}} will probably be handled or inserted automatically, while the predicate implementations for find/1, make/1, stream/2, and place_to/2 are to be provided by the target types. -* __The supporting system__ had to combine several code snippets into one rule system to be used for running queries, with some global base rules, rules injected by each individual participating object kind and finally user provided rules added by the current session. The actual query is bound to "Cap" (and consequently run as a goal by {{{call(Q)}}}). The implementation needs to provide a symbol table associating variable terms (like "T" or "P") to C/C++ object types, enabling the participating object kinds to register their specific predicate implementations. This is crucial, because there can be no general scheme of object-provided predicates (for each object kind different predicates make sense, e.g. [[ports|PortHandling]] have other possibilities than [[wiring requests|WiringRequest]]). Basically, a query issues a Prolog goal, which in turn evaluates domain specific predicates provided by the participating objects and thus calls back into C/C++ code. The supporting system maintains the internal connection (via the "type" predicate) such that from Prolog viewpoint it looks as if we were binding Variables directly to object instances. (there are some nasty technical details because of the backtracking nature of Prolog evaluations which need to be hidden away) +Then, running the goal {{{:-retrieve(T, stream(T,mpeg)).}}} would search a Track object, try to retrieve a pipe object with stream-type=mpeg and associate the track with this pipe. This relies on a predicate "stream(P,mpeg)" implemented (natively) for the pipe object. So, "Cap" is the query issued from calling code &mdash; here {{{stream(T,mpeg)}}}, the type guard {{{type(T, track)}}} will probably be handled or inserted automatically, while the predicate implementations for find/1, make/1, stream/2, and place_to/2 are to be provided by the target types. +* __The supporting system__ had to combine several code snippets into one rule system to be used for running queries, with some global base rules, rules injected by each individual participating object kind and finally user provided rules added by the current session. The actual query is bound to "Cap" (and consequently run as a goal by {{{call(Q)}}}). The implementation needs to provide a symbol table associating variable terms (like "T" or "P") to C/C++ object types, enabling the participating object kinds to register their specific predicate implementations. This is crucial, because there can be no general scheme of object-provided predicates (for each object kind different predicates make sense, e.g. [[pipes|PipeHandling]] have other possibilities than [[wiring requests|WiringRequest]]). Basically, a query issues a Prolog goal, which in turn evaluates domain specific predicates provided by the participating objects and thus calls back into C/C++ code. The supporting system maintains the internal connection (via the "type" predicate) such that from Prolog viewpoint it looks as if we were binding Variables directly to object instances. (there are some nasty technical details because of the backtracking nature of Prolog evaluations which need to be hidden away) * Any __participating object kind__ needs a way to declare domain specific predicates, thus triggering the registration of the necessary hooks within the supporting system. Moreover, it should be able to inject further prolog code (as shown in the example above with the {{{strem(T, mpeg)}}} predicate. For each of these new domain specific predicates, there needs to be a functor which can be invoked when the C implementation of the predicate is called from Prolog (in some cases even later, when the final solution is "executed", e.g. a new instance has been created and now some properties need to be set). !!a note on Plugins -In the design of the Cinelerra-3 Proc Layer done thus far, we provide //no possibility to introduce a new object kind// into the system via plugin interface. The system uses a fixed collection of classes intended to cover all needs (Clip, Effect, Track, Port, Label, Automation, ~Macro-Clips). Thus, plugins will only be able to provide new parametrisations of existing classes. This should not be any real limitation, because the whole system is designed to achieve most of its functionality by freely combining rather basic object kinds. As a plus, it plays nicely with any plain-C based plugin interface. For example, we will have C++ adapter classes for the most common sorts of effect plugin (pull system and synchronous frame-by-frame push with buffering) with a thin C adaptation layer for the specific external plugin systems used. Everything beyond this point can be considered "condiguration data" (including the actual plugin implementation to be loaded) +In the design of the Cinelerra-3 Proc Layer done thus far, we provide //no possibility to introduce a new object kind// into the system via plugin interface. The system uses a fixed collection of classes intended to cover all needs (Clip, Effect, Track, Pipe, Label, Automation, ~Macro-Clips). Thus, plugins will only be able to provide new parametrisations of existing classes. This should not be any real limitation, because the whole system is designed to achieve most of its functionality by freely combining rather basic object kinds. As a plus, it plays nicely with any plain-C based plugin interface. For example, we will have C++ adapter classes for the most common sorts of effect plugin (pull system and synchronous frame-by-frame push with buffering) with a thin C adaptation layer for the specific external plugin systems used. Everything beyond this point can be considered "condiguration data" (including the actual plugin implementation to be loaded)
@@ -2726,6 +2736,11 @@ The link between ~MObject and Asset should be {{{const}}}, so the clip can't cha At first sight the link between asset and clip-MO is a simple logical relation between entities, but it is not strictly 1:1 because typical media are [[multichannel|MultichannelMedia]]. Even if the media is compound, there is //only one asset::Clip//, because in the logical view we have only one "clip-thing". On the other hand, in the Session/EDL, we have a compound clip ~MObject comprised of several elementary clip objects, each of which will refer to its own sub-media (channel) within the compound media (and don't forget, this structure can be tree-like) {{red{open question:}}} do the clip-MO's of the individual channels refer directly to asset::Media? does this mean the relation is different from the top level, where we have a relation to a asset::Clip??
+
+
Conceptually, the Render Engine is the core of the application. But &mdash; surprisingly &mdash; we don't even have a distinct »~RenderEngine« component in our design. Rather, the engine is formed by the cooperation of several components spread over two layers (Backend and Proc-Layer): The [[Builder]] creates a network of [[render nodes|ProcNode]], which is used by the Backend to pull individual Frames.
+&rarr; OverviewRenderEngine
+
+
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.
 
@@ -2745,7 +2760,7 @@ At first sight the link between asset and clip-MO is a simple logical relation b
 The Session object is a singleton &mdash; actually it is a »~PImpl«-Facade object (because the actual implementation object can be swapped for (re)loading Sessions).<br/>The Session is comprised of
 * a collection of ''EDL'' objects
 * a ''current EDL'', which can be switched and accessed {{red{TODO not sure if I keep this design...}}}
-* a collection of ''global Ports''
+* a collection of ''global Pipes''
 * the ''Fixture'' with a possibility to [[(re)build it|PlanningBuildFixture]]
@@ -2758,14 +2773,15 @@ For larger editing projects the simple structure of a session containing "t With all the structural complexities possible within such a session, we need an isolation layer to provide __one__ definitive state where all configuration has been made explicit. Thus the session manages one special object list, the [[Fixture]], which can be seen as all currently active objects placed onto a single timeline. !!!organisational devices -The possibility of having multiple ~EDLs helps organizing larger projects. Each [[EDL]] is just a logical grouping; because all effective properties of any MObject within this EDL are defined by the ~MObject itself and the [[Placement]], by which the object is anchored to some time point, some track, can be connected to some port, or linked to another object. In a similar manner, Tracks are just another organisational aid for grouping objects, disabling them and defining common output ports. +The possibility of having multiple ~EDLs helps organizing larger projects. Each [[EDL]] is just a logical grouping; because all effective properties of any MObject within this EDL are defined by the ~MObject itself and the [[Placement]], by which the object is anchored to some time point, some track, can be connected to some pipe, or linked to another object. In a similar manner, Tracks are just another organisational aid for grouping objects, disabling them and defining common output pipes. -!!!global ports -Any session should contain a number of global [[(destination) ports|Port]], typically video out and audio out. The goal is, to get any content producing or transforming object in some way connected to one of these outputs, either //by [[placing|Placement]] it directly// to some port, or by //placing it to a track// and having the track refer to some port. Besides the global destination ports, we can use internal ports to form busses or subgroups, either on a global (session) level, or attached to individual tracks. Normally, ports just gather and mix data, but of course any port can have an attached effect chain. (&rarr; see [[more on Tracks and Ports within the EDL|TrackPortEDL]]) +!!!global pipes +Any session should contain a number of global [[(destination) pipes|Pipe]], typically video out and audio out. The goal is, to get any content producing or transforming object in some way connected to one of these outputs, either //by [[placing|Placement]] it directly// to some pipe, or by //placing it to a track// and having the track refer to some pipe. Besides the global destination pipes, we can use internal pipes to form busses or subgroups, either on a global (session) level, or by using the processing pipe within a [[virtual clip|VirtualClip]], which can be placed freely within the ~EDLs. Normally, pipes just gather and mix data, but of course any pipe can have an attached effect chain. (&rarr; see [[more on Tracks and Pipes within the EDL|TrackPipeEDL]]) !!!default configuration [>img[draw/Proc.builder1.png]]While all these possibilities may seem daunting, there is a simple default configuration loaded into any pristine new session: -It will contain a global video and audio outport, just one EDL with one track; this track will have a internal video and audio port (bus) configured with one fading device sending to the global output ports. So, by adding some clip with a simple absolute placement to this track and some time position, the clip gets connected and rendered, after [[(re)building|PlanningBuildFixture]] the [[Fixture]] and passing the result to the [[Builder]] &mdash; and using the resulting render nodes network (Render Engine). +It will contain a global video and audio out pipe, just one EDL with one track; this track will have a internal video and audio pipe (bus) configured with one fading device sending to the global output ports. So, by adding some clip with a simple absolute placement to this track and some time position, the clip gets connected and rendered, after [[(re)building|PlanningBuildFixture]] the [[Fixture]] and passing the result to the [[Builder]] &mdash; and using the resulting render nodes network (Render Engine). + 
<<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">>
@@ -2860,14 +2876,14 @@ Instead, we should try to just connect the various subsystems via Interfaces and 
Structural Assets are intended mainly for internal use, but the user should be able to see and query them. They are not "loaded" or "created" direcly, rather they //leap into existance // by creating or extending some other structures in the EDL/Session, hence the name. Some of the structural Asset parametrisation can be modified to control of some aspects of the Proc Layer's (default) behaviour.
 * [[Processing Patterns|ProcPatt]] encode information how to set up some parts of the render network to be created automatically: for example, when building a clip, we use the processing pattern how to decode and preprocess the actual media data.
-* [[Tracks|Track]] are one of the dimensions used for organizing the EDL. They serve as an Anchor to attach parametrisation of output port, overlay mode etc. By [[placing|Placement]] to a track, some media object inherits placement properties from this track.
-* [[Ports|Port]] form &mdash; at least as visible to the user &mdash; the basic building block of the render network, because the latter appears to be a collection of processing pipelines rooted on Ports and interconnected. (this is the //outward view; // in fact the render network consists of [[nodes|ProcNode]] and is [[built|Builder]] from the Ports, clips, effects...)
+* [[Tracks|Track]] are one of the dimensions used for organizing the EDL. They serve as an Anchor to attach parametrisation of output pipe, overlay mode etc. By [[placing|Placement]] to a track, some media object inherits placement properties from this track.
+* [[Pipes|Pipe]] form &mdash; at least as visible to the user &mdash; the basic building block of the render network, because the latter appears to be a collection of interconnected processing pipelines. (this is the //outward view; // in fact the render network consists of [[nodes|ProcNode]] and is [[built|Builder]] from the Pipes, clips, effects...)
 [>img[Asset Classess|uml/fig131205.png]]
 !naming scheme
 The Asset name field of structural Assets utilizes a special naming scheme, which allows to derive the name based on the capabilities of the structural asset. For example, by default all media clips with a given media stream type (e.g. H264) will use the same [[processing Pattern|ProcPatt]] for rendering. {{red{todo: work out the details of this naming scheme??}}}
 
 !querying
-Structural assets can be queried by specifying the specific type (Port, Track, ProcPatt) and a query goal, which means in the current implementation just querying for some predicate defined with the structural asset. For example, you can {{{Query<Port> ("stream(mpeg)")}}}, yieliding the first port found which declares to have stream type "mpeg"
+Structural assets can be queried by specifying the specific type (Pipe, Track, ProcPatt) and a query goal, which means in the current implementation just querying for some predicate defined with the structural asset. For example, you can {{{Query<Pipe> ("stream(mpeg)")}}}, yieliding the first pipe found which declares to have stream type "mpeg" 
/*{{{*/
@@ -4038,17 +4054,17 @@ function addKeyDownHandlers(e)
-
Tracks are just a structure used to organize the Media Objects within the EDL. They form a grid, and besides that, they have no special meaning. They are grouping devices, not first-class entities. A track doesn't "have" a port or "is" a video track and the like; it can be configured to behave in such manner by using placements.
+
Tracks are just a structure used to organize the Media Objects within the EDL. They form a grid, and besides that, they have no special meaning. They are grouping devices, not first-class entities. A track doesn't "have" a port or pipe or "is" a video track and the like; it can be configured to behave in such manner by using placements.
 
 Tracks are assets on their own, but they can be found within a given EDL. So, several ~EDLs can share a single track or each EDL can have its own, separate tracks. 
 * Like most ~MObjects, tracks have a asset view: you can find a track asset in the asset manager.
 * and they have an object view: there is an track MObject which can be [[placed|Placement]], thus defining properties of this track within one EDL
-Of course, we can place other ~MObjects relative to some track (that's the main reason why we want to have tracks). In this sense, the [[handling of Tracks|TrackHandling]] is somewhat special: the placement of some track can be found directly within the EDL (and not within the general collection of placed objects which form the contents of any EDL). This placement defines properties of the track, which will be inherited if necessary by all ~MObjects placed to this track. For example, if placing a track to some global [[Port]], and if placing a clip to this track, without placing the clip directly to another port, the port information of the track will be fetched by the builder when needed to make the output connection of the clip.
+Of course, we can place other ~MObjects relative to some track (that's the main reason why we want to have tracks). In this sense, the [[handling of Tracks|TrackHandling]] is somewhat special: the placement of some track can be found directly within the EDL (and not within the general collection of placed objects which form the contents of any EDL). This placement defines properties of the track, which will be inherited if necessary by all ~MObjects placed to this track. For example, if placing (=plugging) a track to some global [[Pipe]], and if placing a clip to this track, without placing the clip directly to another pipe, the associated-to-pipe information of the track will be fetched by the builder when needed to make the output connection of the clip.
 &rarr; [[Handling of Tracks|TrackHandling]]
-&rarr; [[Handling of Ports|PortHandling]]
+&rarr; [[Handling of Pipes|PipeHandling]]
-
+
''towards a definition of »Track«''. We don't want to tie ourself to some naive and overly simplistic definition, just because it is convenient. For classical (analogue) media, tracks are physical entities dictated by the nature of the process by which the media works. Especially, Tape machines have read/writing heads, which creates fixed tracks to which to route the signals. This is a practical geometric necessity. For digital media, there is no such necessity. We are bound primarily by the editor's habits of working.
 
 !!!Assessment of Properties
@@ -4063,17 +4079,17 @@ Starting with the assumption "everything is just connected processing nodes
 
 !!!the constant part
 there seems to be some non time-varying part in each EDL, that doesn't fit well with the simple model "objects on a timeline". Tracks seen as an organisational grid fall into this category: they are a global property of the given EDL. They could be associated to the Session as a whole, but effectively this would subvert the concept of having [[several EDLs|SessionOverview]]. On the other hand, 
-[[ports|Port]] for Video and Sound output are obviously a global property of the Session. There can be several global ports forming a matrix of subgroup busses. We could add ports to tracks by default as well, but we don't do this, because, again, this would run counter to our attempt of treating tracks as merely organisational entities. We have special [[source ports|ClipSourcePort]] on individual clips though, and we will have ports on meta-clips too.
+[[pipes|Pipe]] for Video and Sound output are obviously a global property of the Session. There can be several global pipes forming a matrix of subgroup busses. We could add ports or pipes to tracks by default as well, but we don't do this, because, again, this would run counter to our attempt of treating tracks as merely organisational entities. We have special [[source ports|ClipSourcePort]] on individual clips though, and we will have ports on [[virtual clips|VirtualClip]] too.
 
 !Design
 [[Tracks|Track]] are just a structure used to organize the Media Objects within the EDL. They form a grid, and besides that, they have no special meaning. It seems convenient to make the tracks not just a list, but allow grouping (tree structure) right from start. __~MObjects__ are ''placed'' rather than wired. The wiring is derived from the __Placement__. Placing can happen in several dimensions:
 * placing in time will define when to activate and show the object.
 * placing onto a track associates the ~MObject with this track; the GUI will show it on this track and the track may be used to resolve other properties of the object.
-* placing to a __Port__ brings the object in conjunction with this Port for the build process. It will be considered when building the render network for this port. Source-like objects (clips and exit nodes of effect chains) will be connected to the port, while transforming objects (effects) are inserted at the port. (you may read "placed to port X" as "plug into port X")
-* depending on the nature of the port and the source, placing to some port may create additional degrees of freedom, demanding the object to be placed in this new, additional dimensions: Connecting to video out e.g. creates an overlay mode and a layer position which need to be specified, while connecting to a spatial sound system creates the necessity of a pan position. On the other hand, placing a mono clip onto a mono Port creates no additional degrees of freedom.
-Placements are __resolved__ resulting in an ExplicitPlacement. In most cases this is just a gathering of properties, but as Placements can be incomplete and relative, there is room for real solving. The resolving mechanism tries to __derive missing properties__ from the __context__: When a clip isn't placed to some port but to a Track, than the Track and its parents will be inspected. If some of them has been placed to a port, the object will be connected to this port. Similar for layers and pan position. This is done by [[Placement]] and LocatingPin; as the [[Builder]] uses ~ExplicitPlacements, he isn't concerned with this resolving and uses just the data they deliver to drive the [[basic building operations|BasicBuildingOperations]]
+* placing to a __Pipe__ brings the object in conjunction with this pipe for the build process. It will be considered when building the render network for this pipe. Source-like objects (clips and exit nodes of effect chains) will be connected to the pipe, while transforming objects (effects) are inserted at the pipe. (you may read "placed to pipe X" as "plug into pipe X")
+* depending on the nature of the pipe and the source, placing to some pipe may create additional degrees of freedom, demanding the object to be placed in this new, additional dimensions: Connecting to video out e.g. creates an overlay mode and a layer position which need to be specified, while connecting to a spatial sound system creates the necessity of a pan position. On the other hand, placing a mono clip onto a mono Pipe creates no additional degrees of freedom.
+Placements are __resolved__ resulting in an ExplicitPlacement. In most cases this is just a gathering of properties, but as Placements can be incomplete and relative, there is room for real solving. The resolving mechanism tries to __derive missing properties__ from the __context__: When a clip isn't placed to some pipe but to a Track, than the Track and its parents will be inspected. If some of them has been placed to a pipe, the object will be connected to this pipe. Similar for layers and pan position. This is done by [[Placement]] and LocatingPin; as the [[Builder]] uses ~ExplicitPlacements, he isn't concerned with this resolving and uses just the data they deliver to drive the [[basic building operations|BasicBuildingOperations]]
 &rarr; [[Definition|Track]] and [[handling of Tracks|TrackHandling]]
-&rarr; [[Definition|Port]] and [[handling of Ports|PortHandling]]
+&rarr; [[Definition|Pipe]] and [[handling of Pipes|PipeHandling]]
@@ -4084,14 +4100,14 @@ Placements are __resolved__ resulting in an ExplicitPlacement. In most cases thi * some control data connection to a ParamProvider, because in the most general case the controling curves are treated like automation !!!how much output ports? -The standard case of a transition is sort of mixing together two input streams, like e.g. a simple dissolve. For this to be of any use, this input streams need to be connected to the same ouput port before and after the transition (with regards to the timeline), i.e. the inputs and the transition share placement to the same output destination. In this case, when the transition starts, the direct connections can be suspended and the transition will switch in seamlessly. +The standard case of a transition is sort of mixing together two input streams, like e.g. a simple dissolve. For this to be of any use, this input streams need to be connected to the same ouput destination before and after the transition (with regards to the timeline), i.e. the inputs and the transition share placement to the same output pipe. In this case, when the transition starts, the direct connections can be suspended and the transition will switch in seamlessly. Using transitions is a very basic task and thus needs viable support by the GUI. Handling of transitions need to be very convienient, because it is so important. Because of this, it is compelling to subsume a more complicated situation and treat this more complicated case similar. This is the case, when two (or N) elements have to be combined in the way of a transition, but their further processing in the processing chain //after// the transition needs to be different, maybe they belong to differnent subgroups, have to appear on different layers or with different pan positions. Of courese, the workaround is simple, at least "simple" from the programmers point of view. It is //not// simple from the editor's point of view the moment the editor has to do this simple thing (changing the wiring and add manualy synced fade curves to the individual parts) a dozend or even a hundred times in some larger project. -Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their "simple" counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output ports as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a inconsistently placed transition is just an [[building error|BuildingError]]) +Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their "simple" counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output pipes as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a inconsistently placed transition is just an [[building error|BuildingError]])
-
+
The ''Visitor Pattern'' is a special form of //double dispatch// &mdash; selecting the function actually to be executed at runtime based both on the concrete type of some tool object //and // the target this tool is applied to. The rationale is to separate some specific implementation details from the basic infrastructure and the global interfaces, which can be limited to describe the fundamental properties and operations, while all details relevant only for some specific sub-problem can be kept together encapsulated in a tool implementation class. Typically, there is some iteration mechanism, allowing to apply these tools to all objects in a given container, a collection or object graph, without knowing the exact type of the target and tool objects. See the [[Visitor Pattern design discussion|VisitorUse]]
 
 !Problems with Visitor