diff --git a/doc/devel/uml/class128005.html b/doc/devel/uml/class128005.html index fabe77cf9..524fbb0ac 100644 --- a/doc/devel/uml/class128005.html +++ b/doc/devel/uml/class128005.html @@ -19,7 +19,8 @@

Declaration :

Implementation class for the Session interface

Artifact : sessionimpl, Component(s) : Session

Relation edls (<directional aggregation by value>)

Declaration :

-
Relation fixture (<unidirectional association>)

Declaration :

+
Relation theFixture (<unidirectional association>)

Declaration :

+
Relation ports (<directional aggregation>)

Declaration :

the global ports (busses) of the session

All public operations : currEDL , getFixture

diff --git a/doc/devel/uml/class128133.html b/doc/devel/uml/class128133.html index cbf83e3ea..caa5c3e37 100644 --- a/doc/devel/uml/class128133.html +++ b/doc/devel/uml/class128133.html @@ -18,8 +18,8 @@

Declaration :

Directly inherited by : Fixture

Artifact : edl, Component(s) : Session

- -
Relation tracks (<directional aggregation by value>)

Declaration :

-
Relation clips (<directional aggregation>)

Declaration :

+ +
Relation clips (<directional aggregation>)

Declaration :

+
Relation track (<unidirectional association>)

Declaration :

diff --git a/doc/devel/uml/class128261.html b/doc/devel/uml/class128261.html index 9cb960678..0d8043e71 100644 --- a/doc/devel/uml/class128261.html +++ b/doc/devel/uml/class128261.html @@ -17,11 +17,11 @@

Declaration :

Artifact : fixture, Component(s) : Session

- -
Relation tracks (<directional aggregation by value>)

Declaration :

-
Relation timeline (<directional aggregation by value>)

Declaration :

+ +
Relation theTimeline (<directional aggregation by value>)

Declaration :

Operation getPlaylistForRender

Declaration :

-
Operation getAutomation

Declaration :

+
Operation getAutomation

Declaration :

+
Relation track (<unidirectional association>)

Declaration :

All public operations : getAutomation , getPlaylistForRender

diff --git a/doc/devel/uml/class128389.html b/doc/devel/uml/class128389.html index aeb25e07f..222aa9902 100644 --- a/doc/devel/uml/class128389.html +++ b/doc/devel/uml/class128389.html @@ -16,5 +16,9 @@ -

Declaration :

Artifact : track

+

Declaration :

Artifact : track, Diagram : Session structure

+ +
Relation subTracks (<directional aggregation by value>)

Declaration :

Child tracks in a tree structure

+

All public operations : apply , apply , dispatchOp

+ diff --git a/doc/devel/uml/class129157.html b/doc/devel/uml/class129157.html index fb8effd05..f4d84f14f 100644 --- a/doc/devel/uml/class129157.html +++ b/doc/devel/uml/class129157.html @@ -16,7 +16,7 @@ -

Declaration :

Directly inherited by : Auto Label

+

Declaration :

Directly inherited by : Auto Label Track

Artifact : meta

All public operations : apply , apply , dispatchOp

diff --git a/doc/devel/uml/class130053.html b/doc/devel/uml/class130053.html index 7df85e17a..a7a18ffb9 100644 --- a/doc/devel/uml/class130053.html +++ b/doc/devel/uml/class130053.html @@ -16,7 +16,8 @@ -

Declaration :

+

Declaration :

Directly inherited by : Plug

+

All public operations : get_repr

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

Declaration :

Directly inherited by : OutPort ProcPatt Track

+

Declaration :

Directly inherited by : Port ProcPatt Track

key abstraction: structural asset

Artifact : struct

All public operations : enable , getDependant , getParents , isActive

diff --git a/doc/devel/uml/class137989.html b/doc/devel/uml/class137989.html index 6c5bf6158..5ee601cc6 100644 --- a/doc/devel/uml/class137989.html +++ b/doc/devel/uml/class137989.html @@ -17,8 +17,7 @@

Declaration :

structural asset holding the configuration of a track in the EDL

Artifact : track

- -
Relation wiringTemplate (<unidirectional association>)

Declaration :

+

All public operations : enable , getDependant , getParents , isActive

diff --git a/doc/devel/uml/class138117.html b/doc/devel/uml/class138117.html index 6b36b4366..a635bbfb4 100644 --- a/doc/devel/uml/class138117.html +++ b/doc/devel/uml/class138117.html @@ -4,20 +4,21 @@ -Class OutPort +Class Port -
Class OutPort
+
Class Port

-

Declaration :

structural asset corresponding to some port generating media output

Artifact : outport

-
+

Declaration :

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

Artifact : outport

+ +
Relation wiringTemplate (<unidirectional association>)

Declaration :

All public operations : enable , getDependant , getParents , isActive

diff --git a/doc/devel/uml/class140421.html b/doc/devel/uml/class140421.html new file mode 100644 index 000000000..9fefd2ebb --- /dev/null +++ b/doc/devel/uml/class140421.html @@ -0,0 +1,24 @@ + + + + + + +Class Plug + + + + + +
Class Plug
+

+ + + + +

Declaration :

+ +
Relation outPort (<unidirectional association>)

Declaration :

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 a411e8c2e..861c332cc 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -88,12 +88,13 @@ MObjectinterface MutexI provided a reworked Mutex class in my cinelerra2 repository NodeCreatorToolThis Tool implementation plays the central role in the buld process: given a MObject from Session, it is able to attach ProcNodes to the render engine under construction such as to reflect the properties of the MObject in the actual render. -OutPortstructural asset corresponding to some port generating media output 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) 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 b91453124..9b03604d3 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -89,12 +89,13 @@ MObject
Mutex
NodeCreatorTool
-OutPort
Parameter
ParamProvider
PathManager
Placement
+Plug
PluginAdapter
+Port
Prefetch
Preview
Proc
diff --git a/doc/devel/uml/fig128133.png b/doc/devel/uml/fig128133.png index ccbcf7d90..8b525effd 100644 Binary files a/doc/devel/uml/fig128133.png and b/doc/devel/uml/fig128133.png differ diff --git a/doc/devel/uml/fig130309.png b/doc/devel/uml/fig130309.png index 8e7461c94..b485d3dcc 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 04fc181b7..91a2d89e2 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 888b6b49c..e623f8fd7 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -263,7 +263,7 @@ Documentation
Artifact outport

structural asset corresponding to some port generating media output

-

Artifact source associated with : OutPort

+

Artifact source associated with : Port

Artifact track

structural asset holding the configuration of a track in the EDL

