ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge design dokumentation from branch 'builder'

Browse source
This commit is contained in:
Fischlurch 2008-01-27 03:19:27 +01:00
commit 6e08122fcb
41 changed files with 610 additions and 207 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
doc/devel/uml/class128005.html
View file

@ -19,7 +19,8 @@
<p>Declaration :</p><ul><li>C++ : class SessionImpl : public <a href="class139653.html#refclass139653"><b>Session</b></a> </li></ul><p>Implementation class for the Session interface<br /></p><p>Artifact : <a href="index.html#refartifact128517"><b>sessionimpl</b></a>, Component(s) : <a href="index.html#refcomponent128133"><b>Session</b></a></p><div class="sub">
<a name="refrelation128005"></a>
<table><tr><td><div class="element">Relation <b>edls (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # edls : <a href="class128133.html#refclass128133"><b>EDL</b></a>, multiplicity : 1..*</li><li>C++ : protected: &lt;<a href="class128133.html#refclass128133"><b>EDL</b></a>&gt; edls</li></ul><a name="refrelation128261"></a>
<table><tr><td><div class="element">Relation <b>fixture (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # fixture : <a href="class128261.html#refclass128261"><b>Fixture</b></a>, multiplicity : 1</li><li>C++ : protected: <a href="class128261.html#refclass128261"><b>Fixture</b></a> * fixture</li></ul></div>
<table><tr><td><div class="element">Relation <b>theFixture (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # theFixture : <a href="class128261.html#refclass128261"><b>Fixture</b></a>, multiplicity : 1</li><li>C++ : protected: <a href="class128261.html#refclass128261"><b>Fixture</b></a> * theFixture</li></ul><a name="refrelation147717"></a>
<table><tr><td><div class="element">Relation <b>ports (&lt;directional aggregation&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # ports : <a href="class138117.html#refclass138117"><b>Port</b></a>, multiplicity : *</li><li>C++ : protected: <a href="class138117.html#refclass138117"><b>Port</b></a>* ports</li></ul><p>the global ports (busses) of the session<br /></p></div>
<p>All public operations : <a href="class139653.html#refoperation133509"><b>currEDL</b></a> , <a href="class139653.html#refoperation133637"><b>getFixture</b></a> </p>
</body>
</html>

6
doc/devel/uml/class128133.html
View file

@ -18,8 +18,8 @@
<a name="refclass128133"></a>
<p>Declaration :</p><ul><li>C++ : class EDL </li></ul><p>Directly inherited by : <a href="class128261.html#refclass128261"><b>Fixture</b></a> </p>
<p>Artifact : <a href="index.html#refartifact128645"><b>edl</b></a>, Component(s) : <a href="index.html#refcomponent128133"><b>Session</b></a></p><div class="sub">
<a name="refrelation128645"></a>
<table><tr><td><div class="element">Relation <b>tracks (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # tracks : <a href="class128389.html#refclass128389"><b>Track</b></a>, multiplicity : *</li><li>C++ : protected: list&lt;<a href="class128389.html#refclass128389"><b>Track</b></a>&gt; tracks</li></ul><a name="refrelation128901"></a>
<table><tr><td><div class="element">Relation <b>clips (&lt;directional aggregation&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # clips : <a href="class128517.html#refclass128517"><b>MObject</b></a>, multiplicity : *</li><li>C++ : protected: list&lt;<a href="class128517.html#refclass128517"><b>MObject</b></a> *&gt; clips</li></ul></div>
<a name="refrelation128901"></a>
<table><tr><td><div class="element">Relation <b>clips (&lt;directional aggregation&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # clips : <a href="class128517.html#refclass128517"><b>MObject</b></a>, multiplicity : *</li><li>C++ : protected: list&lt;<a href="class128517.html#refclass128517"><b>MObject</b></a> *&gt; clips</li></ul><a name="refrelation147333"></a>
<table><tr><td><div class="element">Relation <b>track (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # track : <a href="class128389.html#refclass128389"><b>Track</b></a></li><li>C++ : protected: <a href="class128389.html#refclass128389"><b>Track</b></a>* track</li></ul></div>
</body>
</html>

8
doc/devel/uml/class128261.html
View file

@ -17,11 +17,11 @@
<a name="refclass128261"></a>
<p>Declaration :</p><ul><li>C++ : class Fixture : public <a href="class128133.html#refclass128133"><b>EDL</b></a> </li></ul><p>Artifact : <a href="index.html#refartifact128773"><b>fixture</b></a>, Component(s) : <a href="index.html#refcomponent128133"><b>Session</b></a></p><div class="sub">
<a name="refrelation129541"></a>
<table><tr><td><div class="element">Relation <b>tracks (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # tracks : <a href="class128389.html#refclass128389"><b>Track</b></a>, multiplicity : 1..*</li><li>C++ : protected: <a href="class128389.html#refclass128389"><b>Track</b></a> tracks</li></ul><a name="refrelation131717"></a>
<table><tr><td><div class="element">Relation <b>timeline (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # timeline : <a href="class129797.html#refclass129797"><b>ExplicitPlacement</b></a>, multiplicity : *</li><li>C++ : protected: <a href="class129797.html#refclass129797"><b>ExplicitPlacement</b></a> timeline</li></ul><a name="refoperation128645"></a>
<a name="refrelation131717"></a>
<table><tr><td><div class="element">Relation <b>theTimeline (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # theTimeline : <a href="class129797.html#refclass129797"><b>ExplicitPlacement</b></a>, multiplicity : *</li><li>C++ : protected: <a href="class129797.html#refclass129797"><b>ExplicitPlacement</b></a> theTimeline</li></ul><a name="refoperation128645"></a>
<table><tr><td><div class="element">Operation <b>getPlaylistForRender</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : + getPlaylistForRender() : list&lt;ExplicitPlacement [ProcessingLayer::MObject]&gt;</li><li>C++ : public: list&lt;ExplicitPlacement [ProcessingLayer::MObject]&gt; getPlaylistForRender () </li></ul><a name="refoperation129157"></a>
<table><tr><td><div class="element">Operation <b>getAutomation</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : + getAutomation() : Auto [ProcessingLayer::MObject]*</li><li>C++ : public: Auto [ProcessingLayer::MObject]* getAutomation () </li></ul></div>
<table><tr><td><div class="element">Operation <b>getAutomation</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : + getAutomation() : Auto [ProcessingLayer::MObject]*</li><li>C++ : public: Auto [ProcessingLayer::MObject]* getAutomation () </li></ul><a name="refrelation147589"></a>
<table><tr><td><div class="element">Relation <b>track (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # track : <a href="class128389.html#refclass128389"><b>Track</b></a></li><li>C++ : protected: <a href="class128389.html#refclass128389"><b>Track</b></a>* track</li></ul></div>
<p>All public operations : <a href="class128261.html#refoperation129157"><b>getAutomation</b></a> , <a href="class128261.html#refoperation128645"><b>getPlaylistForRender</b></a> </p>
</body>
</html>

6
doc/devel/uml/class128389.html
View file

@ -16,5 +16,9 @@
<!-- ============================================================= -->
<a name="refclass128389"></a>
<p>Declaration :</p><ul><li>C++ : class Track </li></ul><p>Artifact : <a href="index.html#refartifact128901"><b>track</b></a></p></body>
<p>Declaration :</p><ul><li>C++ : class Track : public <a href="class129157.html#refclass129157"><b>Meta</b></a> </li></ul><p>Artifact : <a href="index.html#refartifact128901"><b>track</b></a>, Diagram : <a href="index.html#refclass diagram128133"><b>Session structure</b></a></p><div class="sub">
<a name="refrelation147205"></a>
<table><tr><td><div class="element">Relation <b>subTracks (&lt;directional aggregation by value&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : + subTracks : <a href="class128389.html#refclass128389"><b>Track</b></a>, multiplicity : *</li><li>C++ : public: <a href="class128389.html#refclass128389"><b>Track</b></a> subTracks</li></ul><p>Child tracks in a tree structure<br /></p></div>
<p>All public operations : <a href="class134021.html#refoperation129669"><b>apply</b></a> , <a href="class140165.html#refoperation134789"><b>apply</b></a> , <a href="class140165.html#refoperation134917"><b>dispatchOp</b></a> </p>
</body>
</html>

2
doc/devel/uml/class129157.html
View file

@ -16,7 +16,7 @@
<!-- ============================================================= -->
<a name="refclass129157"></a>
<p>Declaration :</p><ul><li>C++ : class Meta : public <a href="class128773.html#refclass128773"><b>AbstractMO</b></a> </li></ul><p>Directly inherited by : <a href="class129925.html#refclass129925"><b>Auto</b></a> <a href="class129669.html#refclass129669"><b>Label</b></a> </p>
<p>Declaration :</p><ul><li>C++ : class Meta : public <a href="class128773.html#refclass128773"><b>AbstractMO</b></a> </li></ul><p>Directly inherited by : <a href="class129925.html#refclass129925"><b>Auto</b></a> <a href="class129669.html#refclass129669"><b>Label</b></a> <a href="class128389.html#refclass128389"><b>Track</b></a> </p>
<p>Artifact : <a href="index.html#refartifact129669"><b>meta</b></a></p><div class="sub">
</div>
<p>All public operations : <a href="class134021.html#refoperation129669"><b>apply</b></a> , <a href="class140165.html#refoperation134789"><b>apply</b></a> , <a href="class140165.html#refoperation134917"><b>dispatchOp</b></a> </p>

3
doc/devel/uml/class130053.html
View file

@ -16,7 +16,8 @@
<!-- ============================================================= -->
<a name="refclass130053"></a>
<p>Declaration :</p><ul><li>C++ : class Wish : public <a href="class129541.html#refclass129541"><b>Allocation</b></a> </li></ul><div class="sub">
<p>Declaration :</p><ul><li>C++ : class Wish : public <a href="class129541.html#refclass129541"><b>Allocation</b></a> </li></ul><p>Directly inherited by : <a href="class140421.html#refclass140421"><b>Plug</b></a> </p>
<div class="sub">
</div>
<p>All public operations : <a href="class129541.html#refoperation131205"><b>get_repr</b></a> </p>
</body>

2
doc/devel/uml/class136965.html
View file

@ -16,7 +16,7 @@
<!-- ============================================================= -->
<a name="refclass136965"></a>
<p>Declaration :</p><ul><li>C++ : class Struct : public <a href="class136453.html#refclass136453"><b>Asset</b></a> </li></ul><p>Directly inherited by : <a href="class138117.html#refclass138117"><b>OutPort</b></a> <a href="class138757.html#refclass138757"><b>ProcPatt</b></a> <a href="class137989.html#refclass137989"><b>Track</b></a> </p>
<p>Declaration :</p><ul><li>C++ : class Struct : public <a href="class136453.html#refclass136453"><b>Asset</b></a> </li></ul><p>Directly inherited by : <a href="class138117.html#refclass138117"><b>Port</b></a> <a href="class138757.html#refclass138757"><b>ProcPatt</b></a> <a href="class137989.html#refclass137989"><b>Track</b></a> </p>
<p>key abstraction: structural asset<br /></p><p>Artifact : <a href="index.html#refartifact136709"><b>struct</b></a></p><div class="sub">
</div>
<p>All public operations : <a href="class136453.html#refoperation132997"><b>enable</b></a> , <a href="class136453.html#refoperation132229"><b>getDependant</b></a> , <a href="class136453.html#refoperation132101"><b>getParents</b></a> , <a href="class136453.html#refoperation132869"><b>isActive</b></a> </p>

3
doc/devel/uml/class137989.html
View file

@ -17,8 +17,7 @@
<a name="refclass137989"></a>
<p>Declaration :</p><ul><li>C++ : class Track : public <a href="class136965.html#refclass136965"><b>Struct</b></a> </li></ul><p>structural asset holding the configuration of a track in the EDL<br /></p><p>Artifact : <a href="index.html#refartifact137477"><b>track</b></a></p><div class="sub">
<a name="refrelation144389"></a>
<table><tr><td><div class="element">Relation <b>wiringTemplate (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # wiringTemplate : <a href="class138757.html#refclass138757"><b>ProcPatt</b></a>, multiplicity : 1</li><li>C++ : protected: <a href="class138757.html#refclass138757"><b>ProcPatt</b></a>* wiringTemplate</li></ul></div>
</div>
<p>All public operations : <a href="class136453.html#refoperation132997"><b>enable</b></a> , <a href="class136453.html#refoperation132229"><b>getDependant</b></a> , <a href="class136453.html#refoperation132101"><b>getParents</b></a> , <a href="class136453.html#refoperation132869"><b>isActive</b></a> </p>
</body>
</html>

9
doc/devel/uml/class138117.html
View file

@ -4,20 +4,21 @@
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Class OutPort</title>
<title>Class Port</title>
<link rel="stylesheet" href="style.css" type="text/css" />
</head>
<body bgcolor="#ffffff">
<div class = "title">Class OutPort</div>
<div class = "title">Class Port</div>
<p></p>
<!-- ============================================================= -->
<a name="refclass138117"></a>
<p>Declaration :</p><ul><li>C++ : class OutPort : public <a href="class136965.html#refclass136965"><b>Struct</b></a> </li></ul><p>structural asset corresponding to some port generating media output<br /></p><p>Artifact : <a href="index.html#refartifact137605"><b>outport</b></a></p><div class="sub">
</div>
<p>Declaration :</p><ul><li>C++ : class Port : public <a href="class136965.html#refclass136965"><b>Struct</b></a> </li></ul><p>structural asset corresponding to some port for building a processing chain and generating media output<br /></p><p>Artifact : <a href="index.html#refartifact137605"><b>outport</b></a></p><div class="sub">
<a name="refrelation148229"></a>
<table><tr><td><div class="element">Relation <b>wiringTemplate (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # wiringTemplate : <a href="class138757.html#refclass138757"><b>ProcPatt</b></a>, multiplicity : 0..1</li><li>C++ : protected: <a href="class138757.html#refclass138757"><b>ProcPatt</b></a>* wiringTemplate</li></ul></div>
<p>All public operations : <a href="class136453.html#refoperation132997"><b>enable</b></a> , <a href="class136453.html#refoperation132229"><b>getDependant</b></a> , <a href="class136453.html#refoperation132101"><b>getParents</b></a> , <a href="class136453.html#refoperation132869"><b>isActive</b></a> </p>
</body>
</html>

24
doc/devel/uml/class140421.html Normal file
View file

@ -0,0 +1,24 @@
<!-- Documentation produced by the Html generator of Bouml (http://bouml.free.fr) -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Class Plug</title>
<link rel="stylesheet" href="style.css" type="text/css" />
</head>
<body bgcolor="#ffffff">
<div class = "title">Class Plug</div>
<p></p>
<!-- ============================================================= -->
<a name="refclass140421"></a>
<p>Declaration :</p><ul><li>C++ : class Plug : public <a href="class130053.html#refclass130053"><b>Wish</b></a> </li></ul><div class="sub">
<a name="refrelation147973"></a>
<table><tr><td><div class="element">Relation <b>outPort (&lt;unidirectional association&gt;)</b></div></td></tr></table><p>Declaration :</p><ul><li>Uml : # outPort : <a href="class138117.html#refclass138117"><b>Port</b></a></li><li>C++ : protected: <a href="class138117.html#refclass138117"><b>Port</b></a>* outPort</li></ul><p>the Port this MObject wants to be conected to<br /></p></div>
<p>All public operations : <a href="class129541.html#refoperation131205"><b>get_repr</b></a> </p>
</body>
</html>

3
doc/devel/uml/classes.html
View file

@ -88,12 +88,13 @@
<tr bgcolor=#f0f0f0><td><a href="class128517.html#refclass128517" target = "projectFrame"><b>MObject</b></a></td><td>interface</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128394.html#refclass128394" target = "projectFrame"><b>Mutex</b></a></td><td></td><td>I provided a reworked Mutex class in my cinelerra2 repository</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class134405.html#refclass134405" target = "projectFrame"><b>NodeCreatorTool</b></a></td><td></td><td>This 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.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class138117.html#refclass138117" target = "projectFrame"><b>OutPort</b></a></td><td></td><td>structural asset corresponding to some port generating media output</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class134533.html#refclass134533" target = "projectFrame"><b>Parameter</b></a></td><td></td><td>Descriptor and access object for a plugin parameter. Parameters may be provided with values from the session, and this values may be automated.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class134661.html#refclass134661" target = "projectFrame"><b>ParamProvider</b></a></td><td>interface</td><td>A facility to get the actual value of a plugin/effect parameter</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class130437.html#refclass130437" target = "projectFrame"><b>PathManager</b></a></td><td></td><td>While building a render engine, this Strategy class decides on the actual render strategy in accordance to the current controller settings (system state)</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128645.html#refclass128645" target = "projectFrame"><b>Placement</b></a></td><td>interface</td><td>used to specify the position of a MObject in the EDL. This can be done in various ways (absolute, relative). <br />Placement at the same time acts as (refcounting) smart pointer for accessing the MObject.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class140421.html#refclass140421" target = "projectFrame"><b>Plug</b></a></td><td></td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class132485.html#refclass132485" target = "projectFrame"><b>PluginAdapter</b></a></td><td></td><td>Adapter used to integrage an effects processor in the render pipeline</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class138117.html#refclass138117" target = "projectFrame"><b>Port</b></a></td><td></td><td>structural asset corresponding to some port for building a processing chain and generating media output</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129077.html#refclass129077" target = "projectFrame"><b>Prefetch</b></a></td><td></td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137605.html#refclass137605" target = "projectFrame"><b>Preview</b></a></td><td></td><td>alternative version of the media data, probably with lower resolution</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class136837.html#refclass136837" target = "projectFrame"><b>Proc</b></a></td><td></td><td>key abstraction: data processing asset</td></tr>

3
doc/devel/uml/classes_list.html
View file

@ -89,12 +89,13 @@
<a href="class128517.html#refclass128517" target = "projectFrame"><b>MObject</b></a><br />
<a href="class128394.html#refclass128394" target = "projectFrame"><b>Mutex</b></a><br />
<a href="class134405.html#refclass134405" target = "projectFrame"><b>NodeCreatorTool</b></a><br />
<a href="class138117.html#refclass138117" target = "projectFrame"><b>OutPort</b></a><br />
<a href="class134533.html#refclass134533" target = "projectFrame"><b>Parameter</b></a><br />
<a href="class134661.html#refclass134661" target = "projectFrame"><b>ParamProvider</b></a><br />
<a href="class130437.html#refclass130437" target = "projectFrame"><b>PathManager</b></a><br />
<a href="class128645.html#refclass128645" target = "projectFrame"><b>Placement</b></a><br />
<a href="class140421.html#refclass140421" target = "projectFrame"><b>Plug</b></a><br />
<a href="class132485.html#refclass132485" target = "projectFrame"><b>PluginAdapter</b></a><br />
<a href="class138117.html#refclass138117" target = "projectFrame"><b>Port</b></a><br />
<a href="class129077.html#refclass129077" target = "projectFrame"><b>Prefetch</b></a><br />
<a href="class137605.html#refclass137605" target = "projectFrame"><b>Preview</b></a><br />
<a href="class136837.html#refclass136837" target = "projectFrame"><b>Proc</b></a><br />

BIN
doc/devel/uml/fig128133.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 63 KiB

After

Width:  |  Height:  |  Size: 66 KiB

BIN
doc/devel/uml/fig130309.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

BIN
doc/devel/uml/fig131205.png
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 14 KiB

5
doc/devel/uml/index.html
View file

@ -263,7 +263,7 @@ Documentation</title>
<a name="refartifact137605"></a>
<table><tr><td><div class="element">Artifact <b>outport</b></div></td></tr></table>
<p>structural asset corresponding to some port generating media output<br /></p>
<p>Artifact <i>source</i> associated with : <a href="class138117.html#refclass138117"><b>OutPort</b></a></p>
<p>Artifact <i>source</i> associated with : <a href="class138117.html#refclass138117"><b>Port</b></a></p>
<a name="refartifact137477"></a>
<table><tr><td><div class="element">Artifact <b>track</b></div></td></tr></table>
<p>structural asset holding the configuration of a track in the EDL<br /></p>
@ -612,7 +612,7 @@ Documentation</title>
<table><tr><td><div class="element">Class <b><a href="class137733.html#refclass137733"><b>Effect</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class137861.html#refclass137861"><b>Codec</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class137989.html#refclass137989"><b>Track</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class138117.html#refclass138117"><b>OutPort</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class138117.html#refclass138117"><b>Port</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class138757.html#refclass138757"><b>ProcPatt</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class138245.html#refclass138245"><b>Dataset</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class138373.html#refclass138373"><b>DB</b></a></b></div></td></tr></table>
@ -657,6 +657,7 @@ Documentation</title>
<table><tr><td><div class="element">Class <b><a href="class134661.html#refclass134661"><b>ParamProvider</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class134789.html#refclass134789"><b>Interpolator</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class139909.html#refclass139909"><b>LocatingPin</b></a></b></div></td></tr></table>
<table><tr><td><div class="element">Class <b><a href="class140421.html#refclass140421"><b>Plug</b></a></b></div></td></tr></table>
</div>
<a name="refpackage128901"></a>
<h3 class ="package">2.2.2 Package Builder</h3>

34
doc/devel/uml/index_67.html
View file

@ -29,33 +29,33 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation129290" target = "projectFrame"><b>checked_out</b></a></td><td>relation</td><td>this list keeps all mappings which are in use, and thus prevents them from Cache aging</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact128005" target = "projectFrame"><b>Cinelerra3</b></a></td><td>artifact</td><td>the main executable to be built</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage129" target = "projectFrame"><b>cinelerra3</b></a></td><td>package</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135685" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135557" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135429" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135301" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135173" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135045" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134917" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134789" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134661" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135301" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135429" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135813" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135557" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135685" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance135173" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130565" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131589" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130437" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132229" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132357" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130309" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130181" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132485" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129029" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133509" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130053" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128261" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128133" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129285" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129797" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129541" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130437" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130565" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130693" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131589" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132229" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132357" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129285" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132485" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128133" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133509" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130309" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129029" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128261" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128005" target = "projectFrame"><b>class instance</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation133765" target = "projectFrame"><b>clear</b></a></td><td>operation</td><td>clear current session contents <br />without resetting overall session config.<br />Afterwards, the session will contain only one <br />empty EDL, while all Assets are retained.<br /></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137349.html#refclass137349" target = "projectFrame"><b>Clip</b></a></td><td>class</td><td>bookkeeping (asset) view of a media clip.</td></tr>

2
doc/devel/uml/index_68.html
View file

@ -28,8 +28,8 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage128138" target = "projectFrame"><b>design</b></a></td><td>package</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage128005" target = "projectFrame"><b>design</b></a></td><td>package</td><td>All things concering the big picture.<br />Not a real code package, rather a container for design drafts, specifications, decisions.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refuse case128261" target = "projectFrame"><b>detect Channels</b></a></td><td>use case</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refopaque activity action128389" target = "projectFrame"><b>determine Render Params</b></a></td><td>opaque activity action</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refexpansion region128005" target = "projectFrame"><b>determine Render Params</b></a></td><td>expansion region</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refopaque activity action128389" target = "projectFrame"><b>determine Render Params</b></a></td><td>opaque activity action</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132613" target = "projectFrame"><b>devnull</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refcomponent128773" target = "projectFrame"><b>Dispatcher</b></a></td><td>component</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation134917" target = "projectFrame"><b>dispatchOp</b></a></td><td>operation</td><td></td></tr>

2
doc/devel/uml/index_69.html
View file

@ -24,8 +24,8 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refobject diagram128901" target = "projectFrame"><b>EDL Example2</b></a></td><td>object diagram</td><td>More 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</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation128005" target = "projectFrame"><b>edls</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137733.html#refclass137733" target = "projectFrame"><b>Effect</b></a></td><td>class</td><td>Effect or media processing component</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact129541" target = "projectFrame"><b>effect</b></a></td><td>artifact</td><td>EDL representation of a pluggable and automatable effect.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact137221" target = "projectFrame"><b>effect</b></a></td><td>artifact</td><td>Effect or media processing component</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact129541" target = "projectFrame"><b>effect</b></a></td><td>artifact</td><td>EDL representation of a pluggable and automatable effect.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129029.html#refclass129029" target = "projectFrame"><b>Effect</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation138885" target = "projectFrame"><b>elements</b></a></td><td>relation</td><td>relevant MObjects comprising this segment. TODO: actually necessary??</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation132997" target = "projectFrame"><b>enable</b></a></td><td>operation</td><td>change the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well</td></tr>

1
doc/devel/uml/index_70.html
View file

@ -35,7 +35,6 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact128773" target = "projectFrame"><b>fixture</b></a></td><td>artifact</td><td>the (low level) representation of the EDL with concrete placement data</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128261.html#refclass128261" target = "projectFrame"><b>Fixture</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refcomponent128517" target = "projectFrame"><b>Fixture</b></a></td><td>component</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation128261" target = "projectFrame"><b>fixture</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#reffork activity node129029" target = "projectFrame"><b>fork activity node</b></a></td><td>fork activity node</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128821.html#refclass128821" target = "projectFrame"><b>Frame</b></a></td><td>class</td><td>Frames 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.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refnode128645" target = "projectFrame"><b>Frame</b></a></td><td>node</td><td></td></tr>

2
doc/devel/uml/index_72.html
View file

@ -24,8 +24,8 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation133381" target = "projectFrame"><b>howtoProc</b></a></td><td>operation</td><td>@return descriptor how to build a render pipeline corresponding to this media</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class132101.html#refclass132101" target = "projectFrame"><b>Hub</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact132741" target = "projectFrame"><b>hub</b></a></td><td>artifact</td><td>special ProcNode used to build data distributing connections</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133893" target = "projectFrame"><b>HUE</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133253" target = "projectFrame"><b>HUE</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133893" target = "projectFrame"><b>HUE</b></a></td><td>class instance</td><td></td></tr>
</table>
</body>
</html>

2
doc/devel/uml/index_73.html
View file

@ -20,9 +20,9 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute130437" target = "projectFrame"><b>id</b></a></td><td>attribute</td><td>Asset primary key.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass diagram128309" target = "projectFrame"><b>In Memory Database</b></a></td><td>class diagram</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refactivity action pin128133" target = "projectFrame"><b>inFixture</b></a></td><td>activity action pin</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134149" target = "projectFrame"><b>input</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132869" target = "projectFrame"><b>input</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131461" target = "projectFrame"><b>input</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134149" target = "projectFrame"><b>input</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation131461" target = "projectFrame"><b>instance</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation143621" target = "projectFrame"><b>instructions</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass view129029" target = "projectFrame"><b>Interface</b></a></td><td>class view</td><td></td></tr>

2
doc/devel/uml/index_77.html
View file

@ -32,8 +32,8 @@
<tr bgcolor=#f0f0f0><td><a href="class139397.html#refclass139397" target = "projectFrame"><b>MediaFactory</b></a></td><td>class</td><td>specialized Asset Factory for configuring (new) media asset instances based on existing media files on disk; can create placeholder assets as well</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refmerge activity node128773" target = "projectFrame"><b>merge activity node</b></a></td><td>merge activity node</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137093.html#refclass137093" target = "projectFrame"><b>Meta</b></a></td><td>class</td><td>key abstraction: metadata and organisational asset</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact129669" target = "projectFrame"><b>meta</b></a></td><td>artifact</td><td>abstract base class of all MObjects representing meta data or processing instructions</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact136837" target = "projectFrame"><b>meta</b></a></td><td>artifact</td><td>key abstraction: metadata and organisational asset</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact129669" target = "projectFrame"><b>meta</b></a></td><td>artifact</td><td>abstract base class of all MObjects representing meta data or processing instructions</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129157.html#refclass129157" target = "projectFrame"><b>Meta</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact128261" target = "projectFrame"><b>mobject</b></a></td><td>artifact</td><td>Key Abstraction: A Media Object in the Session</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage130181" target = "projectFrame"><b>mobject</b></a></td><td>package</td><td>sourcecode package<br /><br />MObject Subsystem<br />including the Session (EDL), Builder and Processing Controller</td></tr>

4
doc/devel/uml/index_79.html
View file

@ -19,11 +19,11 @@
<tr bgcolor=#f0f0f0><td align=center><b>Name</b></td><td align=center><b>Kind</b></td><td align=center><b>Description</b></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute129029" target = "projectFrame"><b>offset</b></a></td><td>attribute</td><td>Offset the actual position by this (time) value relative to the anchor point. TODO: Representation?</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute130821" target = "projectFrame"><b>org</b></a></td><td>attribute</td><td>origin 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".</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131333" target = "projectFrame"><b>ouput</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133125" target = "projectFrame"><b>ouput</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134405" target = "projectFrame"><b>ouput</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class138117.html#refclass138117" target = "projectFrame"><b>OutPort</b></a></td><td>class</td><td>structural asset corresponding to some port generating media output</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131333" target = "projectFrame"><b>ouput</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact137605" target = "projectFrame"><b>outport</b></a></td><td>artifact</td><td>structural asset corresponding to some port generating media output</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation147973" target = "projectFrame"><b>outPort</b></a></td><td>relation</td><td>the Port this MObject wants to be conected to</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation132613" target = "projectFrame"><b>output</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refcomponent diagram128005" target = "projectFrame"><b>Overview</b></a></td><td>component diagram</td><td>This drawing shows the top level compoents and relations</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refdeployment diagram128261" target = "projectFrame"><b>Overview Render Engine</b></a></td><td>deployment diagram</td><td></td></tr>

3
doc/devel/uml/index_80.html
View file

@ -29,11 +29,14 @@
<tr bgcolor=#f0f0f0><td><a href="class128645.html#refclass128645" target = "projectFrame"><b>Placement</b></a></td><td>class</td><td>used to specify the position of a MObject in the EDL. This can be done in various ways (absolute, relative). <br />Placement at the same time acts as (refcounting) smart pointer for accessing the MObject.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation129413" target = "projectFrame"><b>play</b></a></td><td>operation</td><td>TODO: will probably be handled differently (see Cehteh)</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refnode128261" target = "projectFrame"><b>playlist</b></a></td><td>node</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class140421.html#refclass140421" target = "projectFrame"><b>Plug</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute128901" target = "projectFrame"><b>plugID</b></a></td><td>attribute</td><td>Identifier of the Plugin to be used</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class132485.html#refclass132485" target = "projectFrame"><b>PluginAdapter</b></a></td><td>class</td><td>Adapter used to integrage an effects processor in the render pipeline</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact133125" target = "projectFrame"><b>pluginadapter</b></a></td><td>artifact</td><td>Adapter for integrating various Effect processors in the render pipeline</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refnode128517" target = "projectFrame"><b>pnode</b></a></td><td>node</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute131461" target = "projectFrame"><b>point</b></a></td><td>attribute</td><td>identifying the point where the nodes should be attached</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class138117.html#refclass138117" target = "projectFrame"><b>Port</b></a></td><td>class</td><td>structural asset corresponding to some port for building a processing chain and generating media output</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation147717" target = "projectFrame"><b>ports</b></a></td><td>relation</td><td>the global ports (busses) of the session</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass view128138" target = "projectFrame"><b>Posix Threads Abstraction</b></a></td><td>class view</td><td>C++ wrapers for pthreads</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129077.html#refclass129077" target = "projectFrame"><b>Prefetch</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137605.html#refclass137605" target = "projectFrame"><b>Preview</b></a></td><td>class</td><td>alternative version of the media data, probably with lower resolution</td></tr>

2
doc/devel/uml/index_82.html
View file

@ -22,8 +22,8 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation142085" target = "projectFrame"><b>registry</b></a></td><td>relation</td><td>@internal Table or DB holding all registered asset instances.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact129925" target = "projectFrame"><b>relativelocation</b></a></td><td>artifact</td><td>Placement implemnetaion providing various ways of attaching a MObject to another one</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129413.html#refclass129413" target = "projectFrame"><b>RelativeLocation</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute128133" target = "projectFrame"><b>relType</b></a></td><td>attribute</td><td>the kind of relation denoted by this Placement</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class133893.html#refclass133893" target = "projectFrame"><b>RelType</b></a></td><td>class</td><td>the possible kinds of RelativePlacements</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute128133" target = "projectFrame"><b>relType</b></a></td><td>attribute</td><td>the kind of relation denoted by this Placement</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation132741" target = "projectFrame"><b>remove</b></a></td><td>operation</td><td>remove the given asset &lt;i&gt;together with all its dependants&lt;/i&gt; from the internal DB</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass diagram128389" target = "projectFrame"><b>Render Entities</b></a></td><td>class diagram</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refactivity parameter128005" target = "projectFrame"><b>Render Request</b></a></td><td>activity parameter</td><td></td></tr>

3
doc/devel/uml/index_83.html
View file

@ -46,8 +46,8 @@
<tr bgcolor=#f0f0f0><td><a href="class138885.html#refclass138885" target = "projectFrame"><b>SimpleClip</b></a></td><td>class</td><td>Elementary clip consisting of only one media stream</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128906.html#refclass128906" target = "projectFrame"><b>SmartPointer</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass view128266" target = "projectFrame"><b>SmartPointers</b></a></td><td>class view</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation141957" target = "projectFrame"><b>source</b></a></td><td>relation</td><td>media source of this clip</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation142469" target = "projectFrame"><b>source</b></a></td><td>relation</td><td>the media source this clip referes to</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation141957" target = "projectFrame"><b>source</b></a></td><td>relation</td><td>media source of this clip</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class133765.html#refclass133765" target = "projectFrame"><b>Source</b></a></td><td>class</td><td>Source Node: represents a media source to pull data from.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact134277" target = "projectFrame"><b>source</b></a></td><td>artifact</td><td>Representation of a Media source</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refdeployment diagram129797" target = "projectFrame"><b>Source Overview</b></a></td><td>deployment diagram</td><td></td></tr>
@ -64,6 +64,7 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass diagram131205" target = "projectFrame"><b>Struct-Asset Relations</b></a></td><td>class diagram</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation144901" target = "projectFrame"><b>subject</b></a></td><td>relation</td><td>Placement acts as smart pointer</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation144005" target = "projectFrame"><b>subPattern</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation147205" target = "projectFrame"><b>subTracks</b></a></td><td>relation</td><td>Child tracks in a tree structure</td></tr>
</table>
</body>
</html>

13
doc/devel/uml/index_84.html
View file

@ -19,35 +19,36 @@
<tr bgcolor=#f0f0f0><td align=center><b>Name</b></td><td align=center><b>Kind</b></td><td align=center><b>Description</b></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refactivity diagram129541" target = "projectFrame"><b>the render configuration flow</b></a></td><td>activity diagram</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute130181" target = "projectFrame"><b>theApp_</b></a></td><td>attribute</td><td>holds the single instance and triggers initialization</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation128261" target = "projectFrame"><b>theFixture</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation131717" target = "projectFrame"><b>theTimeline</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128138.html#refclass128138" target = "projectFrame"><b>Thread</b></a></td><td>class</td><td>We can basically reuse the Thread class design from cinelerra2, Thread becomes a baseclass for all Threads </td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute128261" target = "projectFrame"><b>time</b></a></td><td>attribute</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact134789" target = "projectFrame"><b>time</b></a></td><td>artifact</td><td>unified representation of a time point, including conversion functions</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class134917.html#refclass134917" target = "projectFrame"><b>Time</b></a></td><td>class</td><td>denotes a temporal position (time point), based on timeline start.<br /><br />investigate posix.4 realtime timers, wrap these here</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refnode128005" target = "projectFrame"><b>timeline</b></a></td><td>node</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation131717" target = "projectFrame"><b>timeline</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage129925" target = "projectFrame"><b>tool</b></a></td><td>package</td><td>sourcecode package<br /><br />Tools and Utilities <br />(separate from the main cinelrra binary)</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class140037.html#refclass140037" target = "projectFrame"><b>Tool</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class130693.html#refclass130693" target = "projectFrame"><b>ToolFactory</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact130565" target = "projectFrame"><b>toolfactory</b></a></td><td>artifact</td><td>supply of Tool implementations for the Builder</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class137989.html#refclass137989" target = "projectFrame"><b>Track</b></a></td><td>class</td><td>structural asset holding the configuration of a track in the EDL</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation147333" target = "projectFrame"><b>track</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refattribute128389" target = "projectFrame"><b>track</b></a></td><td>attribute</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact128901" target = "projectFrame"><b>track</b></a></td><td>artifact</td><td>descriptor for one track in the Session</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation147589" target = "projectFrame"><b>track</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact137477" target = "projectFrame"><b>track</b></a></td><td>artifact</td><td>structural asset holding the configuration of a track in the EDL</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact128901" target = "projectFrame"><b>track</b></a></td><td>artifact</td><td>descriptor for one track in the Session</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128389.html#refclass128389" target = "projectFrame"><b>Track</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation142341" target = "projectFrame"><b>tracks</b></a></td><td>relation</td><td>elementary media assets comprising this compound</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation128645" target = "projectFrame"><b>tracks</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation129541" target = "projectFrame"><b>tracks</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class131845.html#refclass131845" target = "projectFrame"><b>Trafo</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact132485" target = "projectFrame"><b>trafo</b></a></td><td>artifact</td><td>transforming processing Node </td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation134405" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation129797" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td>This operation is to be overloaded for the specific MObject subclasses to be treated.</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130565" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130437" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130693" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130437" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130309" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130181" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130053" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation129925" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation130053" target = "projectFrame"><b>treat</b></a></td><td>operation</td><td></td></tr>
</table>
</body>
</html>

10
doc/devel/uml/index_86.html
View file

@ -22,21 +22,21 @@
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact134021" target = "projectFrame"><b>vframe</b></a></td><td>artifact</td><td>a buffer and render process holding a Video frame</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133381" target = "projectFrame"><b>vid1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131973" target = "projectFrame"><b>vid1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134021" target = "projectFrame"><b>vid_a</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129413" target = "projectFrame"><b>vid_A</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131717" target = "projectFrame"><b>vid_a</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129925" target = "projectFrame"><b>vid_A</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128645" target = "projectFrame"><b>vid_A</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134533" target = "projectFrame"><b>video</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134021" target = "projectFrame"><b>vid_a</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129413" target = "projectFrame"><b>vid_A</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance131077" target = "projectFrame"><b>video</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133765" target = "projectFrame"><b>video</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132741" target = "projectFrame"><b>video</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134277" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134533" target = "projectFrame"><b>video</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance132997" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance129157" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128517" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance134277" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance133637" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance130949" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refclass instance128517" target = "projectFrame"><b>video1</b></a></td><td>class instance</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class140165.html#refclass140165" target = "projectFrame"><b>Visitable</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refpackage130949" target = "projectFrame"><b>visitor</b></a></td><td>package</td><td>sub-namespace for visitor library implementation</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refartifact139141" target = "projectFrame"><b>visitor</b></a></td><td>artifact</td><td>Acyclic Visitor library</td></tr>

2
doc/devel/uml/index_87.html
View file

@ -19,7 +19,7 @@
<tr bgcolor=#f0f0f0><td align=center><b>Name</b></td><td align=center><b>Kind</b></td><td align=center><b>Description</b></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation131845" target = "projectFrame"><b>what</b></a></td><td>operation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refoperation131717" target = "projectFrame"><b>what</b></a></td><td>operation</td><td>the base class of all exceptions thrown by the standard library</td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation144389" target = "projectFrame"><b>wiringTemplate</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation148229" target = "projectFrame"><b>wiringTemplate</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class130053.html#refclass130053" target = "projectFrame"><b>Wish</b></a></td><td>class</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="index.html#refrelation130058" target = "projectFrame"><b>write_buffer</b></a></td><td>relation</td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class129162.html#refclass129162" target = "projectFrame"><b>WriteBuffer</b></a></td><td>class</td><td></td></tr>

1
doc/devel/uml/public_properties.html
View file

@ -24,6 +24,7 @@
<tr bgcolor=#f0f0f0><td><a href="class139141.html#refrelation144133"><b>nodes</b></a></td><td><a href="class139141.html#refclass139141"><b>DoAttach</b></a></td><td></td></tr>
<tr bgcolor=#f0f0f0><td><a href="class136453.html#refattribute130821"><b>org</b></a></td><td><a href="class136453.html#refclass136453"><b>Asset</b></a></td><td>origin 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".</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class139141.html#refattribute131461"><b>point</b></a></td><td><a href="class139141.html#refclass139141"><b>DoAttach</b></a></td><td>identifying the point where the nodes should be attached</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class128389.html#refrelation147205"><b>subTracks</b></a></td><td><a href="class128389.html#refclass128389"><b>Track</b></a></td><td>Child tracks in a tree structure</td></tr>
<tr bgcolor=#f0f0f0><td><a href="class136453.html#refattribute130949"><b>version</b></a></td><td><a href="class136453.html#refclass136453"><b>Asset</b></a></td><td>version 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.</td></tr>
</table>
</body>

34
uml/cinelerra3/128133
View file

@ -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 // <generalisation>
b multiplicity "" parent class_ref 136965 // Struct
end
classrelation 144389 // wiringTemplate (<unidirectional association>)
relation 142469 --->
a role_name "wiringTemplate" multiplicity "1" protected
cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
"
classrelation_ref 144389 // wiringTemplate (<unidirectional association>)
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 // <generalisation>
relation 139653 ---|>
a public
@ -714,6 +705,23 @@ ${inlines}
classrelation_ref 141445 // <generalisation>
b multiplicity "" parent class_ref 136965 // Struct
end
classrelation 148101 // <dependency>
relation 145925 -_->
a default
cpp default "#include in header"
classrelation_ref 148101 // <dependency>
b multiplicity "" parent class_ref 138757 // ProcPatt
end
classrelation 148229 // wiringTemplate (<unidirectional association>)
relation 146053 --->
a role_name "wiringTemplate" multiplicity "0..1" protected
cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
"
classrelation_ref 148229 // wiringTemplate (<unidirectional association>)
b multiplicity "" parent class_ref 138757 // ProcPatt
end
end
class 138757 "ProcPatt"

88
uml/cinelerra3/128133.diagram
View file

@ -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 // <directional aggregation by value>
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 // <unidirectional association>
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 // <generalisation>
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 // <directional aggregation by value>
geometry HV
from ref 128133 z 1999 stereotype "<<list>>" 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 // <directional aggregation by value>
geometry HV
from ref 128261 z 1999 stereotype "<<list>>" 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 // <directional aggregation>
geometry VH
from ref 128133 z 1999 stereotype "<<list>>" xyz 258 547 3000 to point 252 167
from ref 128133 z 1999 stereotype "<<list>>" 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 // <generalisation>
no_multiplicity_a no_multiplicity_b
relationcanvas 135941 relation_ref 131077 // <directional aggregation by value>
from ref 128261 z 1999 stereotype "<<list>>" 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 // <unidirectional association>
from ref 135813 z 1999 to point 433 897
@ -198,7 +196,7 @@ relationcanvas 138245 relation_ref 131717 // <generalisation>
no_multiplicity_a no_multiplicity_b
relationcanvas 138757 relation_ref 137093 // <directional aggregation>
geometry VHr
from ref 138629 z 1999 stereotype "<<list>>" xyz 479 716 3000 to point 517 714
from ref 138629 z 1999 stereotype "<<list>>" 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 // <generalisation>
no_role_a no_role_b
no_multiplicity_a no_multiplicity_b
relationcanvas 139525 relation_ref 142725 // <realization>
from ref 128005 z 1999 stereotype "<<PImpl>>" xyz 57 558 3000 to ref 139269
from ref 128005 z 1999 stereotype "<<PImpl>>" xyz 56 594 3000 to ref 139269
no_role_a no_role_b
no_multiplicity_a no_multiplicity_b
relationcanvas 139781 relation_ref 142853 // <unidirectional association>
@ -251,4 +249,36 @@ relationcanvas 144517 relation_ref 143877 // <unidirectional association>
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 // <generalisation>
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 // <directional aggregation by value>
from ref 129029 z 1999 stereotype "<<vector>>" 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 // <unidirectional association>
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 // <unidirectional association>
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 // <directional aggregation>
from ref 128005 z 1999 to point 311 616
line 146309 z 1999 stereotype "<<vector>>" 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 // <generalisation>
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 // <unidirectional association>
from ref 146437 z 1999 to ref 146053
role_a_pos 398 594 3000 no_role_b
no_multiplicity_a no_multiplicity_b
end

115
uml/cinelerra3/128261
View file

@ -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 (<unidirectional association>)
classrelation 128261 // theFixture (<unidirectional association>)
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 (<unidirectional association>)
classrelation_ref 128261 // theFixture (<unidirectional association>)
b multiplicity "" parent class_ref 128261 // Fixture
end
@ -144,6 +144,17 @@ ${inlines}
classrelation_ref 144645 // <realization>
b multiplicity "" parent class_ref 139653 // Session
end
classrelation 147717 // ports (<directional aggregation>)
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 (<directional aggregation>)
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 (<directional aggregation by value>)
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 (<directional aggregation by value>)
b multiplicity "" parent class_ref 128389 // Track
end
classrelation 128901 // clips (<directional aggregation>)
relation 128517 o-->
stereotype "list"
@ -260,6 +261,16 @@ ${inlines}
classrelation_ref 128901 // clips (<directional aggregation>)
b multiplicity "" parent class_ref 128517 // MObject
end
classrelation 147333 // track (<unidirectional association>)
relation 145157 --->
a role_name "track" multiplicity "" protected
cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
"
classrelation_ref 147333 // track (<unidirectional association>)
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 (<directional aggregation by value>)
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 (<directional aggregation by value>)
b multiplicity "" parent class_ref 128389 // Track
end
classrelation 131717 // timeline (<directional aggregation by value>)
classrelation 131717 // theTimeline (<directional aggregation by value>)
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 (<directional aggregation by value>)
classrelation_ref 131717 // theTimeline (<directional aggregation by value>)
b multiplicity "" parent class_ref 129797 // ExplicitPlacement
end
@ -330,6 +331,16 @@ ${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl}
end
classrelation 147589 // track (<unidirectional association>)
relation 145413 --->
a role_name "track" multiplicity "" protected
cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
"
classrelation_ref 147589 // track (<unidirectional association>)
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 // <generalisation>
relation 144901 ---|>
a public
cpp default "${type}"
classrelation_ref 147077 // <generalisation>
b multiplicity "" parent class_ref 129157 // Meta
end
classrelation 147205 // subTracks (<directional aggregation by value>)
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 (<directional aggregation by value>)
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 // <generalisation>
relation 145669 ---|>
a public
cpp default "${type}"
classrelation_ref 147845 // <generalisation>
b multiplicity "" parent class_ref 130053 // Wish
end
classrelation 147973 // outPort (<unidirectional association>)
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 (<unidirectional association>)
b multiplicity "" parent class_ref 138117 // Port
end
end
class 134533 "Parameter"
visibility public
nformals 1

2
uml/cinelerra3/129285
View file

@ -1,6 +1,6 @@
format 40
"ProcessingLayer" // ProcessingLayer
revision 9
revision 11
modified_by 5 "hiv"
// class settings
//class diagram settings

9
uml/cinelerra3/130309.diagram
View file

@ -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 // <generalisation>
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 // <dependency>
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

131
uml/cinelerra3/130437
View file

@ -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 "/*

59
uml/cinelerra3/131205.diagram
View file

@ -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 // <generalisation>
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 // <generalisation>
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 // <generalisation>
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 // <directional aggregation by value>
from ref 128389 z 1999 stereotype "<<vector>>" 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 "<<vector>>" 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 // <generalisation>
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 // <directional aggregation>
from ref 128645 z 1999 stereotype "<<vector>>" 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 "<<vector>>" 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 // <generalisation>
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 // <unidirectional association>
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 // <unidirectional association>
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 // <unidirectional association>
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

23
uml/cinelerra3/5.session
View file

@ -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

2
uml/cinelerra3/cinelerra3.prj
View file

@ -1,6 +1,6 @@
format 40
"cinelerra3"
revision 39
revision 41
modified_by 5 "hiv"
cpp_root_dir "../../src/"

194
wiki/renderengine.html
View file

@ -514,12 +514,12 @@ ColorPalette
SiteUrl</pre>
</div>
<div title="Asset" modifier="Ichthyostega" modified="200710092321" created="200708100337" tags="def classes" changecount="14">
<pre>Asset management is a subsystem on its own. Assets are &quot;things&quot; that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the &quot;bookkeeping view&quot;, while the EDL is the &quot;manipulation and process view&quot;. 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.
<div title="Asset" modifier="Ichthyostega" modified="200801061942" created="200708100337" tags="def classes" changecount="15">
<pre>Asset management is a subsystem on its own. Assets are &quot;things&quot; that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the &quot;bookkeeping view&quot;, while the EDL is the &quot;manipulation and process view&quot;. 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.
&amp;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
&amp;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...
&amp;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
<div title="AssetManager" modifier="Ichthyostega" created="200709200300" changecount="1">
<pre>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.</pre>
</div>
<div title="AttachedPlacementProblem" modifier="Ichthyostega" modified="200801121214" created="200801111305" tags="impl draft dynamic" changecount="2">
<pre>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.</pre>
</div>
<div title="Automation" modifier="Ichthyostega" modified="200708100315" created="200706250751" tags="def" changecount="5">
<pre>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]]
</pre>
</div>
<div title="BasicBuildingOperations" modifier="Ichthyostega" modified="200712100627" created="200712040334" tags="design dynamic def Builder" changecount="20">
<div title="BasicBuildingOperations" modifier="Ichthyostega" modified="200801111146" created="200712040334" tags="design dynamic Builder" changecount="22">
<pre>Starting out from the concepts of Objects, Placement to Tracks, Ports and connection properties (&amp;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 &amp;mdash; in the most general case &amp;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</pre>
</div>
<div title="ConfigQuery" modifier="Ichthyostega" modified="200801181309" created="200801181308" tags="def" changecount="4">
<pre>Configuration Queries are requests to the system to &quot;create or retrieve an object with //this and that // capabilities&quot;. 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&lt;Port&gt; (&quot;stream(mpeg)&quot;)}}} requests a port excepting/delivering mpeg stream data &amp;mdash; and it depends on the current configuration what &quot;mpeg&quot; 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.
&amp;rarr; [[Configuration Rules system|ConfigRules]]
</pre>
</div>
<div title="ConfigRules" modifier="Ichthyostega" modified="200801202311" created="200801171352" tags="overview spec" changecount="7">
<pre>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 &quot;stream&quot; is the //predicate, // meaning here &quot;the stream type is...?&quot; and &quot;mpeg&quot; is a //term // denoting an actual property, object, thing, number etc &amp;mdash; the actual kind of stream in the given example. Multible comma separated predicates are combined with logical &quot;and&quot;. 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&lt;TYPE&gt;}}} template, because their actual meaning is &quot;retrieve or create an object of TYPE, configured such that...!&quot;. 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 &quot;{{{object(tYPE)}}}&quot;
!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 &amp;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.
&amp;rarr; [[considerations for a Prolog based implementation|QueryImplProlog]]
</pre>
</div>
<div title="Controller" modifier="Ichthyostega" modified="200712090624" created="200706220319" tags="def" changecount="4">
<pre>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
<pre>RenderEngine
</pre>
</div>
<div title="DesignGoals" modifier="Ichthyostega" modified="200711122343" created="200706210557" tags="design" changecount="13">
<div title="DefaultsManagement" modifier="Ichthyostega" modified="200801171440" created="200801121708" tags="def spec" changecount="5">
<pre>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-&gt;default(Query&lt;TYPE&gt; (&quot;query string&quot;))}}}, 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]]
</pre>
</div>
<div title="DesignDecisions" modifier="Ichthyostega" modified="200801062304" created="200801062209" tags="decision design discuss" changecount="17">
<pre>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'' &amp;mdash; of course, that's a //no-brainer // todays. Rather, important is what is not &quot;an object&quot;, 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 &quot;opened&quot;, 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 &quot;have&quot; a port or &quot;is&quot; 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]] &amp;mdash; and that's all. No special &quot;media viewer&quot; and &quot;arranger&quot;, 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 &quot;parameter&quot; 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 &quot;bezier automation&quot;, and then maybe a &quot;linear automation&quot;, a &quot;mask automation&quot; and yet another way to handle transitions)
</pre>
</div>
<div title="DesignGoals" modifier="Ichthyostega" modified="200801062154" created="200706210557" tags="design" changecount="16">
<pre>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.&lt;br&gt;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
&amp;rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
</pre>
</div>
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200801041015" created="200708080322" tags="overview" changecount="15">
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200801171322" created="200708080322" tags="overview" changecount="20">
<pre>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]] &amp;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]]
</pre>
</div>
<div title="ImplementationGuidelines" modifier="Ichthyostega" modified="200711210542" created="200711210531" tags="discuss draft" changecount="7">
@ -1502,8 +1558,8 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
&lt;style type=&quot;text/css&quot;&gt;#contentWrapper {display:none;}&lt;/style&gt;&lt;div id=&quot;SplashScreen&quot; style=&quot;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;&quot;&gt;loading &lt;b&gt;Cinelerra Renderengine&lt;/b&gt; devel doku&lt;blink&gt; ...&lt;/blink&gt;&lt;br&gt;&lt;br&gt;&lt;span style=&quot;font-size: 14px; color:red;&quot;&gt;Requires Javascript.&lt;/span&gt;&lt;/div&gt;</pre>
</div>
<div title="MediaAsset" modifier="Ichthyostega" modified="200709221337" created="200709021530" tags="def classes" changecount="2">
<pre>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__ &amp;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.
<div title="MediaAsset" modifier="Ichthyostega" modified="200801101307" created="200709021530" tags="def classes" changecount="5">
<pre>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__ &amp;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]]
</pre>
</div>
@ -2193,7 +2249,7 @@ Placements have //value semantics,// i.e. we don't stress the identity of a plac
</pre>
</div>
<div title="PlanningBuildFixture" modifier="Ichthyostega" modified="200712100633" created="200712100445" tags="impl Builder" changecount="10">
<div title="PlanningBuildFixture" modifier="Ichthyostega" modified="200801061937" created="200712100445" tags="impl Builder draft" changecount="11">
<pre>//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.
&lt;&lt;tasksum end&gt;&gt;
</pre>
</div>
<div title="PlanningNodeCreaterTool" modifier="Ichthyostega" modified="200712100626" created="200712090659" tags="impl Builder" changecount="6">
<div title="PlanningNodeCreaterTool" modifier="Ichthyostega" modified="200801111250" created="200712090659" tags="impl Builder draft" changecount="8">
<pre>//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&lt;Clip&gt;}}}
&lt;&lt;task&gt;&gt;get the ProcPatt of the underlying media (asset)
&lt;&lt;task&gt;&gt;process the ProcPatt recursively
&lt;&lt;task&gt;&gt;create or access? {{red{TODO: decide this}}} the ClipSourcePort
&lt;&lt;task&gt;&gt;access the ClipSourcePort (which may be created on-the-fly)
&lt;&lt;task&gt;&gt;enqueue an WiringRequest for connecting the source pipeline to the source port
&lt;&lt;task&gt;&gt;process the source port recursively (thus adding the camera etc.)
&lt;&lt;task&gt;&gt;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//
</pre>
</div>
<div title="Port" modifier="Ichthyostega" modified="200801062330" created="200801062110" tags="def decision" changecount="4">
<pre>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 &quot;input&quot; and &quot;output&quot; ports &amp;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 &amp;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.
&amp;rarr; [[Handling of Tracks|TrackHandling]]
&amp;rarr; [[Handling of Ports|PortHandling]]
</pre>
</div>
<div title="PortHandling" modifier="Ichthyostega" modified="200801121656" created="200801101352" tags="spec" changecount="9">
<pre>!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 &quot;detaching&quot; 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]] &amp;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 &amp;mdash; contrary to the stream type &amp;mdash; this pattern may be switched
</pre>
</div>
<div title="ProblemsTodo" modifier="Ichthyostega" modified="200709251721" created="200708050524" tags="design discuss" changecount="15">
<pre>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
<pre>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
</pre>
</div>
<div title="QueryImplProlog" modifier="Ichthyostega" modified="200801210153" created="200801202321" tags="draft design" changecount="11">
<pre>//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 (&quot;declarative&quot;) 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 &quot;mpeg&quot; 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 &quot;stream(P,mpeg)&quot; implemented (natively) for the port object. So, &quot;Cap&quot; is the query issued from calling code &amp;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 &quot;Cap&quot; (and consequently run as a goal by {{{call(Q)}}}). The implementation needs to provide a symbol table associating variable terms (like &quot;T&quot; or &quot;P&quot;) 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 &quot;type&quot; 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 &quot;executed&quot;, 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.
</pre>
</div>
<div title="RSSReaderPlugin" modifier="Ichthyostega" created="200708081515" tags="systemConfig" changecount="1">
<pre>/***
|''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 &quot;clip-thing&quot;. 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??</pre>
</div>
<div title="RenderEngine" modifier="Ichthyostega" modified="200711122340" created="200706190056" tags="overview" changecount="44">
<div title="RenderEngine" modifier="Ichthyostega" modified="200801062200" created="200706190056" tags="overview" changecount="45">
<pre>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.
&lt;&lt;&lt;
''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
&amp;rarr; BuildProcess and RenderProcess
&amp;rarr; [[Two Examples|Examples]] (Object diagrams)
&amp;rarr; how [[Automation]] works {{red{to be defined in more detail}}}
&amp;rarr; [[Problems|ProblemsTodo]] {{red{to be solved}}}
&amp;rarr; [[Problems|ProblemsTodo]] to be solved and notable [[design decisions|DesignDecisions]]
&amp;rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
</pre>
</div>
@ -2643,14 +2748,14 @@ The Session object is a singleton &amp;mdash; actually it is a »~PImpl«-Facade
* a collection of ''global Ports''
* the ''Fixture'' with a possibility to [[(re)build it|PlanningBuildFixture]]</pre>
</div>
<div title="SessionOverview" modifier="Ichthyostega" modified="200712100615" created="200709272105" tags="design" changecount="13">
<pre>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.
<div title="SessionOverview" modifier="Ichthyostega" modified="200801061947" created="200709272105" tags="design" changecount="15">
<pre>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 &quot;the&quot; 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
</pre>
</div>
<div title="StructAsset" modifier="Ichthyostega" created="200709221353" tags="def classes" changecount="1">
<pre>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...}}}
<div title="StructAsset" modifier="Ichthyostega" modified="200801101402" created="200709221353" tags="def classes" changecount="8">
<pre>Structural Assets are intended mainly for internal use, but the user should be able to see and query them. They are not &quot;loaded&quot; or &quot;created&quot; 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 &amp;mdash; at least as visible to the user &amp;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...)
[&gt;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]]
</pre>
!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&lt;Port&gt; (&quot;stream(mpeg)&quot;)}}}, yieliding the first port found which declares to have stream type &quot;mpeg&quot;</pre>
</div>
<div title="StyleSheet" modifier="Ichthyostega" modified="200709040043" created="200701131624" tags="MPTWTheme excludeMissing" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706090017" changecount="14">
<pre>/*{{{*/
@ -3931,7 +4037,18 @@ function addKeyDownHandlers(e)
</pre>
</div>
<div title="TrackPortEDL" modifier="Ichthyostega" modified="200712100628" created="200711300405" tags="design discuss def decision Builder" changecount="21">
<div title="Track" modifier="Ichthyostega" modified="200801062330" created="200801062320" tags="def design decision" changecount="3">
<pre>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 &quot;have&quot; a port or &quot;is&quot; 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.
&amp;rarr; [[Handling of Tracks|TrackHandling]]
&amp;rarr; [[Handling of Ports|PortHandling]]
</pre>
</div>
<div title="TrackPortEDL" modifier="Ichthyostega" modified="200801062328" created="200711300405" tags="design discuss def decision Builder" changecount="26">
<pre>''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 &quot;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 &quot;objects on a timeline&quot;. 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 &quot;placed to port X&quot; as &quot;plug into port X&quot;)
* 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]]</pre>
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]]
&amp;rarr; [[Definition|Track]] and [[handling of Tracks|TrackHandling]]
&amp;rarr; [[Definition|Port]] and [[handling of Ports|PortHandling]]
</pre>
</div>
<div title="TransitionsHandling" modifier="Ichthyostega" created="200712080417" tags="def design" changecount="1">
<div title="TransitionsHandling" modifier="Ichthyostega" modified="200801061213" created="200712080417" tags="def design" changecount="2">
<pre>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 &quot;simple&quot; 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.