WIP defined lots of details regarding the handling of Ports

This commit is contained in:
Fischlurch 2008-01-12 18:19:37 +01:00
parent d255d68d35
commit b7bce2a2f7
18 changed files with 368 additions and 66 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View file

@ -92,6 +92,14 @@ namespace util
return set.end() != set.find (val);
}
/** shortcut for string value containment test */
template <typename T>
inline bool
contains (std::string& str, const T& val)
{
return str.find (val) != std::string::npos;
}
/** shortcut for brute-force containment test
* in any sequencial container */
template <typename SEQ>

View file

@ -25,6 +25,33 @@
namespace asset
{
namespace // Port Asset implementation details
{
/** @internal derive a sensible asset ident tuple when creating
* a track asset based on a query
* @todo define the actual naming scheme of struct assets
*/
const Asset::Ident
createPortIdent (PProcPatt& wiring, string& id, wstring& shortD, wstring& longD)
{
string name ("port-" + id); // TODO something sensible here; append number, sanitize etc.
TODO ("Implement port name scheme!!");
Category category (STRUCT,"ports");
return Asset::Ident (name, category );
}
}
/** */
Port::Port (PProcPatt& wiring, string portID="", wstring shortDesc="", wstring longDesc="")
: Struct (createPortIdent (wiring,portID,shortDesc,longDesc)),
portID_ (portID),
shortDesc_ (shortDesc),
longDesc_ (longDesc)
{
}

View file

@ -31,8 +31,20 @@
namespace asset
{
class Port;
template<>
class ID<Port> : public ID<Struct>
{
public:
ID (size_t id);
ID (const Port&);
};
/**
* structural asset corresponding to some port
* for building a processing chain and
@ -40,12 +52,27 @@ namespace asset
*/
class Port : public Struct
{
PProcPatt wiringTemplate;
string portID_;
wstring shortDesc_;
wstring longDesc_;
protected:
ProcPatt* wiringTemplate;
Port (PProcPatt& wiring, string portID="", wstring shortDesc="", wstring longDesc="") ;
friend class StructFactory;
};
// catch up with postponed definition of ID<Struct> ctors...
//
inline ID<Port>::ID(size_t id) : ID<Struct> (id) {};
inline ID<Port>::ID(const Port& port) : ID<Struct> (port.getID()) {};
typedef shared_ptr<asset::Port> PPort;
} // namespace asset
#endif

View file

@ -50,6 +50,8 @@ namespace asset
};
typedef shared_ptr<const asset::ProcPatt> PProcPatt;
} // namespace asset

View file

@ -31,21 +31,21 @@
namespace asset
{
namespace // Implementation details
{
/** @internal derive a sensible asset ident tuple when creating
* a track asset based on a query
* @todo define the actual naming scheme of struct assets
*/
const Asset::Ident
createTrackIdent (Query<Track>& query)
{
string name ("track-" + query); // TODO something sensible here; append number, sanitize etc.
TODO ("track naming scheme??");
Category category (STRUCT,"tracks");
return Asset::Ident (name, category );
}
}
namespace // common Struct Asset implementation details
{
/** @internal derive a sensible asset ident tuple when creating
* a track asset based on a query
* @todo define the actual naming scheme of struct assets
*/
const Asset::Ident
createTrackIdent (Query<Track>& query)
{
string name ("track-" + query); // TODO something sensible here; append number, sanitize etc.
TODO ("track naming scheme??");
Category category (STRUCT,"tracks");
return Asset::Ident (name, category );
}
}

View file

@ -43,6 +43,7 @@
#include<string>
using std::string;
using std::wstring;
namespace asset
@ -77,7 +78,7 @@ namespace asset
}
protected:
Struct (const Asset::Ident& idi) : Asset(idi) {} //////////////TODO
Struct (const Asset::Ident& idi) : Asset(idi) {}
friend class StructFactory;
};

View file

@ -235,6 +235,7 @@ namespace asset
#include "proc/asset/proc.hpp"
#include "proc/asset/struct.hpp"
#include "proc/asset/track.hpp"
#include "proc/asset/port.hpp"
#include "proc/asset/meta.hpp"
@ -254,6 +255,7 @@ namespace asset
template shared_ptr<Media> AssetManager::getPtr (const Media& asset);
template shared_ptr<Clip> AssetManager::getPtr (const Clip& asset);
template shared_ptr<Track> AssetManager::getPtr (const Track& asset);
template shared_ptr<Port> AssetManager::getPtr (const Port& asset);
} // namespace asset

View file

@ -60,6 +60,12 @@ namespace mobject
/** startpos in source */
Time start_;
/** @todo using a mere ref here is against the scheme and only
done as temporal solution, until we work out how to handle
multichannel clips. It should be a smart pointer of some kind
and the unlink() function of the asset should take it into
account when breaking circular references.
*/
const Media & mediaDef_;
const asset::Clip & clipDef_;