@@ -612,7 +612,7 @@ Documentation
Class Effect
Class Codec
Class Track
-
Class OutPort
+
Class Port
Class ProcPatt
Class Dataset
Class DB
@@ -657,6 +657,7 @@ Documentation
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 269befa2c..c41be7ee3 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -29,33 +29,33 @@ 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 +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. diff --git a/doc/devel/uml/index_68.html b/doc/devel/uml/index_68.html index 68da1dfbd..8f898d37f 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 Paramsopaque activity action determine Render Paramsexpansion region +determine Render Paramsopaque activity action devnullclass instance Dispatchercomponent dispatchOpoperation diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index 20380e20a..caf706b98 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -24,8 +24,8 @@ 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 -effectartifactEDL representation of a pluggable and automatable effect. effectartifactEffect or media processing component +effectartifactEDL representation of a pluggable and automatable effect. 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 diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index 10124ce04..b36d60aff 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -35,7 +35,6 @@ fixtureartifactthe (low level) representation of the EDL with concrete placement data Fixtureclass Fixturecomponent -fixturerelation 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 diff --git a/doc/devel/uml/index_72.html b/doc/devel/uml/index_72.html index 58b669cd2..a26e1439f 100644 --- a/doc/devel/uml/index_72.html +++ b/doc/devel/uml/index_72.html @@ -24,8 +24,8 @@ howtoProcoperation@return descriptor how to build a render pipeline corresponding to this media Hubclass hubartifactspecial ProcNode used to build data distributing connections -HUEclass instance HUEclass instance +HUEclass instance diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 27e37a604..798945020 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -20,9 +20,9 @@ idattributeAsset primary key. In Memory Databaseclass diagram inFixtureactivity action pin -inputclass instance inputclass instance inputclass instance +inputclass instance instanceoperation instructionsrelation Interfaceclass view diff --git a/doc/devel/uml/index_77.html b/doc/devel/uml/index_77.html index 775e82c1e..68bbd5cfb 100644 --- a/doc/devel/uml/index_77.html +++ b/doc/devel/uml/index_77.html @@ -32,8 +32,8 @@ MediaFactoryclassspecialized Asset Factory for configuring (new) media asset instances based on existing media files on disk; can create placeholder assets as well merge activity nodemerge activity node Metaclasskey abstraction: metadata and organisational asset -metaartifactabstract base class of all MObjects representing meta data or processing instructions metaartifactkey abstraction: metadata and organisational asset +metaartifactabstract base class of all MObjects representing meta data or processing instructions Metaclass mobjectartifactKey Abstraction: A Media Object in the Session mobjectpackagesourcecode package

MObject Subsystem
including the Session (EDL), Builder and Processing Controller diff --git a/doc/devel/uml/index_79.html b/doc/devel/uml/index_79.html index 9ba074764..13aab1740 100644 --- a/doc/devel/uml/index_79.html +++ b/doc/devel/uml/index_79.html @@ -19,11 +19,11 @@ NameKindDescription offsetattributeOffset the actual position by this (time) value relative to the anchor point. TODO: Representation? orgattributeorigin or authorship id. Can be a project abbreviation, a package id or just the authors nickname or UID. This allows for the compnent name to be more generic (e.g. "blur"). Default for all assets provided by the core cinelerra-3 codebase is "cin3". -ouputclass instance ouputclass instance ouputclass instance -OutPortclassstructural asset corresponding to some port generating media output +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 Overview Render Enginedeployment diagram diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index 2e0da44b5..9258e1132 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -29,11 +29,14 @@ 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 +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 diff --git a/doc/devel/uml/index_82.html b/doc/devel/uml/index_82.html index a76e8f590..3a3a83808 100644 --- a/doc/devel/uml/index_82.html +++ b/doc/devel/uml/index_82.html @@ -22,8 +22,8 @@ registryrelation@internal Table or DB holding all registered asset instances. relativelocationartifactPlacement implemnetaion providing various ways of attaching a MObject to another one RelativeLocationclass -relTypeattributethe kind of relation denoted by this Placement RelTypeclassthe possible kinds of RelativePlacements +relTypeattributethe kind of relation denoted by this Placement removeoperationremove the given asset <i>together with all its dependants</i> from the internal DB Render Entitiesclass diagram Render Requestactivity parameter diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index eb3719cf0..847236104 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -46,8 +46,8 @@ SimpleClipclassElementary clip consisting of only one media stream SmartPointerclass SmartPointersclass view -sourcerelationmedia source of this clip sourcerelationthe media source this clip referes to +sourcerelationmedia source of this clip SourceclassSource Node: represents a media source to pull data from. sourceartifactRepresentation of a Media source Source Overviewdeployment diagram @@ -64,6 +64,7 @@ Struct-Asset Relationsclass diagram subjectrelationPlacement acts as smart pointer subPatternrelation +subTracksrelationChild tracks in a tree structure diff --git a/doc/devel/uml/index_84.html b/doc/devel/uml/index_84.html index 00c40c769..b2f672c79 100644 --- a/doc/devel/uml/index_84.html +++ b/doc/devel/uml/index_84.html @@ -19,35 +19,36 @@ NameKindDescription the render configuration flowactivity diagram theApp_attributeholds the single instance and triggers initialization +theFixturerelation +theTimelinerelation ThreadclassWe can basically reuse the Thread class design from cinelerra2, Thread becomes a baseclass for all Threads timeattribute timeartifactunified representation of a time point, including conversion functions Timeclassdenotes a temporal position (time point), based on timeline start.

investigate posix.4 realtime timers, wrap these here timelinenode -timelinerelation toolpackagesourcecode package

