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

(cont) analyzing the problem of output designation

Browse source
This commit is contained in:
Fischlurch 2010-06-25 04:43:06 +02:00
parent cffbdd72e5
commit 639aff0fa5
3 changed files with 29 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
tests/components/proc/mobject/session/deletecliptest.cpp
View file

@ -68,7 +68,7 @@ namespace test {
UNIMPLEMENTED("typesafe searching for MObjects in the Session");
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////TODO: work out how to search within the Model!!
#if false /////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #639 : work out how to search within the Model!!
PClipMO clipPlacement = sess->currEDL().find(SESSION1_CLIP);
// global Var assigned in buildTestsession1()
@ -78,10 +78,10 @@ namespace test {
sess->remove (clipPlacement);
ASSERT (!sess->currEDL().find(SESSION1_CLIP)); // EDL forgot the Clip/Placement
ASSERT (!sess->currEDL().find(SESSION1_CLIP)); // Session forgot the Clip/Placement
ASSERT (!aMang.known (clipAID)); // corresponding Clip Asset has disappeared
ASSERT (!clipPlacement->getMedia()); // internal cross-links removed
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////TODO: work out how to search within the Model!!
#endif /////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #639 : work out how to search within the Model!!
}
};

2
tests/components/proc/mobject/session/session-structure-test.cpp
View file

