diff --git a/uml/cinelerra3/5.session b/uml/cinelerra3/5.session index a2742eb7a..f89f4f060 100644 --- a/uml/cinelerra3/5.session +++ b/uml/cinelerra3/5.session @@ -2,16 +2,14 @@ window_sizes 1140 830 270 860 680 71 diagrams classdiagram_ref 130309 // Asset Kinds 860 633 100 4 0 0 - classdiagram_ref 128133 // Session structure - 860 633 100 4 0 0 + active classdiagram_ref 128133 // Session structure + 860 633 100 4 401 0 classdiagram_ref 128389 // Render Entities 688 506 100 4 120 0 - active classdiagram_ref 129285 // Builder Entities - 860 680 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 diff --git a/wiki/renderengine.html b/wiki/renderengine.html index b45512278..5e68485a1 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -2905,11 +2905,26 @@ function addKeyDownHandlers(e) -
-
''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 reading/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 only bound by the editor's habits of working.
+

+
''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
-Media are used as Clips (contiguous chunks), they are a compound of several elementary streams, and they have a temporal extension (length). Indeed, the temporal dimension is the only fundamental property that can't be changed. Orthogonally to this dimension, we add one or more organisational dimensions forming a grid. This means, while the time is quasi-contiguos, the organisational grid is discrete in structure. And we assume that we can //locate or place// some media clip at one distinctive point in this organisational grid. Combined with the temporal dimension, this grid is thus extruded to form something like Tracks.

+!!!Assessment of Properties
+Media are used as Clips (contiguous chunks), they are a compound of several elementary streams, and they have a temporal extension (length). Indeed, the temporal dimension is the only fundamental property that can't be changed. Orthogonal to this dimension, we find one or more organisational dimensions forming a grid:
+* a media stream may be sent to one of several possible output destinations (image or sound, subgroup busses, MIDI instruments)
+* for any given output destination there may be variations in the //way of connecting// (overlay mode and layer, pan position, MIDI channel)
+* besides, we often just want to stash away some clip without using it, e.g. as an alternative or for later referral
+This is to say we have //several degrees of freedom// within this organisational grid. It's not because some sound is located on this track that he will be sent to a given output, but the clip is located on this track //and// is connected to that output //and// — supposed we have full-periphonic surround sound — it is located 60° to the right and 30°. Combined with the (always contiguous) temporal dimension, this discrete grid is thus extruded to form something like discrete Tracks.
+
+!!!do we really need Tracks?
+Starting with the assumption "everything is just connected processing nodes", Tracks may seem superfluous. The problem with this approach is: it doesn't scale well. While it is fine to be able to connect clips and effects as we see fit (indeed, we want to build such a system), it is clearly not feasible to wire every clip manually to the output ports or add a panner effect to each and every audio sample. Because while editing, most of the time things are done in a fairly regular and systematic manner. Preferably we use the tracks as //preconfigured group setup// and just //place media onto them;// any such [[Placement]] can do the necessary wiring semi-automatic (rule-based).
+
+!Design
+__Tracks__ are just a structure used to organize the Media Objects within the EDL. They are 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.
+* 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 additional dimensions: Connecting to video out e.g. creates an overlay mode and a layer position, while connecting to a spatial sound system creates a pan position. Placing a mono clip onto a mono Port creates no additional properties though.
+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 input he gets
Using the ''Visitor Design Pattern'' is somewhat controversial, mainly because this pattern is rather complicated, requires certain circumstances to be usefull, and — especially when used in the original form described by Gamma et al — puts quite some burden on the implementor. This problems can be ameliorated by using library implementation techniques described by Robert Martin and implemented e.g. by Alexandrescu in the Loki library.