Tools and Utilities
(separate from the main cinelrra binary) Toolclass ToolFactoryclass toolfactoryartifactsupply of Tool implementations for the Builder Trackclassstructural asset holding the configuration of a track in the EDL +trackrelation trackattribute -trackartifactdescriptor for one track in the Session +trackrelation trackartifactstructural asset holding the configuration of a track in the EDL +trackartifactdescriptor for one track in the Session Trackclass tracksrelationelementary media assets comprising this compound -tracksrelation -tracksrelation 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 diff --git a/doc/devel/uml/index_86.html b/doc/devel/uml/index_86.html index 8695a80a4..74937c93e 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 -videoclass instance +vid_aclass instance +vid_Aclass instance videoclass instance videoclass instance videoclass instance -video1class instance +videoclass 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 cdf4db578..54f6d4f8c 100644 --- a/doc/devel/uml/index_87.html +++ b/doc/devel/uml/index_87.html @@ -19,7 +19,7 @@ NameKindDescription whatoperation whatoperationthe base class of all exceptions thrown by the standard library -wiringTemplaterelation +wiringTemplaterelation Wishclass write_bufferrelation WriteBufferclass diff --git a/doc/devel/uml/public_properties.html b/doc/devel/uml/public_properties.html index 6790afee8..2cf2100de 100644 --- a/doc/devel/uml/public_properties.html +++ b/doc/devel/uml/public_properties.html @@ -24,6 +24,7 @@ nodesDoAttach orgAssetorigin or authorship id. Can be a project abbreviation, a package id or just the authors nickname or UID. This allows for the compnent name to be more generic (e.g. "blur"). Default for all assets provided by the core cinelerra-3 codebase is "cin3". pointDoAttachidentifying the point where the nodes should be attached +subTracksTrackChild tracks in a tree structure versionAssetversion number of the thing or concept represented by this asset. Of each unique tuple (name, category, org) there will be only one version in the whole system. Version 0 is reserved for internal purposes. Versions are considered to be ordered, and any higher version is supposed to be fully backwards compatible to all previous versions. diff --git a/uml/cinelerra3/128133 b/uml/cinelerra3/128133 index aefe38ecb..cb48c458d 100644 --- a/uml/cinelerra3/128133 +++ b/uml/cinelerra3/128133 @@ -1,6 +1,6 @@ format 40 "Asset" // ProcessingLayer::Asset - revision 15 + revision 17 modified_by 5 "hiv" // class settings //class diagram settings @@ -59,7 +59,7 @@ format 40 end classdiagram 131205 "Struct-Asset Relations" - 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 + draw_all_relations no 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 size A4 end @@ -684,18 +684,9 @@ ${inlines} classrelation_ref 141317 // b multiplicity "" parent class_ref 136965 // Struct end - - classrelation 144389 // wiringTemplate () - relation 142469 ---> - a role_name "wiringTemplate" multiplicity "1" protected - cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; -" - classrelation_ref 144389 // wiringTemplate () - b multiplicity "" parent class_ref 138757 // ProcPatt - end end - class 138117 "OutPort" + class 138117 "Port" visibility package cpp_decl "${comment}${template}class ${name}${inherit} { @@ -706,7 +697,7 @@ ${inlines} idl_decl "" explicit_switch_type "" - comment "structural asset corresponding to some port generating media output" + comment "structural asset corresponding to some port for building a processing chain and generating media output" classrelation 141445 // relation 139653 ---|> a public @@ -714,6 +705,23 @@ ${inlines} classrelation_ref 141445 // b multiplicity "" parent class_ref 136965 // Struct end + + classrelation 148101 // + relation 145925 -_-> + a default + cpp default "#include in header" + classrelation_ref 148101 // + b multiplicity "" parent class_ref 138757 // ProcPatt + end + + classrelation 148229 // wiringTemplate () + relation 146053 ---> + a role_name "wiringTemplate" multiplicity "0..1" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 148229 // wiringTemplate () + b multiplicity "" parent class_ref 138757 // ProcPatt + end end class 138757 "ProcPatt" diff --git a/uml/cinelerra3/128133.diagram b/uml/cinelerra3/128133.diagram index 2df4f1453..0aa4daeb2 100644 --- a/uml/cinelerra3/128133.diagram +++ b/uml/cinelerra3/128133.diagram @@ -2,11 +2,11 @@ format 40 classcanvas 128005 class_ref 128005 // SessionImpl 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 19 606 2000 + xyz 18 679 2000 end classcanvas 128133 class_ref 128133 // EDL 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 232 606 2000 + xyz 231 679 2000 end classcanvas 128261 class_ref 128261 // Fixture 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 @@ -14,7 +14,7 @@ classcanvas 128261 class_ref 128261 // Fixture end classcanvas 129029 class_ref 128389 // 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 306 712 2000 + xyz 425 679 2000 end classcanvas 129413 class_ref 128517 // MObject 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 @@ -26,7 +26,7 @@ classcanvas 129669 class_ref 128645 // Placement end classcanvas 129925 class_ref 128389 // 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 319 1005 2000 + xyz 357 991 2000 end classcanvas 130949 class_ref 128773 // AbstractMO 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 @@ -75,12 +75,12 @@ classcanvas 136581 class_ref 129925 // Auto note 136837 "Placement \"locates\" a Media Object" xyzwh 370 73 3005 207 36 textcanvas 136965 "the Timeline is a list of placements reduced to absolute coordinates (time, track)" - xyzwh 464 925 2000 121 90 + xyzwh 468 919 2000 121 90 textcanvas 137093 "Fixture is the actual assembly of various Media Objects ready to be performed" - xyzwh 39 909 2000 147 108 + xyzwh -27 863 2000 147 108 classcanvas 137221 class_ref 130053 // Wish 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 561 532 2000 + xyz 560 532 2000 end classcanvas 137349 class_ref 130181 // Constraint 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 @@ -88,7 +88,7 @@ classcanvas 137349 class_ref 130181 // Constraint end classcanvas 138629 class_ref 135173 // Segment 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 417 678 2000 + xyz 666 731 2000 end classcanvas 139013 class_ref 138629 // CompoundClip 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 @@ -106,35 +106,33 @@ 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 + 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 +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 relationcanvas 128389 relation_ref 128005 // from ref 128005 z 1999 to ref 128133 - role_a_pos 201 603 3000 no_role_b - multiplicity_a_pos 205 636 3000 no_multiplicity_b + role_a_pos 200 676 3000 no_role_b + multiplicity_a_pos 204 709 3000 no_multiplicity_b relationcanvas 128517 relation_ref 128133 // from ref 128005 z 1999 to ref 128261 - role_a_pos 240 870 3000 no_role_b - multiplicity_a_pos 214 870 3000 no_multiplicity_b + role_a_pos 230 870 3000 no_role_b + multiplicity_a_pos 204 870 3000 no_multiplicity_b relationcanvas 128645 relation_ref 128261 // geometry VHr - from ref 128261 z 1999 to point 252 931 + from ref 128261 z 1999 to point 251 931 line 128901 z 1999 to ref 128133 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 129157 relation_ref 128389 // - geometry HV - from ref 128133 z 1999 stereotype "<>" xyz 286 628 3000 to point 326 625 - line 129285 z 1999 to ref 129029 - role_a_pos 338 687 3000 no_role_b - multiplicity_a_pos 314 687 3000 no_multiplicity_b -relationcanvas 130181 relation_ref 129029 // - geometry HV - from ref 128261 z 1999 stereotype "<>" xyz 334 914 3000 to point 339 931 - line 130565 z 1999 to ref 129925 - role_a_pos 351 980 3000 no_role_b - multiplicity_a_pos 315 980 3000 no_multiplicity_b relationcanvas 130821 relation_ref 128517 // geometry VH - from ref 128133 z 1999 stereotype "<>" xyz 258 547 3000 to point 252 167 + from ref 128133 z 1999 stereotype "<>" xyz 255 653 3000 to point 251 167 line 132357 z 1999 to ref 129413 role_a_pos 280 145 3000 no_role_b multiplicity_a_pos 298 178 3000 no_multiplicity_b @@ -175,7 +173,7 @@ relationcanvas 135685 relation_ref 130949 // no_multiplicity_a no_multiplicity_b relationcanvas 135941 relation_ref 131077 // from ref 128261 z 1999 stereotype "<>" xyz 371 893 3000 to ref 135813 - role_a_pos 419 844 3000 no_role_b + role_a_pos 389 857 3000 no_role_b multiplicity_a_pos 451 877 3000 no_multiplicity_b relationcanvas 136069 relation_ref 131205 // from ref 135813 z 1999 to point 433 897 @@ -198,7 +196,7 @@ relationcanvas 138245 relation_ref 131717 // no_multiplicity_a no_multiplicity_b relationcanvas 138757 relation_ref 137093 // geometry VHr - from ref 138629 z 1999 stereotype "<>" xyz 479 716 3000 to point 517 714 + from ref 138629 z 1999 stereotype "<>" xyz 611 767 3000 to point 517 767 line 138885 z 1999 to ref 135813 role_a_pos 529 783 3000 no_role_b multiplicity_a_pos 505 783 3000 no_multiplicity_b @@ -207,7 +205,7 @@ relationcanvas 139141 relation_ref 140805 // no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 139525 relation_ref 142725 // - from ref 128005 z 1999 stereotype "<>" xyz 57 558 3000 to ref 139269 + from ref 128005 z 1999 stereotype "<>" xyz 56 594 3000 to ref 139269 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 139781 relation_ref 142853 // @@ -251,4 +249,36 @@ relationcanvas 144517 relation_ref 143877 // line 144773 z 1999 to ref 141317 role_a_pos 492 244 3000 no_role_b no_multiplicity_a no_multiplicity_b +relationcanvas 144901 relation_ref 144901 // + from ref 129029 z 1999 to point 445 489 + line 145029 z 1999 to ref 131973 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 145285 relation_ref 145029 // + from ref 129029 z 1999 stereotype "<>" xyz 389 732 3000 to point 445 749 + line 145413 z 1999 to point 369 749 + line 145541 z 1999 to ref 129029 + role_a_pos 382 748 3000 no_role_b + multiplicity_a_pos 403 704 3000 no_multiplicity_b +relationcanvas 145669 relation_ref 145157 // + from ref 128133 z 1999 to ref 129029 + role_a_pos 376 681 3000 no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 145925 relation_ref 145413 // + from ref 128261 z 1999 to ref 129925 + role_a_pos 321 978 3000 no_role_b + no_multiplicity_a no_multiplicity_b +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 + multiplicity_a_pos 329 627 3000 no_multiplicity_b +relationcanvas 146565 relation_ref 145669 // + from ref 146437 z 1999 to ref 137221 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 146693 relation_ref 145797 // + from ref 146437 z 1999 to ref 146053 + role_a_pos 398 594 3000 no_role_b + no_multiplicity_a no_multiplicity_b end diff --git a/uml/cinelerra3/128261 b/uml/cinelerra3/128261 index 10080e773..aea54b2f1 100644 --- a/uml/cinelerra3/128261 +++ b/uml/cinelerra3/128261 @@ -1,6 +1,6 @@ format 40 "MObject" // ProcessingLayer::MObject - revision 27 + revision 28 modified_by 5 "hiv" // class settings //class diagram settings @@ -127,12 +127,12 @@ ${inlines} b multiplicity "" parent class_ref 128133 // EDL end - classrelation 128261 // fixture () + classrelation 128261 // theFixture () relation 128133 ---> - a role_name "fixture" multiplicity "1" protected + a role_name "theFixture" multiplicity "1" protected cpp default " ${comment}${static}${mutable}${volatile}${const}${type} * ${name}${value}; " - classrelation_ref 128261 // fixture () + classrelation_ref 128261 // theFixture () b multiplicity "" parent class_ref 128261 // Fixture end @@ -144,6 +144,17 @@ ${inlines} classrelation_ref 144645 // b multiplicity "" parent class_ref 139653 // Session end + + classrelation 147717 // ports () + relation 145541 o--> + stereotype "vector" + a role_name "ports" 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 + end end class 139781 "SessManager" @@ -241,16 +252,6 @@ ${inlines} idl_decl "" explicit_switch_type "" - classrelation 128645 // tracks () - relation 128389 *--> - stereotype "list" - a role_name "tracks" multiplicity "*" protected - cpp default " ${comment}${static}${mutable}${volatile}${const}${stereotype}<${type}> ${name}${value}; -" - classrelation_ref 128645 // tracks () - b multiplicity "" parent class_ref 128389 // Track - end - classrelation 128901 // clips () relation 128517 o--> stereotype "list" @@ -260,6 +261,16 @@ ${inlines} classrelation_ref 128901 // clips () b multiplicity "" parent class_ref 128517 // MObject end + + classrelation 147333 // track () + relation 145157 ---> + a role_name "track" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 147333 // track () + b multiplicity "" parent class_ref 128389 // Track + association_type class_ref 128645 // Placement + end end class 128261 "Fixture" @@ -281,23 +292,13 @@ ${inlines} b multiplicity "" parent class_ref 128133 // EDL end - classrelation 129541 // tracks () - relation 129029 *--> - stereotype "list" - a role_name "tracks" multiplicity "1..*" protected - cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; -" - classrelation_ref 129541 // tracks () - b multiplicity "" parent class_ref 128389 // Track - end - - classrelation 131717 // timeline () + classrelation 131717 // theTimeline () relation 131077 *--> stereotype "list" - a role_name "timeline" multiplicity "*" protected + a role_name "theTimeline" multiplicity "*" protected cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; " - classrelation_ref 131717 // timeline () + classrelation_ref 131717 // theTimeline () b multiplicity "" parent class_ref 129797 // ExplicitPlacement end @@ -330,6 +331,16 @@ ${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} end + + classrelation 147589 // track () + relation 145413 ---> + a role_name "track" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 147589 // track () + b multiplicity "" parent class_ref 128389 // Track + association_type class_ref 128645 // Placement + end end class 135173 "Segment" @@ -383,6 +394,26 @@ ${inlines} idl_decl "" explicit_switch_type "" + associated_diagram classdiagram_ref 128133 // Session structure + classrelation 147077 // + relation 144901 ---|> + a public + cpp default "${type}" + classrelation_ref 147077 // + b multiplicity "" parent class_ref 129157 // Meta + end + + classrelation 147205 // subTracks () + relation 145029 *--> + stereotype "vector" + a role_name "subTracks" multiplicity "*" public + comment "Child tracks in a tree structure" + cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; +" + classrelation_ref 147205 // subTracks () + b multiplicity "" parent class_ref 128389 // Track + association_type class_ref 128645 // Placement + end end class 128517 "MObject" @@ -963,6 +994,36 @@ ${inlines} end end + class 140421 "Plug" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 147845 // + relation 145669 ---|> + a public + cpp default "${type}" + classrelation_ref 147845 // + b multiplicity "" parent class_ref 130053 // Wish + end + + classrelation 147973 // outPort () + relation 145797 ---> + a role_name "outPort" multiplicity "" protected + comment "the Port this MObject wants to be conected to" + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 147973 // outPort () + b multiplicity "" parent class_ref 138117 // Port + end + end + class 134533 "Parameter" visibility public nformals 1 diff --git a/uml/cinelerra3/129285 b/uml/cinelerra3/129285 index 7b8ccd808..55db3685a 100644 --- a/uml/cinelerra3/129285 +++ b/uml/cinelerra3/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 9 + revision 11 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/130309.diagram b/uml/cinelerra3/130309.diagram index 81e77861e..7de6c806f 100644 --- a/uml/cinelerra3/130309.diagram +++ b/uml/cinelerra3/130309.diagram @@ -55,9 +55,9 @@ 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 // OutPort +classcanvas 132613 class_ref 138117 // Port 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 677 445 2000 + xyz 682 445 2000 end classcanvas 132997 class_ref 138245 // Dataset 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 @@ -207,6 +207,11 @@ relationcanvas 138501 relation_ref 144133 // from ref 131461 z 1999 to ref 131333 no_role_a no_role_b no_multiplicity_a no_multiplicity_b +relationcanvas 138629 relation_ref 145925 // + from ref 132613 z 1999 to point 714 509 + line 138757 z 1999 to ref 135813 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b line 128261 -_-_ geometry HV from ref 128005 z 1999 to point 331 150 line 128389 z 1999 to ref 128133 diff --git a/uml/cinelerra3/130437 b/uml/cinelerra3/130437 index b1c2021e8..2bad861ba 100644 --- a/uml/cinelerra3/130437 +++ b/uml/cinelerra3/130437 @@ -1,6 +1,6 @@ format 40 "session" // design::codegen::proc::mobject::session - revision 11 + revision 12 modified_by 5 "hiv" // class settings //class diagram settings @@ -274,7 +274,14 @@ ${namespace_end}" associated_classes class_ref 128389 // Track end - comment "descriptor for one track in the Session" + comment "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. +" end artifact 129285 "abstractmo" @@ -666,6 +673,126 @@ ${namespace_end}" end end + artifact 139397 "constraint" + stereotype "source" + cpp_h "/* + ${NAME}.hpp - ${description} +@{CopyrightClaim}@{GPLHeader} +*/ + + +#ifndef ${NAMESPACE}_${NAME}_H +#define ${NAMESPACE}_${NAME}_H + +${includes} +${declarations} + + +${namespace_start} + +${definition} +${namespace_end} +#endif +" + cpp_src "/* + ${Name} - ${description} +@{CopyrightClaim}@{GPLHeader} +* *****************************************************/ + + +${includes} +${namespace_start} + + +${members} +${namespace_end}" + associated_classes + class_ref 130181 // Constraint + end + comment "LocatingPin representing an directive by the user that +must not be violated" + end + + artifact 139269 "wish" + stereotype "source" + cpp_h "/* + ${NAME}.hpp - ${description} +@{CopyrightClaim}@{GPLHeader} +*/ + + +#ifndef ${NAMESPACE}_${NAME}_H +#define ${NAMESPACE}_${NAME}_H + +${includes} +${declarations} + + +${namespace_start} + +${definition} +${namespace_end} +#endif +" + cpp_src "/* + ${Name} - ${description} +@{CopyrightClaim}@{GPLHeader} +* *****************************************************/ + + +${includes} +${namespace_start} + + +${members} +${namespace_end}" + associated_classes + class_ref 130053 // Wish + end + comment "LocatingPin representing a low-priority directive by the user, +to be fulfilled only if possible (and after satisfying the +more important LocatingPins)" + end + + artifact 139525 "plug" + stereotype "source" + cpp_h "/* + ${NAME}.hpp - ${description} +@{CopyrightClaim}@{GPLHeader} +*/ + + +#ifndef ${NAMESPACE}_${NAME}_H +#define ${NAMESPACE}_${NAME}_H + +${includes} +${declarations} + + +${namespace_start} + +${definition} +${namespace_end} +#endif +" + cpp_src "/* + ${Name} - ${description} +@{CopyrightClaim}@{GPLHeader} +* *****************************************************/ + + +${includes} +${namespace_start} + + +${members} +${namespace_end}" + associated_classes + class_ref 140421 // Plug + end + comment "LocatingPin for requesting connection to some Port" + end + artifact 130181 "label" stereotype "source" cpp_h "/* diff --git a/uml/cinelerra3/131205.diagram b/uml/cinelerra3/131205.diagram index 02ad56b41..6b22db552 100644 --- a/uml/cinelerra3/131205.diagram +++ b/uml/cinelerra3/131205.diagram @@ -2,78 +2,83 @@ format 40 packagecanvas 128005 package_ref 128133 // Asset - xyzwh 328 34 1994 448 544 + xyzwh 52 6 1994 448 544 classcanvas 128133 class_ref 139013 // BuildInstruct 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 651 391 2000 + xyz 375 363 2000 end classcanvas 128261 class_ref 136837 // Proc 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 481 508 2005 + xyz 205 480 2005 end 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 684 277 2000 + xyz 408 249 2000 end -classcanvas 128517 class_ref 138117 // OutPort +classcanvas 128517 class_ref 138117 // Port 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 510 196 2000 + xyz 240 168 2000 end classcanvas 128645 class_ref 139141 // DoAttach 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 613 459 2000 + xyz 337 431 2000 end classcanvas 128773 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 604 196 2000 + xyz 328 168 2000 end classcanvas 128901 class_ref 139269 // DoRecurse 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 685 459 2000 + xyz 409 431 2000 end classcanvas 129029 class_ref 136965 // Struct 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 701 101 2005 + xyz 425 73 2005 end relationcanvas 129157 relation_ref 139653 // geometry VHV - from ref 128517 z 1999 to point 535 167 - line 130437 z 1999 to point 721 167 + from ref 128517 z 1999 to point 260 139 + line 130437 z 1999 to point 445 139 line 130565 z 1999 to ref 129029 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 129285 relation_ref 141189 // - from ref 128389 z 1999 to point 721 228 + from ref 128389 z 1999 to point 445 200 line 130693 z 1999 to ref 129029 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 129413 relation_ref 139525 // geometry VHV - from ref 128773 z 1999 to point 624 167 - line 130181 z 1999 to point 721 167 + from ref 128773 z 1999 to point 348 139 + line 130181 z 1999 to point 445 139 line 130309 z 1999 to ref 129029 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 129541 relation_ref 141701 // - from ref 128389 z 1999 stereotype "<>" xyz 678 340 3000 to ref 128133 - role_a_pos 704 366 3000 no_role_b - multiplicity_a_pos 668 366 3000 multiplicity_b_pos 689 328 3000 + from ref 128389 z 1999 stereotype "<>" xyz 361 286 3000 to ref 128133 + role_a_pos 364 301 3000 no_role_b + multiplicity_a_pos 392 338 3000 multiplicity_b_pos 467 292 3000 relationcanvas 129669 relation_ref 141829 // from ref 128645 z 1999 to ref 128133 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 129797 relation_ref 142213 // - from ref 128645 z 1999 stereotype "<>" xyz 510 628 3000 to ref 128261 - role_a_pos 535 494 3000 no_role_b - multiplicity_a_pos 535 527 3000 no_multiplicity_b + from ref 128645 z 1999 stereotype "<>" xyz 278 485 3000 to ref 128261 + role_a_pos 259 466 3000 no_role_b + multiplicity_a_pos 259 499 3000 no_multiplicity_b relationcanvas 130053 relation_ref 141957 // from ref 128901 z 1999 to ref 128133 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 130821 relation_ref 142469 // - geometry VH - from ref 128773 z 1999 to point 624 296 - line 131205 z 1999 to ref 128389 - role_a_pos 587 295 3000 no_role_b - multiplicity_a_pos 667 307 3000 no_multiplicity_b +relationcanvas 131461 relation_ref 142085 // + from ref 128901 z 1999 to point 471 396 + line 131845 z 1999 to point 471 320 + line 131973 z 1999 to ref 128389 + role_a_pos 443 334 3000 no_role_b + multiplicity_a_pos 431 301 3000 multiplicity_b_pos 451 408 3000 +relationcanvas 131589 relation_ref 146053 // + from ref 128517 z 1999 to point 260 267 + line 131717 z 1999 to ref 128389 + role_a_pos 293 252 3000 no_role_b + multiplicity_a_pos 300 268 3000 no_multiplicity_b end diff --git a/uml/cinelerra3/5.session b/uml/cinelerra3/5.session index f89f4f060..d8ab0b626 100644 --- a/uml/cinelerra3/5.session +++ b/uml/cinelerra3/5.session @@ -1,23 +1,32 @@ window_sizes 1140 830 270 860 680 71 diagrams classdiagram_ref 130309 // Asset Kinds - 860 633 100 4 0 0 - active classdiagram_ref 128133 // Session structure - 860 633 100 4 401 0 + 860 633 100 4 158 0 + classdiagram_ref 128133 // Session structure + 860 633 100 4 462 0 classdiagram_ref 128389 // Render Entities - 688 506 100 4 120 0 + 743 538 100 4 0 0 + active classdiagram_ref 131205 // Struct-Asset Relations + 555 620 100 4 0 0 end show_stereotypes selected -package_ref 129 // cinelerra3 + package_ref 129 // cinelerra3 open - deploymentview_ref 128261 // gen - deploymentview_ref 129029 // gen + + package_ref 128005 // design 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 + class_ref 128389 // Track class_ref 128645 // Placement class_ref 129413 // RelativeLocation class_ref 129541 // Allocation + class_ref 140421 // Plug class_ref 139909 // LocatingPin class_ref 134021 // Buildable class_ref 134149 // BuilderTool diff --git a/uml/cinelerra3/cinelerra3.prj b/uml/cinelerra3/cinelerra3.prj index 47e92b6e0..f342468f2 100644 --- a/uml/cinelerra3/cinelerra3.prj +++ b/uml/cinelerra3/cinelerra3.prj @@ -1,6 +1,6 @@ format 40 "cinelerra3" - revision 39 + revision 41 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/renderengine.html b/wiki/renderengine.html index fee468d59..8d57363ad 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -514,12 +514,12 @@ ColorPalette SiteUrl -
-
Asset management is a subsystem on its own. Assets are "things" that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the "bookkeeping view", while the EDL is the "manipulation and process view". Some Assets can be //loaded// and a collection of Assets is saved with eatch Session. Besides, there is a collection of basic Assets allways available by default.
+