@ -88,7 +88,7 @@ namespace test {
ASSERT (0 <= sess->getFixture()->size()); // TODO implement
ASSERT (sess->currEDL().getTracks()->isValid());
// PAsset track = sess->currEDL().getTracks()[0];
// PAsset track = sess->currEDL().getTracks()[0]; // TODO obsolete
// AssetManager& aMang = AssetManager::instance();
// ASSERT (track == aMang.getAsset (track->getID()));

39
wiki/renderengine.html
View file

@ -2514,8 +2514,8 @@ While the general approach and reasoning remains valid, a lot of the details loo
* details of picking a suitable [[operation mode|RenderImplDetails]] of the node (e.g. utilitsing &quot;in-place&quot; calculation)
</pre>
</div>
<div title="NodeCreatorTool" modifier="Ichthyostega" modified="200909041744" created="200712100626" tags="def" changecount="3">
<pre>~NodeCreatorTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the ~NodeCreatorTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the NodeCreaterTool creates and wires the necessary [[nodes|ProcNode]]</pre>
<div title="NodeCreatorTool" modifier="Ichthyostega" modified="201006250229" created="200712100626" tags="def" changecount="4">
<pre>~NodeCreatorTool is a [[visiting tool|VisitorUse]] used as second step in the [[Builder]]. Starting out from a [[Fixture]], the builder first [[divides the Timeline into segments|SegmentationTool]] and then processes each segment with the ~NodeCreatorTool to build a render nodes network (Render Engine) for this part of the timeline. While visiting individual Objects and Placements, the ~NodeCreatorTool creates and wires the necessary [[nodes|ProcNode]]</pre>
</div>
<div title="NodeFrameNumbering" modifier="Ichthyostega" modified="200810160129" created="200810140254" tags="spec draft" changecount="3">
<pre>!Problem of Frame identification
@ -2593,23 +2593,34 @@ The operation point is provided by the current BuilderMould and used by the [[pr
This is possible because the operation point has been provided (by the mould) with informations about the media stream type to be wired, which, together with information accessible at the the [[render node interface|ProcNode]] and from the [[referred processing assets|ProcAsset]], with the help of the [[connection manager|ConManager]] allows to figure out what's possible and how to do the desired connections. Additionally, in the course of deciding about possible connections, the PathManager is consulted to guide strategic decisions regarding the [[render node configuration|NodeConfiguration]], possible type conversions and the rendering technology to employ.
</pre>
</div>
<div title="OutputDesignation" modifier="Ichthyostega" modified="201006220153" created="201006220126" tags="Model draft design discuss" changecount="2">
<div title="OutputDesignation" modifier="Ichthyostega" modified="201006250242" created="201006220126" tags="Model draft design discuss" changecount="15">
<pre>__6/2010__: an ever recurring (and yet unsolved) problem in the design of Luimiera's ~Proc-Layer is how to refer to output destinations, and how to organise them.
To get ahead with this problem, I'll start collecting observations, relations and drafts on this tiddler.
!Observations
* effectively each [[Timeline]] is known to expose a set of global Pipes
* ehen connecting a Sequence to a Timeline or a VirtualClip, we also establish a mapping between the possible media stream channels produced by the sequence and the real output slots located in the enclosing entity
* uncertainity on who has to provide the global pipes
* when connecting a Sequence to a Timeline or a VirtualClip, we also establish a mapping
* this mapping translates possible media stream channels produced by the sequence into (real) output slots located in the enclosing entity
* uncertainity on who has to provide the global pipes, implementation wise &amp;mdash;
** as Timeline is just a facade, BindingMO has to expose something which can be referred for attaching effects (to global pipes)
** when used as VirtualClip, there is somehow a channel configuration, either as asset, or exposed by the BindingMO
* Placements always resolve at least two dimensions: time and output. The latter means that a [[Placement]] can figure out to where to connect
* the resolution ability of Placements could help to overcome the problems in conjunction with a VirtualClip: missing output destination informations could be inherited down from the virtual clip's placement....
* the resolution ability of Placements could help to overcome the problems in conjunction with a VirtualClip: missing output destination informations could be inherited down....
* expanding on the basic concept of a Placement in N-dimensional configuration space, this //figuring out// would denote the ability to resolve the final output destination
* this resolution to a final destination is explicitly context dependent. We engage into quite some complexities to make this happen (&amp;rarr; BindingScopeProblem)
* [[processing patterns|ProcPatt]] are used for creating nodes on the source network of a clip, and similarily for fader, overlay and mixing into a summation pipe
* in case the track tree of a sequence doesn't contain specific routing advice, connections will be done directly to the global pipes in order and by matching StreamType (i.e. typically video to video master, audio to stereo audio master). When a monitor (viewer window) is attached to a timeline, similar output connections are made from the timeline's global pipes, i.e. the video display will take the contents of the first video (master) bus, and the first stereo audio pipe will be pulled and sent to system audio out.
* a mismatch between the system output possibilities and the stream type of a bus to be monitored should result in the same adaptation mechanism to kick in, as is used internally, when connecting an ~MObject to the next bus. Possibly we'll use separate rules in this case (allow 3D to flat, stereo to mono, render 5.1 into ambisonics...)
!Conclusions
* there are //direct, indirect// and //relative// referrals to an output designation
* //relative// in this context means that we refer to &quot;the N^^th^^ of this kind&quot; (e.g. the second video out)
* we need to attach some metadata with an output; especially we need an associated StreamType
* output designation is structured into several //levels://
** within the body of the model, mostly we address output destinations relatively
** at some point, we'll address a //subgroup// within the global pipes, which acts like a summation sink
** there might be //master pipes//
** finally, there is the hardware output or the distinct channel within the rendered result &amp;mdash; but this is never referred explicitly
</pre>
</div>
@ -6076,7 +6087,7 @@ Using transitions is a very basic task and thus needs viable support by the GUI.
Because of this experience, ichthyo wants to support a more general case of transitions, which have N output connections, behave similar to their &quot;simple&quot; counterpart, but leave out the mixing step. As a plus, such transitions can be inserted at the source ports of N clips or between any intermediary or final output pipes as well. Any transition processor capable of handling this situation should provide some flag, in order to decide if he can be placed in such a manner. (wichin the builder, encountering a inconsistently placed transition is just an [[building error|BuildingError]])
</pre>
</div>
<div title="TypedID" modifier="Ichthyostega" modified="201004040114" created="201003200157" tags="Model Rules design draft" changecount="31">
<div title="TypedID" modifier="Ichthyostega" modified="201006250014" created="201003200157" tags="Model Rules design draft" changecount="32">
<pre>//drafted service as of 4/10 &amp;mdash; &amp;rarr;[[implementation plans|TypedLookup]]//
A registration service to associate object identities, symbolic identifiers and types.
@ -6085,7 +6096,7 @@ For maintaining persistent objects, generally an unique object ID is desirable.
Formal symmetry might be another motivation: we separate into objects and assets, where the latter represent the //bookkeeping view.// But there remain some cases where the asset side, the bookkeeping is void of any substantial functionality. Just for the sake of orthogonality it //would be preferable//&amp;nbsp; to maintain a registration (for scripted use, for overview and organisational activities by the user, for diagnostics and repair work in the saved session state). A mere data record suffices to fulfil these requirements &amp;mdash; while there are other kinds of asset exposing a substantial amount of functionality.
Both these motivations highlight a tension between having a single global namespace of unique ~IDs, and having type-bound sub namespaces of limited scope, as the latter allows for using human readable symbolic ~IDs. Usually, when it comes to writing rules and configuration or creating instances explicitly from code, the specific context of the situation allows or even requires to focus down upon a single and distinct type of objects immediately &amp;mdash; global uniqueness is not much of a concern here.
Both these motivations highlight a tension between having a single global namespace of unique ~IDs, and having type-bound sub namespaces of limited scope, as the latter allows for using human readable symbolic ~IDs. Usually, when it comes to writing rules and configuration or creating instances explicitly from code, the specific context of the situation allows or even requires to focus down upon a single and distinct kind of objects immediately &amp;mdash; global uniqueness is not much of a concern here.
!desired functionality
A registration service backed by an index table can be used to //translate//&amp;nbsp; between these two seemingly contradictory usage view angles.
@ -6123,7 +6134,7 @@ Just an ''registration scheme'' should be implemented right now, working complet
see [[implementation planning|TypedLookup]]
</pre>
</div>
<div title="TypedLookup" modifier="Ichthyostega" modified="201006130130" created="201004031607" tags="Rules spec impl draft" changecount="15">
<div title="TypedLookup" modifier="Ichthyostega" modified="201006250025" created="201004031607" tags="Rules spec impl draft" changecount="18">
<pre>TypedID is a registration service to associate object identities, symbolic identifiers and types. It acts as frontend to the TypedLookup service within Proc-Layer, at the implementation level. While TypedID works within a strictly typed context, this type information is translated into an internal index on passing over to the implementation, which manages a set of tables containing base entries with an combined symbolic+hash ID, plus an opaque buffer. Thus, the strictly typed context is required to re-access the stored data. But the type information wasn't erased entirely, so this typed context can be re-gained with the help of an internal type index. All of this is considered implementation detail and may be subject to change without further notice; any access is assumed to happen through the TypedID frontend. Besides, there are two more specialised frontends.
!Front-ends
@ -6143,18 +6154,18 @@ In most cases, the //actually usable instance// of an entity isn't identical to
!basic usage patterns
* ''Assets'' are maintained by the AssetManager, which always holds a smart-ptr to the managed asset. Assets include explicit links to dependent assets. Thus, there is no point in interfering with lifecylce management, so we store just a ''weak reference'' here, which the access functor turns back into a smart-ptr, sharing ownership.
* Plain ''~MObjects'' are somewhat similar, but there is no active lifecycle management &amp;mdash; they are always tied either to a placement of linked from within the assets or render processes. When done, they just go out of scope. Thus we too use a ''weak reference'' here, assumed the respective entity has mixed in {{{TypedID::Link}}}
* Plain ''~MObjects'' are somewhat similar, but there is no active lifecycle management &amp;mdash; they are always tied either to a placement of linked from within the assets or render processes. When done, they just go out of scope. Thus we too use a ''weak reference'' here, thereby expecting the respective entity to mix in {{{TypedID::Link}}}
* Active ''Placements'' of an MObject behave like //object instances// within the model/session. They live within the PlacementIndex and cary an unique {{{LUID}}}-ID. Thus, it's sufficient to store this ''Placement-ID'', which can be used by the access functor to fetch the corresponding Placement from the session.
Obviously, the ~TypedLookup system is open for addition of completely separate and different types.
[&gt;img[TypedLookup implementation sketch|uml/fig140293.png]]
|&gt;| !Entity |!pattern |
|1:1| Track|Placement|
|~| Label|Placement|
|~| Sequence|Asset|
|~| StreamType|Asset|
|1:n| Tag|Asset|
|~| Sequence| Asset|
|~| StreamType| Asset|
|1:n| Tag| Asset|
|~| Clip|~MObject|
|~| Effect| ~MObejct|
|~| Effect|~MObejct|
|~| Transition| Asset(?)|
</pre>
</div>