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

further problem analysis

Browse source
This commit is contained in:
Fischlurch 2007-09-21 03:40:04 +02:00
parent 91a4835f6a
commit f2c3027071
5 changed files with 59 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
uml/cinelerra3/128133
View file

@ -1,6 +1,6 @@
format 40
"Asset" // ProcessingLayer::Asset
revision 8
revision 10
modified_by 5 "hiv"
// class settings
//class diagram settings
@ -390,7 +390,7 @@ ${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl}
classrelation 143237 // <dependency>
relation 141317 -_->
a default
cpp default "Generated"
cpp default "#include in header"
classrelation_ref 143237 // <dependency>
b multiplicity "" parent class_ref 138757 // ProcPatt
end
@ -536,7 +536,6 @@ ${inlines}
b multiplicity "*" parent class_ref 136709 // Media
association_type class_ref 136709 // Media
end
end
class 137477 "Unknown"
@ -719,5 +718,25 @@ ${inlines}
comment "Implementation of the registry holding all Asset instances known to the Asset Manager subsystem. As of 8/2007 implemented by a hashtable."
end
class 138885 "SimpleClip"
visibility package
cpp_decl "${comment}${template}class ${name}${inherit}
{
${members} };
${inlines}
"
java_decl ""
idl_decl ""
explicit_switch_type ""
classrelation 143365 // <generalisation>
relation 141445 ---|>
a public
cpp default "${type}"
classrelation_ref 143365 // <generalisation>
b multiplicity "" parent class_ref 128901 // Clip
end
end
end
end

10
uml/cinelerra3/128261
View file

@ -1,6 +1,6 @@
format 40
"MObject" // ProcessingLayer::MObject
revision 18
revision 19
modified_by 5 "hiv"
// class settings
//class diagram settings
@ -446,6 +446,14 @@ ${inlines}
b multiplicity "" parent class_ref 128901 // Clip
end
classrelation 143493 // components (<directional aggregation>)
relation 141573 o-->
a role_name "components" multiplicity "1..*" protected
cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value};
"
classrelation_ref 143493 // components (<directional aggregation>)
b multiplicity "*" parent class_ref 128901 // Clip
end
end
class 129029 "Effect"

21
uml/cinelerra3/130437.diagram
View file

@ -70,7 +70,7 @@ classcanvas 137221 class_ref 138501 // CompoundMedia
end
classcanvas 138373 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
xyz 72 301 2000
xyz 110 293 2000
end
classcanvas 138885 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
@ -80,6 +80,10 @@ classcanvas 139013 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 751 115 2000
end
classcanvas 140293 class_ref 138885 // SimpleClip
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 32 293 3005
end
relationcanvas 128517 relation_ref 139141 // <generalisation>
from ref 128261 z 1999 to ref 128389
no_role_a no_role_b
@ -150,7 +154,7 @@ relationcanvas 136965 relation_ref 140165 // <unidirectional association>
geometry VH
from ref 128005 z 1999 to point 489 78
line 137093 z 1999 to ref 128133
role_a_pos 488 56 3000 no_role_b
role_a_pos 475 61 3000 no_role_b
multiplicity_a_pos 516 89 3000 multiplicity_b_pos 477 123 3000
relationcanvas 137349 relation_ref 140421 // <generalisation>
from ref 137221 z 1999 to ref 128133
@ -158,7 +162,7 @@ relationcanvas 137349 relation_ref 140421 // <generalisation>
no_multiplicity_a no_multiplicity_b
relationcanvas 137477 relation_ref 140549 // <directional aggregation>
from ref 137221 z 1999 to point 654 77
line 137733 z 1999 stereotype "<<vector>>" xyz 670 122 3000 to ref 128133
line 137733 z 1999 stereotype "<<vector>>" xyz 658 123 3000 to ref 128133
role_a_pos 615 55 3000 no_role_b
multiplicity_a_pos 590 122 3000 multiplicity_b_pos 642 123 3000
relationcanvas 137861 relation_ref 140677 // <unidirectional association>
@ -166,7 +170,7 @@ relationcanvas 137861 relation_ref 140677 // <unidirectional association>
line 138245 z 1999 to point 383 49
line 137989 z 1999 to point 492 49
line 138117 z 1999 to ref 128133
role_a_pos 488 44 3000 no_role_b
role_a_pos 392 51 3000 no_role_b
multiplicity_a_pos 516 77 3000 multiplicity_b_pos 149 235 3000
relationcanvas 138501 relation_ref 140805 // <generalisation>
from ref 138373 z 1999 to ref 128901
@ -182,4 +186,13 @@ relationcanvas 139397 relation_ref 141317 // <dependency>
line 139781 z 1999 to ref 139013
no_role_a no_role_b
no_multiplicity_a no_multiplicity_b
relationcanvas 140421 relation_ref 141445 // <generalisation>
from ref 140293 z 1999 to ref 128901
no_role_a no_role_b
no_multiplicity_a no_multiplicity_b
relationcanvas 140549 relation_ref 141573 // <directional aggregation>
from ref 138373 z 1999 to point 154 263
line 140677 z 1999 to ref 128901
role_a_pos 149 247 3000 no_role_b
multiplicity_a_pos 160 260 3000 multiplicity_b_pos 142 268 3000
end