+
Asset management is a subsystem on its own. Assets are "things" that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the "bookkeeping view", while the EDL is the "manipulation and process view". Some Assets can be //loaded// and a collection of Assets is saved with each Session. Besides, there is a collection of basic Assets always available by default.
 
 The Assets are important reference points holding the information needed to access external resources. For example, an Clip asset can reference a Media asset, which in turn holds the external filename from which to get the media stream. For Effects, the situation is similar. Assets thus serve two quite distinct purposes. One is to load, list, group search and browse them, and to provide an entry point to create new or get at existing MObjects in the EDL, while the other purpose is to provide attribute and property informations to the inner parts of the engine, while at the same time isolating and decoupling them from environmental details. 
 
-We can distinguish several different Kinds of Assets, each one with specific properties. While all these Kinds of Assets implement the basic Asset interface, they themselfs are the __key abstractions__ of the asset management view. Mostly, their interfaces will be used directly, because they are quite different in behaviour. Thus it is common to see asset related operations being templated on the Asset Kind. 
+We can distinguish several different Kinds of Assets, each one with specific properties. While all these Kinds of Assets implement the basic Asset interface, they in turn are the __key abstractions__ of the asset management view. Mostly, their interfaces will be used directly, because they are quite different in behaviour. Thus it is common to see asset related operations being templated on the Asset Kind. 
 &rarr; see also [[Creating and registering Assets|AssetCreation]]
 [img[Asset Classess|uml/fig130309.png]]
 