View file

@ -34,6 +34,14 @@ return: 0
END
PLANNED "BasicPort_test" BasicPort_test <<END
END
PLANNED "BasicTrack_test" BasicTrack_test <<END
END
TEST "MakeClip_test" MakeClip_test <<END
return: 0
END

View file

@ -0,0 +1,194 @@
/*
BasicPort(Test) - checking the basic properties of Port Assets
Copyright (C) CinelerraCV
2007, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
#include "common/test/run.hpp"
#include "common/util.hpp"
#include "proc/asset/category.hpp"
#include "proc/asset/port.hpp"
#include "proc/assetmanager.hpp"
#include "proc/mobject/session.hpp"
#include "proc/asset/assetdiagnostics.hpp"
#include <boost/format.hpp>
#include <iostream>
using boost::format;
using util::contains;
using util::isnil;
using std::string;
using std::cout;
namespace asset
{
namespace test
{
/***********************************************************************
* @test basic properties of Port (structural) Assets.
* <ul><li>created by referral</li>
* <li>access existing port by referral</li>
* <li>create with full properties</li>
* <li>access ProcPatt</li>
* <li>check dependency</li>
* </ul>
*/
class BasicPort_test : public Test
{
virtual void run(Arg arg)
{
string portID = isnil(arg)? "blackHole" : arg[1];
string streamID = 2>arg.size()? "teststream" : arg[2] ;
createExplicit (portID,streamID);
create_or_ref (portID);
dependProcPatt (portID);
}
void createExplicit (string pID, string sID)
{
PPort thePort = asset::Struct::create (pID,sID);
ASSERT (thePort);
ASSERT (thePort->getProcPatt());
ASSERT (thePort->getPortID() == util::sanitize(pID));
ASSERT (thePort->getProcPatt()->getStreamID() == sID);
ASSERT (thePort->getShortDesc() == thePort->getPortID());
ID<Port> assetID = thePort->getID();
ASSERT (assetID.org = "cin3");
ASSERT (contains (assetID.name, thePort->getPortID()));
ASSERT (contains (assetID.name, thePort->getProcPatt()->getStreamID()));
Category cat (assetID.category);
Category refcat (STRUCT,"ports");
ASSERT ( cat.hasKind(STRUCT) );
ASSERT ( cat.isWithin(refcat) );
}
void create_or_ref(string pID)
{
pID = util::sanitize (pID);
PPort port1 = asset::Struct::query<Port> ("port("+pID+")");
ASSERT (port1);
ASSERT (port1->getPortID() == pID);
string pID2 = "another-" + pID;
PPort port2 = asset::Struct::query<Port> ("port("+pID2+")");
ASSERT (port2);
ASSERT (port2 != port1);
Category c1 = port1->getID().category;
Category c2 = port2->getID().category;
ASSERT (c1 == c2);
PPort port3 = asset::Struct::query<Port> ("port("+pID2+")");
ASSERT (port3 == port2);
}
void create_using_default()
{
PPort port1 = asset::Struct::query<Port> ("");
ASSERT (port1);
ASSERT (port1 == mobject::Session::current->getDefault<Port>());
ASSERT (port1->getID().category.hasKind(VIDEO));
ASSERT (port1->getProcPatt());
PProcPatt popa = mobject::Session::current->getDefault<ProcPatt>("port()");
ASSERT (popa == port1->getProcPatt());
PPort port2 = asset::Struct::query<Port> ("port()");
ASSERT (port2 == port1);
string sID = popa->getStreamID(); // sort of a "default stream type"
PPort port3 = asset::Struct::query<Port> ("stream("+sID+")");
ASSERT (port3);
ASSERT (port3->getProcPatt()->getStreamID() == sID);
ASSERT (port3->getProcPatt() == mobject::Session::current->getDefault<ProcPatt>("stream("+sID+")");
}
void dependProcPatt(string pID)
{
PPort thePort = asset::Struct::query<Port> ("port("+pID+")");
ASSERT (thePort);
PProcPatt thePatt = thePort->getProcPatt();
ASSERT (thePatt);
ASSERT (dependencyCheck (thePort, thePatt));
PProcPatt pattern2 = thePatt->newCopy("another");
ASSERT (thePatt != pattern2);
ASSERT (!dependencyCheck (thePort, pattern2));
TODO ("add something to the new pattern, e.g. an effect");
// now querying for a port using this pattern (created on-the-fly)
// note: because the pattern is new, this new port will be used as
// default port for this pattern automatically
PPort port2x = asset::Struct::query<Port> ("pattern(another)");
ASSERT (pattern2 == port2x->getProcPatt());
ASSERT (port2x == mobject::Session::current->getDefault<Port>("pattern(another)"));
thePort->switchProcPatt(pattern2);
ASSERT ( dependencyCheck (thePort, pattern2));
ASSERT (!dependencyCheck (thePort, thePatt));
AssetManager& aMang = AssetManager::instance();
ASSERT ( aMang.known (thePort->getID()));
ASSERT ( aMang.known (thePatt->getID()));
ASSERT ( aMang.known (pattern2->getID()));
aMang.remove (pattern2->getID());
ASSERT ( aMang.known (thePatt->getID()));
ASSERT (!aMang.known (pattern2->getID()));
ASSERT (!aMang.known (thePort->getID())); // has been unlinked too, because dependant on pattern2
ASSERT (thePort);
ASSERT (thePort->getProcPatt());
ASSERT (thePort->getProcPatt() == pattern2); // but is still valid, as long as the ref is alive....
PPort port3x = asset::Struct::query<Port> ("pattern(another)");
ASSERT (port3x->getProcPatt() != pattern2); // because pattern2 is already unlinked...
ASSERT (port3x == mobject::Session::current->getDefault<Port>("pattern(another)"));
ASSERT (port3x != port2x); // ..we got a new default port for "pattern(another)" too!
TRACE (assetmem, "leaving BasicPort_test::dependProcPatt()");
// expect now port2x and pattern2 to be destroyed...
}
};
/** Register this test class... */
LAUNCHER (BasicPort_test, "unit asset");
} // namespace test
} // namespace asset

