diff --git a/.gitignore b/.gitignore index 5dc912d9e..10dbaee23 100644 --- a/.gitignore +++ b/.gitignore @@ -5,7 +5,7 @@ *.os *.gch ,valgrind.log* -Buildhelper.pyc +admin/scons/*.pyc optcache Makefile.in build/* diff --git a/SConstruct b/SConstruct index 066cd31b0..c5f2971ee 100644 --- a/SConstruct +++ b/SConstruct @@ -26,6 +26,8 @@ sys.path.append("./admin/scons") import os from Buildhelper import * +from LumieraEnvironment import * + #-----------------------------------Configuration OPTIONSCACHEFILE = 'optcache' @@ -33,6 +35,7 @@ CUSTOPTIONSFILE = 'custom-options' SRCDIR = 'src' BINDIR = 'bin' TESTDIR = 'tests' +ICONDIR = 'icons' VERSION = '0.1+pre.01' #-----------------------------------Configuration @@ -53,13 +56,13 @@ def setupBasicEnvironment(): EnsureSConsVersion(0,96,90) opts = defineCmdlineOptions() - - env = Environment(options=opts) - + env = LumieraEnvironment(options=opts) + env.Append ( CCCOM=' -std=gnu99') # workaround for a bug: CCCOM currently doesn't honor CFLAGS, only CCFLAGS env.Replace( VERSION=VERSION , SRCDIR=SRCDIR , BINDIR=BINDIR + , ICONDIR=ICONDIR , CPPPATH=["#"+SRCDIR] # used to find includes, "#" means always absolute to build-root , CPPDEFINES=['-DLUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines , CCFLAGS='-Wall ' # -fdiagnostics-show-option @@ -74,7 +77,7 @@ def setupBasicEnvironment(): appendVal(env,'ARCHFLAGS', 'CCFLAGS') # for both C and C++ appendVal(env,'OPTIMIZE', 'CCFLAGS', val=' -O3') appendVal(env,'DEBUG', 'CCFLAGS', val=' -ggdb') - + prepareOptionsHelp(opts,env) opts.Save(OPTIONSCACHEFILE, env) return env @@ -127,7 +130,7 @@ def defineCmdlineOptions(): ,PathOption('SRCTAR', 'Create source tarball prior to compiling', '..', PathOption.PathAccept) ,PathOption('DOCTAR', 'Create tarball with dev documentaionl', '..', PathOption.PathAccept) ) - + return opts @@ -161,38 +164,42 @@ def configurePlatform(env): setup platform specific options. Abort build in case of failure. """ - conf = Configure(env) - # run all configuration checks in the current env + conf = env.Configure() + # run all configuration checks in the given env + + # Perform checks for prerequisites -------------------------------------------- + if not conf.TryAction('pkg-config --version > $TARGET')[0]: + print 'We need pkg-config for including library configurations, exiting.' + Exit(1) - # Checks for prerequisites ------------ if not conf.CheckLibWithHeader('m', 'math.h','C'): print 'Did not find math.h / libm, exiting.' Exit(1) - + if not conf.CheckLibWithHeader('dl', 'dlfcn.h', 'C'): print 'Functions for runtime dynamic loading not available, exiting.' Exit(1) - + if not conf.CheckLibWithHeader('nobugmt', 'nobug.h', 'C'): print 'Did not find NoBug [http://www.pipapo.org/pipawiki/NoBug], exiting.' Exit(1) - + if not conf.CheckLibWithHeader('pthread', 'pthread.h', 'C'): print 'Did not find the pthread lib or pthread.h, exiting.' else: conf.env.Append(CPPFLAGS = ' -DHAVE_PTHREAD') conf.env.Append(CCFLAGS = ' -pthread') - + if conf.CheckCHeader('execinfo.h'): conf.env.Append(CPPFLAGS = ' -DHAS_EXECINFO_H') - + if conf.CheckCHeader('valgrind/valgrind.h'): conf.env.Append(CPPFLAGS = ' -DHAS_VALGRIND_VALGIND_H') if not conf.CheckCXXHeader('tr1/memory'): print 'We rely on the std::tr1 proposed standard extension for shared_ptr.' Exit(1) - + if not conf.CheckCXXHeader('boost/config.hpp'): print 'We need the C++ boost-lib.' Exit(1) @@ -206,8 +213,36 @@ def configurePlatform(env): if not conf.CheckLibWithHeader('boost_regex-mt','boost/regex.hpp','C++'): print 'We need the boost regular expression lib (incl. binary lib for linking).' Exit(1) - - + +# if not conf.CheckLibWithHeader('gavl', ['gavlconfig.h', 'gavl/gavl.h'], 'C'): + + if not conf.CheckPkgConfig('gavl', 1.0): + print 'Did not find Gmerlin Audio Video Lib [http://gmerlin.sourceforge.net/gavl.html], exiting.' + Exit(1) + else: + conf.env.mergeConf('gavl') + + if not conf.CheckPkgConfig('gtkmm-2.4', 2.8): + print 'Unable to configure GTK--, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('cairomm-1.0', 0.6): + print 'Unable to configure Cairo--, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('gdl-1.0', '0.6.1'): + print 'Unable to configure the GNOME DevTool Library, exiting.' + Exit(1) + + if not conf.CheckPkgConfig('xv'): Exit(1) +# if not conf.CheckPkgConfig('xext'): Exit(1) +# if not conf.CheckPkgConfig('sm'): Exit(1) +# +# obviously not needed? + + print "** Gathered Library Info: %s" % conf.env.libInfo.keys() + + # create new env containing the finished configuration return conf.Finish() @@ -221,7 +256,7 @@ def definePackagingTargets(env, artifacts): artifacts['src.tar'] = t env.Alias('src.tar', t) env.Alias('tar', t) - + t = Tarball(env,location='$DOCTAR',suffix='-doc',dirs='admin doc wiki uml tests') artifacts['doc.tar'] = t env.Alias('doc.tar', t) @@ -240,7 +275,7 @@ def defineBuildTargets(env, artifacts): objlib = ( srcSubtree(env,'$SRCDIR/common') + srcSubtree(env,'$SRCDIR/lib') ) - plugobj = srcSubtree(env,'$SRCDIR/plugin', isShared=True) + objplug = srcSubtree(env,'$SRCDIR/plugin', isShared=True) core = ( env.StaticLibrary('$BINDIR/lumiback.la', objback) + env.StaticLibrary('$BINDIR/lumiproc.la', objproc) + env.StaticLibrary('$BINDIR/lumi.la', objlib) @@ -254,7 +289,16 @@ def defineBuildTargets(env, artifacts): env.Depends(objlib, precomp) artifacts['lumiera'] = env.Program('$BINDIR/lumiera', ['$SRCDIR/main.cpp']+ core ) - artifacts['plugins'] = env.SharedLibrary('$BINDIR/lumiera-plugin', plugobj) + artifacts['plugins'] = env.SharedLibrary('$BINDIR/lumiera-plugin', objplug) + + # the Lumiera GTK GUI + envgtk = env.Clone().mergeConf(['gtkmm-2.4','cairomm-1.0','gdl-1.0','xv','xext','sm']) + objgui = srcSubtree(envgtk,'$SRCDIR/gui') + + artifacts['lumigui'] = ( envgtk.Program('$BINDIR/lumigui', objgui + core) + + env.Install('$BINDIR', env.Glob('$ICONDIR/*.png')) + + env.Install('$BINDIR', env.Glob('$SRCDIR/gui/*.rc')) + ) # call subdir SConscript(s) for independent components SConscript(dirs=[SRCDIR+'/tool'], exports='env artifacts core') @@ -270,13 +314,13 @@ def definePostBuildTargets(env, artifacts): il = env.Alias('install-lib', '$DESTDIR/lib') env.Alias('install', [ib, il]) - build = env.Alias('build', artifacts['lumiera']+artifacts['plugins']+artifacts['tools']) + build = env.Alias('build', artifacts['lumiera']+artifacts['lumigui']+artifacts['plugins']+artifacts['tools']) allbu = env.Alias('allbuild', build+artifacts['testsuite']) env.Default('build') # additional files to be cleaned when cleaning 'build' env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ]) env.Clean ('build', [ '$SRCDIR/pre.gch' ]) - + # Doxygen documentation # Note: at the moment we only depend on Doxyfile # obviousely, we should depend on all sourcefiles diff --git a/admin/scons/Buildhelper.py b/admin/scons/Buildhelper.py index ae3f5fb1f..02f17b2b4 100644 --- a/admin/scons/Buildhelper.py +++ b/admin/scons/Buildhelper.py @@ -90,6 +90,18 @@ def globRootdirs(roots): +def filterNodes(nlist, removeName=None): + """ filter out scons build nodes using the given criteria. + removeName: if set, remove all nodes with this srcname + """ + if removeName: + predicate = lambda n : not fnmatch.fnmatch(os.path.basename(str(n[0])), removeName) + else: + predicate = lambda n : True; + + return filter(predicate, nlist) + + def RegisterPrecompiledHeader_Builder(env): """ Registeres an Custom Builder for generating a precompiled Header. Note you should define a dependency to the PCH file @@ -111,7 +123,7 @@ def RegisterPrecompiledHeader_Builder(env): def Tarball(env,location,dirs,suffix=''): """ Custom Command: create Tarball of some subdirs - location: where to create the tar (optionally incl. filename.tar.gz) + location: where to create the tar (may optionally include filename.tar.gz) suffix: (optional) suffix to include in the tar name dirs: directories to include in the tar @@ -132,7 +144,7 @@ def Tarball(env,location,dirs,suffix=''): def createTarball(target,source,env): - """ helper, builds the tar using the python2.3 tarfil lib. + """ helper, builds the tar using the python2.3 tarfile lib. This allows us to prefix all paths, thus moving the tree into a virtual subdirectory containing the Version number, as needed by common packaging systems. diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py new file mode 100644 index 000000000..82d419a65 --- /dev/null +++ b/admin/scons/LumieraEnvironment.py @@ -0,0 +1,97 @@ +# -*- python -*- +## +## LumieraEnvironment.py - custom SCons Environment +## + +# Copyright (C) Lumiera.org +# 2008, Hermann Vosseler +# +# 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. +##################################################################### + + +from SCons.SConf import SConf +from SCons.Environment import Environment + +from Buildhelper import * + + + +class LumieraEnvironment(Environment): + """ Custom SCons build environment for Lumiera + This allows us to carry structured config data without + using global vars. Idea inspired by Ardour. + """ + def __init__(self,*args,**kw): + Environment.__init__ (self,*args,**kw) + self.libInfo = {} + + def Configure (self, *args, **kw): + kw['env'] = self + return apply(LumieraConfigContext, args, kw) + + def mergeConf (self,other): + """ extract the library/compiler flags from other Environment. + Optionally accepts a list or just sting(s) representing keys + in our own libInfo Dictionary + """ + if isinstance(other, list): + for elm in other: + self.mergeConf(elm) + elif isinstance(other, str): + if other in self.libInfo: + self.mergeConf(self.libInfo[other]) + else: + self.Append (LIBS = other.get ('LIBS',[])) + self.Append (LIBPATH = other.get ('LIBPATH', [])) + self.Append (CPPPATH = other.get('CPPPATH', [])) + self.Append (LINKFLAGS = other.get('LINKFLAGS', [])) + + return self + + + def addLibInfo (self, libID, minVersion=0): + """ use pkg-config to create an Environment describing the lib. + Don't add this defs to the current Environment, rather store + them in the libInfo Dictionary. + """ + minVersion = str(minVersion) + if 0 != os.system('pkg-config --print-errors --exists "%s >= %s"' % (libID,minVersion)): + print "Problems configuring the Library %s (>= %s)" % (libID,minVersion) + return False + + self.libInfo[libID] = libInfo = LumieraEnvironment() + libInfo.ParseConfig ('pkg-config --cflags --libs '+ libID ) + return libInfo + + def Glob (self, pattern): + """ temporary workaround; newer versions of SCons provide this as a global function + """ + pattern = self.subst(pattern) + return glob.glob(pattern) + + +class LumieraConfigContext(SConf): + """ Extends the SCons Configure context with some convenience methods + """ + def __init__(self, *args,**kw): + SConf.__init__(self,*args,**kw) + + def CheckPkgConfig (self, libID, minVersion=0): + print "Checking for library configuration: %s " % libID + # self.Message(self,"Checking for library configuration: %s " % libID) + return self.env.addLibInfo (libID, minVersion) + + diff --git a/doc/devel/uml/class130949.html b/doc/devel/uml/class130949.html index 774585ac5..05f451c34 100644 --- a/doc/devel/uml/class130949.html +++ b/doc/devel/uml/class130949.html @@ -18,7 +18,7 @@

Declaration :

Encapsulates the logic used to get a "current render process" in accordance to the currentyl applicable controller settings. The provided StateProxy serves to hold any mutalbe state used in the render process, so the rest of the render engine can be stateless.

Artifact : renderstate

-
Operation getStateProxy

Declaration :

+
Operation getStateProxy

Declaration :

All public operations : getStateProxy

diff --git a/doc/devel/uml/class131589.html b/doc/devel/uml/class131589.html index c65bef7fb..86ae3636b 100644 --- a/doc/devel/uml/class131589.html +++ b/doc/devel/uml/class131589.html @@ -18,5 +18,6 @@

Declaration :

The output of the render pipeline. Pulling from such exit nodes actually ivokes the render process

Artifact : exitnode

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131717.html b/doc/devel/uml/class131717.html index d03898369..2a2783381 100644 --- a/doc/devel/uml/class131717.html +++ b/doc/devel/uml/class131717.html @@ -16,10 +16,14 @@ -

Declaration :

Directly inherited by : ExitNode Hub Link Source Trafo

+

Declaration :

Directly inherited by : ExitNode Link Source Trafo

Key abstraction of the Render Engine: A Data processing Node

Artifact : procnode

Relation datasrc (<unidirectional association>)

Declaration :

The predecessor in a processing pipeline, i.e. a source to get data to be processed

-
Relation params (<directional aggregation by value>)

Declaration :

+
Relation params (<directional aggregation by value>)

Declaration :

+
Relation predecessors (<directional aggregation by value>)

Declaration :

+
Operation pull

Declaration :

+
Operation process

Declaration :

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131845.html b/doc/devel/uml/class131845.html index 278d1cdb1..1a439ca08 100644 --- a/doc/devel/uml/class131845.html +++ b/doc/devel/uml/class131845.html @@ -19,5 +19,6 @@

Declaration :

Directly inherited by : CodecAdapter Mask PluginAdapter Projector

Artifact : trafo

+

All public operations : process , pull

diff --git a/doc/devel/uml/class131973.html b/doc/devel/uml/class131973.html index 68e7e24de..5e99f1b3d 100644 --- a/doc/devel/uml/class131973.html +++ b/doc/devel/uml/class131973.html @@ -16,8 +16,8 @@ -

Declaration :

Directly inherited by : GLPipe

-

Artifact : link

+

Declaration :

Artifact : link

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132229.html b/doc/devel/uml/class132229.html index f0ba8e9d7..8fc999275 100644 --- a/doc/devel/uml/class132229.html +++ b/doc/devel/uml/class132229.html @@ -18,5 +18,6 @@

Declaration :

Special video processing node used to scale and translate image data.

Artifact : projector

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132357.html b/doc/devel/uml/class132357.html index 0d94f52bc..1b054fe8f 100644 --- a/doc/devel/uml/class132357.html +++ b/doc/devel/uml/class132357.html @@ -18,5 +18,6 @@

Declaration :

Artifact : mask

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132485.html b/doc/devel/uml/class132485.html index b6389bd12..54bafe5c9 100644 --- a/doc/devel/uml/class132485.html +++ b/doc/devel/uml/class132485.html @@ -18,5 +18,6 @@

Declaration :

Adapter used to integrage an effects processor in the render pipeline

Artifact : pluginadapter

+

All public operations : process , pull

diff --git a/doc/devel/uml/class132741.html b/doc/devel/uml/class132741.html index f0a749926..a9dd11ca8 100644 --- a/doc/devel/uml/class132741.html +++ b/doc/devel/uml/class132741.html @@ -4,21 +4,26 @@ -Class StateProxy +Class State -
Class StateProxy
+
Class State

-

Declaration :

Directly inherited by : ARender GLRender VRender

+

Declaration :

Directly inherited by : InvocationStateBase StateAdapter StateProxy

Artifact : stateproxy, Component(s) : Builder

-
Relation currFrame (<unidirectional association>)

Declaration :

  • Uml : # currFrame : Frame
  • C++ : protected: Frame * currFrame
+
Relation currFrame (<unidirectional association>)

Declaration :

+
Operation fetch

Declaration :

+
Operation allocateBuffer

Declaration :

+
Operation releaseBuffer

Declaration :

+
Operation isCalculated

Declaration :

+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

diff --git a/doc/devel/uml/class132997.html b/doc/devel/uml/class132997.html deleted file mode 100644 index 7680639be..000000000 --- a/doc/devel/uml/class132997.html +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - -Class VRender - - - - - -
Class VRender
-

- - - - -

Declaration :

Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)

Artifact : vrender

-
- - diff --git a/doc/devel/uml/class133765.html b/doc/devel/uml/class133765.html index af0e6bfb1..b6f9bde2d 100644 --- a/doc/devel/uml/class133765.html +++ b/doc/devel/uml/class133765.html @@ -18,5 +18,6 @@

Declaration :

Source Node: represents a media source to pull data from.

Artifact : source

+

All public operations : process , pull

diff --git a/doc/devel/uml/class135045.html b/doc/devel/uml/class135045.html index 16259137b..c91ed83fb 100644 --- a/doc/devel/uml/class135045.html +++ b/doc/devel/uml/class135045.html @@ -18,5 +18,6 @@

Declaration :

Artifact : codecadapter

+

All public operations : process , pull

diff --git a/doc/devel/uml/class142469.html b/doc/devel/uml/class142469.html new file mode 100644 index 000000000..31b631174 --- /dev/null +++ b/doc/devel/uml/class142469.html @@ -0,0 +1,24 @@ + + + + + + +Class StateProxy + + + + + +
Class StateProxy
+

+ + + + +

Declaration :

+ +
Relation wiring (<unidirectional association>)

Declaration :

+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class142597.html b/doc/devel/uml/class142597.html new file mode 100644 index 000000000..69ed2147c --- /dev/null +++ b/doc/devel/uml/class142597.html @@ -0,0 +1,26 @@ + + + + + + +Class StateAdapter + + + + + +
Class StateAdapter
+

+ + + + +

Declaration :

+ +
Operation retrieve

Declaration :

+
Relation state (<unidirectional association>)

Declaration :

+
Relation <unidirectional association>

Declaration :

+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer , retrieve

+ + diff --git a/doc/devel/uml/class132869.html b/doc/devel/uml/class142725.html similarity index 56% rename from doc/devel/uml/class132869.html rename to doc/devel/uml/class142725.html index 743378103..13bdadf5b 100644 --- a/doc/devel/uml/class132869.html +++ b/doc/devel/uml/class142725.html @@ -4,19 +4,18 @@ -Class ARender +Class WiringDescriptor -
Class ARender
+
Class WiringDescriptor

- -

Declaration :

Representation of a Audio render process

Artifact : arender

-
+ +

Declaration :

Directly inherited by : NodeWiring

diff --git a/doc/devel/uml/class133125.html b/doc/devel/uml/class143109.html similarity index 53% rename from doc/devel/uml/class133125.html rename to doc/devel/uml/class143109.html index 140cc4b67..f2696562b 100644 --- a/doc/devel/uml/class133125.html +++ b/doc/devel/uml/class143109.html @@ -4,19 +4,17 @@ -Class GLRender +Class BackendCache -
Class GLRender
+
Class BackendCache

- -

Declaration :

Representation of a OpenGL accelerated Video render process

Artifact : glrender

-
- + +

Declaration :

diff --git a/doc/devel/uml/class132613.html b/doc/devel/uml/class143237.html similarity index 51% rename from doc/devel/uml/class132613.html rename to doc/devel/uml/class143237.html index 0134205d1..b1b5a8387 100644 --- a/doc/devel/uml/class132613.html +++ b/doc/devel/uml/class143237.html @@ -4,19 +4,17 @@ -Class GLPipe +Class Caller -
Class GLPipe
+
Class Caller

- -

Declaration :

specialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form

Artifact : glpipe

-
- + +

Declaration :

diff --git a/doc/devel/uml/class132101.html b/doc/devel/uml/class143365.html similarity index 61% rename from doc/devel/uml/class132101.html rename to doc/devel/uml/class143365.html index ca7d5ac7e..8f96f6b27 100644 --- a/doc/devel/uml/class132101.html +++ b/doc/devel/uml/class143365.html @@ -4,19 +4,19 @@ -Class Hub +Class NodeWiring -
Class Hub
+
Class NodeWiring

- -

Declaration :

Artifact : hub

+ +

Declaration :

diff --git a/doc/devel/uml/class143493.html b/doc/devel/uml/class143493.html new file mode 100644 index 000000000..63ef30fb2 --- /dev/null +++ b/doc/devel/uml/class143493.html @@ -0,0 +1,24 @@ + + + + + + +Class InvocationStateBase + + + + + +
Class InvocationStateBase
+

+ + + + +

Declaration :

Directly inherited by : Caching

+
+
+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class143621.html b/doc/devel/uml/class143621.html new file mode 100644 index 000000000..39379446c --- /dev/null +++ b/doc/devel/uml/class143621.html @@ -0,0 +1,24 @@ + + + + + + +Class Caching + + + + + +
Class Caching
+

+ + + + +

Declaration :

Directly inherited by : Process

+
+
+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class143749.html b/doc/devel/uml/class143749.html new file mode 100644 index 000000000..2d3726110 --- /dev/null +++ b/doc/devel/uml/class143749.html @@ -0,0 +1,24 @@ + + + + + + +Class Process + + + + + +
Class Process
+

+ + + + +

Declaration :

Directly inherited by : InPlace

+
+
+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class143877.html b/doc/devel/uml/class143877.html new file mode 100644 index 000000000..b3164a70a --- /dev/null +++ b/doc/devel/uml/class143877.html @@ -0,0 +1,24 @@ + + + + + + +Class InPlace + + + + + +
Class InPlace
+

+ + + + +

Declaration :

Directly inherited by : StateProxy

+
+
+

All public operations : allocateBuffer , fetch , isCalculated , releaseBuffer

+ + diff --git a/doc/devel/uml/class144005.html b/doc/devel/uml/class144005.html new file mode 100644 index 000000000..9fd2629bc --- /dev/null +++ b/doc/devel/uml/class144005.html @@ -0,0 +1,24 @@ + + + + + + +Class WiringTable + + + + + +
Class WiringTable
+

+ + + + +

Declaration :

+ +
Relation <directional aggregation by value>

Declaration :

+
Relation <unidirectional association>

Declaration :

+ + diff --git a/doc/devel/uml/class144133.html b/doc/devel/uml/class144133.html new file mode 100644 index 000000000..995d09019 --- /dev/null +++ b/doc/devel/uml/class144133.html @@ -0,0 +1,20 @@ + + + + + + +Class BuffHandle + + + + + +
Class BuffHandle
+

+ + + + +

Declaration :

+ diff --git a/doc/devel/uml/classdiagrams.html b/doc/devel/uml/classdiagrams.html index 4cf5416cc..e1289d57d 100644 --- a/doc/devel/uml/classdiagrams.html +++ b/doc/devel/uml/classdiagrams.html @@ -27,8 +27,10 @@ Media-Asset Relations Proc-Asset Relations Render Entities +Render Mechanics Rules access Session structure +StateAdapter composition Struct-Asset Relations diff --git a/doc/devel/uml/classes.html b/doc/devel/uml/classes.html index 23162b8f6..7992c89cf 100644 --- a/doc/devel/uml/classes.html +++ b/doc/devel/uml/classes.html @@ -21,15 +21,18 @@ Allocationa directive to place a MObject in a specific way AppconfigsingletonSingleton to hold inevitable global flags and constants and for performing erarly (static) global initialization tasks. Applicable -ARenderRepresentation of a Audio render process AssemblerThis is the actual building facility: provided the correct tools and associations, it serves to build and connect the individual ProcNode objects AssetinterfaceSuperinterface describing especially the bookeeping properties of Assets AssetManagerboundaryFacade for the Asset subsystem AutoAutomation data for some parameter (i.e. a time varying function) +BackendCache +BuffHandle Buildableinterface BuilderFacadeboundaryProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade BuilderToolinterfaceUsed according to the visitor pattern: each Tool contains the concrete implementation for one task to be done to the various MObject classes BuildInstruct(Interface) building instructions to be executed by the Builder on the render node network under construction. +Caching +Caller Categorytree like classification of Assets Clipbookkeeping (asset) view of a media clip. Clip @@ -71,11 +74,10 @@ FrameDescriptorinterfaceA FrameDescriptor implements the higher level interfaces for frames. Further refinements are made by subclassing and policy classes FrameReference GLBuf -GLPipespecialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form -GLRenderRepresentation of a OpenGL accelerated Video render process -Hub +InPlace InterpolatorProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter Invalid +InvocationStateBase Label Link LocatingPinAn element with value semantics, which actually implements the placement of some MObject by positioning it in some way. @@ -91,6 +93,7 @@ MObjectinterface MutexI provided a reworked Mutex class in my Cinelerra2 repository NodeCreatorToolThis 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. +NodeWiring ParameterDescriptor and access object for a plugin parameter. Parameters may be provided with values from the session, and this values may be automated. ParamProviderinterfaceA facility to get the actual value of a plugin/effect parameter PathManagerWhile building a render engine, this Strategy class decides on the actual render strategy in accordance to the current controller settings (system state) @@ -101,6 +104,8 @@ Prefetch Previewalternative version of the media data, probably with lower resolution Prockey abstraction: data processing asset +ProcDispatcher +Process Processor ProcNodeinterfaceKey abstraction of the Render Engine: A Data processing Node ProcPattspecial type of structural Asset representing information how to build some part of the render engine's processing nodes network. @@ -122,8 +127,10 @@ SimpleClipElementary clip consisting of only one media stream SmartPointerauxiliary SourceSource Node: represents a media source to pull data from. +Stateinterface State -StateProxyinterface +StateAdapter +StateProxyimplementation std::exceptionauxiliary Structkey abstraction: structural asset ThreadWe can basically reuse the Thread class design from Cinelerra2, Thread becomes a baseclass for all Threads @@ -139,7 +146,8 @@ Useractor VFrame Visitable -VRenderRepresentation of a Video render process. (Encapsulates the video buffers for the actual calculations) +WiringDescriptor +WiringTable Wish WriteBuffer WriteBufferPool diff --git a/doc/devel/uml/classes_list.html b/doc/devel/uml/classes_list.html index 6f3005da9..f89fb300a 100644 --- a/doc/devel/uml/classes_list.html +++ b/doc/devel/uml/classes_list.html @@ -22,15 +22,18 @@ Allocation
Appconfig
Applicable
-ARender
Assembler
Asset
AssetManager
Auto
+BackendCache
+BuffHandle
Buildable
BuilderFacade
BuilderTool
BuildInstruct
+Caching
+Caller
Category
Clip
Clip
@@ -72,11 +75,10 @@ FrameDescriptor
FrameReference
GLBuf
-GLPipe
-GLRender
-Hub
+InPlace
Interpolator
Invalid
+InvocationStateBase
Label
Link
LocatingPin
@@ -92,6 +94,7 @@ MObject
Mutex
NodeCreatorTool
+NodeWiring
Parameter
ParamProvider
PathManager
@@ -102,6 +105,8 @@ Prefetch
Preview
Proc
+ProcDispatcher
+Process
Processor
ProcNode
ProcPatt
@@ -123,8 +128,10 @@ SimpleClip
SmartPointer
Source
+State
State
-StateProxy
+StateAdapter
+StateProxy
std::exception
Struct
Thread
@@ -140,7 +147,8 @@ User
VFrame
Visitable
-VRender
+WiringDescriptor
+WiringTable
Wish
WriteBuffer
WriteBufferPool
diff --git a/doc/devel/uml/collaborationdiagrams.html b/doc/devel/uml/collaborationdiagrams.html index 2d8ab627d..5ccf1d4a5 100644 --- a/doc/devel/uml/collaborationdiagrams.html +++ b/doc/devel/uml/collaborationdiagrams.html @@ -18,6 +18,7 @@ +
"default" object
build processThis figure shows the process of building and starting a RenderEngine
Render Process
diff --git a/doc/devel/uml/fig128389.png b/doc/devel/uml/fig128389.png index c6a57b857..fa8dcdc95 100644 Binary files a/doc/devel/uml/fig128389.png and b/doc/devel/uml/fig128389.png differ diff --git a/doc/devel/uml/fig129157.png b/doc/devel/uml/fig129157.png index 4629abad9..7ce020fc6 100644 Binary files a/doc/devel/uml/fig129157.png and b/doc/devel/uml/fig129157.png differ diff --git a/doc/devel/uml/fig131973.png b/doc/devel/uml/fig131973.png new file mode 100644 index 000000000..78f068e2d Binary files /dev/null and b/doc/devel/uml/fig131973.png differ diff --git a/doc/devel/uml/fig132229.png b/doc/devel/uml/fig132229.png new file mode 100644 index 000000000..4cc4b71d5 Binary files /dev/null and b/doc/devel/uml/fig132229.png differ diff --git a/doc/devel/uml/fig132357.png b/doc/devel/uml/fig132357.png new file mode 100644 index 000000000..e454c31e9 Binary files /dev/null and b/doc/devel/uml/fig132357.png differ diff --git a/doc/devel/uml/index.html b/doc/devel/uml/index.html index bbecbcbc0..de5e95e2f 100644 --- a/doc/devel/uml/index.html +++ b/doc/devel/uml/index.html @@ -32,7 +32,7 @@ Documentation

provided classes : Error, Time

Component Builder
-

provided classes : StateProxy

+

provided classes : State

required classes : Fixture, SessionImpl

Component Session
@@ -54,9 +54,10 @@ Documentation
Component AssetManagement
Component Dispatcher
+

provided classes : ProcDispatcher

Component Engine
-

Depends on Frame (Stream) Provider

required classes : StateProxy

+

Depends on Frame (Stream) Provider

required classes : State

Component ProcNode
@@ -78,6 +79,9 @@ Documentation

required classes : MediaAccessFacade

Component AssetDB
+ +
Component client code
+

required classes : ProcDispatcher

1.2 Component View interfaces

@@ -112,7 +116,7 @@ Documentation
Artifact Lumiera

Depends on common

Depends on gui

Depends on proc

Depends on backend

the main executable to be built

-

executable associated with : aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation, mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool

+

executable associated with : mobject, source, frame, placement, sessionimpl, builderfacade, controllerfacade, processor, pluginadapter, effect, buildertool, segmentationtool, aframe, assembler, trafo, explicitplacement, auto, glrender, link, parameter, renderengine, allocation, vframe, toolfactory, arender, renderstate, label, glbuf, procnode, stateproxy, hub, buildable, abstractmo, nodecreatertool, projector, interpolator, edl, fixture, glpipe, vrender, exitnode, pathmanager, track, paramprovider, mask, main, conmanager, clip, meta, fixedlocation, relativelocation

Artifact main

Artifact source

@@ -192,7 +196,7 @@ Documentation
Artifact stateproxy

Key Interface representing a render process and encapsulating state

-

Artifact source associated with : StateProxy

+

Artifact source associated with : State

Artifact controllerfacade

Facade and service access point for the Proc Layer Controller

@@ -517,7 +521,7 @@ Documentation
Artifact hub

special ProcNode used to build data distributing connections

-

Artifact source associated with : Hub

+

Artifact source

Artifact projector

video ProcNode for scaling and translating image data

@@ -537,19 +541,19 @@ Documentation
Artifact glpipe

specialized connection element for handling OpenGL implementation details

-

Artifact source associated with : GLPipe

+

Artifact source

Artifact arender

Representation of a Audio Render process

-

Artifact source associated with : ARender

+

Artifact source

Artifact vrender

Representation of a Video render process

-

Artifact source associated with : VRender

+

Artifact source

Artifact glrender

Representation of a OpenGL accellerated Video render process

-

Artifact source associated with : GLRender

+

Artifact source

Artifact aframe

a buffer and render process holding a Audio frame

@@ -670,6 +674,7 @@ Documentation
Class ParamProvider
Class Interpolator
Class LocatingPin
+
Class ProcDispatcher

2.2.2 Package Builder

@@ -759,7 +764,7 @@ Documentation
Class ToolFactory
Class ConManager
Class Assembler
-
Class StateProxy
+
Class State
Class Buildable
Class BuilderTool
Class SegmentationTool
@@ -872,26 +877,37 @@ reuse exiting Engine

Selection :

Transformation

Automation Entities



+ +

+

Render Mechanics



+ +

+

StateAdapter composition



Class RenderEngine
Class Processor
Class ExitNode
Class ProcNode
Class Trafo
Class Link
-
Class Hub
Class Projector
Class Mask
Class PluginAdapter
Class CodecAdapter
-
Class GLPipe
-
Class ARender
-
Class VRender
-
Class GLRender
Class Frame
Class AFrame
Class VFrame
Class GLBuf
Class Source
+
Class StateProxy
+
Class StateAdapter
+
Class WiringDescriptor
+
Class NodeWiring
+
Class InvocationStateBase
+
Class Caching
+
Class Process
+
Class InPlace
+
Class WiringTable
+
Class BuffHandle
@@ -1005,13 +1021,7 @@ reuse exiting Engine

Selection :

Transformation

  • datasrc = input

    • Class instance vid_a

    type :Source

    -
    Class instance aud_a

    type :Source

    -
    Class instance vid1

    type :VRender

    relations :

    -
    Class instance au1

    type :ARender

    relations :

    +
    Class instance aud_a

    type :Source

    Class instance

    type :VFrame

    Class instance

    type :AFrame

    Class instance

    type :RenderEngine

    relations :

    Selection :

    Transformation

    Class instance HUE

    type :PluginAdapter

    relations :

    -
    Class instance vid1

    type :VRender

    relations :

    Class instance

    type :VFrame

    Class instance video1

    type :Processor

    attributes :

    Selection :

    Transformation

    Class instance video

    type :ExitNode

    relations :

    +

    +

    +

    Render Process



    + +
    Class instance node1

    type :ProcNode

    +
    Class instance ad1

    type :StateAdapter

    +
    Class instance current

    type :StateProxy

    +
    Class instance node2

    type :ProcNode

    +
    Class instance ad2

    type :StateAdapter

    Class BackendCache
    +
    Class Caller
    + +
    Class instance node3

    type :ProcNode

    +
    Class instance ad3

    type :StateAdapter

    +
    Class instance vid1

    type :StateProxy

    +
    Class instance au1

    type :StateProxy

    3 Package BackendLayer

    diff --git a/doc/devel/uml/index_60.html b/doc/devel/uml/index_60.html index 4909e634c..8712d7074 100644 --- a/doc/devel/uml/index_60.html +++ b/doc/devel/uml/index_60.html @@ -17,8 +17,8 @@ - + @@ -28,8 +28,8 @@ - + diff --git a/doc/devel/uml/index_65.html b/doc/devel/uml/index_65.html index 3fce72879..ab57596c5 100644 --- a/doc/devel/uml/index_65.html +++ b/doc/devel/uml/index_65.html @@ -23,9 +23,13 @@ + + + + @@ -36,7 +40,6 @@ - @@ -51,9 +54,9 @@ - - + + diff --git a/doc/devel/uml/index_66.html b/doc/devel/uml/index_66.html index 2d9540c91..db64b33db 100644 --- a/doc/devel/uml/index_66.html +++ b/doc/devel/uml/index_66.html @@ -21,7 +21,9 @@ + + @@ -34,8 +36,8 @@ - + diff --git a/doc/devel/uml/index_67.html b/doc/devel/uml/index_67.html index 08c04b765..1612ca9ea 100644 --- a/doc/devel/uml/index_67.html +++ b/doc/devel/uml/index_67.html @@ -19,46 +19,49 @@ + + - + - - - - - - - - + + - - - - - - - - - - - - - + + + + + + + + - + + + + + + + + + - + + + + + - + @@ -104,6 +107,7 @@ +
    NameKindDescription
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    <flow>transition
    access Fileuse case
    activity finalactivity final
    activity finalactivity final
    ad1class instance
    ad2class instance
    ad3class instance
    add new object to sessionuse case
    AFrameclass
    aframeartifacta buffer and render process holding a Audio frame
    allocateBufferoperation
    allocationartifact
    Allocationclassa directive to place a MObject in a specific way
    anchorrelation
    applyoperation
    applyoperation
    Architecturecomponent viewThe various Components comprising the Lumiera Video editing Application
    ARenderclassRepresentation of a Audio render process
    arenderartifactRepresentation of a Audio Render process
    AssemblerclassThis is the actual building facility: provided the correct tools and associations, it serves to build and connect the individual ProcNode objects
    assemblerartifactbuilding facility (implementation of the build process)
    assetmanagerartifactFacade for the Asset subsystem
    Assetsclass view
    ATTACHattributeattach subject to anchor (e.g. an effect to a clip)
    au1class instance
    aud_Aclass instance
    au1class instance
    aud_aclass instance
    aud_Aclass instance
    audioclass instance
    audio1class instance
    audio1class instance
    Backend Componentsclass view
    backend use casesuse case diagram
    backend-componentscomponent diagram
    BackendCacheclass
    BackendLayerpackage
    BuffHandleclass
    buildoperation
    build flowactivity diagram
    build necessary?decision activity node
    buildableartifactmarker interface denoting any MObject able to be treated by Tools
    buildEngineoperationMain Operation of the Builder: create a render engine for a given part of the timeline
    Buildercomponent
    Builderpackage
    builderpackagesourcecode package

    The Builder creating the Render Engine,
    located within the MObject Subsystem
    Builderpackage
    Builder Entitiesclass diagram
    Builder Workingsclass view
    BuilderFacadeclassProvides unified access to the builder functionality. While individual components of the builder subsystem may be called if necessary or suitable, it is usually better to do all extern invocations via the high level methods of this Facade
    NameKindDescription
    Cachecomponent
    Cachecomponent view
    Cachingclass
    Callerclass
    categoryrelationprimary tree like classification of the asset
    Categoryclasstree like classification of Assets
    categoryartifacttree like classification of Assets
    causeattributea copy of the first exception encountered in this exception chain
    chainrelationChain of additional Placements further constraining the position of this MObject
    chainoperationcreate and add another Placement for this media object, thus increasingly constraining the (possible) position of this object.
    chainrelationChain of additional Placements further constraining the position of this MObject
    checked_inrelationchecked_in objects are subject of cache aging and must be not in use
    checked_outrelationthis list keeps all mappings which are in use, and thus prevents them from Cache aging
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    class instanceclass instance
    clearoperationclear current session contents
    without resetting overall session config.
    Afterwards, the session will contain only one
    empty EDL, while all Assets are retained.
    client codecomponent
    Clipclassbookkeeping (asset) view of a media clip.
    clipartifactbookkeeping (asset) view of a media clip.
    clipartifacta Media Clip
    clipartifactbookkeeping (asset) view of a media clip.
    Clipclass
    clipsrelation
    Codecclassdescription of some media data decoder or encoder facility
    create specific objectuse case
    createClipoperationcreate a (possibly compound) Clip refering to this media, ready to be added to the EDL.
    currEDLoperationThe EDL currently in focus. In most cases, Session and EDL are almost the same, just EDL emphasizes the collection aspect. But generally (for larger editing projects) one Session can contain several EDLs, which may even be nested. At any given time, only one of these EDLs has focus and recieves the editing commands.
    currentclass instance
    currentrelationStandard access path to get at the current session via the Session Manager, which acts as a "PImpl" smart pointer
    currFramerelation
    diff --git a/doc/devel/uml/index_68.html b/doc/devel/uml/index_68.html index 90bc7ba4d..e9e768a1e 100644 --- a/doc/devel/uml/index_68.html +++ b/doc/devel/uml/index_68.html @@ -32,8 +32,8 @@ designpackage designpackageAll things concering the big picture.
    Not a real code package, rather a container for design drafts, specifications, decisions. detect Channelsuse case -determine Render Paramsexpansion region determine Render Paramsopaque activity action +determine Render Paramsexpansion region devnullclass instance Dispatchercomponent dispatchOpoperation diff --git a/doc/devel/uml/index_69.html b/doc/devel/uml/index_69.html index 6c17d406d..1f6fd3f19 100644 --- a/doc/devel/uml/index_69.html +++ b/doc/devel/uml/index_69.html @@ -24,8 +24,8 @@ EDL Example2object diagramMore 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 edlsrelation EffectclassEffect or media processing component -effectartifactEDL representation of a pluggable and automatable effect. effectartifactEffect or media processing component +effectartifactEDL representation of a pluggable and automatable effect. Effectclass elementsrelationrelevant MObjects comprising this segment. TODO: actually necessary?? enableoperationchange the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well diff --git a/doc/devel/uml/index_70.html b/doc/devel/uml/index_70.html index 78b986b1b..5e1189dd5 100644 --- a/doc/devel/uml/index_70.html +++ b/doc/devel/uml/index_70.html @@ -18,6 +18,7 @@ + diff --git a/doc/devel/uml/index_71.html b/doc/devel/uml/index_71.html index 82430e314..f4ad7d96d 100644 --- a/doc/devel/uml/index_71.html +++ b/doc/devel/uml/index_71.html @@ -46,9 +46,7 @@ - - diff --git a/doc/devel/uml/index_72.html b/doc/devel/uml/index_72.html index 0abaaac68..3547e6f3e 100644 --- a/doc/devel/uml/index_72.html +++ b/doc/devel/uml/index_72.html @@ -22,7 +22,6 @@ - diff --git a/doc/devel/uml/index_73.html b/doc/devel/uml/index_73.html index 798945020..9a0a77429 100644 --- a/doc/devel/uml/index_73.html +++ b/doc/devel/uml/index_73.html @@ -20,9 +20,10 @@ - + + @@ -31,8 +32,10 @@ + +
    NameKindDescription
    Factoryclassa template for generating functor-like Factory objects, used to encapsulate object creation and providing access via smart-pointers only.
    fetchoperation
    Fileclass
    filerelation
    File Mappingclass diagramShows whats used to access Frames
    getValueoperation
    GLBufclass
    glbufartifacta buffer and render process holding a Video frame for OpenGL rendering
    GLPipeclassspecialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form
    glpipeartifactspecialized connection element for handling OpenGL implementation details
    GLRenderclassRepresentation of a OpenGL accelerated Video render process
    glrenderartifactRepresentation of a OpenGL accellerated Video render process
    groupsattributeadditional classification, selections or departments this asset belongs to. Groups are optional, non-exclusive and may be overlapping.
    guipackagesourcecode package

    User Interface classes go here
    handles_availableattributeinitialized to the maximum number of filehandles the backend may use for mapped files. When no handles are available, the handle which is last in the handles list is closed and (re-)used.
    Else this number is decremented for each new filehandle used and incremented for any one explicitly freed.
    Hierarchyclass diagramLumiera Exception hierarchy
    howtoProcoperation@return descriptor how to build a render pipeline corresponding to this media
    Hubclass
    hubartifactspecial ProcNode used to build data distributing connections
    HUEclass instance
    HUEclass instance
    idattributeAsset primary key.
    In Memory Databaseclass diagram
    inFixtureactivity action pin
    inputclass instance
    InPlaceclass
    inputclass instance
    inputclass instance
    inputclass instance
    instanceoperation
    instructionsrelation
    Interfaceclass view
    interpolatorartifactdenotes a facility to get (continuously interpolated) parameter values
    InterpolatorclassProvides the implementation for getting the acutal value of a time varying or automated effect/plugin parameter
    Invalidclass
    InvocationStateBaseclass
    iporelation
    isActiveoperationweather this asset is swithced on and consequently included in the fixture and participates in rendering
    isCalculatedoperation
    diff --git a/doc/devel/uml/index_77.html b/doc/devel/uml/index_77.html index e6d8e8031..1428ef6eb 100644 --- a/doc/devel/uml/index_77.html +++ b/doc/devel/uml/index_77.html @@ -33,8 +33,8 @@ MediaFactoryclassspecialized Asset Factory for configuring (new) media asset instances based on existing media files on disk; can create placeholder assets as well merge activity nodemerge activity node Metaclasskey abstraction: metadata and organisational asset -metaartifactkey abstraction: metadata and organisational asset metaartifactabstract base class of all MObjects representing meta data or processing instructions +metaartifactkey abstraction: metadata and organisational asset Metaclass mobjectartifactKey Abstraction: A Media Object in the Session mobjectpackagesourcecode package

    MObject Subsystem
    including the Session (EDL), Builder and Processing Controller diff --git a/doc/devel/uml/index_78.html b/doc/devel/uml/index_78.html index 1cf51971d..74fa8a9d8 100644 --- a/doc/devel/uml/index_78.html +++ b/doc/devel/uml/index_78.html @@ -20,9 +20,13 @@ nameattributeelement ID, comprehensible but sanitized. The tuple (category, name, org) is unique. need sub objectuse case nextrelationnext additional LocatingPin, if any +node1class instance +node2class instance +node3class instance nodecreatertoolartifactcentral Tool implementing the Renderengine building NodeCreatorToolclassThis 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. nodesrelation +NodeWiringclass diff --git a/doc/devel/uml/index_79.html b/doc/devel/uml/index_79.html index 4ac4c3b33..d1fdc83c0 100644 --- a/doc/devel/uml/index_79.html +++ b/doc/devel/uml/index_79.html @@ -19,9 +19,9 @@ NameKindDescription offsetattributeOffset the actual position by this (time) value relative to the anchor point. TODO: Representation? orgattributeorigin 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 Lumiera codebase is "lumi". +ouputclass instance ouputclass instance ouputclass instance -ouputclass instance outPortrelationthe Port this MObject wants to be conected to outputrelation Overviewcomponent diagramThis drawing shows the top level compoents and relations diff --git a/doc/devel/uml/index_80.html b/doc/devel/uml/index_80.html index ba34ae763..a3268b59b 100644 --- a/doc/devel/uml/index_80.html +++ b/doc/devel/uml/index_80.html @@ -40,6 +40,7 @@ pnodenode pointattributeidentifying the point where the nodes should be attached Posix Threads Abstractionclass viewC++ wrapers for pthreads +predecessorsrelation predicate implclass instance Prefetchclass Previewclassalternative version of the media data, probably with lower resolution @@ -51,6 +52,9 @@ procattributeholds the Processor (Render Engine Element) to be built by the current build step Proc-Asset Relationsclass diagram proc-componentscomponent diagram +ProcDispatcherclass +Processclass +processoperation ProcessingLayerpackage Processorclass processorartifacta single render pipeline for one segment of the timeline @@ -62,6 +66,7 @@ ProjectorclassSpecial video processing node used to scale and translate image data. projectorartifactvideo ProcNode for scaling and translating image data providerrelation +pulloperation diff --git a/doc/devel/uml/index_82.html b/doc/devel/uml/index_82.html index 1bade53e8..b5b305e10 100644 --- a/doc/devel/uml/index_82.html +++ b/doc/devel/uml/index_82.html @@ -22,10 +22,13 @@ registryrelation@internal Table or DB holding all registered asset instances. relativelocationartifactPlacement implemnetaion providing various ways of attaching a MObject to another one RelativeLocationclass -RelTypeclassthe possible kinds of RelativePlacements +releaseBufferoperation relTypeattributethe kind of relation denoted by this Placement +RelTypeclassthe possible kinds of RelativePlacements removeoperationremove the given asset <i>together with all its dependants</i> from the internal DB Render Entitiesclass diagram +Render Mechanicsclass diagram +Render Processcollaboration diagram Render Requestactivity parameter RenderEngineclass renderengineartifacta complete network of processing nodes usable for rendering @@ -42,6 +45,7 @@ resolveoperation Resolvercomponent ResolverBaseclass +retrieveoperation rootCauseoperationIf this exception was caused by a chain of further exceptions,
    return the first one registered in this throw sequence.
    This works only, if every exceptions thrown as a consequence
    of another exception is propperly constructed by passing
    the original exception to the constructor Rule Basecomponent Rules accessclass diagram diff --git a/doc/devel/uml/index_83.html b/doc/devel/uml/index_83.html index e2f2fcea3..5dd747140 100644 --- a/doc/devel/uml/index_83.html +++ b/doc/devel/uml/index_83.html @@ -32,8 +32,8 @@ Service Componentsclass view Sessioncomponent sessionartifactInterface: the session edited by the user -Sessionclass view sessionpackagesourcecode package

    Everything concerning the EDL and Session, within the MObject Subsystem +Sessionclass view SessionclassPrimary Interface for all editing tasks.
    The session contains defaults, all the assets being edited, and a set of EDL with the individual MObjects to be manipulated and rendered. Session structureclass diagram sessionimplartifactholds the complete session data to be edited by the user @@ -47,17 +47,21 @@ SimpleClipclassElementary clip consisting of only one media stream SmartPointerclass SmartPointersclass view -sourcerelationthe media source this clip referes to sourcerelationmedia source of this clip +sourcerelationthe media source this clip referes to SourceclassSource Node: represents a media source to pull data from. sourceartifactRepresentation of a Media source Source Overviewdeployment diagram startattributestartpos in source startattributebegin of the timerange covered by this processor startattribute +Stateclass Statenode Stateclass -StateProxyclass +staterelation +StateAdapterclass +StateAdapter compositionclass diagram +StateProxyclass stateproxyartifactKey Interface representing a render process and encapsulating state std::exceptionclass Structclasskey abstraction: structural asset diff --git a/doc/devel/uml/index_84.html b/doc/devel/uml/index_84.html index 14d928057..b0541e88b 100644 --- a/doc/devel/uml/index_84.html +++ b/doc/devel/uml/index_84.html @@ -42,13 +42,13 @@ trafoartifacttransforming processing Node treatoperation treatoperationThis operation is to be overloaded for the specific MObject subclasses to be treated. +treatoperation treatoperation treatoperation -treatoperation treatoperation +treatoperation treatoperation treatoperation -treatoperation TypeHandlerclass TypeHandler<Pipe>class diff --git a/doc/devel/uml/index_86.html b/doc/devel/uml/index_86.html index e3c5f01a9..cda6a585e 100644 --- a/doc/devel/uml/index_86.html +++ b/doc/devel/uml/index_86.html @@ -20,27 +20,25 @@ versionattributeversion 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. VFrameclass vframeartifacta buffer and render process holding a Video frame -vid1class instance -vid1class instance -vid_Aclass instance -vid_Aclass instance -vid_aclass instance -vid_aclass instance +vid1class instance vid_Aclass instance -videoclass instance -videoclass instance +vid_aclass instance +vid_Aclass instance +vid_Aclass instance +vid_aclass instance videoclass instance +videoclass instance +videoclass instance videoclass instance -video1class instance -video1class instance -video1class instance -video1class instance video1class instance video1class instance +video1class instance +video1class instance +video1class instance +video1class instance Visitableclass visitorpackagesub-namespace for visitor library implementation visitorartifactAcyclic Visitor library -VRenderclassRepresentation of a Video render process. (Encapsulates the video buffers for the actual calculations) vrenderartifactRepresentation of a Video render process diff --git a/doc/devel/uml/index_87.html b/doc/devel/uml/index_87.html index bd2bf3399..7e2b7e31f 100644 --- a/doc/devel/uml/index_87.html +++ b/doc/devel/uml/index_87.html @@ -20,6 +20,9 @@ whatoperation whatoperationthe base class of all exceptions thrown by the standard library when to queryuse case diagram +wiringrelation +WiringDescriptorclass +WiringTableclass wiringTemplaterelation wishartifactLocatingPin representing a low-priority directive by the user,
    to be fulfilled only if possible (and after satisfying the
    more important LocatingPins) Wishclass diff --git a/doc/devel/uml/public_operations.html b/doc/devel/uml/public_operations.html index 697d67b52..c252030f0 100644 --- a/doc/devel/uml/public_operations.html +++ b/doc/devel/uml/public_operations.html @@ -17,6 +17,7 @@ + @@ -29,6 +30,7 @@ + @@ -47,26 +49,31 @@ + + + + + - + + - diff --git a/src/common/Makefile.am b/src/common/Makefile.am index 06082da31..965ac6079 100644 --- a/src/common/Makefile.am +++ b/src/common/Makefile.am @@ -25,7 +25,7 @@ liblumicommon_a_CXXFLAGS = $(CXXFLAGS) -Wall liblumicommon_a_CPPFLAGS = -I$(top_srcdir)/src/ liblumicommon_a_SOURCES = \ - $(liblumicommon_a_srcdir)/time.cpp \ + $(liblumicommon_a_srcdir)/lumitime.cpp \ $(liblumicommon_a_srcdir)/util.cpp \ $(liblumicommon_a_srcdir)/visitor.cpp \ $(liblumicommon_a_srcdir)/cmdline.cpp \ @@ -43,7 +43,7 @@ noinst_HEADERS += \ $(liblumicommon_a_srcdir)/singleton.hpp \ $(liblumicommon_a_srcdir)/singletonpolicies.hpp \ $(liblumicommon_a_srcdir)/singletonpreconfigure.hpp \ - $(liblumicommon_a_srcdir)/time.hpp \ + $(liblumicommon_a_srcdir)/lumitime.hpp \ $(liblumicommon_a_srcdir)/typelist.hpp \ $(liblumicommon_a_srcdir)/visitor.hpp \ $(liblumicommon_a_srcdir)/visitordispatcher.hpp \ diff --git a/src/common/cmdline.cpp b/src/common/cmdline.cpp index 1e8e1849f..dec1a0620 100644 --- a/src/common/cmdline.cpp +++ b/src/common/cmdline.cpp @@ -27,7 +27,9 @@ #include "proc/nobugcfg.hpp" #include -#include +#include +#include +#include using boost::algorithm::split; using boost::algorithm::join; diff --git a/src/common/error.hpp b/src/common/error.hpp index 687425ec2..84140af80 100644 --- a/src/common/error.hpp +++ b/src/common/error.hpp @@ -152,6 +152,7 @@ namespace lumiera /** install our own handler for undeclared exceptions. Will be * called automatically ON_BASIC_INIT when including errror.hpp + * @note it's OK this is defined multiple times... * @see appconfig.hpp */ void install_unexpectedException_handler (); namespace { diff --git a/src/common/time.cpp b/src/common/lumitime.cpp similarity index 97% rename from src/common/time.cpp rename to src/common/lumitime.cpp index a37979c6b..bd50c78bf 100644 --- a/src/common/time.cpp +++ b/src/common/lumitime.cpp @@ -21,7 +21,7 @@ * *****************************************************/ -#include "common/time.hpp" +#include "common/lumitime.hpp" #include diff --git a/src/common/time.hpp b/src/common/lumitime.hpp similarity index 92% rename from src/common/time.hpp rename to src/common/lumitime.hpp index d065c3f36..33b5bb4c3 100644 --- a/src/common/time.hpp +++ b/src/common/lumitime.hpp @@ -1,5 +1,5 @@ /* - TIME.hpp - unified representation of a time point, including conversion functions + LUMITIME.hpp - unified representation of a time point, including conversion functions Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,8 +21,8 @@ */ -#ifndef LUMIERA_TIME_H -#define LUMIERA_TIME_H +#ifndef LUMIERA_LUMITIME_H +#define LUMIERA_LUMITIME_H #include diff --git a/src/lib/appconfig.hpp b/src/lib/appconfig.hpp index b82c3fa2b..a69336d78 100644 --- a/src/lib/appconfig.hpp +++ b/src/lib/appconfig.hpp @@ -129,7 +129,8 @@ namespace lumiera * All other lables are just arbitrary (string) constants and it * is necessary that "someone" cares to fire off the lifcycle events * at the right place. For example, lumiera-main (and the test runner) - * calls \c Appconfig::instance().execute(ON_GLOBAL_INIT) (and..SHUTDOWN) + * calls \c Appconfig::instance().execute(ON_GLOBAL_INIT) (and..SHUTDOWN) + * @note duplicate or repeated calls with the same callback are a NOP */ class LifecycleHook : private noncopyable diff --git a/src/lib/time.c b/src/lib/time.c index f9135ac8c..22340ee77 100644 --- a/src/lib/time.c +++ b/src/lib/time.c @@ -28,6 +28,7 @@ lumiera_tmpbuf_print_time (gavl_time_t time) { int milliseconds, seconds, minutes, hours; int negative; + if(time < 0) { diff --git a/src/proc/Makefile.am b/src/proc/Makefile.am index 603f4d825..aa758771f 100644 --- a/src/proc/Makefile.am +++ b/src/proc/Makefile.am @@ -114,8 +114,7 @@ liblumiprocmobjectbuilder_a_SOURCES = \ $(liblumiprocmobjectbuilder_a_srcdir)/assembler.cpp \ $(liblumiprocmobjectbuilder_a_srcdir)/conmanager.cpp \ $(liblumiprocmobjectbuilder_a_srcdir)/nodecreatertool.cpp \ - $(liblumiprocmobjectbuilder_a_srcdir)/segmentationtool.cpp \ - $(liblumiprocmobjectbuilder_a_srcdir)/toolfactory.cpp + $(liblumiprocmobjectbuilder_a_srcdir)/segmentationtool.cpp liblumiprocmobjectcontroller_a_srcdir = $(top_srcdir)/src/proc/mobject/controller @@ -209,7 +208,6 @@ noinst_HEADERS += \ $(liblumiproc_a_srcdir)/mobject/builder/conmanager.hpp \ $(liblumiproc_a_srcdir)/mobject/builder/nodecreatertool.hpp \ $(liblumiproc_a_srcdir)/mobject/builder/segmentationtool.hpp \ - $(liblumiproc_a_srcdir)/mobject/builder/toolfactory.hpp \ $(liblumiproc_a_srcdir)/mobject/builderfacade.hpp \ $(liblumiproc_a_srcdir)/mobject/controller/pathmanager.hpp \ $(liblumiproc_a_srcdir)/mobject/controller/renderstate.hpp \ diff --git a/src/proc/lumiera.hpp b/src/proc/lumiera.hpp index c00a70254..49822b469 100644 --- a/src/proc/lumiera.hpp +++ b/src/proc/lumiera.hpp @@ -32,7 +32,7 @@ #include "common/p.hpp" #include "common/util.hpp" -#include "common/time.hpp" +#include "common/lumitime.hpp" #include "common/error.hpp" ///< pulls in NoBug via nobugcfg.hpp #include "lib/appconfig.hpp" diff --git a/src/proc/mobject/builder/toolfactory.cpp b/src/proc/mobject/builder/toolfactory.cpp deleted file mode 100644 index 8e1b14631..000000000 --- a/src/proc/mobject/builder/toolfactory.cpp +++ /dev/null @@ -1,42 +0,0 @@ -/* - ToolFactory - supply of Tool implementations for the Builder - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - 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 "proc/mobject/builder/toolfactory.hpp" - -namespace mobject - { - namespace builder - { - - - - BuilderTool & - ToolFactory::configure () - { - } - - - - } // namespace mobject::builder - -} // namespace mobject diff --git a/src/proc/mobject/builder/toolfactory.hpp b/src/proc/mobject/builder/toolfactory.hpp deleted file mode 100644 index 2061b4fd2..000000000 --- a/src/proc/mobject/builder/toolfactory.hpp +++ /dev/null @@ -1,48 +0,0 @@ -/* - TOOLFACTORY.hpp - supply of Tool implementations for the Builder - - Copyright (C) Lumiera.org - 2008, Hermann Vosseler - - 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. - -*/ - - -#ifndef MOBJECT_BUILDER_TOOLFACTORY_H -#define MOBJECT_BUILDER_TOOLFACTORY_H - -#include "proc/mobject/builder/buildertool.hpp" - - - -namespace mobject - { - namespace builder - { - - - class ToolFactory - { - public: - BuilderTool & configure () ; - }; - - - - } // namespace mobject::builder - -} // namespace mobject -#endif diff --git a/tests/common/testtargetobj.hpp b/tests/common/testtargetobj.hpp index 28ac5890d..5eb7ddf01 100644 --- a/tests/common/testtargetobj.hpp +++ b/tests/common/testtargetobj.hpp @@ -29,7 +29,7 @@ #include "common/factory.hpp" //#include "common/util.hpp" -#include +#include #include #include #include diff --git a/uml/lumiera/128389 b/uml/lumiera/128389 index 52c1b5245..2a8c1a7c0 100644 --- a/uml/lumiera/128389 +++ b/uml/lumiera/128389 @@ -1,6 +1,6 @@ format 40 "RenderEngine" // ProcessingLayer::RenderEngine - revision 13 + revision 16 modified_by 5 "hiv" // class settings //class diagram settings @@ -82,6 +82,16 @@ format 40 size A4 end + classdiagram 131973 "Render Mechanics" + draw_all_relations no hide_attributes default hide_operations default show_members_full_definition yes 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 + + classdiagram 132357 "StateAdapter composition" + 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 + class 131333 "RenderEngine" visibility package cpp_decl "${comment}${template}class ${name}${inherit} @@ -155,7 +165,7 @@ ${inlines} a package cpp default "#include in source" classrelation_ref 136325 // - b multiplicity "" parent class_ref 132741 // StateProxy + b multiplicity "" parent class_ref 132741 // State end attribute 129413 "start" @@ -233,6 +243,46 @@ ${members}}; classrelation_ref 137861 // params () b multiplicity "" parent class_ref 134533 // Parameter end + + classrelation 152581 // predecessors () + relation 149125 *--> + stereotype "array" + a role_name "predecessors" multiplicity "*" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; +" + classrelation_ref 152581 // predecessors () + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + + operation 135685 "pull" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136069 "process" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end end class 131845 "Trafo" @@ -275,26 +325,6 @@ ${inlines} end end - class 132101 "Hub" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - classrelation 133125 // - relation 132357 ---|> - a public - cpp default "${type}" - classrelation_ref 133125 // - b multiplicity "" parent class_ref 131717 // ProcNode - end - end - class 132229 "Projector" visibility package cpp_decl "${comment}${template}class ${name}${inherit} @@ -377,90 +407,6 @@ ${inlines} end end - class 132613 "GLPipe" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "specialized connection node used to handle the transfer of OpenGL data from a image bitmap into texture form" - classrelation 133381 // - relation 132613 ---|> - a public - cpp default "${type}" - classrelation_ref 133381 // - b multiplicity "" parent class_ref 131973 // Link - end - end - - class 132869 "ARender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a Audio render process" - classrelation 134661 // - relation 133509 ---|> - a public - cpp default "${type}" - classrelation_ref 134661 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - - class 132997 "VRender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a Video render process. (Encapsulates the video buffers for the actual calculations)" - classrelation 134789 // - relation 133637 ---|> - a public - cpp default "${type}" - classrelation_ref 134789 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - - class 133125 "GLRender" - visibility package - cpp_decl "${comment}${template}class ${name}${inherit} - { -${members} }; -${inlines} -" - java_decl "" - idl_decl "" - explicit_switch_type "" - - comment "Representation of a OpenGL accelerated Video render process" - classrelation 134917 // - relation 133765 ---|> - a public - cpp default "${type}" - classrelation_ref 134917 // - b multiplicity "" parent class_ref 132741 // StateProxy - end - end - class 133253 "Frame" abstract visibility public stereotype "interface" cpp_decl "${comment}${template}class ${name}${inherit} @@ -568,5 +514,271 @@ ${inlines} b multiplicity "" parent class_ref 136709 // Media end end + + class 142469 "StateProxy" + visibility package stereotype "implementation" + nformals 2 + formal name "WIRING" type "class" explicit_default_value "" + explicit_extends "" + formal name "POLICY" type "class" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152453 // + relation 148997 ---|> + a public + cpp default "${type}" + classrelation_ref 152453 // + b multiplicity "" parent class_ref 132741 // State + end + + classrelation 153221 // + relation 149765 ---|> + a public + cpp default "${type}" + classrelation_ref 153221 // + b multiplicity "" parent class_ref 143877 // InPlace + end + + classrelation 154117 // wiring () + relation 150661 ---> + a role_name "wiring" multiplicity "1" const_relation protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 154117 // wiring () + b multiplicity "" parent class_ref 144005 // WiringTable + end + end + + class 142597 "StateAdapter" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152325 // + relation 148869 ---|> + a public + cpp default "${type}" + classrelation_ref 152325 // + b multiplicity "" parent class_ref 132741 // State + end + + operation 135557 "retrieve" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + classrelation 152709 // state () + relation 149253 ---> + a role_name "state" multiplicity "1" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 152709 // state () + b multiplicity "" parent class_ref 142469 // StateProxy + end + + classrelation 152837 // + relation 149381 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 152837 // + b multiplicity "" parent class_ref 133253 // Frame + end + end + + class 142725 "WiringDescriptor" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 143365 "NodeWiring" + visibility package + nformals 1 + formal name "STATE" type "class" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 152965 // + relation 149509 ---|> + a public + cpp default "${type}" + classrelation_ref 152965 // + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + + classrelation 153093 // + relation 149637 -_-> + a default + cpp default "Generated" + classrelation_ref 153093 // + b multiplicity "" parent class_ref 142597 // StateAdapter + end + end + + class 143493 "InvocationStateBase" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153733 // + relation 150277 ---|> + a public + cpp default "${type}" + classrelation_ref 153733 // + b multiplicity "" parent class_ref 132741 // State + end + end + + class 143621 "Caching" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153605 // + relation 150149 ---|> + a public + cpp default "${type}" + classrelation_ref 153605 // + b multiplicity "" parent class_ref 143493 // InvocationStateBase + end + end + + class 143749 "Process" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153477 // + relation 150021 ---|> + a public + cpp default "${type}" + classrelation_ref 153477 // + b multiplicity "" parent class_ref 143621 // Caching + end + end + + class 143877 "InPlace" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153349 // + relation 149893 ---|> + a public + cpp default "${type}" + classrelation_ref 153349 // + b multiplicity "" parent class_ref 143749 // Process + end + end + + class 144005 "WiringTable" + visibility package + nformals 1 + formal name "SIZ" type "int" explicit_default_value "" + explicit_extends "" + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + classrelation 153861 // + relation 150405 *--> + stereotype "array" + a role_name "" multiplicity "SIZ" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type} ${name}${value}; +" + classrelation_ref 153861 // + b multiplicity "" parent class_ref 144133 // BuffHandle + end + + classrelation 153989 // + relation 150533 ---> + a role_name "" multiplicity "" protected + cpp default " ${comment}${static}${mutable}${volatile}${const}${type}* ${name}${value}; +" + classrelation_ref 153989 // + b multiplicity "" parent class_ref 142725 // WiringDescriptor + end + end + + class 144133 "BuffHandle" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end end end diff --git a/uml/lumiera/128389.diagram b/uml/lumiera/128389.diagram index 5a6ad5049..da7bca1cb 100644 --- a/uml/lumiera/128389.diagram +++ b/uml/lumiera/128389.diagram @@ -14,7 +14,7 @@ classcanvas 128389 class_ref 131589 // ExitNode end classcanvas 128517 class_ref 131717 // ProcNode 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 462 264 2000 + xyz 462 257 2000 end classcanvas 129029 class_ref 131845 // Trafo 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 @@ -24,10 +24,6 @@ classcanvas 129157 class_ref 131973 // Link 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 648 444 2000 end -classcanvas 129285 class_ref 132101 // Hub - 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 593 444 2000 - end classcanvas 129413 class_ref 132229 // Projector 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 561 2000 @@ -40,26 +36,10 @@ classcanvas 129669 class_ref 132485 // PluginAdapter 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 506 621 2000 end -classcanvas 129797 class_ref 132613 // GLPipe - 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 699 531 2000 - end -classcanvas 132229 class_ref 132741 // StateProxy +classcanvas 132229 class_ref 132741 // State 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 36 374 2000 end -classcanvas 132997 class_ref 132869 // ARender - 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 31 511 2000 - end -classcanvas 133125 class_ref 132997 // VRender - 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 110 511 2000 - end -classcanvas 133253 class_ref 133125 // GLRender - 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 175 511 2000 - end classcanvas 133765 class_ref 133253 // Frame 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 269 612 2000 @@ -97,36 +77,25 @@ relationcanvas 128901 relation_ref 131973 // multiplicity_a_pos 414 419 3000 no_multiplicity_b relationcanvas 129925 relation_ref 132101 // geometry VHV - from ref 128389 z 1999 to point 445 384 - line 130693 z 1999 to point 499 384 + from ref 128389 z 1999 to point 445 397 + line 130693 z 1999 to point 499 397 line 130821 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 130053 relation_ref 132229 // geometry VHV - from ref 129029 z 1999 to point 516 383 - line 130949 z 1999 to point 499 383 + from ref 129029 z 1999 to point 516 397 + line 130949 z 1999 to point 499 397 line 131077 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 130181 relation_ref 132357 // - geometry VHV - from ref 129285 z 1999 to point 613 384 - line 131205 z 1999 to point 499 384 - line 131333 z 1999 to ref 128517 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 130309 relation_ref 132485 // geometry VHV - from ref 129157 z 1999 to point 668 384 - line 131461 z 1999 to point 499 384 + from ref 129157 z 1999 to point 668 397 + line 131461 z 1999 to point 499 397 line 131589 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 131717 relation_ref 132613 // - from ref 129797 z 1999 to ref 129157 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 131845 relation_ref 132741 // from ref 129413 z 1999 to ref 129029 no_role_a no_role_b @@ -139,27 +108,6 @@ relationcanvas 132101 relation_ref 132997 // from ref 129669 z 1999 to ref 129029 no_role_a no_role_b no_multiplicity_a no_multiplicity_b -relationcanvas 133381 relation_ref 133509 // - geometry VHV - from ref 132997 z 1999 to point 58 472 - line 134277 z 1999 to point 73 472 - line 134405 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b -relationcanvas 133509 relation_ref 133637 // - geometry VHV - from ref 133125 z 1999 to point 136 472 - line 134533 z 1999 to point 73 472 - line 134661 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b -relationcanvas 133637 relation_ref 133765 // - geometry VHV - from ref 133253 z 1999 to point 206 472 - line 134789 z 1999 to point 73 472 - line 134917 z 1999 to ref 132229 - no_role_a no_role_b - no_multiplicity_a no_multiplicity_b relationcanvas 135045 relation_ref 133893 // geometry VHV from ref 133893 z 1999 to point 252 704 @@ -179,14 +127,14 @@ relationcanvas 135429 relation_ref 134149 // no_role_a no_role_b no_multiplicity_a no_multiplicity_b relationcanvas 136965 relation_ref 134533 // - from ref 132229 z 1999 to point 306 465 + from ref 132229 z 1999 stereotype "<>" xyz 279 441 3000 to point 306 465 line 137093 z 1999 to ref 133765 role_a_pos 318 587 3000 no_role_b no_multiplicity_a multiplicity_b_pos 124 427 3000 relationcanvas 137349 relation_ref 134661 // geometry VHV - from ref 137221 z 1999 to point 763 384 - line 137477 z 1999 to point 499 384 + from ref 137221 z 1999 to point 763 397 + line 137477 z 1999 to point 499 397 line 137605 z 1999 to ref 128517 no_role_a no_role_b no_multiplicity_a no_multiplicity_b @@ -203,8 +151,8 @@ relationcanvas 139397 relation_ref 135429 // from ref 128517 z 1999 to point 432 264 line 139525 z 1999 to point 432 294 line 139653 z 1999 to ref 128517 - role_a_pos 414 272 3000 no_role_b - no_multiplicity_a multiplicity_b_pos 445 291 3000 + role_a_pos 414 276 3000 no_role_b + no_multiplicity_a multiplicity_b_pos 445 296 3000 relationcanvas 139909 relation_ref 136965 // from ref 139781 z 1999 to ref 129029 no_role_a no_role_b diff --git a/uml/lumiera/128901 b/uml/lumiera/128901 index e4d919380..455fee7d7 100644 --- a/uml/lumiera/128901 +++ b/uml/lumiera/128901 @@ -1,6 +1,6 @@ format 40 "Builder" // ProcessingLayer::MObject::Builder - revision 14 + revision 16 modified_by 5 "hiv" // class settings //class diagram settings @@ -299,7 +299,7 @@ ${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} end end - class 132741 "StateProxy" + class 132741 "State" abstract visibility public stereotype "interface" cpp_decl "${comment}${template}class ${name}${inherit} { @@ -316,12 +316,73 @@ ${members}}; classrelation 135941 // currFrame () relation 134533 ---> + stereotype "vector" a role_name "currFrame" multiplicity "" protected cpp default " ${comment}${static}${mutable}${volatile}${const}${type} * ${name}${value}; " classrelation_ref 135941 // currFrame () b multiplicity "1" parent class_ref 133253 // Frame end + + operation 135813 "fetch" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 135941 "allocateBuffer" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136197 "releaseBuffer" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end + + operation 136325 "isCalculated" + public explicit_return_type "" + nparams 0 + cpp_decl " ${comment}${friend}${static}${inline}${virtual}${type} ${name} ${(}${)}${const}${volatile} ${throw}${abstract};" + cpp_def "${comment}${inline}${type} +${class}::${name} ${(}${)}${const}${volatile} ${throw}${staticnl} +{ + ${body} +} + +" + + + end end class 134021 "Buildable" diff --git a/uml/lumiera/129029.diagram b/uml/lumiera/129029.diagram index 9892c6c73..7ca7da511 100644 --- a/uml/lumiera/129029.diagram +++ b/uml/lumiera/129029.diagram @@ -33,12 +33,6 @@ classinstancecanvas 129797 classinstance_ref 131717 // vid_a classinstancecanvas 129925 classinstance_ref 131845 // aud_a xyz 444 398 2000 end -classinstancecanvas 131717 classinstance_ref 131973 // vid1 - xyz 188 427 2000 - end -classinstancecanvas 131845 classinstance_ref 132101 // au1 - xyz 554 289 2000 - end classinstancecanvas 131973 classinstance_ref 132229 // xyz 117 492 2000 end @@ -49,9 +43,15 @@ note 133125 "render state proxy passed on" xyzwh 123 355 2000 104 53 textcanvas 133253 "Video and Audio Clip of length = 5 frames positioned at frame 2, producing two output streams (frame sequence)." xyzwh 445 507 2000 175 83 +classinstancecanvas 133381 classinstance_ref 137093 // vid1 + xyz 172 431 2000 + end +classinstancecanvas 133893 classinstance_ref 137221 // au1 + xyz 556 289 2000 + end objectlinkcanvas 128389 rel relation_ref 131845 // geometry VH - from ref 128005 z 1999 to point 117 205 + from ref 128005 z 1999 stereotype "<>" xyz 101 154 3000 to point 117 205 line 81 z 1999 to ref 128261 role_a_pos 188 183 3000 no_role_b objectlinkcanvas 128901 rel relation_ref 131973 // @@ -75,20 +75,18 @@ objectlinkcanvas 131461 rel relation_ref 135429 // objectlinkcanvas 131589 rel relation_ref 135429 // from ref 128773 z 1999 to ref 129925 role_a_pos 494 373 3000 no_role_b -objectlinkcanvas 132229 rel relation_ref 134533 // +objectlinkcanvas 133509 norel geometry VHr - from ref 131717 z 1999 to point 140 438 - line 1 z 1999 to ref 131973 - role_a_pos 152 467 3000 no_role_b -objectlinkcanvas 132485 rel relation_ref 134533 // + from ref 133381 z 1999 to point 140 442 + line 133637 z 1999 to ref 131973 + no_role_a no_role_b +objectlinkcanvas 134021 norel geometry HV - from ref 131845 z 1999 to point 676 300 - line 1 z 1999 to ref 132101 - role_a_pos 688 328 3000 no_role_b -line 132613 -_-_ - from ref 128261 z 1999 to point 244 320 - line 132741 z 1999 to ref 131717 -line 132869 -_-_ - from ref 128133 z 1999 to point 583 259 - line 132997 z 1999 to ref 131845 + from ref 133893 z 1999 to point 676 300 + line 134149 z 1999 to ref 132101 + no_role_a no_role_b +line 133765 -_-_ + from ref 128261 z 1999 to ref 133381 +line 134277 -_-_ + from ref 128133 z 1999 to ref 133893 end diff --git a/uml/lumiera/129157.diagram b/uml/lumiera/129157.diagram index f63b08370..81552e7a1 100644 --- a/uml/lumiera/129157.diagram +++ b/uml/lumiera/129157.diagram @@ -26,11 +26,8 @@ end classinstancecanvas 129157 classinstance_ref 133253 // HUE xyz 477 444 2000 end -classinstancecanvas 129541 classinstance_ref 133381 // vid1 - xyz 409 293 2000 - end classinstancecanvas 129669 classinstance_ref 133509 // - xyz 138 498 2000 + xyz 151 399 2000 end classinstancecanvas 129797 classinstance_ref 133637 // video1 xyz 478 172 2000 @@ -60,6 +57,9 @@ note 134661 "Note: because the Engine Components are stateless, various calculat xyzwh 569 45 2000 240 75 textcanvas 134789 "Video Clip from 2 to 7, with an attached HUE effect starting 3 frames after begin and overlapping by 1 frame beyond the end" xyzwh 145 553 2000 175 87 +classinstancecanvas 134917 classinstance_ref 137093 // vid1 + xyz 410 291 3005 + end objectlinkcanvas 130053 rel relation_ref 135429 // from ref 129925 z 1999 to ref 128901 role_a_pos 537 361 3000 no_role_b @@ -67,46 +67,46 @@ objectlinkcanvas 130437 rel relation_ref 135429 // from ref 129157 z 1999 to ref 128645 role_a_pos 539 472 3000 no_role_b objectlinkcanvas 130565 rel relation_ref 131973 // - from ref 128773 z 1999 stereotype "<>" xyz 624 285 3000 to ref 128517 + from ref 128773 z 1999 stereotype "<>" xyz 656 263 3000 to ref 128517 role_a_pos 661 304 3000 no_role_b -objectlinkcanvas 130693 rel relation_ref 134533 // - geometry VHr - from ref 129541 z 1999 to point 161 304 - line 130821 z 1999 to ref 129669 - role_a_pos 173 473 3000 no_role_b -objectlinkcanvas 130949 rel relation_ref 135429 // - from ref 128901 z 1999 to ref 129157 - role_a_pos 538 419 3000 no_role_b -objectlinkcanvas 131589 rel relation_ref 131973 // - from ref 129797 z 1999 stereotype "<>" xyz 499 284 3000 to ref 129925 - role_a_pos 537 304 3000 no_role_b -objectlinkcanvas 132613 rel relation_ref 135429 // - from ref 128517 z 1999 to ref 132229 - role_a_pos 662 419 3000 no_role_b -objectlinkcanvas 132869 rel relation_ref 135429 // - from ref 132229 z 1999 to ref 128389 - role_a_pos 662 533 3000 no_role_b -objectlinkcanvas 133637 rel relation_ref 135429 // - from ref 133509 z 1999 to ref 133381 - role_a_pos 348 361 3000 no_role_b -objectlinkcanvas 133765 rel relation_ref 135429 // - from ref 133125 z 1999 to ref 132997 - role_a_pos 416 577 3000 no_role_b -objectlinkcanvas 133893 rel relation_ref 131973 // - from ref 133253 z 1999 stereotype "<>" xyz 291 273 3000 to ref 133509 - role_a_pos 348 304 3000 no_role_b -objectlinkcanvas 134277 rel relation_ref 135429 // - from ref 133381 z 1999 to ref 133125 - role_a_pos 349 473 3000 no_role_b -objectlinkcanvas 134405 rel relation_ref 135429 // +objectlinkcanvas 135045 rel relation_ref 135429 // from ref 128645 z 1999 to ref 132997 role_a_pos 446 567 3000 no_role_b -objectlinkcanvas 134533 rel relation_ref 131845 // +objectlinkcanvas 135173 rel relation_ref 131845 // geometry VH - from ref 128005 z 1999 to point 123 205 - line 6 z 1999 to ref 133253 - role_a_pos 197 183 3000 no_role_b -line 131973 -_-_ - from ref 129797 z 1999 to point 445 243 - line 132101 z 1999 to ref 129541 + from ref 128005 z 1999 stereotype "<>" xyz 127 141 3000 to point 123 205 + line 136965 z 1999 to ref 133253 + role_a_pos 152 186 3000 no_role_b +objectlinkcanvas 135301 rel relation_ref 135429 // + from ref 128901 z 1999 to ref 129157 + role_a_pos 538 419 3000 no_role_b +objectlinkcanvas 135429 rel relation_ref 131973 // + from ref 133253 z 1999 stereotype "<>" xyz 282 261 3000 to ref 133509 + role_a_pos 348 304 3000 no_role_b +objectlinkcanvas 135557 rel relation_ref 135429 // + from ref 128517 z 1999 to ref 132229 + role_a_pos 662 419 3000 no_role_b +objectlinkcanvas 135685 rel relation_ref 135429 // + from ref 133125 z 1999 to ref 132997 + role_a_pos 416 577 3000 no_role_b +objectlinkcanvas 135813 rel relation_ref 135429 // + from ref 132229 z 1999 to ref 128389 + role_a_pos 662 533 3000 no_role_b +objectlinkcanvas 135941 rel relation_ref 131973 // + from ref 129797 z 1999 stereotype "<>" xyz 529 262 3000 to ref 129925 + role_a_pos 537 304 3000 no_role_b +objectlinkcanvas 136069 rel relation_ref 135429 // + from ref 133509 z 1999 to ref 133381 + role_a_pos 348 361 3000 no_role_b +objectlinkcanvas 136197 rel relation_ref 135429 // + from ref 133381 z 1999 to ref 133125 + role_a_pos 349 473 3000 no_role_b +objectlinkcanvas 136325 norel + geometry VHr + from ref 134917 z 1999 to point 174 302 + line 136453 z 1999 to ref 129669 + no_role_a no_role_b +line 136581 -_-_ + from ref 129797 z 1999 to point 451 237 + line 136709 z 1999 to ref 134917 end diff --git a/uml/lumiera/129285 b/uml/lumiera/129285 index 28f619bb6..246c9e4d6 100644 --- a/uml/lumiera/129285 +++ b/uml/lumiera/129285 @@ -1,6 +1,6 @@ format 40 "ProcessingLayer" // ProcessingLayer - revision 14 + revision 21 modified_by 5 "hiv" // class settings //class diagram settings @@ -391,26 +391,6 @@ format 40 end end - classinstance 131973 "vid1" - type class_ref 132997 // VRender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 132229 // - end - end - - classinstance 132101 "au1" - type class_ref 132869 // ARender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 132357 // - end - end - classinstance 132229 "" type class_ref 133509 // VFrame attributes @@ -499,16 +479,6 @@ format 40 end end - classinstance 133381 "vid1" - type class_ref 132997 // VRender - attributes - end - relations - relation_ref 134533 // - classinstance_ref 133509 // - end - end - classinstance 133509 "" type class_ref 133509 // VFrame attributes @@ -602,5 +572,108 @@ format 40 classinstance_ref 134405 // ouput end end + + collaborationdiagram 132229 "Render Process" + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + size A4 + end + + classinstance 136197 "node1" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136325 "ad1" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + classinstance 136453 "current" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end + + classinstance 136581 "node2" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136709 "ad2" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + class 143109 "BackendCache" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + class 143237 "Caller" + visibility package + cpp_decl "${comment}${template}class ${name}${inherit} + { +${members} }; +${inlines} +" + java_decl "" + idl_decl "" + explicit_switch_type "" + + end + + classinstance 136837 "node3" + type class_ref 131717 // ProcNode + attributes + end + relations + end + end + + classinstance 136965 "ad3" + type class_ref 142597 // StateAdapter + attributes + end + relations + end + end + + classinstance 137093 "vid1" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end + + classinstance 137221 "au1" + type class_ref 142469 // StateProxy + attributes + end + relations + end + end end end diff --git a/uml/lumiera/130309 b/uml/lumiera/130309 index f5c27c9a0..e89c34727 100644 --- a/uml/lumiera/130309 +++ b/uml/lumiera/130309 @@ -1,6 +1,6 @@ format 40 "engine" // design::codegen::proc::engine - revision 8 + revision 9 modified_by 5 "hiv" // class settings //class diagram settings @@ -306,7 +306,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132101 // Hub end comment "special ProcNode used to build data distributing connections" end @@ -501,7 +500,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132613 // GLPipe end comment "specialized connection element for handling OpenGL implementation details" end @@ -540,7 +538,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132869 // ARender end comment "Representation of a Audio Render process" end @@ -579,7 +576,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 132997 // VRender end comment "Representation of a Video render process" end @@ -618,7 +614,6 @@ ${namespace_start} ${members} ${namespace_end}" associated_classes - class_ref 133125 // GLRender end comment "Representation of a OpenGL accellerated Video render process" end diff --git a/uml/lumiera/131973.diagram b/uml/lumiera/131973.diagram new file mode 100644 index 000000000..4b7003a43 --- /dev/null +++ b/uml/lumiera/131973.diagram @@ -0,0 +1,83 @@ +format 40 + +classcanvas 128005 class_ref 131717 // ProcNode + 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 103 405 2004 + end +classcanvas 128517 class_ref 132741 // State + 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 77 18 2000 + end +classcanvas 129669 class_ref 133253 // Frame + 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 264 313 3005 + end +classcanvas 131845 class_ref 142469 // StateProxy + 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 126 211 2000 + end +classcanvas 131973 class_ref 142597 // StateAdapter + 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 40 317 3010 + end +classcanvas 132357 class_ref 142725 // WiringDescriptor + 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 229 497 2000 + end +classcanvas 135045 class_ref 143365 // NodeWiring + 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 241 568 2000 + end +textcanvas 135685 "determines concrete Type" + xyzwh 100 594 2004 130 18 +relationcanvas 129797 relation_ref 134533 // + from ref 128517 z 1999 stereotype "<>" xyz 277 115 3000 to point 300 136 + line 130053 z 1999 to ref 129669 + role_a_pos 312 288 3000 no_role_b + no_multiplicity_a multiplicity_b_pos 173 109 3000 +relationcanvas 132101 relation_ref 148869 // + geometry VHV unfixed + from ref 131973 z 1999 to point 78 181 + line 134021 z 1999 to point 118 181 + line 134149 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 132229 relation_ref 148997 // + geometry VHV + from ref 131845 z 1999 to point 178 181 + line 134277 z 1999 to point 118 181 + line 134405 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 132485 relation_ref 149125 // + geometry HV + from ref 128005 z 1999 stereotype "<>" xyz 205 454 3000 to point 277 452 + line 133381 z 1999 to ref 132357 + role_a_pos 289 472 3000 no_role_b + multiplicity_a_pos 265 472 3000 no_multiplicity_b +relationcanvas 133509 relation_ref 149253 // + from ref 131973 z 1999 to point 178 312 + line 133637 z 1999 to ref 131845 + role_a_pos 190 302 3000 no_role_b + multiplicity_a_pos 164 302 3000 no_multiplicity_b +relationcanvas 134533 relation_ref 149381 // + from ref 131973 z 3004 to ref 129669 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135173 relation_ref 149509 // + from ref 135045 z 1999 to ref 132357 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 135301 relation_ref 149637 // + geometry VHr + from ref 135045 z 1999 to point 78 596 + line 135557 z 1999 to ref 131973 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +line 134661 -_-_ + from ref 131973 z 2003 to ref 128005 +line 134789 -_-_ + from ref 131973 z 2003 to point 134 414 + line 134917 z 2003 to ref 128005 +preferred_whz 414 544 1 +end diff --git a/uml/lumiera/132229.diagram b/uml/lumiera/132229.diagram new file mode 100644 index 000000000..af599827d --- /dev/null +++ b/uml/lumiera/132229.diagram @@ -0,0 +1,184 @@ +format 40 + +classinstancecanvas 128261 classinstance_ref 136197 // node1 + xyz 152 504 2000 + end +classinstancecanvas 128389 classinstance_ref 136325 // ad1 + xyz 191 393 2000 + end +classinstancecanvas 128517 classinstance_ref 136453 // current + xyz 188 92 2000 + end +classinstancecanvas 128645 classinstance_ref 136581 // node2 + xyz 388 393 2000 + end +classinstancecanvas 128773 classinstance_ref 136709 // ad2 + xyz 422 301 2000 + end +classinstance 128901 class_ref 143109 // BackendCache + name "" xyz 692 12 2000 +classinstance 129029 class_ref 143237 // Caller + name "" xyz 28 505 2000 +classinstancecanvas 130949 classinstance_ref 136837 // node3 + xyz 625 300 2000 + end +classinstancecanvas 131077 classinstance_ref 136965 // ad3 + xyz 665 199 2000 + end +textcanvas 133381 "node1 using node2 as predecessor; calculates in-place, will push result to Cache" + xyzwh 149 538 2000 408 21 +textcanvas 133509 "node2 using node3 as predecessor. Calculates without caching" + xyzwh 385 427 2005 350 18 +textcanvas 133637 "node3 doesn't calc, but fetch result from Cache" + xyzwh 564 329 2000 231 18 +linkcanvas 129157 + from ref 129029 z 1999 to ref 128261 +dirscanvas 129285 z 1000 linkcanvas_ref 129157 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "1 pull()" xyz 97 480 3000 +linkcanvas 129413 + from ref 128261 z 1999 to ref 128389 +dirscanvas 130309 z 1000 linkcanvas_ref 129413 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "2 retrieve()" xyz 141 437 3000 + backward_label "16 process()" xyz 236 471 3000 +linkcanvas 129541 + from ref 128389 z 1999 to ref 128517 +dirscanvas 131717 z 1000 linkcanvas_ref 129541 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "3 fetch() +11 allocateBuffer() +17 isCalculated()" xyz 128 228 3000 +linkcanvas 129669 + from ref 128389 z 1999 to ref 128645 +dirscanvas 130437 z 1000 linkcanvas_ref 129669 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "4 pull()" xyz 319 369 3000 +linkcanvas 129797 + from ref 128645 z 1999 to ref 128773 +dirscanvas 130693 z 1000 linkcanvas_ref 129797 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "5 retrieve()" xyz 379 349 3000 + backward_label "13 process()" xyz 469 372 3000 +linkcanvas 130181 + from ref 128773 z 1999 to ref 128517 +dirscanvas 133765 z 1000 linkcanvas_ref 130181 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "14 releaseBuffer()" xyz 285 227 3000 +linkcanvas 131205 + from ref 128773 z 1999 to ref 130949 +dirscanvas 131845 z 1000 linkcanvas_ref 131205 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "6 pull()" xyz 553 276 3000 +linkcanvas 131333 + from ref 130949 z 1999 to ref 131077 +dirscanvas 131973 z 1000 linkcanvas_ref 131333 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "7 retrieve()" xyz 615 236 3000 +linkcanvas 131461 + from ref 131077 z 1999 to ref 128517 +dirscanvas 132101 z 1000 linkcanvas_ref 131461 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "8 fetch()" xyz 449 179 3000 +linkcanvas 131589 + from ref 128517 z 1999 to point 295 24 + line 134277 z 1999 to ref 128901 +dirscanvas 132229 z 1000 linkcanvas_ref 134277 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "9 fetch +12 allocateNewFrame +15 releaseFrame +18 isCalculatedFrame +20 releaseFrame" xyz 487 29 3000 +linkcanvas 132357 + from ref 131077 z 1999 to point 515 211 + line 132613 z 1999 to ref 128773 +dirscanvas 132741 z 1000 linkcanvas_ref 132357 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default +linkcanvas 132485 + from ref 128773 z 1999 to point 280 312 + line 132869 z 1999 to ref 128389 +dirscanvas 132997 z 1000 linkcanvas_ref 132485 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "10 allocateBuffer()" xyz 306 293 3000 +linkcanvas 133893 + from ref 129029 z 1999 to point 49 155 + line 134021 z 1999 to ref 128517 +dirscanvas 134149 z 1000 linkcanvas_ref 134021 + show_full_operations_definition default show_hierarchical_rank default write_horizontally default drawing_language default package_name_in_tab default show_context default draw_all_relations default shadow default + forward_label "19 releaseBuffer()" xyz 65 100 3000 +msgs + msg operation_ref 135685 // "pull()" + forward ranks 1 "1" dirscanvas_ref 129285 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 2 "1.1" dirscanvas_ref 130309 + msgs + msg operation_ref 135813 // "fetch()" + forward ranks 3 "1.1.1" dirscanvas_ref 131717 + no_msg + msg operation_ref 135685 // "pull()" + forward ranks 4 "1.1.2" dirscanvas_ref 130437 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 5 "1.1.2.1" dirscanvas_ref 130693 + msgs + msg operation_ref 135685 // "pull()" + forward ranks 6 "1.1.2.1.1" dirscanvas_ref 131845 + msgs + msg operation_ref 135557 // "retrieve()" + forward ranks 7 "1.1.2.1.1.1" dirscanvas_ref 131973 + msgs + msg operation_ref 135813 // "fetch()" + forward ranks 8 "1.1.2.1.1.1.1" dirscanvas_ref 132101 + msgs + explicitmsg "fetch" + forward ranks 9 "1.1.2.1.1.1.1.1" dirscanvas_ref 132229 + no_msg + msgsend + msgsend + msgsend + msgsend + msgsend + msgsend + msgsend + msg operation_ref 135941 // "allocateBuffer()" + forward ranks 10 "2" dirscanvas_ref 132997 + msgs + msg operation_ref 135941 // "allocateBuffer()" + forward ranks 11 "2.1" dirscanvas_ref 131717 + msgs + explicitmsg "allocateNewFrame" + forward ranks 12 "2.1.1" dirscanvas_ref 132229 + no_msg + msgsend + msgsend + msg operation_ref 136069 // "process()" + backward ranks 13 "3" dirscanvas_ref 130693 + no_msg + msg operation_ref 136197 // "releaseBuffer()" + forward ranks 14 "4" dirscanvas_ref 133765 + msgs + explicitmsg "releaseFrame" + forward ranks 15 "4.1" dirscanvas_ref 132229 + no_msg + msgsend + msg operation_ref 136069 // "process()" + backward ranks 16 "5" dirscanvas_ref 130309 + no_msg + msg operation_ref 136325 // "isCalculated()" + forward ranks 17 "6" dirscanvas_ref 131717 + msgs + explicitmsg "isCalculatedFrame" + forward ranks 18 "6.1" dirscanvas_ref 132229 + no_msg + msgsend + msg operation_ref 136197 // "releaseBuffer()" + forward ranks 19 "7" dirscanvas_ref 134149 + msgs + explicitmsg "releaseFrame" + forward ranks 20 "7.1" dirscanvas_ref 132229 + no_msg + msgsend +msgsend +end diff --git a/uml/lumiera/132357.diagram b/uml/lumiera/132357.diagram new file mode 100644 index 000000000..a097c7137 --- /dev/null +++ b/uml/lumiera/132357.diagram @@ -0,0 +1,81 @@ +format 40 + +classcanvas 128005 class_ref 132741 // State + 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 78 10 2000 + end +classcanvas 128133 class_ref 143493 // InvocationStateBase + 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 203 104 2000 + end +classcanvas 128261 class_ref 143621 // Caching + 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 235 157 2000 + end +classcanvas 128389 class_ref 143749 // Process + 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 236 212 2000 + end +classcanvas 128517 class_ref 143877 // InPlace + 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 238 268 2000 + end +classcanvas 128645 class_ref 142469 // StateProxy + 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 209 332 2004 + end +classcanvas 130309 class_ref 144005 // WiringTable + 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 101 298 2000 + end +classcanvas 130437 class_ref 142725 // WiringDescriptor + 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 36 213 2005 + end +classcanvas 130565 class_ref 144133 // BuffHandle + 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 36 379 2000 + end +textcanvas 131461 "const" + xyzwh 109 257 2010 29 18 +relationcanvas 128901 relation_ref 149765 // + from ref 128645 z 1999 to ref 128517 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129029 relation_ref 149893 // + from ref 128517 z 1999 to ref 128389 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129157 relation_ref 150021 // + from ref 128389 z 1999 to ref 128261 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129285 relation_ref 150149 // + from ref 128261 z 1999 to ref 128133 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 129413 relation_ref 150277 // + from ref 128133 z 1999 to point 260 69 + line 129925 z 1999 to point 190 69 + line 130181 z 1999 to point 161 176 + line 130053 z 1999 to point 118 176 + line 129797 z 1999 to ref 128005 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 130693 relation_ref 150405 // + geometry VHr + from ref 130309 z 1999 stereotype "<>" xyz 43 309 3000 to point 70 326 + line 130821 z 1999 to ref 130565 + no_role_a no_role_b + multiplicity_a_pos 45 354 3000 no_multiplicity_b +relationcanvas 130949 relation_ref 150533 // + from ref 130309 z 1999 to ref 130437 + no_role_a no_role_b + no_multiplicity_a no_multiplicity_b +relationcanvas 131077 relation_ref 150661 // + geometry VHr + from ref 128645 z 1999 to point 136 371 + line 131333 z 1999 to ref 130309 + role_a_pos 148 367 3000 no_role_b + multiplicity_a_pos 122 359 3000 no_multiplicity_b +end diff --git a/uml/lumiera/5.session b/uml/lumiera/5.session index fc9677d8c..1a789da17 100644 --- a/uml/lumiera/5.session +++ b/uml/lumiera/5.session @@ -1,14 +1,23 @@ window_sizes 1140 830 270 860 680 71 diagrams - active componentdiagram_ref 128005 // Overview - 702 640 80 4 2 0 + classdiagram_ref 131973 // Render Mechanics + 428 623 100 4 2 0 + collaborationdiagram_ref 132229 // Render Process + 817 644 100 4 0 0 + active classdiagram_ref 132357 // StateAdapter composition + 418 520 100 4 0 0 end show_stereotypes selected - package_ref 129 // lumiera +package_ref 129 // lumiera open - componentview_ref 128133 // interfaces - classview_ref 128005 // Session + class_ref 132741 // State + +package_ref 129029 // Controller + class_ref 131717 // ProcNode + class_ref 142469 // StateProxy + class_ref 142597 // StateAdapter + usecaseview_ref 128005 // Renderengine Use class_ref 140677 // QueryHandler class_ref 140805 // TypeHandler class_ref 140933 // ResolverBase diff --git a/uml/lumiera/lumiera.prj b/uml/lumiera/lumiera.prj index dcdd63301..2238424c2 100644 --- a/uml/lumiera/lumiera.prj +++ b/uml/lumiera/lumiera.prj @@ -1,6 +1,6 @@ format 40 "lumiera" - revision 44 + revision 47 modified_by 5 "hiv" cpp_root_dir "../../src/" diff --git a/wiki/compatibility.html b/wiki/compatibility.html index 6eec84d85..0d6077a15 100644 --- a/wiki/compatibility.html +++ b/wiki/compatibility.html @@ -747,19 +747,19 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS } //}}} -
    +
    ! Programming Languages
 * C
 ** a C99 compatible compiler, some GCC extensions are used, most are optional.
 * C++
 ** C++98
 ** std::tr1 (for <std::tr1::memory>)
-** BOOST ~~(below are the DEBIAN package names)~~
-*** libboost-dev (=1.34.1-2)
-*** libboost-program-options-dev (=1.34.1-2)
-*** libboost-program-options1.34.1 (=1.34.1-2) ''NOTE: binary lib dependency''
-*** libboost-regex-dev (=1.34.1-2)
-*** libboost-regex1.34.1 (=1.34.1-2) ''binary lib depenency''
+* BOOST ~~(listed below are the DEBIAN package names)~~
+** libboost-dev (>=1.34.1-2)
+** libboost-program-options-dev (>=1.34.1-2)
+** libboost-program-options1.34.1 (>=1.34.1-2) ''NOTE: binary dependency''
+** libboost-regex-dev (>=1.34.1-2)
+** libboost-regex1.34.1 (>=1.34.1-2) ''binary..''
 ** //usually, newer versions are OK//
 
 * bash
@@ -769,7 +769,8 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 * autotools
 * SCons
 ** //need either autotools or scons//
-** SCons (0.96.90), Python (2.3)
+** SCons (0.96), Python (2.4)
+** pkg-config
 * Doxygen
 * test.sh (included)
 
@@ -778,9 +779,18 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 * bouml
 
 ! Libraries
-* boost (see above)
+* boost (see above, version 1.35 works too)
 * NoBug
-* gavl
+* [[GAVL|http://gmerlin.sourceforge.net/gavl.html]] (1.0.0) 
+* for the GUI: gtkmm-2.4 gdl-1.0 cairomm-1.0 xv
+** libgtkmm-2.4-dev (>=2.8)
+** libcairomm-1.0-dev (>=0.6.0)
+** libgdl-1-dev (>=0.6.1)
+*** libbonoboui2-dev (>=2.14.0)
+** libxv-dev ~~(1.0.2 is known to work)~~
+
+//usually, newer versions are OK//
+
    diff --git a/wiki/index.html b/wiki/index.html index 2c34a10d1..75eedf40a 100644 --- a/wiki/index.html +++ b/wiki/index.html @@ -759,21 +759,30 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS } //}}}
    -
    +
    for __Building__
 * gcc (4.1), glibc6 (2.3), libstdc++6 (4.1)
-* [[build system|BuildSystem]] dependencies: SCons (0.96.90), Python (2.3)
+* [[build system|BuildSystem]] dependencies: SCons (0.96.90), Python (2.4), pkg-config
+* [[GAVL|http://gmerlin.sourceforge.net/gavl.html]] (1.0.0) 
 * NoBug for Logging, Tracing, Asserting (can be obtained from [[Pipapo.org|http://www.pipapo.org/pipawiki/NoBug]])
 * ~NoBug needs [[valgrind|Valgrind]] (3.2), execinfo.h and libpthread (&rarr; glibc)
 * std::tr1 &mdash; esp. for the former BOOST::shared_ptr (which is now proposed standard)
-* BOOST ~~(below are the DEBIAN package names)~~
-** libboost-dev (=1.34.1-2)
-** libboost-program-options-dev (=1.34.1-2)
-** libboost-program-options1.34.1 (=1.34.1-2) ''NOTE: binary dependency''
-** libboost-regex-dev (=1.34.1-2)
-** libboost-regex1.34.1 (=1.34.1-2) ''binary..''
+* BOOST ~~(listed below are the DEBIAN package names)~~
+** libboost-dev (>=1.34.1-2)
+** libboost-program-options-dev (>=1.34.1-2)
+** libboost-program-options1.34.1 (>=1.34.1-2) ''NOTE: binary dependency''
+** libboost-regex-dev (>=1.34.1-2)
+** libboost-regex1.34.1 (>=1.34.1-2) ''binary..''
+* for the GUI: gtkmm-2.4 gdl-1.0 cairomm-1.0 xv
+** libgtkmm-2.4-dev (>=2.8)
+** libcairomm-1.0-dev (>=0.6.0)
+** libgdl-1-dev (>=0.6.1)
+*** libbonoboui2-dev (>=2.14.0)
+** libxv-dev (>=1.0.2)
 //usually, newer versions are OK//
 
+boost 1.35 works too.
+
 for __Running__
    @@ -942,14 +951,18 @@ git push git://git.pipapo.org/lumiera/mob lumiera/mob is an anonymous account at pipapo.org where everyone can commit changes.
    -
    +
    We keep a protocol or short summary of each important discussion. The summaries of the monthly developer meetings are posted to the Mailinglist and can be found on pipapo.org too
 
+* [[06-08 developer meeting 5.Jun.2008|IRC_2008-06-05]]
 * [[05-08 developer meeting 8.May.2008|IRC_2008-05-08]]
 * [[04-08 developer meeting 3.Apr.2008|IRC_2008-04-03]]
 * [[03-08 developer meeting 6.Mar.2008|IRC_2008-03-06]]
 * [[1.official developer meeting 1.Feb.2008|IRC_2008-02-01]]
 * [[informal developer meeting 10.Aug.2007|IRC_2007-08-10]]
+
+!talks about distinct topics
+* [[buffer allocation for render nodes (6/08)|IRC_log_BufferAllocation_2008-06]]
    @@ -1588,6 +1601,206 @@ Ichthyo explains that the builder needs to detect cycles and check if the high l Next meeting is on thursday 5th June 21:00 UTC
    +
    +
    ! 5.June 2008 on #lumiera
+21:00 -23:15 UTC. __Participants__:
+ * cehteh
+ * ichthyo
+ * joelholdsworth
+ * rcbarnes
+ * raffa
+
+//Protocol written by ichthyo//
+
+
+! Left over from the last meeting
+//Nothing left over and no urgent topics.//
+Seemingly, work is proceeding in all parts of the application.
+
+! Discuss Ideas and Drafts in design process
+//There are no new design proposals and no proposals that can be finalized.//
+
+Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in "idea" state. Following that, most of the meeting is spent on discussing the details of two of these proposals.
+
+!!! Idea: Design the Render Nodes interface
+[[Design of the render nodes interface|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface]]
+
+''Cehteh'' points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. Later on, interface versions will be numbered. If needed, we could add a special "draft" or "experimental" tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface.
+
+''Ichthyo'' agrees, but adds he also meant "interface" in this proposal in a wider sense, like in "what do we need and require from a processing node". Knowing how generally Lumiera will handle the processing nodes while rendering helps him with defining and implementing the builder
+
+__Conclusion__: "currently in work". For now, grow interfaces on demand.
+-----
+
+!!! Idea: Placement Metaphor used within the high-level view of Proc-Layer
+[[Placement Metaphor in the Proc-Layer|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor]]
+
+In the course of the discussion, ''Ichthyo'' explains the rationale
+* one common mechanism for sticking objects together and putting them into the session
+* either specify the "placement"-parameters (time, output destination, track) directly, link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks)
+* ability to build a system of high-level media objects (clips, effects...) which re-adjust automatically on change
+* extensible to handle or derive some parameters based on conditions and rules, e.g. for semi-automatic wiring of the output destination based on tags
+
+''Joelholdsworth'' is concerned that this proposal may go too far and tries to tie things together which aren't really connected. While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, he can't see a clear benefit of controlling sound pan or video layer order from the placement. Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, layer number or sound pan would be properties of the object.
+
+But that's exactly what Ichthyo wants to avoid. Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video.
+
+//On the whole, there is no conclusion yet.// Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), maybe parts of the functionality should be separated out.
+
+While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered.
+* it is not necessary to make all of the Placement proposal visible to the GUI (and the user). Proc layer may as well provide a simplyfied and hard wired API for the most common properties (layer index, pan) and only use this part of the Placement concept for building and wiring the nodes.
+* the adjustment of objects linked together by a placement can be handled as follows: 
+*# GUI notifies Proc of a position/parameter change of one object and gets immediate, synchronous feedback (OK or fail)
+*# Proc detects the other linked objects affected by the change and notifies GUI (both synchronous and asynchronous is possible) to update information regarding those objects
+*# GUI pulls the necessary properties by calling Proc on a per object base.
+* as a rule of thumb, GUI <-> Proc is mostly synchronous, while Backend <-> GUI is often asynchronous, but there are exceptions from the rule
+* we have general //parameters//, which are automatible. These are represented as //control data connections between the nodes.// We certainly don't want to represent some things in this way, though. For example, the in/out points of clips are fixed values.
+* in Ichthyo's concept, the Placement doesn't itself provide such parameter values/sources, rather it can be used to //find// or //derive// parameter sources.
+* the node graph is built bottom up, starting at the source, then via the effects attached locally to a clip, further on upwards (directed by the tree of tracks) to be finally connected via global busses to the output ports. Rendering pulls from these output ports.
+* Joelholdsworth, Cehteh, Ichthyo and Rcbarnes agree that the plain //node-editor// approach is problematic in the context of a NLE. It shows too much details and fails to capture the temporal aspect. We strive at having node-like features and flexibility, but rather within the timeline.
+* especially, the topology of the node graph isn't constant over the whole timeline. But it's the job of the builder in the Proc layer to deal with these complexities, the user shouldn't be overwhelmed with all those details.
+-----
+
+! Next meeting
+* some people in europe complained that 21:00 UTC is too late, esp. with daylight saving
+* there was the proposal to alternate between the current schedule, and sunday 16:00 UTC
+* but Joel can't attend on sunday afternoon for now
+* so we settle down on thursday, 16:30
+
+Next meeting: ''Thursday 3.July 2008 16:30 UTC''
+
    +
    +
    +
    ! 5.June 2008 on #lumiera
+__cehteh__ and __ichthyo__
+{{{
+[2008-06-05 19:21:21] <cehteh> do you need me? .. i am away if not .. i have no much to say for the today meeting either
+[2008-06-05 19:21:57] <ichthyo> I have one topic I want to discuss with you, cehteh
+[2008-06-05 19:22:07] <ichthyo> but it need not be now, or in the meeting
+[2008-06-05 19:22:07] <cehteh> ok
+[2008-06-05 19:22:24] <ichthyo> it's about allocating processing buffers 
+[2008-06-05 19:23:20] <cehteh> the backend will provide them as temporary files/cyclic buffers
+[2008-06-05 19:23:52] <cehteh> its not there yet but in my mind
+[2008-06-05 19:24:11] <ichthyo> haha, same for the builder... it's mostly just in my mind
+[2008-06-05 19:24:42] <cehteh> opened almost like a normal file but giving frame properties instead filename
+[2008-06-05 19:24:56] <cehteh> (there will be a distinct api for that)
+[2008-06-05 19:25:01] <ichthyo> ok
+[2008-06-05 19:25:05] <ichthyo> regarding the buffers: my question is more special
+[2008-06-05 19:25:19] <ichthyo> if you want to cache a frame (intermediary result)
+[2008-06-05 19:25:35] <ichthyo> then I thought we could avoid the copy operation
+[2008-06-05 19:25:44] <ichthyo> I could arrange things accordingly
+[2008-06-05 19:25:46] <cehteh> then the backend creates a backing mmaped file for that maybe manages its size (or do you want to tell how much frames you want to cache?)
+[2008-06-05 19:26:06] <cehteh> yes perfect .. thats what i am planning
+[2008-06-05 19:26:26] <ichthyo> you know, many processing nodes will be able to process "in place"
+[2008-06-05 19:26:34] <ichthyo> but ther are some that can't do this
+[2008-06-05 19:27:44] <ichthyo> so basically each processing function will "see" input frame buffer(s) and output frame buffer(s). but when a node is "in-place-capable", actually the in and out buffer may point to the same location
+[2008-06-05 19:26:55] <cehteh> basiically all temporary frames with the same properties are allcoated from the same backing file (well maybe 2 caching levels but not important here)
+[2008-06-05 19:27:06] <cehteh> the index give them meaning
+[2008-06-05 19:27:49] <cehteh> do you can query (and lock) a frame by that
+[2008-06-05 19:28:04] <ichthyo> that sounds good
+[2008-06-05 19:28:24] <cehteh> do some inplace editing and then tell the backend "this is now frame N of node X"
+[2008-06-05 19:28:34] <ichthyo> yeah, exactly
+[2008-06-05 19:28:44] <cehteh> (plus a uuid or preferably genertion number)
+[2008-06-05 19:28:39] <ichthyo> basically my Idea was as follows:
+[2008-06-05 19:29:47] <ichthyo> when I know the result will be cached, I'll let the node process into the location of the cache frame, and any node which will /use/ this frame as an input will be wired such that it isn't allowed to modify this frame (which is supposed to be located in the cache)
+[2008-06-05 19:30:45] <cehteh> yes thats managed in the index
+[2008-06-05 19:30:48] <ichthyo> for this to work, I need to "allocate and lock" a location in the cache, and release it when it contains the final processed result
+[2008-06-05 19:31:17] <cehteh> well i try to make no locks there, you query frames which are uniquely identified
+[2008-06-05 19:31:44] <ichthyo> it doesnt need to be a "lock
+[2008-06-05 19:31:55] <ichthyo> just some way to tell that this frame is "under construction"
+[2008-06-05 19:32:01] <cehteh> yes
+[2008-06-05 19:32:14] <cehteh> we thinking the same :)
+[2008-06-05 19:32:57] <cehteh> well problem is when shortly after that another node queries the source frame which got destructed .. thats something the builder needs to avoid, nothing i can do then
+[2008-06-05 19:33:21] <ichthyo> yes, builder will care for that
+[2008-06-05 19:33:41] <ichthyo> I can even tell in advance the maximum number of temporary buffers I need
+[2008-06-05 19:33:51] <cehteh> and it not only needs a under-construcion
+[2008-06-05 19:34:44] <cehteh> there are 2 indices one for source and one for destination
+[2008-06-05 19:35:11] <cehteh> indices will have a pointer to the 'job' working on it i tihnk
+[2008-06-05 19:35:24] <ichthyo> ok
+[2008-06-05 19:35:48] <cehteh> (actually there is a list planed many jobs can read-share an frame)
+[2008-06-05 19:36:40] <cehteh> i would like if I do not need to do *any* checks in that direction ... means the builder delivers clean jobs which dont step on their own foot
+[2008-06-05 19:36:54] <ichthyo> my understanding too
+[2008-06-05 19:37:07] <ichthyo> also, I want the nodes to be freed of any checks
+[2008-06-05 19:37:33] <ichthyo> so they can assume they get a valid buffer pointer to the right sort of buffer
+[2008-06-05 19:37:54] <cehteh> yes thats guranteed
+[2008-06-05 19:37:41] <cehteh> if it fails then we get some hairy bugs ... but checking job dependencies afterwards is costly
+[2008-06-05 19:38:53] <ichthyo> I mean -- I want to prepare everything as much as possible while building, so that all that needs to be "filled in" when starting the processing are the actual buffer locations
+[2008-06-05 19:38:58] <cehteh> *thinkin* prolly easier than it looks
+[2008-06-05 19:39:10] <cehteh> exaxctly
+[2008-06-05 19:39:50] <ichthyo> we can't prepare everything, because, some nodes may include a variable ammount of source frames
+[2008-06-05 19:40:11] <ichthyo> and this number can depend on automation. Classic example is the "time average" video effect
+[2008-06-05 19:39:53] <cehteh> problem is only when the builder generates one node which takes X and in-place generates Y from it
+[2008-06-05 19:40:10] <cehteh> and you have a 2nd node which takes X too 
+[2008-06-05 19:40:23] <cehteh> this needs to be serialized somehow
+[2008-06-05 19:41:12] <ichthyo> regarding the problem you mention: I want to exclude/avoid this situation already when building
+[2008-06-05 19:41:35] <cehteh> yes thats what i was thinking .. thats easiest addressed there
+[2008-06-05 19:41:46] <cehteh> and a very ugly bug when it fails :(
+[2008-06-05 19:41:42] <ichthyo> when a node puts its result into a frame located within the cache
+[2008-06-05 19:41:59] <ichthyo> this frame is treated as if it is read-only
+[2008-06-05 19:42:21] <ichthyo> no node depending on this frame will be wired in a way that allows "in-place"
+[2008-06-05 19:42:33] <cehteh> about the time averaging: i plan to hint some dependencies so you can ask for "maybe" or by some priority depending on quality/whatever
+[2008-06-05 19:43:19] <cehteh> where quality should be runtime adjusted by the profiler
+[2008-06-05 19:43:39] <ichthyo> the problem with time averaging is: we don't know how much frames will be averaged at build time, because that's a automatable effect parameter
+[2008-06-05 19:43:47] <cehteh> thats a case where a dependencie might not be fullfilled .. but only on request
+[2008-06-05 19:44:08] <ichthyo> but the "quality" thing sounds like a good idea
+[2008-06-05 19:44:17] <cehteh> yes then split that rendering into 3 passes?
+[2008-06-05 19:44:27] <cehteh> 1st pass : building the graph
+[2008-06-05 19:44:53] <cehteh> 2nd pass: determine dependencies (by inspecting automation)
+[2008-06-05 19:45:00] <cehteh> 3rd pass: do the render
+[2008-06-05 19:45:10] <ichthyo> maybe?
+[2008-06-05 19:45:17] <ichthyo> 1st pass of course is clear
+[2008-06-05 19:45:25] <cehteh> well do you have a better idea?
+[2008-06-05 19:45:49] <cehteh> so far i thought about 2 pass where the dependency analysis was part of the builder
+[2008-06-05 19:46:02] <ichthyo> agreed
+[2008-06-05 19:46:28] <cehteh> but making it three pass shouldnt be a problem or?
+[2008-06-05 19:46:51] <ichthyo> I also thought after having finished the raw graph, I'll do some configuration calldown, e.g. to determine the maximum number of buffers needed
+[2008-06-05 19:46:59] <cehteh> maybe even adaptive 2/3 pass depending on effects ... but maybe that would complicate it unnecessary
+[2008-06-05 19:47:43] <ichthyo> its not really a problem, just need to be aware and work the details out correctlyy
+[2008-06-05 19:47:49] <cehteh> i dont think you need  to count the buffers (not yet, maybe i oversee soemthing)
+[2008-06-05 19:48:08] <cehteh> otherwise the backend should manage that automatically
+[2008-06-05 19:48:18] <ichthyo> yes, I'm fine with that
+[2008-06-05 19:48:46] <ichthyo> just to note, if it helps with the allocation, I /can/ tell the maximum number of buffers needed
+[2008-06-05 19:49:00] <ichthyo> (for a given segment of the graph, of course)
+[2008-06-05 19:49:09] <cehteh> not sure if i overseen something, but i think when needed such a 'configuration calldown' (and optimizing pass) could be added later
+[2008-06-05 19:49:27] <ichthyo> sure
+[2008-06-05 19:49:50] <cehteh> buffers itself doesnt cost .. but if you really need a lot it will cause IO
+[2008-06-05 19:49:57] <cehteh> but that unavoidable anyways
+[2008-06-05 19:50:05] <ichthyo> no no
+[2008-06-05 19:50:19] <cehteh> yes yes
+[2008-06-05 19:50:20] <ichthyo> I'll try to minimize buffer use as much as possible
+[2008-06-05 19:50:24] <cehteh> :)
+[2008-06-05 19:50:30] <cehteh> of course
+[2008-06-05 19:51:00] <cehteh> but there are always some limits on finite machines
+[2008-06-05 19:51:26] <ichthyo> the problematic case are usual rather rare corner cases, but it should handle those flawless, of course
+[2008-06-05 19:51:36] <ichthyo> similar for the size of the buffers
+[2008-06-05 19:51:46] <ichthyo> I dont want Lumiera to clip the image
+[2008-06-05 19:51:49] <ichthyo> as cinelerra does
+[2008-06-05 19:52:04] <ichthyo> e.g. when using the motion tracker
+[2008-06-05 19:52:20] <cehteh> well if you need safe-regions around you need to use biggier frames
+[2008-06-05 19:52:31] <cehteh> but memory requirements grow quadratic!
+[2008-06-05 19:52:46] <ichthyo> the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra
+[2008-06-05 19:52:59] <cehteh> yes agreed
+[2008-06-05 19:53:15] <ichthyo> I don't think we need safe-regions allways, 
+[2008-06-05 19:53:31] <ichthyo> but, as e.g. the motion tracking will create automation data in Lumiera
+[2008-06-05 19:53:38] <cehteh> yes only for some effect .. motion tracker doesnt need it
+[2008-06-05 19:53:50] <ichthyo> it means the actual buffer size depends on automation data for a given frame
+[2008-06-05 19:53:56] <cehteh> that just xyr transformation
+[2008-06-05 19:54:35] <cehteh> a blur is something which might require a small safe-region to bleed over the edges
+[2008-06-05 19:54:43] <ichthyo> yes, you are right
+[2008-06-05 19:54:52] <ichthyo> if the motion tracker is wired intelligently
+[2008-06-05 19:55:05] <ichthyo> it doesn't need to move anyting itself
+[2008-06-05 19:55:18] <cehteh> mapping the motion tracker transformation to a destionation might need safe regions
+[2008-06-05 19:55:30] <cehteh> (in case of rotations)
+[2008-06-05 19:55:36] <ichthyo> yes agreed
+[2008-06-05 19:56:16] <cehteh> well temp buffers will be allcocated for frames of the same 'class' i aleready saied that
+[2008-06-05 19:56:50] <cehteh> and i will group these classes so that some similar sizes fall in the same class 
+[2008-06-05 19:57:19] <cehteh> that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in
+[2008-06-05 19:57:32] <cehteh> the kernel will do that automatically for us
+[2008-06-05 19:57:37] <ichthyo> :)
+[2008-06-05 19:57:59] <cehteh> well mostly .. i need to whip it with the right hints ;)
+[2008-06-05 19:58:10] <ichthyo> :-o
+}}}
    +
    /***
 ''InlineJavascriptPlugin for ~TiddlyWiki version 1.2.x and 2.0''
diff --git a/wiki/renderengine.html b/wiki/renderengine.html
index c55d698a2..5dabc8bbb 100644
--- a/wiki/renderengine.html
+++ b/wiki/renderengine.html
@@ -556,10 +556,11 @@ is how to implement the relationship between [[MObject]]s and Assets. Do we use
    -
    +
    Assets are created by a Factories returning smart pointers; the Asset creation is bound to specific use cases and //only available// for these specific situations. There is no generic Asset Factory.
 
-For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file)
    +For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters &mdash; for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file &rarr; LoadingMedia) + 
    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.
    @@ -578,6 +579,9 @@ The first step towards an solution is to isolate the problem; obviously we //nee [img[how to implement Automation|uml/fig129669.png]]
    +
    +
    While generally automation is treated as a function over time, defining and providing such a function requires some //Automation Data.// The actual layout and meaning of this data is deemed an implementation detail of the [[parameter provider|ParamProvider]] used, but nevertheless an automation data set has object characteristics within the [[EDL (high-level-model)|EDL]], allowing it to be attached, moved and [[placed|Placement]] by the user.
    +
    Starting out from the concepts of Objects, Placement to Tracks, render Pipes and connection properties (&rarr; see [[here|TrackPipeEDL]]) 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.
 &rarr;see also: BuilderPrimitives for the elementary situations used to cary out the building operations
@@ -729,11 +733,11 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
 }
 //}}}
    -
    +
    All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actual performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &mdash; to pay in the Builder &mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
 
 [>img[Outline of the Build Process|uml/fig129413.png]]
-The building itself will be broken down into several small tool application steps. Each of these steps has to be mapped to the MObjects found on the [[Timeline]]. Remember: the idea is that the so called "[[Fixture]]" contains only [[ExplicitPlacement]]s which in turn link to MObjects like Clips, Effects and Automation. So it is sufficient to traverse this list and map the build tools to the elements. Each of these build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
+The building itself will be broken down into several small tool application steps. Each of these steps has to be mapped to the MObjects found on the [[Timeline]]. Remember: the idea is that the so called "[[Fixture]]" contains only [[ExplicitPlacement]]s which in turn link to MObjects like Clips, Effects and [[Automation]]. So it is sufficient to traverse this list and map the build tools to the elements. Each of these build tools has its own state, which serves to build up the resulting Render Engine. So far I see two steps to be necessary:
 * find the "Segments", i.e. the locations where the overall configuration changes
 * for each segment: generate a ProcNode for each found MObject and wire them accordingly
 Note, //we still have to work out how exactly building, rendering and playback work// together with the backend-design. The build process as such doesn't overly depend on these decisions. It is easy to reconfigure this process. For example, it would be possible as well to build for each frame separately (as Cinelerra2 does), or to build one segment covering the whole timeline (and handle everything via [[Automation]]
@@ -749,7 +753,31 @@ Note, //we still have to work out how exactly building, rendering and playback w
 [img[Colaborations in the Build Process|uml/fig128517.png]]
    -
    +
    +
    Actually setting up and wiring a [[processing node|ProcNode]] involves several issues and is carried out at the lowest level of the build process.
+It is closely related to &rarr; [[the way nodes are operated|NodeOperationProtocol]] and the &rarr; [[mechanics of the render process|RenderMechanics]]
+
+!!!object creation
+The Nodes are small polymorphic objects, carrying configuration data, but no state. They are [[specially allocated|ManagementRenderNodes]], and the object creation is accessible by means of the NodeFactory solely. They //must not be deallocated manually.// The decision of what concrete node type to create depends on the actual build situation and is worked out by the combination of [[mould|BuilderMould]] and [[processing pattern|ProcPatt]] at the current OperationPoint, issuing a call to one of NodeFactory's {{{operator()}}}
+
+!!!node, plugin and processing function
+Its a good idea to distinguish clearly between those concepts. A plugin is a piece of (possibly external) code we use to carry out operations. We have to //discover its properties and capabilities.// We don't have to discover anything regarding nodes, because we (Lumiera builder and renderengine) are creating, configuring and wiring them to fit the specific purpose. Both are to be distinguished from processing functions, which do the actual calculations on the media data. Every node typically encompasses at least one processing function, which may be an internal function in the node object, a library function from Lumiera or GAVL, or external code loaded from a plugin.
+
+!!!node interfaces
+As a consequence of this distinctions, in conjunction with a processing node, we have to deal with three different interfaces
+* the __build interface__ is used by the builder to set up and wire the nodes. It can be full blown C++ (including templates)
+* the __operation interface__ is used to run the calculations, which happens in cooperation of Proc-Layer and Backend. So a function-style interface is preferable.
+* the __inward interface__ is accessed by the processing function in the course of the calculations to get at the necessary context, including in/out buffers and param values.
+
+!!!wiring data connections
+A node //knows its predecessors, but not its successors.// When being //pulled//&nbsp; in operation, it can expect to get a frame provider for accessing the in/out buffer locations (some processing functions may be "in-place capable", but that's only a special case of the former). At this point, the ''pull principle'' comes into play: the node may request input frames from the frame provider, passing its predecessors as a ''continuation''.
+With regard to the build process, the wiring of data connections translates into providing the node with its predecessors and preconfiguring the possible continuations. While in the common case, a node has just one input/output and pulls from its predecessor a frame for the same timeline position, the general case can be more contrived. A node may process N buffers in parallel and may require several different time positions for it's input, even at a differing framerate. So the actual source specification is (predNode,time,frameType). The objective of the wiring done in the build process is to factor out the parts known in advance, while in the render process only the variable part need to be filled in. Or to put it differently: wiring builds a higher order function (time)->(continuation), where continuation can be invoked to get the desired input frame.
+
+!!!wiring control conections
+In many cases, the parameter values provided by these connections aren't frame based data, rather, the processing function needs a call interface to get the current value (value for a given time), which is provided by the parameter object. Here, the wiring needs to link to the suitable parameter instance, which is located within the high-level model (!). As an additional complication, calculating the actual parameter value may require a context data frame (typically for caching purposes to speed up the interpolation). While these parameter context data frames are completely opaque for the render node, they have to be passed in and out similar to the state needed by the node itself, and the wiring has to prepare for accessing these frames too.
+
    +
    +
    The Builder takes some MObject/[[Placement]] information (called Timeline) and generates out of this a Render Engine configuration able to render this Objects. It does all decisions and retrieves the current configuration of all objects and plugins, so the Render Engine can just process them stright forward.
 
 The Builder is the central part of the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]
@@ -761,7 +789,7 @@ As the builder has to create a render node network implementing most of the feat
 * //operating the Builder// can be viewed at from two different angles, either emphasizing the [[basic building operations|BasicBuildingOperations]] employed to assemble the render node network, or focussing rather at the [[mechanics|BuilderMechanics]] of cooperating parts while processing.
 * besides, we can identify a small set of elementary situations we call [[builder primitives|BuilderPrimitives]], to be covered by the mentioned BuilderToolKit; by virtue of [[processing patterns|ProcPatt]] they form an [[interface to the rule based configuration|BuilderRulesInterface]].
 * the actual building (i.e. the application of tools to the timeline) is done by the [[Assembler|BuilderAssembler]], which is basically a collection of functions (but has a small amount of global configuration state)
-* any non-trivial wiring of render nodes, tracks, pipes and automation is done by the services of the [[connection manager|ConManager]]
+* any non-trivial wiring of render nodes, tracks, pipes and [[automation|Automation]] is done by the services of the [[connection manager|ConManager]]
    @@ -773,13 +801,14 @@ As the builder has to create a render node network implementing most of the feat !!pattern of operation The working pattern of this builder mechanics can be described as triggering, enqueuing, priorizing, recursing and exhausting. Without the priorizing part, it would be a depth-first call graph without any context state, forcing us to have all cross reference information available at every node or element to be treated. We prefer to avoid this overhead by ordering the operations into several phases and within these phases into correlated entities with the help of a ''weighting function'' and scheduling with a ''priority queue''
    -
    +
    The [[Builder]] uses different kinds of tools for creating a network of render nodes from a given high-level model. When breaking down this (necessarily complex) process into small manageable chunks, we arrive at [[elementary building situations|BuilderPrimitives]]. For each of these there is a specialized tool. We denote these tools as "moulds" because they are a rather passive holder for the objects to be attached and wired up. They are shaped according to the basic form the connections have to follow for each of these basic situations:
 * attaching an effect to a pipe
 * combining pipes via a transition
 * starting out a pipe from a source reader
 * general connections from the exit node of a pipe to the port of another pipe
-In all those cases, the active part is provided by [[processing patterns|ProcPatt]] &mdash; sort of micro programs executed within the context of a given mould: the processing pattern defines the steps to take (in the standard/basic case this is just "attach"), while the mould holds and provides the location where these steps will operate.
    +In all those cases, the active part is provided by [[processing patterns|ProcPatt]] &mdash; sort of micro programs executed within the context of a given mould: the processing pattern defines the steps to take (in the standard/basic case this is just "attach"), while the mould holds and provides the location where these steps will operate. Actually, this location is represented as a OperationPoint, provided by the mould and abstracting the details of making multi-channel connections. + 
    While assembling and building up the render engines node network, a small number of primitive building situations is encountered repeatedly. The BuilderToolKit provides a "[[mould|BuilderMould]]" for each of these situations, typically involving parametrisation and the application of a [[processing pattern|ProcPatt]].
@@ -852,16 +881,12 @@ While building, the application of such a visiting tool (especially the [[NodeCr
    -
    +
    Besides the primary working tool within the builder (namely the [[Node Creator Tool|PlanningNodeCreatorTool]]), on a lower level, we encounter several [[elementary building situations|BuilderPrimitives]] &mdash; and for each of these elementary situations we can retrieve a suitable "fitting tool" or [[mould|BuilderMould]]. The palette of these moulds is called the ''tool kit'' of the builder. It is subject to configuration by rules.
 
-!! {{red{open questions}}}
-* how to address these moulds
-* how to type them
-* how to parametrize them
 
 !!addressing a mould
-All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type ({{{PipeMould}}}, {{{CombiningMould}}}, {{{SourceChainMould}}}, {{{WiringMould}}}) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
+All mould instances are owned and managed by the [[tool factory|BuilderToolFactory]], and can be referred to by their type (PipeMould, CombiningMould, SourceChainMould, WiringMould) and a concrete object instance (of suitable type). The returned mould (instance) acts as a handle to stick together the given object instance (from the high-level model) with the corresponding point in the low-level node network under construction. As consequence of this approach, the tool factory instance holds a snapshot of the current building state, including all the active spots in the build process. As the latter is driven by objects from the high-level model appearing (in a sensible order &rarr; see BuilderMechanics) within the NodeCreatorTool, new moulds will be created and fitted as necessary, and existing moulds will be exhausted when finished, until the render node network is complete.
 
 !!configuring a mould
 As each mould kind is different, it has a {{{prepare(...)}}} function with suitably typed parameters. The rest is intended to be  self-configuring (for example, a ~CombiningMould will detect the actual kind of Transition and select the internal mode of operation), so that it's sufficient to just call {{{operate()}}}
@@ -869,7 +894,10 @@ As each mould kind is different, it has a {{{prepare(...)}}} function with suita
 !!sequence of operations
 When {{{operate()}}} doesn't throw, the result is a list of //successor moulds// &mdash; you shouldn't use the original mould after triggering its operation, because it may have been retracted as a result and reused for another purpose by the tool factory. It is not necessary to store these resulting moulds either (as they can be retrieved as described above), but they can be used right away for the next building step if applicable. In the state they are returned from a successful building step (mould operation = execution of a contained [[processing pattern|ProcPatt]]), they are usually already holding a reference to the part of the network just created and need to be configured only with the next high-level object (effect, placement, pipe, processing pattern or similar, depending on the concrete situation) in order to carry out the next step.
 
-&rarr;see also: BuilderPrimitives for the elementary working situations corresponding to these fitting tools
+!!single connection step
+at the lowest level within the builder there is the step of building a //connection.// This step is executed by the processing pattern with the help of the mould. Actually, making such a connection is more complicated, because in the standard case it will connect N media streams simultaneously (N=2 for stereo sound or 3D video, N=6 for 5.1 Surround, N=9 for 2nd order Ambisonics). These details are encapsulated within the OperationPoint, which is provided by the mould and exhibits a common interface for the processing pattern to express the connecting operation.
+
+&rarr;see also: BuilderPrimitives for the elementary working situations corresponding to each of these [[builder moulds|BuilderMould]]
    @@ -889,6 +917,15 @@ TertiaryMid: #99a TertiaryDark: #667 Error: #f88
    +
    +
    The Connection Manager is a __Facade__ for querying information and deriving decisions regarding various aspects of data streams and possible connections.
+* retrieve information about capabilities of a stream type given by ID
+* decide if a connection is possible
+* retrieve a //strategy// for implementing a connection
+
+In the intended implementation, a good deal of this functionality will actually be implemented by [[rules|ConfigRules]], while other parts need to be provided by hard wired logic, at least as a fallback. Anyway, the purpose of the Connection Manager ois to isolate the [[Builder]], which is client of this information and decision services, from these details
+
    +
    Configuration Queries are requests to the system to "create or retrieve an object with //this and that // capabilities". 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), pipe(myPipe)}}}. Queries are typed to the kind of expected result object: {{{Query<Pipe> ("stream(mpeg)")}}} requests a pipe excepting/delivering mpeg stream data &mdash; and it depends on the current configuration what "mpeg" means. If there is any stream data producing component in the system, which advertises to deliver {{{stream(mpeg)}}}, and a pipe can be configured or connected with this component, then the [[defaults manager|DefaultsManagement]] will create/deliver a [[Pipe|PipeHandling]] object configured accordingly.
 &rarr; [[Configuration Rules system|ConfigRules]]
@@ -980,7 +1017,7 @@ This is an very important external Interface, because it links together all thre
 
    [[ProcLayer and Engine]]
    -
    +
    As detailed in the [[definition|DefaultsManagement]], {{{default(Obj)}}} is sort of a Joker along the lines "give me a suitable Object and I don't care for further details". Actually, default objects are implemented by the {{{mobject::session::DefsManager}}}, which remembers and keeps track of anything labeled as "default". This defaults manager is a singleton and can be accessed via the [[Session]] interface, meaning that the memory track regarding defaults is part of the session state. Accessing an object via the query for an default actually //tagges// this object (storing a weak ref in the ~DefsManager). Alongside with each object successfully queried via "default", the degree of constriction is remembered, i.e. the number of additional conditions contained in the query. This enables us to search for default objects starting with the most unspecific.
 
 !Skeleton
@@ -1000,7 +1037,7 @@ Taken precisely, the "degree of constriction" yields only a partial or
 {{red{WARN}}} there is an interference with the (planned) Undo function. This is a general problem of the config queries; just ignoring this issue seems reasonable.
 
 !!!Problems with the (preliminary) mock implementation
-As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see {{{MockConfigQuery}}}). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
+As we don't have a Prolog interpreter on board yet, we utilize a mock store with preconfigured answers. (see MockConfigQuery). As this preliminary solution is lacking the ability to create new objects, we need to resort to some trickery here (please look away). The overall logic is quite broken, because the system isn't capable to do any real resolution &mdash; if we ignore this fact, the rest of the algorithm can be implemented, tested and used right now.
    @@ -1010,7 +1047,7 @@ As we don't have a Prolog interpreter on board yet, we utilize a mock store with {{{default(Obj)}}} is a predicate expressing that the object {{{Obj}}} can be considered the default setup under the given conditions. Using the //default// can be considered as a shortcut for actually finding a exact and unique solution. The latter would require to specify all sorts of detailed properties up to the point where only one single object can satisfy all conditions. On the other hand, leaving some properties unspecified would yield a set of solutions (and the user code issuing the query had to provide means for selecting one soltution from this set). Just falling back on the //default// means that the user code actually doesn't care for any additional properties (as long as the properties he //does// care for are satisfied). Nothing is said specifically on //how//&nbsp; this default gets configured; actually there can be rules //somewhere,// and, additionally, anything encountered once while asking for a default can be re-used as default under similar circumstances. &rarr; [[implementing defaults|DefaultsImplementation]]
    -
    +
    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'' &mdash; of course, that's a //no-brainer // todays. Rather, important is what is not "an object", meaning it can't be arranged arbitrarily
@@ -1023,10 +1060,10 @@ We ''separate'' processing (rendering) and configuration (building). We have a [
 ''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 "have" a pipe or "is" a video track and the like; it can be configured to behave in such manner by using placements though). [[Pipes|Pipe]] are hooks for making connections and are the only facility to build processing chains. We have global pipes, and each clip is built around a lokal [[source port|ClipSourcePort]] &mdash; and that's all. No special "media viewer" and "arranger", 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 "parameter" 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 "bezier automation", and then maybe a "linear automation", a "mask automation" and yet another way to handle transitions)
+''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 "parameter" to be served by some [[parameter provider|ParamProvider]]. Consequently, [[Automation]] is just another kind of parameter, i.e. a function &mdash; how this function is calculated is an encapsulated implementation detail (we don't have "bezier automation", and then maybe a "linear automation", a "mask automation" and yet another way to handle transitions)
    -
    +
    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?
@@ -1045,7 +1082,7 @@ As always, the main goal is //to cut down complexity// by the usual approach to
 
 To achieve this, here we try to separate ''Configuration'' from ''Processing''. Further, in Configuration we try to separate the ''high level view'' (users view when editing) from the ''low level view'' (the actual configuration effective for the calculations). Finally, we try to factor out and encapsulate ''State'' in order to make State explicit.
 
-The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render 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. Make the actual processing nodes Template classes, parametrized by the color model and number of components. Make all Nodes of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. Make the OpenGL rendering into alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering out of the implementation of the actual processing. Introduce separate control data connections for the automation data, separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes using the same automation data).
+The main tool used to implement this separation is the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]]. Here especially we move all decisions and parametrization into the BuildProcess. The Nodes in the render 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. Make the actual processing nodes Template classes, parametrized by the color model and number of components. Make all Nodes of equal footing with each other, able to be connected freely within the limitations of the necessary input and output. Make the OpenGL rendering into alternate implementation of some operations together with an alternate signal flow (usable only if the whole Pipeline can be built up to support this changed signal flow), thus factoring out all the complexities of managing the data flow between core and hardware accelerated rendering out of the implementation of the actual processing. Introduce separate control data connections for the [[automation data|Automation]], separating the case of true multi-channel-effects from the case where one node just gets remote controlled by another node (or two nodes are utilizing the same automation data).
 
 Another pertinent theme is to make the basic building blocks simpler, while on the other hand gaining much more flexibility for combining these building blocks. For example we try to unfold any "internal-multi" effects into separate instances (e.g. the possibility of having an arbitrary number of single masks at any point of the pipeline instead of having one special masking facility encompassing multiple sub-masks. Similarly, we treat the Objects in the EDL in a more uniform manner and gain the possibility to [[place|Placement]] them in various ways.
    @@ -1090,16 +1127,17 @@ Basically, each elementary operation has to record the informations necessary to {{red{to be defined in more detail later...}}}
    -
    +
    The &raquo;Timeline&laquo; is a sequence of ~MObjects -- here clips -- together with an ExplicitPlacement, locating each clip at a given time and track. (Note: I simplified the time format and wrote frame numbers to make it more clear)
 [img[Example1: Objects in the EDL/Fixture|uml/fig128773.png]]
 
 ----
 After beeing processed by the Builder, we get the following Render Engine configuration
+{{red{note: please take this only as a "big picture", the implementation details got a lot more complicated as of 6/08}}}
 [img[Example1: generated Render Engine|uml/fig129029.png]]
    -
    +
    {{red{TODO: seemingly this example is slightly outdated, as the implementation of placements is now indirect via LocatingPin objects}}}
 This Example showes the //high level// EDL as well. This needs to be transformed into a Fixture by some facility still to be designed. Basically, each [[Placement]] needs to be queried for this to get the corresponding ExplicitPlacement. The difficult part is to handle possible Placement constraints, e.g. one clip can't be placed at a timespan covered by another clip on the same track. In the current Cinelerra2, all of this is done directly by the GUI actions.
 
@@ -1109,6 +1147,7 @@ The &raquo;Timeline&laquo; is a sequence of ~MObjects -- note: using the
 ----
 After beeing processed by the Builder, we get a Render Engine configuration.<br>
 It has to be segmented at least at every point with changes in the configuration, but some variations are possible, e.g. we could create a Render Engine for every Frame (as Cinelerra2 does) or we could optimize out some configurations (for example the effect extended beyond the end of the clip)
+{{red{note: as of 6/08 this can be taken only as the "big picture". Implementation will differ in details, and is more complicated than shown here}}}
 [img[Example2: generated Render Engine|uml/fig129157.png]]
    @@ -1279,7 +1318,7 @@ For this Lumiera design, we could consider making GOP just another raw media dat &rarr;see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
    -
    +
    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 Lumiera Renderengine, the Builder and the related parts.
 
 * [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@@ -1296,6 +1335,7 @@ For this Lumiera design, we could consider making GOP just another raw media dat
 * [[integrating the Config Query system|ConfigQueryIntegration]]
 * [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreatorTool]]
 * [[how to handle »attached placement«|AttachedPlacementProblem]]
+* working out the [[basic building situations|BuilderPrimitives]] and [[mechanics of rendering|RenderMechanics]]
    @@ -1652,7 +1692,7 @@ From experiences with other middle scale projects, I prefer having the test code [img[Example: Interfaces/Namespaces of the ~Session-Subsystems|uml/fig130053.png]]
    -
    +
    Opening and accessing media files on disk poses several problems, most of which belong to the domain of Lumiera's data backend. Here, we focus on the questions related to making media data available to the EDL and the render engine. Each media will be represented by an MediaAsset object, which indeed could be a compound object (in case of MultichannelMedia). Building this asset object thus includes getting informations from the real file on disk. For delegating this to the backend, we use the following query interface:
 * {{{queryFile(char* name)}}} requests accessing the file and yields some (opaque) handle when successful.
 * {{{queryChannel(fHandle, int)}}} will then be issued in sequence with ascending index numbers, until it returns {{{NULL}}}.
@@ -1663,7 +1703,9 @@ From experiences with other middle scale projects, I prefer having the test code
 
 {{red{to be defined in more detail later...}}}
 
-{{red{how to create a test stub for this interface...?}}}
    +&rarr; see "~MediaAccessFacade" for a (preliminary) interface definitioin +&rarr; see "~MediaAccessMock" for a mock/test implementaion + 
    Used to actually implement the various kinds of [[Placement]] of ~MObjects. ~LocatingPin is the root of a hierarchy of different kinds of placing, constraining and locating a Media Object. Basically, this is an instance of the ''state pattern'': The user sees one Placement object with value semantics, but when the properties of the Placement are changed, actually a ~LocatingPin object (or rather a chain of ~LocatingPins) is changed within the Placement. Subclasses of ~LocatingPin implement different placing/constraining behaviour:
@@ -1722,6 +1764,12 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 {{red{let's see if this approach works...}}}
    +
    +
    Contrary to the &rarr;[[Assets and MObjects|ManagementAssetRelation]], the usage pattern for [[render nodes|ProcNode]] is quite simple: All nodes are created together every time a new segment of the network is being build and are all needed together until this segment is re-built, at which point they can be thrown away altogether. While it would be easy to handle the nodes automatically by smart-ptr (the creation is accessible only by use of the {{{NodeFactory}}} anyways), it //seems advisable to care for a bulk allocation/deallocation here.// The reason being not so much the amount of memory (which is expected to be moderate), but the fact, that the build process can be triggered repeatedly several times a second when tweaking the EDL, which could lead to fragmentation and memory pressure.
+
+__5/2008__: the allocation mechanism can surely be improved later, but for now I am going for a simple implementation based on keeping all nodes of one kind together in a vector. The list of possible node kinds is hard wired, allowing to generate the object holding a chunk of nodes for one segment, mostly relying on the runtime system for the management.
+
    +
    <!--{{{-->
 <link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml'/>
@@ -1729,9 +1777,11 @@ This Design strives to achieve a StrongSeparation between the low-level Structur
 
 <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="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;">loading <b>Proc-Layer</b> devel doku<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>
    -
    +
    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__ &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]]
+
+&rarr; see also LoadingMedia
    @@ -1791,7 +1841,27 @@ So, when creating a clip out of such a compound media asset, the clip has to be 
    NodeCreaterTool 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 NodeCreaterTool 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]]
    -
    +
    +
    The [[nodes|ProcNode]] are wired to form a "Directed Acyclic Graph"; each node knows its predecessor(s), but not its successor(s).  The RenderProcess is organized according to the ''pull principle'', thus we find an operation {{{pull()}}} at the core of this process. There is no such thing as an "engine object" calling nodes iteratively or table driven, rather, the nodes themselves issue recursive calls to their predecessor(s). For this to work, we need the nodes to adhere to a specific protocol:
+# Node is pulled, with a StateProxy object as parameter (encapsulating the access to the frames or buffers)
+# Node may now access current parameter values, using the state accessible via the StateProxy
+# using it's //input-output and wiring descriptor,// the Node creates a StateAdapter wrapping the StateProxy for allocating buffers and accessing the required input
+# StateAdapter first tries to get the output frames from the Cache in the Backend. In case of failure, a {{{process()}}} call is prepared by generating {{{pull()}}} call(s) for the input
+# as late as possible, typically on return, these recursive pull-calls have allocated a buffer containing the input data.
+# when input is ready prior to the {{{process()}}} call, output buffers will be allocated, either from the cache, or (if not caching) from the "parent" StateAdapter up the callstack.
+# after all buffers are available, the StateAdapter issues the {{{process()}}} call back to the originating node, which now may dereference the frame pointers and do its calculations
+# finally, when the {{{pull()}}} call returns, "parent" state originating the pull holds onto the buffers containing the calculated output result.
+some points to note:
+* the WiringDescriptor is {{{const}}} and precalculated while building (remember another thread may call in parallel)
+* when a node is "inplace-capable", input and output buffer may actually point to the same location
+* but there is no guarantee for this to happen, because the cache may be involved (and we can't overwrite the contents of a cache frame)
+* generally, a node may have N inputs and M output frames, which are expected to be processed in a single call
+
+&rarr; the [["mechanics" of the render process|RenderMechanics]]
+&rarr; more fine grained [[implementation details|RenderImplDetails]]
+
    +
    +
    We have to consider carefully how to handle the Creation of new class instances. Because, when done naively, it can defeat all efforts of separating subsystems, or &mdash; the other extreme &mdash; lead to a //switch-on-typeID//  programming style. We strive at a solution somewhere in the middle by utilizing __Abstract Factories__ on Interface or key abstraction classes, but providing specialized overloads for the different use cases. So in each use case we have to decide if we want to create a instance of some general concept (Interface), or if we have a direct collaboration and thus need the Factory to provide a more specific sub-Interface or even a concrete type.
 
 !Object creation use cases
@@ -1802,7 +1872,8 @@ So, when creating a clip out of such a compound media asset, the clip has to be
 |mark selection as clip|asset::Clip, session::Clip, Placement with unspec. LocatingPin| doesn't add to EDL|
 |loading Plugin|asset::Effect| usually at program startup|
 |create Session|asset::Track, asset::Pipe| |
-&rarr; [[Creating and registering Assets|AssetCreation]]
+&rarr; [[creating and registering Assets|AssetCreation]]
+&rarr; [[loading media|LoadingMedia]]
 
 !![[MObjects|MObject]]
 |add media to EDL|asset::Clip, session::Clip, Placement with unspecified LocatingPin| creating whole-media clip on-the-fly |
@@ -1831,6 +1902,14 @@ But because I know the opinions on this topc are varying (users tend to be delig
 My proposed aproach is to treat OpenGL as a separate video raw data type, requiring separete and specialized [[Processing Nodes|ProcNode]] for all calculations. Thus the Builder could connect OpenGL nodes if it is possible to cover the whole render path for preview and fall back to the normal ~ProcNodes for all relevant renders
    +
    +
    A low-level abstraction within the [[Builder]] &mdash; it serves to encapsulate the details of making multi-channel connections between the render nodes: In some cases, a node can handle N channels internally, while in other cases we need to replicate the node N times and wire each channel individually.
+
+The operation point is provided by the current BuilderMould and used by the [[processing pattern|ProcPatt]] executing within this mould and conducting the current build step. The operation point's interface allows //to abstract//&nbsp; these details, as well as to //gain additional control//&nbsp; if necessary (e.g. addressing only one of the channels). The most prominent build instruction used within the processing patterns (which is the instruction {{{"attach"}}}) relies on the aforementioned //approach of abstracted handling,// letting the operation point determine automatically how to make the connection.
+
+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.
+
    +
    The Lumiera Processing Layer is comprised of various subsystems and can be separated into a low-level and a high-level part. At the low-level end is the [[Render Engine|OverviewRenderEngine]] which basically is a network of render nodes cooperating closely with the Backend Layer in order to carry out the actual playback and media transforming calculations. Whereas on the high-level side we find several different [[Media Objects|MObjects]] that can be placed into the [[EDL]], edited and manipulated. This is complemented by the [[Asset Management|Asset]], which is the "bookkeeping view" of all the different "things" within each [[Session|SessionOverview]].
 
@@ -1841,7 +1920,7 @@ There is rather strong separation between these two levels, and &mdash; <
 [img[Block Diagram|uml/fig128005.png]]
    -
    +
    Render Engine, [[Builder]] and [[Controller]] are closely related Subsystems. Actually, the [[Builder]] //creates// a newly configured Render Engine //for every// RenderProcess. Before doing so, it queries from the Session (or, to be more precise, from the [[Fixture]] within the current Session) all necessary Media Object Placement information. The [[Builder]] then derives from this information the actual assembly of [[Processing Nodes|ProcNode]] comprising the Render Engine. Thus:
  * the source of the build process is a sequence of absolute (explicit) [[Placements|Placement]] called the [[Playlist]]
  * the [[build process|BuildProcess]] is driven, configured and controlled by the [[Controller]] subsystem component. It encompasses the actual playback configuration and State of the System.
@@ -1879,8 +1958,8 @@ see also: RenderEntities, [[two Examples (Object diagrams)|Examples]]
 <!--}}}-->
    -
    -
    A ParamProvider is the counterpart for (one or many) Parameter instances. It implements the value access function made available by the Parameter object to its clients.
+
    
+
    A ParamProvider is the counterpart for (one or many) [[Parameter]] instances. It implements the value access function made available by the Parameter object to its clients.
 
 To give a concrete example: 
 * a Fade Plugin needs the actual fade value for Frame t=xxx
@@ -1892,8 +1971,8 @@ To give a concrete example:
 &rarr; see the class diagram for [[Automation]]
 
    
 
    
-
    
-
    Parameters are all probably variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application state to take effect.
+
    
+
    Parameters are all possibly variable control values used within the Render Engine. Contrast this with configuration values, which are considered to be fixed and need an internal reset of the application (or session) state to take effect.
 
 A ''Parameter Object'' provides a descriptor of the kind of parameter, together with a function used to pull the //actual value// of this parameter. Here, //actual// has a two-fold meaning:
 * if called without a time specification, it is either a global (but variable) system or session parameter or a default value for automated Parameters. (the intention is to treat this cases uniformly)
@@ -2572,11 +2651,11 @@ We need a way of addressing existing [[pipes|Pipe]]. Besides, as the Pipes 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//
 
    
 
    
-
    
+
    
 
    Open issues, Things to be worked out, Problems still to be solved... 
 
 !!Parameter Handling
-The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime.
+The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered, enumerated and described at runtime. (&rarr; see [[tag:automation|automation]])
 
 ''Automation Type'': Directly connected is the problem of handling the //type// of parameters sensible, including the value type of automation data. My first (somewhat naive) approach was to "make everything a double". But this soon leads into quite some of the same problems haunting the automation solution implemented in the current Cinelerra codebase. What makes the issue difficult is the fact we both need static diversity as well as dynamic flexibility. Usually, when combining hierarchies and templates, one has to be very careful; so I just note the problem down at the moment and will revisit it later, when I have a more clear understanding of the demands put onto the [[ProcNode]]s
 
@@ -2630,12 +2709,13 @@ Besides, they provide an important __inward interface__ for the [[ProcNode]]s, w
 
 
    
 
    
-
    
+
    
 
    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.
 <<<
 ''Status'': started out as design draft in summer '07, Ichthyo is now in the middle of a implementing the foundations and main structures in C++
-* basic AssetManager working
-* currently impmenenting the Builder (&rarr;[[more|PlanningNodeCreatorTool]])
+* basic [[AssetManager]] working
+* [[Builder]] implementation is on the way (&rarr;[[more|BuilderPrimitives]])
+* currently working out how to wire and operate procesing nodes (&rarr;[[more|RenderMechanics]])
 <<<
 
 !Summary
@@ -2657,8 +2737,19 @@ The system is ''open'' inasmuch every part mirrors the structure of correspondin
 &rarr; [[Implementation Details|ImplementationDetails]] {{red{WIP}}}
 
    
 
    
-
    
+
    
 
    A data processing node within the Render Engine. Its key feature is the possibility to pull from it one (freely addressable) [[Frame]] of calculated data. Further, each ~ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
+
+!! {{red{open questions}}}
+* how to address a node
+* how to type them
+* how to discover the number and type of the ports
+* how to discover the possible parameter ports
+* how to define and query for additional capabilities
+
+&rarr; see also the [[open design process draft|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface]]
+&rarr; see [[mem management|ManagementRenderNodes]]
+&rarr; see RenderProcess
 
    
 
    
 
    
@@ -2947,18 +3038,115 @@ At first sight the link between asset and clip-MO is a simple logical relation b
 &rarr; OverviewRenderEngine
 
    
 
    
-
    
-
    The Render Engine only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of [[Processing Nodes|ProcNode]] discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
+
    
+
    The [[Render Engine|Rendering]] only carries out the low-level and performance critical tasks. All configuration and decision concerns are to be handled by [[Builder]] and [[Controller]]. While the actual connection of the Render Nodes can be highly complex, basically each Segment of the Timeline with uniform characteristics is handled by one Processor, which is a graph of [[Processing Nodes|ProcNode]] discharging into a ExitNode. The Render Engine Components as such are //stateless// themselves; for the actual calculations they are combined with a StateProxy object generated by and connected internally to the [[Controller]], while at the same time holding the Data Buffers (Frames) for the actual calculations.
 
 [img[Entities comprising the Render Engine|uml/fig128389.png]]
 
    
 
    
-
    
-
    {{red{TODO: describe the Render Process.}}}
+
    
+
    Below are some notes regarding details of the actual implementation of the render process and processing node operation. In the description of the [[render node operation protocol|NodeOperationProtocol]] and the [[mechanics of the render process|RenderMechanics]], these details were left out deliberately.
 
- * see also the [[Entities involved in Rendering|RenderEntities]]
+!Layered structure of State
+State can be seen as structured like an onion. All the [[StateAdapter]]s in one call stack are supposed to be within one layer: they all know of a "current state", which in turn is a StateProxy (and thus may refer yet to another state, maybe accros the network or in the backend or whatever). The actual {{{process()}}} function "within" the individual nodes just sees a single StateAdapter and thus can be thought to be a layer below.
+
+!Buffer identification
+For the purpose of node operation, Buffers are identified by a //Buffer-handle,// which contains both the actual buffer pointer and an internal indes and classification of the source providing the buffer; the latter information is used for deallocation. Especially for calling the {{{process()}}} function (which is supposed to be plain C) the respective StateAdapter provides an array containing just the output and input buffer pointers
+
+!Problem of multi-channel nodes
+Some data processors simply require to work on multiple channels simultanously, while others work just on a single channel and will be replicated by the builder for each channel invoved. Thus, we are struck with the nasty situation that the node graph may go through some nodes spanning the chain of several channels. Now the decision is //not to care for this complexity within a single chain calculating a single channel.// We rely solely on the cache to avoid duplicated calculations. When a given node happens to produce multiple output buffers, we are bound to allocate them for the purpose of this nodes {{{process()}}} call, but we just "let go" the buffers not needed immediately for the channel acutally to be processed. For this to work, it is supposed that the builder has wired in a caching, and that the cache will hit when we touch the same node again for the other channels.
+
+!Configuration of the processing nodes
+[>img[uml/fig132357.png]]
+Every node is actually decomposed into three parts
+* an interface container of a ProcNode subclass
+* an {{{const}}} WiringDescriptor, which is actually parametrized to a subtype encoding details of the intended operation
+* an StateAdapter object created on the stack for each {{{pull()}}} call and configured specifically for the intended operation
+Thus, the outer container can be changed polymorphically to support the different kinds of nodes (large-scale view). The actual wiring of the nodes is contained in the WiringDescriptor, including the {{{process()}}} function pointer. Additionally, this WiringDescriptor knows the actual type of the StateAdapter to create, and this actual type has been chosen by the builder such as to select details of the desired operation of this mode, for example caching / no caching or maybe ~OpenGL rendering or the special case of a node pulling directly from a source reader. Most of this configuration is done by selecting the right template specialisation within the builder; thus in the critical path most of the calls can be inlined
+
+!!!! composing the actual StateAdapter
+As shown in the class diagram to the right, the actual implementation is assembled by chaining together the various policy classes governing parts of the node operation, like Caching, in-Place calculation capability, etc. (&rarr; see [[here|StateAdapter]] for details). The rationale is that we can allocate at runtime a StateProxy object directly on the stack with the necessary buffer table size and an precisely tailored and mostly inlined implementation of the call sequence for "calculating the predecessor nodes". We //do employ//&nbsp; some virtual calls for the buffer management in order to avoid coupling the policy classes to the actual number of in/out buffers. (As of 6/2008, this is mainly a precaution to be able to control the number of generated template instances. If we ever get in the region of several hundred individual specialisations, we'd need to separate out the allocation of the "wiring table" into a hand-made stack-like buffer allocated from the heap.)
+
+!Rules for buffer allocation and freeing
+* only output buffers are allocated. It is //never necessary//&nbsp; to allocate input buffers!
+* buffers are to be allocated as late as possible, typically just before invoking {{{process()}}}
+* buffers are allways allocated by calling to the preceeding StateAdapter in the callstack ("parent stae"), because of the possibility to write to cache.
+* {{{pull()}}} returns the buffer-ID of the single output requested by this call. Using this ID, the caller may retrieve the actual buffer holding the result from the "current state" StaeProxy.
+* any other buffers filled with results in the course of the same {{{process()}}} call can be released immediately before returning from the {{{pull()}}}
+* similar, and input buffers are to be released immediately after the {{{process()}}} call, but before returing from this {{{pull()}}}
+* buffers are allways released by calling to the "current state" (which is a StateProxy), providing the buffer-ID to be released
+
+@@clear(right):display(block):@@
 
    
 
    
+
    
+
    While the render process, with respect to the dependencies, the builder and the processing function is sufficiently characterized by referring to the ''pull principle'' and by defining a [[protocol|NodeOperationProtocol]] each node has to adhere to &mdash; for actually get it coded we have to care for some important details, especially //how to manage the buffers.// It may well be that the length of the code path necessary to invoke the individual processing functions is finally not so important, compared with the time spent at the inner pixel loop within these functions. But my guess is (as of 5/08), that the overall number of data moving and copying operations //will be//&nbsp; of importance.
+
+!requirements
+* operations should be "in place" as much as possible
+* because caching necessitates a copy, the points where this happens should be controllable.
+* buffers should accommodate automatically to provide the necessary space without clipping the image.
+* the type of the media data can change while passing through the network, and so does the type of the buffers.
+On the other hand, the processing function within the individual node needs to be shielded from these complexities. It can expect to get just //N~~I~~// input buffers and //N~~O~~// output buffers of required type. And, moreover, as the decision how to organize the buffers certainly depends on non-local circumstances, it should be preconfigured while building.
+
+!data flow
+[>img[uml/fig131973.png]]
+Not everything can be preconfigured though. The pull principle opens the possibility for the node to decide on a per call base what predecessor(s) to pull (if any). This decision may rely on automation parameters, which thus need to be accessible prior to requesting the buffer(s). Additionally, in a later version we plan to have the node network calculate some control values for adjusting the cache and backend timings &mdash; and of course at some point we'll want to utilize the GPU, resulting in the need to feed data from our processing buffers into some texture representation.
+
+!buffer management
+Besides the StateProxy representing the actual render process and holding a couple of buffer (refs), we employ a lightweight adapter object in between. It is used //for a single {{{pull()}}}-call// &mdash; mapping the actual buffers to the input and output port numbers of the processing node and for dealing with the cache calls. While the StateProxy manages a pool of frame buffers, this interspersed adapter allows us to either use a buffer retrieved from the cache as an input, possibly use a new buffer located within the cache as output, or (in case no caching happens) to just use the same buffer as input and output for "in-place"-processing. The idea is that most of the configuration of this adapter object is prepared in the wiring step while building the node network.
+
+The usage patern of the buffers can be stack-like when processing nodes require multiple input buffers. In the standard case, which also is the simplest case, a pair of buffers (or a single buffer for "in-place" capable nodes) suffices to calculate a whole chain of nodes. But &mdash; as the recursive descent means depth-first processing &mdash; in case multiple input buffers are needed, we may encounter a situation where some of these input buffers already contain processed data, while we have to descend into yet another predecessor node chain to pull the data for the remaining buffers. Care has to be taken //to allocate the buffers as late as possible,// otherwise we could end up holding onto a buffer almost for each node in the network. Effectively this translates into the rule to allocate output buffers only after all input buffers are ready and filled with data; thus we shouldn't allocate buffers when //entering// the recursive call to the predecessor(s), rather we have to wait until we are about to return from the downcall chain.
+Besides, these considerations also show we need a means of passing on the current buffer usage pattern while calling down. This usage pattern not only includes a record of what buffers are occupied, but also the intended use of these occupied buffers, especially if they can be modified in-place, and at which point they may be released and reused.
+__note__: this process outlined here and below is still an simplification. The actual implementation has some additional [[details to care for|RenderImplDetails]]
+
+!!Example: calculating a 3 node chain
+# Caller invokes calculation by pulling from exit node, providing the top-level StateProxy
+# node1 (exit node) builds StateAdapter and calls retrieve() on it to get the desired output result
+# this StateAdapter (ad1) knows he could get the result from Cache, so he tries, but it's a miss
+# thus he pulls from the predecessor node2 according to the [[input descriptor|ProcNodeInputDescriptor]] of node1
+# node2 builds its StateAdapter and calls retrieve()
+# but because StateAdapter (ad2) is configured to directly forward the call down (no caching), it pulls from node3
+# node3 builds its StateAdapter and calls retrieve()
+# this StateAdapter (ad3) is configured to look into the Cache...
+# this time producing a Cache hit
+# now StateAdapter ad2 has input data, but needs a output buffer location, which re requests from its //parent state// (ad1)
+# and, because ad1 is configured for Caching and is "in-place" capable, it's clear that this output buffer will be located within the cache
+# thus the allocation request is forwarded to the cache, which provides a new "slot"
+# now node2 has both a valid input and a usable output buffer, thus the process function can be invoked
+# and after the result has been rendered into the output buffer, the input is no longer needed
+# and can be "unlocked" in the Cache
+# now the input data for node1 is available, and as node1 is in-place-capable, no further buffer allocation is necessary prior to calculating
+# the finished result is now in the buffer (which happens to be also the input buffer and is actually located within the Cache)
+# thus it can be marked as ready for the Cache, which may now provide it to other processes (but isn't allowed to overwrite it)
+# finally, when the caller is done with the data, it signalles this to the top-level State object
+# which forwards this information to the cache, which in turn may now do with the released Buffer as he sees fit.
+[img[uml/fig132229.png]]
+
+@@clear(right):display(block):@@
+__see also__
+&rarr; the [[Entities involved in Rendering|RenderEntities]]
+&rarr; additional [[implementation details|RenderImplDetails]]
+&rarr; [[Memory management for render nodes|ManagementRenderNodes]]
+&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
+
    
+
    
+
    
+
    For each segment (of the effective timeline), there is a Processor holding the exit node(s) of a processing network, which is a "Directed Acyclic Graph" of small, preconfigured, stateless [[processing nodes|ProcNode]]. This network is operated according to the ''pull principle'', meaning that the rendering is just initiated by "pulling" output from the exit node, causing a cascade of recursive downcalls. Each node knows its predecessor(s) an can pull the necessary input from there. Consequently, there is no centralized "engine object" which may invoke nodes iteratively or table driven &mdash; rather, the rendering can be seen as a passive service provided for the backend, which may pull from the exit nodes at any time, in any order (?), and possibly multithreaded.
+All State necessary for a given calculation process is encapsulated and accessible by a StateProxy object, which can be seen as the representation of "the process". At the same time, this proxy provides the buffers holding data to be processed and acts as a gateway to the backend to handle the communication with the Cache. In addition to this //top-level State,// each calculation step includes a small [[state adapter object|StateAdapter]] (stack allocated), which is pre-configured by the builder and serves the purpose to isolate the processing function from the detals of buffer management.
+
+
+__see also__
+&rarr; the [[Entities involved in Rendering|RenderEntities]]
+&rarr; the [[mechanics of rendering and buffer management|RenderMechanics]]
+&rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
+
    
+
    
+
    
+
    The rendering of input sources to the desired output ports happens within the &raquo;''Render Engine''&laquo;, which can be seen as a collaboration of Proc-Layer, Backend together with external/library code for the actual data manipulation. In preparation of the RenderProcess, the [[Builder]] as wired up a network of [[processing nodes|ProcNode]] called the ''low-level model'' (in contrast to the high-level model of objects placed within the EDL/Session). Generally, this network is a "Directed Acyclic Graph" starting at the //exit nodes// (output ports) and pointing down to the //source readers.// In Lumiera, rendering is organized according to the ''pull principle'': when a specific frame of rendered data is requested from an exit node, a recursive calldown happens, as each node asks his predecessor(s) for the necessary input frame(s). This may include pulling frames from various input sources and for several time points, thus pull rendering is more powerful (but also more difficult to understand) than push rendering, where the process would start out with a given source frame.
+
+Rendering can be seen as a passive service available to the Backend, which remains in charge what to render and when. Render processes may be running in parallel without any limitations. All of the storage and data management falls into the realm of the Backend. The render nodes themselves are ''completely stateless'' &mdash; if some state is necessary for carrying out the calculations, the backend will provide a //state frame// in addition to the data frames.
    
+
    
 
    
 
    The Session contains all informations, state and objects to be edited by the User. From a users view, the Session is synonymous to the //current Project//. 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]]. &rarr; [[Session design overview|SessionOverview]]
 
@@ -3059,11 +3247,39 @@ if (oldText.indexOf("SplashScreen")==-1)
 }
 //}}}
    
 
    
-
    
+
    
+
    A small (in terms of storage) and specifically configured StateProxy object which is created on the stack for each individual {{{pull()}}} call. The actual type of this object is composed out of several building blocks (policy classes) and placed by the builder as a template parameter on the WiringDescriptor of the individual ProcNode. This happens in the WiringFactory in file {{{nodewiring.cpp}}}, which consequently contains all the possible combinations (pre)generated at compile time.
+
+!building blocks
+* ''Caching'': whether the result frames of this processing step will be communicated to the Cache and thus could be fetched from there instead of actually calculating them.
+* ''Process'': whether this node does any calculations on it's own or just pulls from a source
+* ''Inplace'': whether this node is capable of processing the result "in-place", thereby overwriting the input buffer
+* ''Multiout'': whether this node produces multiple output channels/frames in one processing step
+
+!!implementation
+!!!!Caching
+When a node participates in ''caching'', a result frame may be pulled immediately from cache instead of calculating it. Moreover, //any output buffer//&nbsp; of this node will be allocated //within the cache.// Consequently, caching interferes with the ability of the next node to calculate "in-Place". In the other case, when ''not using the cache'', the {{{pull()}}} call immediately starts out with calling down to the predecessor nodes, and the allocation of output buffer(s) is always delegated to the parent state (i.e. the StateProxy pulling results from this node). 
+
+Generally, buffer allocation requests from predecessor nodes (while being pulled by this node) will either be satisfied by using the "current state", or treated as if they were our own output buffers when this node is in-Place capable.
+
+!!!!Multiple Outputs
+Some simplifications are possible in the default case of a node producing just ''one single output'' stream. Otherwise, we'd have to allocate multiple output buffers, and then, after processing, select the one needed as a result and deallocate the superfluous further buffers.
+
+!!!!in-Place capability
+If a node is capable of calculating the result by ''modifying it's input'' buffer(s), an important performance optimization is possible, because in a chain of in-place capable nodes, we don't need any buffer allocations. But, on the other hand, this optimization may collide with the caching, because a frame retrieved from cache must not be modified.
+Without this optimization, in the base case each processing needs an input and an output. Exceptionally, we could think of special nodes which //require// to process in-place, in which case we'd need to provide a copy of the input buffer to work on under certain circumstances. 
+
+!!!!Processing
+If ''not processing'' we don't have any input buffers, instead we get our output buffers from an external source.
+Otherwise, in the default case of actually ''processing'' out output, we have to organize input buffers, allocate output buffers, call the {{{process()}}} function of the WiringDescriptor and finally release the input buffers.
+
    
+
    
+
    
 
    An Object representing a //Render Process// and containing associated state information.
 * it is created in the Controller subsystem while initiating the BuildProcess
 * it is passed on to the generated Render Engine, which in turn passes it down to the individual Processors
 * moreover, it contains methods to communicate with other state relevant parts of the system, thereby shielding the rendering code from any complexities of Thread communication if necessary. (thus the name Proxy)
+* in a future version, it may also encapsulate the communication in a distributed render farm
 
    
 
    
 
    
@@ -3263,8 +3479,8 @@ h1,h2,h3,h4,h5,h6 {
 /*}}}*/
 
    
 
    
-
    
-
    <<timeline better:true maxDays:55 maxEntries:30>>
    
+
    
+
    <<timeline better:true maxDays:55 maxEntries:45>>
    
 
    
 
    
 
    /***
@@ -4330,12 +4546,12 @@ Placements are __resolved__ resulting in an ExplicitPlacement. In most cases thi
 &rarr; [[Definition|Pipe]] and [[handling of Pipes|PipeHandling]]
 
    
 
    
-
    
+
    
 
    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
 * temporal coordinates (time, length)
-* some control data connection to a ParamProvider, because in the most general case the controling curves are treated like automation
+* some control data connection to a ParamProvider, because in the most general case the controling curves are treated similar to  [[automation data|AutomationData]]
 
 !!!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 destination before and after the transition (with regards to the timeline), i.e. the inputs and the transition share placement to the same output pipe. In this case, when the transition starts, the direct connections can be suspended and the transition will switch in seamlessly.
@@ -4345,10 +4561,10 @@ 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 "simple" 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]])
 
    
 
    
-
    
+
    
 
    A ''~Meta-Clip'' or ''Virtual Clip'' (both are synonymous) denotes a clip which doesn't just pull media streams out of a source media asset, but rather provides the results of rendering a complete sub-network. In all other respects it behaves exactly like a "real" clip, i.e. it has [[source ports|ClipSourcePort]], can have attached effects (thus forming a local render pipe) and can be placed and combined with other clips. Depending on what is wired to the source ports, we get two flavours:
-* a __placeholder clip__ has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
-* a __nested EDL__ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, you'd also [[configure the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
+* a __placeholder clip__; has no "embedded" content. Rather, by virtue of placements and wiring requests, the output of some other pipe somewhere in the session will be wired to the clip's source ports. Thus, pulling data from this clip will effectively pull from these source pipes wired to it.
+* a __nested EDL __ is like the other ~EDLs in the Session, just that any missing placement properties will be derived from the Virtual Clip, which is thought as to "contain" the objects of the nested EDL. Typically, you'd also [[configure the tracks|TrackHandling]] of the "inner" EDL such as to connect any output to the source ports of the Virtual Clip.
 
 Like any "real" clip, Virtual Clips have a start offset and a length, which will simply translate into an offset of the frame number pulled from the Virtual Clip's source connection or embedded EDL, making it possible to cut, splice, trim and roll them as usual. This of course implies we can have several instances of the same virtual clip with different start offset and length placed differently. The only limitation is that we can't handle cyclic dependencies for pulling data (which has to be detected and flagged as an error by the builder)
 
    
@@ -4399,7 +4615,7 @@ generally speaking, visitors are preferable when the underlying element type hie
 To see an simple example of our "visiting tool", have a look at {{{tests/components/common/visitingtooltest.cpp}}}
 
    
 
    
-
    
+
    
 
    The Intention of this text is to help you understanding the design and to show some notable details.
 
 !!!!Starting Point
@@ -4420,7 +4636,7 @@ This design strives to build each level and subsystem around some central concep
 * albeit being a special form of a Placement, the ExplicitPlacement is treated as a separate concept. With respect to edit operations within the EDL, it can stand for any sort of Placement. On the other hand the Builder takes a list of ~ExplicitPlacements as input for building up the Render Engine(s). This corresponds to the fact that the render process needs to organize the things to be done on a simple two dimensional grid of (output channel / time). The (extended) contract of an ~ExplicitPlacement provides us with this (output,time).
 * on the lower end of the builder, everything is organized around the Concept of a ProcNode, which enables us to //pull// one (freely addressable) Frame of calculated data. Further, the ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
 * the various types of data to be processed are abstracted away under the notion of a [[Frame]]. Basically, a Frame is an Buffer containing an Array of raw data and it can be located by some generic scheme, including (at least) the absolute starting time (and probably some type or channel id).
-* All sorts of (target domain) [[Parameters]] are treated uniformly. There is a distinction between Parameters (which //could// be variable) and Configuration (which is considered to be fixed). In this context, Automation just appears as a special kind of ParamProvider.
+* All sorts of (target domain) [[parameters|Parameter]] are treated uniformly. There is a distinction between Parameters (which //could// be variable) and Configuration (which is considered to be fixed). In this context, [[Automation]] just appears as a special kind of ParamProvider.
 * and finally, the calculation //process// together with its current state is represented by a StateProxy. I call this a "proxy", because it should encapsulate and hide all tedious details of communication, be it even asynchronous communication with some Controller or Dispatcher running in another Thread. In order to maintain a view on the current state of the render process, it could eventually be necessary to register as an observer somewhere or to send notifications to other parts of the system.
 
 !!!!Handling Diversity
@@ -4433,6 +4649,14 @@ In case it's not already clear: we don't have "the" Render Engine, rat
 The &raquo;current setup&laquo; of the objects in the EDL is sort of a global state. Same holds true for the Controller, as the Engine can be at playback, it can run a background render or scrub single frames. But the whole complicated subsystem of the Builder and one given Render Engine configuration can be made ''stateless''. As a benefit of this we can run this subsystems multi-threaded without the need of any precautions (locking, synchronizing). Because all state information is just passed in as function parameters and lives in local variables on the stack, or is contained in the StateProxy which represents the given render //process// and is passed down as function parameter as well. (note: I use the term "stateless" in the usual, slightly relaxed manner; of course there are some configuration values contained in instance variables of the objects carrying out the calculations, but this values are considered to be constant over the course of the object usage).
 
    
 
    
+
    
+
    The purpose of automation is to vary a parameter of some data processing instance in the course of time while rendering. Thus, automation encompasses all the variability within the render network //which is not a structural change.//
+
+
+!Parameters and Automation
+
+[[Automation]] is treated as a function over time. Everything beyond this definition is considered an implementation detail of the [[parameter provider|ParamProvider]] used to yield the value. Thus automation is closely tied to the concept of a [[Parameter]], which also plays an important role in the communication with the GUI and while [[setting up and wiring the render nodes|BuildRenderNode]] in the course of the build process (&rarr; see [[tag:Builder|Builder]])
    
+
    OperationClassDescription
    allocateBufferState
    applyBuildable
    applyVisitable
    buildAssembler
    currEDLSessionThe EDL currently in focus. In most cases, Session and EDL are almost the same, just EDL emphasizes the collection aspect. But generally (for larger editing projects) one Session can contain several EDLs, which may even be nested. At any given time, only one of these EDLs has focus and recieves the editing commands.
    dispatchOpVisitable
    enableAssetchange the enabled status of this asset. Note the corresponding #isActive predicate may depend on the enablement status of parent assets as well
    fetchState
    findTypeHandler
    getAppconfigaccess the configuation value for a given key.
    @return empty string for unknown keys, else the corresponding configuration value
    get_reprAllocation
    getValueParamProvider
    howtoProcMedia@return descriptor how to build a render pipeline corresponding to this media
    isActiveAssetweather this asset is swithced on and consequently included in the fixture and participates in rendering
    isCalculatedState
    knownAssetManager@return true if the given id is registered in the internal asset DB
    loadSessManagerreplace the current session by a new
    session loaded from serialized state.
    makeTypeHandler
    playRenderEngineTODO: will probably be handled differently (see Cehteh)
    processProcNode
    pullProcNode
    releaseBufferState
    removeAssetManagerremove the given asset <i>together with all its dependants</i> from the internal DB
    resetSessManagerreset all session config and
    start with a pristine default session.
    resolvePlacementcreate an actual (explicit) placement while trying to satisfy the network of adjacent objects and placements.
    resolveQueryHandler
    resolveQueryHandlerImpl
    retrieveStateAdapter
    rootCauseErrorIf this exception was caused by a chain of further exceptions,
    return the first one registered in this throw sequence.
    This works only, if every exceptions thrown as a consequence
    of another exception is propperly constructed by passing
    the original exception to the constructor
    saveSessManagercreate a complete, serialized representation
    of the current session config and contents.
    @todo how to serialize, prameters, return value?
    treatApplicable
    treatBuilderToolThis operation is to be overloaded for the specific MObject subclasses to be treated.
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatNodeCreatorTool
    treatSegmentationTool
    treatSegmentationTool
    treatSegmentationTool
    treatSegmentationTool
    useFileFileProviderAnnounces that the application intends to use this file with mode (READ|WRITE|READWRITE)
    useTemporaryStorageFileProviderProvides a pool for interminate frames
    whatError