@@ -542,7 +542,7 @@ Some of the building blocks providing the framework for the objects placed into
 &rarr; StructAsset {{red{to be defined}}}
 
 !Meta Asset
-Some additional, virtual facilities created in the course of the editing process. Examples are Automation data sets, Lables and reference points, Meta Clips (nested sub-~EDLs)
+Some additional, virtual facilities created in the course of the editing process. Examples are Automation data sets, Labels and reference points, Meta Clips (nested sub-~EDLs)
 * __outward interface operations__ include...
 * __inward interface operations__ include...
 &rarr; MetaAsset {{red{to be defined}}}
@@ -564,13 +564,21 @@ 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.
+* 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
+
+The first step towards an solution is to isolate the problem; obviously we //need the information about attached objects // only for two isolated tasks, namely when building and for creating a GUI representation. So using a query (function call) interface, the rest of the problem is turned into an implementation detail.

+

 

 
Automation is treated as a function over time. It is always tied to a specific Parameter (which can thus be variable over the course of the timeline). All details //how// this function is defined are completely abstracted away. The Parameter uses a ParamProvider to get the value for a given Time (point). Typically, this will use linear or bezier interpolation over a set of keyframes internally. Parameters can be configured to have different value ranges and distribution types (on-off, stepped, continuous, bounded)
 
 [img[how to implement Automation|uml/fig129669.png]]
 

 