View file

@ -1,5 +1,5 @@
/*
DependantAssets(Test) - unittest for the object creating factory
DependantAssets(Test) - check the asset dependency handling
Copyright (C) CinelerraCV
2007, Hermann Vosseler <Ichthyostega@web.de>

View file

@ -1,6 +1,6 @@
format 40
"Asset" // ProcessingLayer::Asset
revision 16
revision 17
modified_by 5 "hiv"
// class settings
//class diagram settings
@ -684,7 +684,6 @@ ${inlines}
classrelation_ref 141317 // <generalisation>
b multiplicity "" parent class_ref 136965 // Struct
end
end
class 138117 "Port"
@ -710,7 +709,7 @@ ${inlines}
classrelation 148101 // <dependency>
relation 145925 -_->
a default
cpp default "Generated"
cpp default "#include in header"
classrelation_ref 148101 // <dependency>
b multiplicity "" parent class_ref 138757 // ProcPatt
end

View file

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

View file

@ -2,83 +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 // 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 516 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 536 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 637 314 3000 to ref 128133
role_a_pos 640 329 3000 no_role_b
multiplicity_a_pos 668 366 3000 multiplicity_b_pos 743 320 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 131461 relation_ref 142085 // <unidirectional association>
from ref 128901 z 1999 to point 747 424
line 131845 z 1999 to point 747 348
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 719 362 3000 no_role_b
multiplicity_a_pos 707 329 3000 multiplicity_b_pos 727 436 3000
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 536 295
from ref 128517 z 1999 to point 260 267
line 131717 z 1999 to ref 128389
role_a_pos 569 280 3000 no_role_b
multiplicity_a_pos 576 296 3000 no_multiplicity_b
role_a_pos 293 252 3000 no_role_b
multiplicity_a_pos 300 268 3000 no_multiplicity_b
end

View file

@ -7,7 +7,7 @@ diagrams
classdiagram_ref 128389 // Render Entities
743 538 100 4 0 0
active classdiagram_ref 131205 // Struct-Asset Relations
741 555 100 4 0 114
555 620 100 4 0 0
end
show_stereotypes
selected

View file

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

View file

@ -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="200801061234" created="200712040334" tags="design dynamic def Builder" changecount="21">
<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
@ -803,6 +811,9 @@ This is an very important external Interface, because it links together all thre
<pre>RenderEngine
</pre>
</div>
<div title="DefaultsManagement" modifier="Ichthyostega" created="200801121708" tags="def spec" changecount="1">
<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;getDefault&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.</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...
@ -1071,7 +1082,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="200801062306" created="200708080322" tags="overview" changecount="16">
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200801111251" created="200708080322" tags="overview" changecount="18">
<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]]
@ -1085,6 +1096,7 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
* [[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|TrackHandling]] and [[Ports|PortHandling]]
* [[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">
@ -1518,8 +1530,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>
@ -2258,7 +2270,7 @@ afterwards.
&lt;&lt;tasksum end&gt;&gt;
</pre>
</div>
<div title="PlanningNodeCreaterTool" modifier="Ichthyostega" modified="200801061936" created="200712090659" tags="impl Builder draft" changecount="7">
<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]]
@ -2284,7 +2296,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.
@ -2319,6 +2331,21 @@ The GUI can connect the viewer(s) to some port (and moreover can use [[probe poi
&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">
@ -2780,16 +2807,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>/*{{{*/