8
uml/cinelerra3/5.session
View file

@ -2,13 +2,13 @@ window_sizes 1140 783 270 860 633 71
diagrams
classdiagram_ref 130309 // Asset Kinds
860 607 100 4 120 0
active classdiagram_ref 130437 // Media-Asset Relations
817 506 100 4 0 38
classdiagram_ref 128133 // Session structure
688 506 100 4 180 80
688 506 100 4 180 0
active classdiagram_ref 130437 // Media-Asset Relations
860 633 100 4 0 0
end
show_stereotypes
selected classrelation_ref 143237 // <dependency>
selected classdiagram_ref 130437 // Media-Asset Relations
open
package_ref 128005 // design

10
wiki/renderengine.html
View file

@ -2021,7 +2021,7 @@ DAMAGE.
//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="ProblemsTodo" modifier="Ichthyostega" modified="200708080104" created="200708050524" tags="design discuss" changecount="12">
<div title="ProblemsTodo" modifier="Ichthyostega" modified="200709210136" created="200708050524" tags="design discuss" changecount="13">
<pre>Open issues, Things to be worked out, Problems still to be solved...
!!Parameter Handling
@ -2040,11 +2040,15 @@ From experience, mainly with other applications, we can draw the following concl
How to handle the simultaneous rendering of several output streams (video, audio channels). Shall we treat the EDL as one entity containing different output channels, or should it rather be seen as a composite of several sub-~EDLs, each for only one output channel? This decision will be reflected in the overall structure of the network of render nodes: We could have a list of channel-output generating pipelines in each processor (for every segment), or we could have independently segmented lists of Processors for every output channel/type. The problem is, //it is not clear what approach to prefer at the moment// because we are just guessing.
!!Tracks, Channels, Layers
Closely related to this is the not-so-obvious problem how to understand the common global structures found in most audio and video editing applications. Mostly, they stem from imitating hardware recording and editing solutions, thus easing the transition for professionals grown up with analog hardware based media. But as digital media are the de-facto standard nowadays, we could have a look at all those accidental complexity introduced by sticking to the hardware tool metaphor.
Closely related to this is the not-so-obvious problem how to understand the common global structures found in most audio and video editing applications. Mostly, they stem from imitating hardware recording and editing solutions, thus easing the transition for professionals grown up with analogue hardware based media. But as digital media are the de-facto standard nowadays, we could rethink some of this accidental complexity introduced by sticking to the hardware tool metaphor.
* is it really necessary to have fixed global tracks?
* is it really helpful to feed &quot;source tracks&quot; into global processing busses/channels?
Users accustomed with modern GUI applications typically expect that //everything is a object// and can be pulled around and manipulated individually. This seems natural at start, but raises the problem of providing a efficient workflow for handling larger projects and editing tasks. So, if we don't have a hard wired multitrack+bus architecture, we need some sort of templating to get the standard editing use case done efficiently.
</pre>
!!Compound and Multiplicity
Simple relations can be hard wired. But, on the contrary, it would be as naive to define a Clip as having a Video track and two audio tracks, as it would be naive to overlook the problem of holding video and corresponding audio together. And, moreover, the default case has to be processed in a //straight forward// fashion, with as few tests and decisions as possible. So, basically each component participating in getting the core processing done has to mirror the structure pattern of the other parts, so that processing can be done without testing and forking. But this leaves us with the problem where to put the initial knowledge about the structural pattern used for building up the compound structures and &amp;mdash; especially &amp;mdash; the problem how to treat different kinds of structural patterns, how to detect the pattern to be applied and how to treat multiple instances of the same structural pattern.
One example of this problem is the [[handling of multichannel media|MultichannelMedia]]. Following the above reasoning, we end with having a [[&quot;structural pattern&quot;|StructPatt]], typically one video stream with MPEG decoder and a pair of audio streams which need either to be routed to some &quot;left&quot; and &quot;right&quot; output ports, or have to be passed through a panning filter accordingly. Now the problem is: //create a new instance of this structure for each new media, or detect which media to subsume under a existing pattern instance.//</pre>
</div>
<div title="ProcLayer" modifier="Ichthyostega" modified="200708100338" created="200708100333" tags="def" changecount="2">
<pre>The middle Layer of our current Architecture plan, i.e. the layer managing all processing and manipulation, while the actual data handling is done in the backend and the user interaction belongs to the GUI Layer.