-

+

 
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.
 
 !Builder working Situations
@@ -602,7 +610,7 @@ After consuming all input objects and satisfying all wiring requests, the result
 !!!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.
 
-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// 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 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.
 
 !!!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]]
@@ -784,6 +792,32 @@ TertiaryMid: #99a
 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.
+&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.
+* 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.
+
+!anatomy of a Configuration Query
+The query is given as a number of logic predicates, which are required to be true. Syntactically, it is a string in prolog syntax, e.g. {{{stream(mpeg)}}}, where "stream" is the //predicate, // meaning here "the stream type is...?" and "mpeg" is a //term // denoting an actual property, object, thing, number etc &mdash; the actual kind of stream in the given example. Multible comma separated predicates are combined with logical "and". Terms may be //variable // at start, which is denoted syntactically by starting them with a uppercase letter. But any variable term need to be //bound //  to some known value while computing the solution to the query, otherwise the query fails. A failed query is treated as a local failure, which may cause some operation being aborted or just some other possibility being chosen.
+Queries are represented by instantiations of the {{{Query<TYPE>}}} template, because their actual meaning is "retrieve or create an object of TYPE, configured such that...!". At the C++ side, this ensures type safety and fosters programming against interfaces, while being implemented rule-wise by silently prepending the query with the predicate "{{{object(tYPE)}}}"
+
+!executing a Configuration Query
+Actually posing such an configuration query, for example to the [[Defaults Manager in the Sessison|DefaultsManagement]], may trigger several actions: First it is checked against internal object registries (depending on the target object type), which may cause the delivery of an already existing object (as reference, clone, or smart pointer). Otherwise, the system tries to figure out an viable configuration for a newly created object instance, possibly by issuing recursive queries. In the most general case this may silently impose additional decisions onto the //execution context // of the query &mdash; by default the session.
+
+!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]]
+

+

 

 
Here, in the context of the Render Engine, the Controller component is responsible for triggering and coordinating the build process and for activating the backend and the Render Engine configuration created by the Builder to carry out the actual rendering. There is another Controller in the backend, the ~PlaybackController, which is in charge of the playback/rendering/display state of the application, and consequently will call this (Proc-Layer) Controller to get the necessary Render Engine.
 
@@ -803,7 +837,27 @@ This is an very important external Interface, because it links together all thre
 
RenderEngine
 

 

-

+

+
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]]
+

+

+

+
Along the way of working out various [[implementation details|ImplementationDetails]], decisions need to be made on how to understand the different facilities and entities and how to tackle some of the problems. This page is mainly a collection of keywords, summaries and links to further the discussion. And the various decisions should allways be read as proposals to solve some problem at hand...
+
+''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 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]]
+
+''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)
+
+''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)
+

+

+

 
This __proc-Layer__ and ~Render-Engine implementation started out as a design-draft by [[Ichthyo|mailto:Ichthyostega@web.de]] in summer 2007. The key idea of this design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder.
 
 !Why doesn't the current Cinelerra-2 Design succeed?
@@ -811,10 +865,10 @@ The design of Cinelerra-2 basically follows a similar design, but __fails becaus
 # too much differentiation is put into the class hierarchy instead of configuring Instances differently.<br>This causes overly heavy use of virtual functions and -- in order to ameliorate this -- falling back to hard wired branching
 # far too much coupling and back-coupling to the internals of the EDL, forcing a overly rigid structure on the latter
 
-!Try to learn from this
+!Try to learn from the Problems of the current Cinelerra-2 codebase
 * build up an [[Node Abstraction|ProcNode]] powerful enough to express //all necessary Operations// without the need to recure on the actual object type
-* need to redesign the internals of the EDL in a far more open manner. See MObjects
-* strive at a StrongSeparation between EDL and Render Engine
+* need to redesign the internals of the EDL in a far more open manner. Everything is an [[M-Object|MObjects]] which is [[placed|Placement]] in some manner
+* strive at a StrongSeparation between EDL and Render Engine, encapsulate and allways implement against interfaces
 
 
 !Design Goals
@@ -1055,7 +1109,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]]
@@ -1067,8 +1121,10 @@ 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 and Ports in the EDL|TrackPortEDL]]. [[Handling of Tracks|TrackHandling]] and [[Ports|PortHandling]]
+* [[getting default configured|DefaultsManagement]] Objects relying on [[rule-based Configuration Queries|ConfigRules]]
 * [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreaterTool]]
+* [[how to handle »attached placement«|AttachedPlacementProblem]]
 

 

 

@@ -1502,8 +1558,8 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;">loading <b>Cinelerra Renderengine</b> devel doku<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>

 

-

-
The Interface asset::Media is a //key abstraction// It ties together several concepts and enables to deal with them on the interfaces in a uniform manner. Besides, as every Asset kind it belongs rather to the bookkeeping view: it holds the specific properties and parametrisation of the media source it stands for. Regarding the __inward interface__ &mdash; as used from within the [[EDL]] or the [[Render Nodes|ProcNode]], it is irrelevant if a given asset::Media object stands for a complete media source, just a clip taken from this source or if a placeholder version of the real media source is used instead.
+

+
The Interface asset::Media is a //key abstraction// It ties together several concepts and enables to deal with them on the interfaces in a uniform manner. Besides, as every Asset kind it belongs rather to the bookkeeping view: an asset::Media holds the specific properties and parametrisation of the media source it stands for. Regarding the __inward interface__ &mdash; as used from within the [[EDL]] or the [[Render Nodes|ProcNode]], it is irrelevant if any given asset::Media object stands for a complete media source, just a clip taken from this source or if a placeholder version of the real media source is used instead.
 [img[Asset Classess|uml/fig130437.png]]
 

 

@@ -2193,7 +2249,7 @@ Placements have //value semantics,// i.e. we don't stress the identity of a plac
 
 

 

-

+

 
//This page is a scrapbook for working out the implementation of how to (re)build the [[Fixture]]//
 Structurally, (re)building the Fixture rather belongs to [[Session]]/[[EDLs|EDL]], but it is implemented very similar to the render engine build process: by treating all ~MObjects found in the various ~EDLs with a common [[visiting tool|VisitorUse]], this tool collects a simplified view with everyting made explicit, which can be pulled of as Fixture, i.e. (special kind of) EDL
 afterwards.
@@ -2242,7 +2298,7 @@ afterwards.
 <<tasksum end>>
 

 

-

+

 
//This page is a scrapbook for working out the implementation of the builder//
 
 * NodeCreaterTool is a [[visiting tool|VisitorUse]]
@@ -2268,7 +2324,7 @@ We need a way of addressing existing [[ports|Port]]. Besides, as the Ports and T
 !!treating a {{{Placement<Clip>}}}
 <<task>>get the ProcPatt of the underlying media (asset)
 <<task>>process the ProcPatt recursively
-<<task>>create or access? {{red{TODO: decide this}}} the ClipSourcePort
+<<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.
@@ -2293,6 +2349,33 @@ 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)
+
+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.
+
+&rarr; [[Handling of Tracks|TrackHandling]]
+&rarr; [[Handling of Ports|PortHandling]]
+
+

+

+

+
!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)
+
+!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]].
+
+!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}}}
+
+!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
+

+

 

 
Open issues, Things to be worked out, Problems still to be solved... 
 
@@ -2367,6 +2450,28 @@ Like all [[structural assets|StructAsset]], ~ProcPatt employs a special naming s
 
a given Render Engine configuration is a list of Processors. Each Processor in turn contains a Graph of ProcNode.s to do the acutal data processing. In order to cary out any calculations, the Processor needs to be called with a StateProxy containing the state information for this RenderProcess
 

 

+

+
//obviously, getting this one to work requires quite a lot of technical details to be planned and implemented.// This said...
+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)
+{{{
+retrieve(O, Cap) :- find(T), capabilities(Cap).
+retrieve(O, Cap) :- make(T), capabilities(Cap).
+capabilities(Q) :- call(Q).
+
+stream(T, mpeg) :- type(T, track), type(P, port), 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 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)
+* 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.
+

+

 

 
/***
 |''Name:''|RSSReaderPlugin|
@@ -2597,7 +2702,7 @@ 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??

 

-

+

 
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++
@@ -2617,7 +2722,7 @@ The system is ''open'' inasmuch every part mirrors the structure of correspondin
 &rarr; BuildProcess and RenderProcess
 &rarr; [[Two Examples|Examples]] (Object diagrams) 
 &rarr; how [[Automation]] works  {{red{to be defined in more detail}}}
-&rarr; [[Problems|ProblemsTodo]] {{red{to be solved}}}
+&rarr; [[Problems|ProblemsTodo]] to be solved and notable [[design decisions|DesignDecisions]]
 &rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
 

 

@@ -2643,14 +2748,14 @@ The Session object is a singleton &mdash; actually it is a »~PImpl«-Facade
 * a collection of ''global Ports''
 * the ''Fixture'' with a possibility to [[(re)build it|PlanningBuildFixture]]
-
-
The [[Session]] (sometimes also called //Project//) contains all informations and objects to be edited by the User. It can be saved and loaded. The individual Objects within the Session, i.e. Clips, Media, Effects, are contained in one (or several) collections within the Session, which we call [[EDL (Edit Decision List)|EDL]]. Moreover, the sesion contains references to all the Media files used, and it contains various default or user defined configuration. At any given time, there is //only one current session// opened within the application.
+

+
The [[Session]] (sometimes also called //Project//) contains all informations and objects to be edited by the User. It can be saved and loaded. The individual Objects within the Session, i.e. Clips, Media, Effects, are contained in one (or several) collections within the Session, which we call [[EDL (Edit Decision List)|EDL]]. Moreover, the sesion contains references to all the Media files used, and it contains various default or user defined configuration, all being represented as [[Asset]]. At any given time, there is //only one current session// opened within the application.
 
 !!!larger projects
 For larger editing projects the simple structure of a session containing "the" timeline is not sufficient. Rather, we have several timelines, e.g. one for each scene. Or we could have several layered or nested timelines (compositional work, multimedia productions). To support these cases without making the default case more complicated, Cinelerra-3 introduces a //focus// for selecting the //current EDL,// which will receive all editing operations.
 
 !!!the definitive state
-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 object placed onto a single timeline.
+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.
@@ -2752,16 +2857,17 @@ Instead, we should try to just connect the various subsystems via Interfaces and
 * to shield the rendering code of all complexities of thread communication and synchronization, we use the StateProxy
 

 

-

-
Structural Assets are intended mainly for internal use, but the user should be able to see and query them. By changing the parametrisation of some structural Asset, we can customize the default behaviour of Cinelerra to some extent.
-* [[Processing Patterns|ProcPatt]] encode the information, how to get at the actual media data when rendering a clip.
-* Tracks are one of the dimensions used for organizing the EDL. Besides, they carry parametrisation of output port, overlay mode etc.
-* Output Ports {{red{still need to be defined...}}}
-
+

+
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...)
+[>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??}}}
 
-[img[Asset Classess|uml/fig131205.png]]
-

+!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"

 

 

 
/*{{{*/
@@ -3931,7 +4037,18 @@ 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 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.
+&rarr; [[Handling of Tracks|TrackHandling]]
+&rarr; [[Handling of Ports|PortHandling]]
+

+

+

 
''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
@@ -3946,17 +4063,20 @@ 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 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.
+[[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.
 
 !Design
-__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. 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:
+[[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.
+* 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]]

+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]]
+&rarr; [[Definition|Track]] and [[handling of Tracks|TrackHandling]]
+&rarr; [[Definition|Port]] and [[handling of Ports|PortHandling]]
+
-
+
Transitions combine the data from at least two processing chains and do this combining in a time varying fashion. So, any transition has
 * N input connections
 * either one or N output connections
@@ -3964,7 +4084,7 @@ 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, 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 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.
 
 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.