benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: Analysis regarding node and turnout identity

Browse source 
The immediate next goal is to verify properties of render nodes
generated by the builder framework; two kinds of validations
can be distinguished
 * structural aspects of the wiring
 * the fact that processing functionality is invoked in proper order

Looking into the structural aspects brings about the necessity
to identify the actual processing function bound into some functor.
Some recapitulation of goals and requirements revealed, that this
can not be a merely technical identity record — because the intention
is to base the ''cache key'' on chained processing node identities,
so that the key is stable as long as the user-visible results will be
equivalent. And while structural data can be aggregated, at the
core this information must be provided by the scheme embedded
into the domain ontology, which is tasked with invoking the
builder in order to implement a ''specific processing-asset''
This commit is contained in:
Fischlurch 2024-10-31 23:50:59 +01:00
parent 9022a69a71
commit aab8278579
7 changed files with 279 additions and 82 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/steam/engine/node-builder.hpp
View file

@ -93,6 +93,7 @@
#include "lib/error.hpp"
#include "lib/symbol.hpp"
#include "lib/nocopy.hpp"
#include "steam/engine/weaving-pattern-builder.hpp"
#include "steam/engine/proc-node.hpp"
@ -110,6 +111,7 @@ namespace steam {
namespace engine {
namespace err = lumiera::error;
using lib::Literal;
using util::_Fmt;
using std::forward;
using std::move;
@ -245,7 +247,7 @@ namespace engine {
/** setup standard wiring to adapt the given processing function.
* @return a PortBuilder specialised to wrap the given \a FUN */
template<typename FUN>
auto invoke (FUN fun);
auto invoke (Literal qualifier, FUN fun);
/** specify an `InvocationAdapter` to use explicitly. */
template<class ADA, typename...ARGS>
@ -373,9 +375,9 @@ namespace engine {
private:
template<typename FUN>
PortBuilder(_Par&& base, FUN&& fun)
PortBuilder(_Par&& base, FUN&& fun, Literal qualifier)
: _Par{move(base)}
, weavingBuilder_{forward<FUN> (fun), _Par::leads_.policyConnect()}
, weavingBuilder_{forward<FUN> (fun), qualifier, _Par::leads_.policyConnect()}
, defaultPort_{_Par::patternData_.size()}
{ }
@ -384,6 +386,7 @@ namespace engine {
/**
* @param qualifier a semantic distinction of the implementation function
* @param fun invocation of the actual _data processing operation._
* @remarks
* - a _»weaving pattern«_ is applied for the actual implementation, which amounts
@ -406,10 +409,10 @@ namespace engine {
template<class POL, class DAT>
template<typename FUN>
auto
PortBuilderRoot<POL,DAT>::invoke (FUN fun)
PortBuilderRoot<POL,DAT>::invoke (Literal qualifier, FUN fun)
{
using WeavingBuilder_FUN = WeavingBuilder<POL, manifoldSiz<FUN>(), FUN>;
return PortBuilder<POL,DAT, WeavingBuilder_FUN>{move(*this), move(fun)};
return PortBuilder<POL,DAT, WeavingBuilder_FUN>{move(*this), move(fun), qualifier};
}
/*
template<class POL>

6
src/steam/engine/weaving-pattern-builder.hpp
View file

@ -101,6 +101,7 @@
//#include "steam/common.hpp"
#include "lib/error.hpp"
#include "lib/symbol.hpp"
//#include "steam/engine/channel-descriptor.hpp"
//#include "vault/gear/job.h"
#include "lib/several-builder.hpp"
@ -127,6 +128,7 @@ namespace engine {
namespace err = lumiera::error;
using std::forward;
using lib::Literal;
using lib::Several;
using lib::Depend;
using util::_Fmt;
@ -376,11 +378,13 @@ namespace engine {
Depend<EngineCtx> ctx;
Literal qualifier_;
FUN fun_;
template<typename...INIT>
WeavingBuilder(FUN&& init, INIT&& ...alloInit)
WeavingBuilder(FUN&& init, Literal qual, INIT&& ...alloInit)
: leadPorts{forward<INIT> (alloInit)...}
, qualifier_{qual}
, fun_{move(init)}
{ }

2
tests/core/steam/engine/node-linkage-test.cpp
View file

@ -73,7 +73,7 @@ namespace test {
{
auto con = prepareNode()
.preparePort()
.invoke(dummyOp)
.invoke(TEST_DUMMY, dummyOp)
.completePort()
.build();
CHECK (isnil (con.leads));

51
tests/core/steam/engine/test-rand-ontology.cpp Normal file
View file

@ -0,0 +1,51 @@
/*
TestRandOntoloy - implementation of a test framework processing dummy data frames
Copyright (C) Lumiera.org
2024, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* *****************************************************/
/** @file test-rand-ontology.cpp
** Implementation of fake data processing to verify invocation logic.
*/
#include "steam/engine/test-rand-ontology.hpp"
#include "lib/error.hpp"
//#include <vector>
namespace steam {
namespace engine{
namespace test {
// namespace err = lumiera::error;
namespace { // hidden local support facilities....
} // (End) hidden impl details
Literal TEST_DUMMY{"Test-Dummy"};
}}} // namespace steam::engine::test

8
tests/core/steam/engine/test-rand-ontology.hpp
View file

@ -20,7 +20,7 @@
*/
/** @file testframe-rand-ontology.hpp
/** @file test-rand-ontology.hpp
** A faked »media calculation« environment to validate the render node network.
*/
@ -29,6 +29,8 @@
#define STEAM_ENGINE_TEST_RAND_ONTOLOGY_H
#include "lib/error.hpp"
#include "lib/symbol.hpp"
#include "steam/engine/testframe.hpp"
#include <array>
@ -38,10 +40,14 @@ namespace steam {
namespace engine{
namespace test {
using lib::Literal;
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Dummy / Placeholder
using NoArg = std::array<char*, 0>;
using SoloArg = std::array<char*, 1>;
extern Literal TEST_DUMMY;
/** @todo a placeholder operation to wire a prototypical render node
*/
inline void

54
wiki/renderengine.html
View file

@ -6391,9 +6391,31 @@ In 2018, the middle Layer was renamed into &amp;rarr; Steam-Layer
</pre>
</div>
<div title="ProcNode" modifier="Ichthyostega" created="200706220409" modified="202407030215" tags="def spec" changecount="5">
<pre>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{⚠ In-depth rework underway as of 7/2024...}}}
<div title="ProcNode" modifier="Ichthyostega" created="200706220409" modified="202410300053" tags="def spec" changecount="22">
<pre>//A data processing node within the Render Engine.// Its key feature is the ability to pull a [[Frame]] of calculated data -- which may involve the invocation of //predecessor nodes// and the evaluation of [[Parameter Providers|ParamProvider]]. Together, those nodes form a »node-network«, a ''D''irected ''A''cyclic ''G''raph (DAG) known as the LowLevelModel, which is //explicit// to the degree that it can be //performed// to generate or process media. As such it is an internal structure and //compiled// by evaluating and interpreting the HighLevelModel within the [[Session]], which is the symbolic or logical representation of »the film edit« or »media product« established and created by the user.
So each node and all interconnections are //oriented.// Calculation starts from the output side and propagates to acquire the necessary inputs, thereby invoking the predecessor nodes (also known as »leads«). This recursive process leads to performing a sequence of calculations -- just to the degree necessary to deliver the desired result. And since the Render Node Network is generated by a compilation step, which is conducted repeatedly and on-demand by the part of the Lumiera application known as the [[Builder]], all node connectivity can be assumed to be adequate and fitting, each predecessor can be assumed to deliver precisely the necessary data into buffers with the correct format to be directly consumed for the current calculation step. The actual processing algorithm working on these buffers is provided by an ''external Media-processing-library'' -- the LowLevelModel can thus be seen as a pre-determined organisation and orchestration structure to enact externally provided processing functionality.
&amp;rarr; [[Description of the render process|RenderProcess]]
!Structure of a Render Node
A {{{steam::engine::ProcNode}}} is an arrangement of descriptors, connectivity and {{{Port}}} objects, residing at a fixed memory location. It holds an //identity record// (the {{{NodeID}}}) and exposes an interface to »pull« and thus invoke calculations, abstracted by a layer of indirection (a virtual method call).
;Lead
:each node holds a (possibly empty) collection of //predecessor nodes// known as »leads« to provide prerequisite source data;
:however, a node can be a //generator// (data producer or data source), in which case it has no leads.
;Port
:while each node offers a single well-delineated functionality, the actual calculation can (optionally) be provided in several flavours or configuration variations typically related to data format. E.g. a sound filtering node can be able to process stereo sound, but also deliver the filtering on the left or right channel in isolation. Or video image processing can be provided to work on various image resolutions, each requiring a different buffer layout. Any such processing variants are exposed as »ports« of the node. Since the node network is pre-canned, individual port entries are only allocated when actually required for currently expected rendering functionality; ports are designated by number, and conceivably in practice many nodes will just expose a single port-#0
;Turnout
:abstracting by virtual call interface, the {{{Turnout}}} instance is the actual implementation of the interface {{{Port}}}. Only at this level the //actual processing function// is known, and the number and arrangement of input- and output-buffers. The Turnout thus encapsulates a »blue print« for the invocation, especially how to retrieve or provide buffers, how to invoke the external library function and where to drop off the result data. Notably the Turnout embeds a sequence of descriptors to designate //which leads// are actually to be pulled in //what sequence// and especially the number of the port to use on each lead node, which obviously varies to accommodate the actual data format requirements.
;Feed Manifold
:when actually invoked, the Turnout creates transient data structures on the call stack, before jumping into recursive invocation of lead ports. A series of input- and output connections is prepared, actually represented as a pointer to some data buffer. The »input slots« are populated with the //result buffers// retrieved from the recursive {{{pull()}}} calls to the lead ports, while the »output slots« are then allocated from a {{{BufferProvider}}} (and will be passed-up the recursive invocation structure when done)
;Invocation Adapter
:each Media-processing-library entails a very specific protocol how to invoke processing functionality, which becomes embedded into an individual adaptor object, including the {{{FeedManifold}}}. Typically, the actual invocation will be bound into a λ-closure, and thus the whole compound can be aggressively optimised.
;Weaving Pattern
:while each processing variant is materialised into an individual {{{Turnout}}} instance, some more generic wiring- and invocation schemes come to play when adapting the processing functions of any given Media-processing-library. The {{{WeavingPattern}}} thus defines a distinct scheme how to arrange and connect inputs and outputs and how to actually invoke the processing function. Notably, some operations allow for in-place processing, where the input-buffer is also the output-buffer and data is directly manipulated in-place, while other libraries require some elaborate layout scheme for the data buffers to work efficiently. And while Lumiera provides a set of //building blocks for weaving patterns,// each Media-processing-library actually must be adapted through a Lumiera plug-in, which entails using those building blocks or even completely different yet compatible weaving patterns as appropriate. In the end, each instantiation of such a weaving pattern becomes embedded into the render node as a {{{Turnout}}} instance and can be invoked through the {{{Port}}} interface.
!Building a Render Node
!The render invocation
{{red{⚠ In-depth rework underway as of 10/2024...}}}
^^┅┅┅┅┅┅the following text is ''superseded''┅┅┅┅┅┅┅┅┅^^
!! {{red{open questions}}}
@ -6937,10 +6959,12 @@ Besides housing the planning pipeline, the RenderDrive is also a JobFunctor for
&amp;rarr; [[Player]]
</pre>
</div>
<div title="RenderEntities" modifier="Ichthyostega" created="200706190715" modified="201812092257" tags="Rendering classes img" changecount="2">
<pre>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 [[Dispatcher|SteamDispatcher]]. 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 {{red{really?? 2018}}}, while at the same time holding the Data Buffers (Frames) for the actual calculations.
<div title="RenderEntities" modifier="Ichthyostega" created="200706190715" modified="202410292339" tags="Rendering classes img" changecount="3">
<pre>{{red{⚠ In-depth rework underway as of 10/2024...}}}
^^┅┅┅┅┅┅the following text is ''superseded''┅┅┅┅┅┅┅┅┅^^
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 [[Dispatcher|SteamDispatcher]]. 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 {{red{really?? 2018}}}, while at the same time holding the Data Buffers (Frames) for the actual calculations.
{{red{Warning: obsolete as of 9/11}}}
{{red{🗲🗲 Warning: what follows is an early draft from 2009, obsoleted by actual plans and development as of 10/2024 🗲🗲}}}
Currently the Render/Playback is beeing targetted for implementation; almost everything in this diagram will be implemented in a slightly differently way....
[img[Entities comprising the Render Engine|uml/fig128389.png]]
</pre>
@ -7154,8 +7178,18 @@ An Activity is //performed// by invoking its {{{activate(now, ctx)}}} function -
In a similar vein, also ''dependency notifications'' need to happen decoupled from the activity chain from which they originate; thus the Post-mechanism is also used for dispatching notifications. Yet notifications are to be treated specially, since they are directed towards a receiver, which in the standard case is a {{{GATE}}}-Activity and will respond by //decrementing its internal latch.// Consequently, notifications will be sent through the ''λ-post'' -- which operationally re-schedules a continuation as a follow-up job. Receiving such a notification may cause the Gate to become opened; in this case the trigger leads to //activation of the chain// hooked behind the Gate, which at some point typically enters into another calculation job. Otherwise, if the latch (in the Gate) is already zero (or the deadline has passed), nothing happens. Thus the implementation of state transition logic ensures the chain behind a Gate can only be //activated once.//
</pre>
</div>
<div title="RenderProcess" modifier="Ichthyostega" created="200706190705" modified="202407030216" tags="Rendering operational" changecount="1">
<pre>{{red{⚠ In-depth rework underway as of 7/2024...}}}
<div title="RenderProcess" modifier="Ichthyostega" created="200706190705" modified="202410300145" tags="Rendering operational" changecount="12">
<pre>At a high level, the Render Process is what „runs“ a playback or render. Using the EngineFaçade, the [[Player]] creates a descriptor for such a process, which notably defines a [[»calculation stream«|CalcStream]] for each individual //data feed// to be produced. To actually implement such an //ongoing stream of timed calculations,// a series of data frames must be produced, for which some source data must be loaded and then individual calculations must be scheduled to work on this data and deliver results within a well defined time window for each frame. Thus, on the implementation level, a {{{CalcStream}}} comprises a pipeline to define [[render jobs|RenderJob]], and a self-repeating re-scheduling mechanism to repeatedly plan and dispatch a //chunk of render jobs// to the [[Scheduler]], which cares to invoke the individual jobs in due time.
This leads to a even more detailed implementation level of the ''render processing''. Within the [[Session]], the user has defined the »edit« or the definition of the media product as an arrangement of media elements placed and arranged into a [[Timeline]]. A repeatedly-running, demand-driven, compiler-like process in Lumiera (known as [[the Builder|Builder]]) consolidates this [[»high-level definition«|HighLevelModel]] into a [[Fixture]] and an directly attached [[network of Render Nodes|LowLevelModel]]. The Fixture hereby defines a [[segment for each part of the timeline|Segmentation]], which can be represented by a single topology of connected render nodes. So each segment spans a time range, quantised into a range of frames -- and the node network attached below this segment is capable of producing media data for each frame within definition range, when given the actual frame number, and some designation of the actual data feed required at that point. Yet it depends on the circumstances what this »data feed« //actually is;// as a rule, anything which can be produced and consumed as compound will be represented as //a single feed.// The typical video will thus comprise a video feed and a stereo sound feed, while another setup may require to deliver individual sound feeds for the left and right channel, or whatever channel layout the sound system has, and it may require two distinct beamer feeds for the two channels of stereoscopic video. However -- as a general rule of architecture -- the Lumiera Render Engine is tasked to perform //all of the processing work,// up to and including all adaptation steps to reach the desired final result. Thus, for rendering into a media container, only a single feed is required, which can be drawn from an encoder node, which in turn consumes several data feeds for its constituents.
To summarise this break-down of the rendering process defined thus far, the [[Scheduler]] ''invokes'' individual [[frame render jobs|RenderJob]], each of which defines a set of »coordinates«:
* an ID of the calculation stream allowing to retrieve the output sink
* a frame number relative to the timeline, encoding a //nominal frame time//
* a specification of the Segment and the ExitNode to pull
{{red{⚠ In-depth rework underway as of 7/2024...}}}
^^┅┅┅┅┅┅the following text is ''superseded''┅┅┅┅┅┅┅┅┅^^
For each segment (of the effective timeline), there is a Processor holding the exit node(s) of a processing network, which is a &quot;Directed Acyclic Graph&quot; of small, preconfigured, stateless [[processing nodes|ProcNode]]. This network is operated according to the ''pull principle'', meaning that the rendering is just initiated by &quot;pulling&quot; output from the exit node, causing a cascade of recursive downcalls or prerequisite calculations to be scheduled as individual [[jobs|RenderJob]]. Each node knows its predecessor(s), thus the necessary input can be pulled from there. Consequently, there is no centralized &quot;engine object&quot; which may invoke nodes iteratively or table driven &amp;mdash; rather, the rendering can be seen as a passive service provided for the Vault, 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 &quot;the process&quot;. At the same time, this proxy provides the buffers holding data to be processed and acts as a gateway to the Vault 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.
@ -7167,10 +7201,10 @@ __see also__
&amp;rarr; the protocol [[how to operate the nodes|NodeOperationProtocol]]
</pre>
</div>
<div title="Rendering" modifier="Ichthyostega" created="200806010248" modified="200806010307" tags="def overview">
<div title="Rendering" modifier="Ichthyostega" created="200806010248" modified="202410292249" tags="def overview" changecount="1">
<pre>The rendering of input sources to the desired output ports happens within the &amp;raquo;''Render Engine''&amp;laquo;, which can be seen as a collaboration of Steam- amd ~Vault-Layer 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 session). Generally, this network is a &quot;Directed Acyclic Graph&quot; 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 Vault, 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 Vault. The render nodes themselves are ''completely stateless'' &amp;mdash; if some state is necessary for carrying out the calculations, the Vault will provide a //state frame// in addition to the data frames.</pre>
Rendering can be seen as a passive service available to the Vault, 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 Vault. The render nodes themselves are ''completely stateless'' -- state is translated into structure or attached at the level of individual invocations in the form of invocation parameters, automation and input data.</pre>
</div>
<div title="ResourceJob" modifier="Ichthyostega" created="201204290102" tags="def Rendering">
<pre>a special kind of [[render job|RenderJob]], used to retrieve input data relying on external IO.

227
wiki/thinkPad.ichthyo.mm
View file

@ -13376,9 +13376,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1519355684307" FOLDED="true" ID="ID_336676610" MODIFIED="1561827482926">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
was <i>ist</i>&#160;der Locator?
@ -13780,9 +13778,7 @@
</node>
<node COLOR="#338800" CREATED="1518762499749" FOLDED="true" ID="ID_214794727" MODIFIED="1561827482927">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Perspective <i>elided</i>
@ -14610,9 +14606,7 @@
</node>
<node CREATED="1529018409007" ID="ID_1460094266" MODIFIED="1529018714798" TEXT="Variante-3b w&#xe4;re nur interessant als eigenst&#xe4;ndige Entit&#xe4;t">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...was <i>bis jetzt</i>&#160;nicht gegeben ist!
@ -16105,9 +16099,7 @@
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1523059593831" ID="ID_1175935224" MODIFIED="1576282358108" TEXT="will mich nicht auf eine Basisklasse festlegen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
model::Tangible ist sch&#246;n,
@ -17938,9 +17930,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn das Kontext-Men&#252; soll auf dem ganzen Widget liegen (und konkurriert &#252;brigens mit der Drag-Geste)
@ -20778,9 +20768,7 @@
<node CREATED="1479678496272" ID="ID_807567871" LINK="file:///home/hiv/devel/lumi/wiki/renderengine.html#GuiTimelineWidgetStructure" MODIFIED="1557498707224" TEXT="Analyse">
<node CREATED="1479678503071" ID="ID_806149006" MODIFIED="1576282358098" TEXT="Grid bringt nix">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Das war zwar schon meine Bauchgef&#252;hl,
@ -26623,9 +26611,7 @@
<node CREATED="1575130722129" ID="ID_1376658524" MODIFIED="1575130746502" TEXT="dieses mu&#xdf; konkret f&#xfc;r die zu bearbeitenden ViewHooks zust&#xe4;ndig sein"/>
<node CREATED="1575130747730" ID="ID_782210944" MODIFIED="1575130767965">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
ViewHooks k&#246;nnen <i>nach Hause telefonieren</i>
@ -48064,9 +48050,7 @@
<node CREATED="1464113740005" ID="ID_1649881726" MODIFIED="1464113748425" TEXT="em&#xf6;glicht Aufr&#xe4;um-Arbeiten"/>
<node CREATED="1464113754412" ID="ID_1095488369" MODIFIED="1575133327061" TEXT="kann NOP implementiert werden">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...in F&#228;llen, in denen der konkrete onion-layer
@ -48616,9 +48600,7 @@
<node CREATED="1456423617763" ID="ID_524247634" MODIFIED="1456423622197" TEXT="wird von der Allokation bestimmt"/>
<node CREATED="1456423642687" ID="ID_1252228590" MODIFIED="1456423660940">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
reflektiert die Zahl der <i>Struktur</i>-Element
@ -49127,9 +49109,7 @@
<node CREATED="1450490467952" ID="ID_1453525628" MODIFIED="1450490480705" TEXT="verwendet zwei GenNode-bindings"/>
<node CREATED="1450490481270" ID="ID_1603770702" MODIFIED="1576282358007" TEXT="fertig implementiert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...was ich einen Monat sp&#228;ter schon wieder vergessen hatte...
@ -49367,9 +49347,7 @@
<node CREATED="1618496127068" ID="ID_1355352407" MODIFIED="1618496134433" TEXT="warum f&#xe4;llt das niemandem auf?"/>
<node CREATED="1618496135139" ID="ID_1442135716" MODIFIED="1618496162854">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Spaltung in <b>Pragmatismus</b>&#160;und <b>Vision</b>
@ -49716,9 +49694,7 @@
<node CREATED="1448070601165" ID="ID_1711137699" MODIFIED="1557498707235" TEXT="Methoden">
<node CREATED="1448407030239" ID="ID_619913132" MODIFIED="1557498707235">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
act, note: Nachricht <i>upstream</i>
@ -57125,8 +57101,7 @@
<b>TestFrame</b>&#160;: verifizierbare Dummy-Berechnungen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<font NAME="SansSerif" SIZE="13"/>
<node CREATED="1729978302935" ID="ID_125813906" MODIFIED="1729978305919" TEXT="Nutzen">
<node CREATED="1729978333588" ID="ID_322770733" MODIFIED="1729978350808">
@ -57137,8 +57112,7 @@
belegen <b>da&#223;</b>&#160;eine Berechnung stattgefunden hat
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1729978316102" ID="ID_206951796" MODIFIED="1729978332808" TEXT="Testen eines Aufruf-Frameworks"/>
</node>
@ -57258,8 +57232,7 @@
es gibt einen fest eingebauten Seed-Mechanismus, der auf der Kanal- und Sequenz-Nummer beruht
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1728777897375" ID="ID_659148718" MODIFIED="1728777958502">
<richcontent TYPE="NODE"><html>
@ -81333,7 +81306,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1720232650869" ID="ID_1972919364" MODIFIED="1720232679870" TEXT="dagegen auf diesem Level-2 hier werden nur noch explizite Einzeltypen konfiguriert"/>
<node CREATED="1720232681738" ID="ID_428670212" MODIFIED="1720232705387" TEXT="und darunter werden nur noch Pointer verarbeitet"/>
</node>
<node CREATED="1720146287602" ID="ID_1218472857" MODIFIED="1720146293047" TEXT="preparePort()">
<node CREATED="1720146287602" ID="ID_1218472857" MODIFIED="1730423775986" TEXT="preparePort()">
<linktarget COLOR="#6f2d5d" DESTINATION="ID_1218472857" ENDARROW="Default" ENDINCLINATION="-296;1367;" ID="Arrow_ID_1837004585" SOURCE="ID_253722349" STARTARROW="None" STARTINCLINATION="552;-1040;"/>
<node CREATED="1720146294771" ID="ID_1809522763" MODIFIED="1720146303963" TEXT="nested Port builder"/>
<node COLOR="#5b280f" CREATED="1719971113760" ID="ID_1114865524" MODIFIED="1728582108404" TEXT="Slot-Anzahl">
<icon BUILTIN="button_cancel"/>
@ -81343,10 +81317,20 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="closed"/>
</node>
</node>
<node CREATED="1719970921342" ID="ID_520256497" MODIFIED="1728586526758" TEXT="invoke(fun)">
<node CREATED="1719970921342" ID="ID_520256497" MODIFIED="1730426651931" TEXT="invoke(qual, fun)">
<arrowlink COLOR="#4a43ba" DESTINATION="ID_1274882287" ENDARROW="Default" ENDINCLINATION="-987;-72;" ID="Arrow_ID_1839790581" STARTARROW="None" STARTINCLINATION="1230;281;"/>
<node CREATED="1728587149140" ID="ID_931734758" MODIFIED="1728587166437" TEXT="bindet den Funktor f&#xfc;r die eigentliche Render-Operation"/>
<node CREATED="1728587167953" HGAP="69" ID="ID_581121579" MODIFIED="1728587192330" TEXT="richtet implizites default-Mapping ein" VSHIFT="-2"/>
<node CREATED="1730426655534" ID="ID_32417212" LINK="#ID_604426019" MODIFIED="1730426873004" TEXT="der Qualifier dient zur eindeutigen semantischen Unterscheidung">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
er wird tats&#228;chlich auf Level-3 gebildet, und besteht zun&#228;chst auf einer inhaltlichen Identifikation des Proc-Asset, dann ggfs. noch einer technischen Differenzierung, welche die Domain-Ontology anh&#228;ngt, sofern die errechneten Ergebnis-Mediendaten dadurch abweichen, und schlie&#223;lich aus der Liste aller Input/Output Stream-Implementierungstypen
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1728587167953" HGAP="61" ID="ID_581121579" MODIFIED="1728587192330" TEXT="richtet implizites default-Mapping ein" VSHIFT="-11"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1719970368235" ID="ID_1051554068" MODIFIED="1728586726004" TEXT="Buffer vorbereiten">
<icon BUILTIN="hourglass"/>
@ -91053,11 +91037,15 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720999408569" ID="ID_253722349" MODIFIED="1729962161501" TEXT="dann aus diesem Konstrukt ein Builder-API ableiten">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720999408569" ID="ID_253722349" MODIFIED="1730423775986" TEXT="dann aus diesem Konstrukt ein Builder-API ableiten">
<arrowlink COLOR="#6f2d5d" DESTINATION="ID_1218472857" ENDARROW="Default" ENDINCLINATION="-296;1367;" ID="Arrow_ID_1837004585" STARTARROW="None" STARTINCLINATION="552;-1040;"/>
<linktarget COLOR="#ff6936" DESTINATION="ID_253722349" ENDARROW="Default" ENDINCLINATION="-884;1900;" ID="Arrow_ID_490205261" SOURCE="ID_642446495" STARTARROW="None" STARTINCLINATION="1078;120;"/>
<icon BUILTIN="flag-yellow"/>
<node CREATED="1719970886798" ID="ID_718917982" MODIFIED="1719970979999" TEXT="createBuffers&lt;ILA&gt;(args....)"/>
<node CREATED="1720178543387" ID="ID_1390316493" MODIFIED="1720178576252" TEXT="adaptInvocation&lt;ADA&gt;">
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1719970886798" ID="ID_718917982" MODIFIED="1730424043445" TEXT="createBuffers&lt;ILA&gt;(args....)">
<icon BUILTIN="hourglass"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1720178543387" ID="ID_1390316493" MODIFIED="1730424031118" TEXT="adaptInvocation&lt;ADA&gt;">
<icon BUILTIN="hourglass"/>
<node CREATED="1720178577432" ID="ID_563185736" MODIFIED="1720178597453" TEXT="ADA &#x2261; Typ der Invocation-Adapter Klasse"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1720999461725" ID="ID_668512282" MODIFIED="1728436131057" TEXT="kl&#xe4;ren: wo/wie wird diese instantiiert?">
<arrowlink COLOR="#8c303b" DESTINATION="ID_1536301470" ENDARROW="Default" ENDINCLINATION="-653;972;" ID="Arrow_ID_1675114658" STARTARROW="None" STARTINCLINATION="373;-24;"/>
@ -91093,6 +91081,16 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node CREATED="1730424032542" ID="ID_311029412" MODIFIED="1730426199407" TEXT="invoke(qual, FUN)">
<node CREATED="1730425989177" ID="ID_1347337581" MODIFIED="1730426088900" TEXT="der qualifier markiert Inhaltliche Eigenschaften">
<linktarget COLOR="#4e40b0" DESTINATION="ID_1347337581" ENDARROW="Default" ENDINCLINATION="-14;74;" ID="Arrow_ID_507591051" SOURCE="ID_162351868" STARTARROW="None" STARTINCLINATION="-4;-31;"/>
<node CREATED="1730426034938" ID="ID_1707661872" MODIFIED="1730426047611" TEXT="...um zu erkennen, wenn der Cache invalidiert wird"/>
<node CREATED="1730426048856" ID="ID_875923873" MODIFIED="1730426056546" TEXT="und auch als Verifikation f&#xfc;r Tests"/>
<node CREATED="1730425828741" ID="ID_1472232983" MODIFIED="1730426454293" TEXT="auf Level-2 lediglich ein Qualifier-Literal notwendig">
<arrowlink COLOR="#3b536f" DESTINATION="ID_1906269130" ENDARROW="Default" ENDINCLINATION="349;0;" ID="Arrow_ID_1942413132" STARTARROW="None" STARTINCLINATION="-709;40;"/>
</node>
</node>
</node>
</node>
</node>
</node>
@ -91145,8 +91143,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1728765067388" ID="ID_1708286207" MODIFIED="1728765109597" TEXT="f&#xfc;r eine Node...">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728765130912" ID="ID_1032840307" MODIFIED="1729986432790" TEXT="die Identit&#xe4;t feststellen k&#xf6;nnen">
<linktarget COLOR="#5e5572" DESTINATION="ID_1032840307" ENDARROW="Default" ENDINCLINATION="-1323;101;" ID="Arrow_ID_1310977916" SOURCE="ID_435456030" STARTARROW="Default" STARTINCLINATION="1366;-77;"/>
<linktarget COLOR="#666a8d" DESTINATION="ID_1032840307" ENDARROW="Default" ENDINCLINATION="312;27;" ID="Arrow_ID_1338984517" SOURCE="ID_1710935234" STARTARROW="None" STARTINCLINATION="158;-13;"/>
<linktarget COLOR="#5e5572" DESTINATION="ID_1032840307" ENDARROW="Default" ENDINCLINATION="-1323;101;" ID="Arrow_ID_1310977916" SOURCE="ID_435456030" STARTARROW="Default" STARTINCLINATION="1366;-77;"/>
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728765172917" ID="ID_33308294" MODIFIED="1728765183676" TEXT="Zahl der Leads und Ports pr&#xfc;fen">
@ -91156,6 +91154,9 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1728769243429" ID="ID_1535113263" MODIFIED="1728769249651" TEXT="f&#xfc;r einen Port...">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728769266173" ID="ID_664281474" MODIFIED="1728769290143" TEXT="die Identit&#xe4;t der gebundenen Funktion feststellen">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1730425962531" ID="ID_162351868" LINK="#ID_1465368594" MODIFIED="1730426145795" TEXT="dies ist eine semantische Identit&#xe4;t">
<arrowlink COLOR="#4e40b0" DESTINATION="ID_1347337581" ENDARROW="Default" ENDINCLINATION="-14;74;" ID="Arrow_ID_507591051" STARTARROW="None" STARTINCLINATION="-4;-31;"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728769319538" ID="ID_1257287659" MODIFIED="1728769363223" TEXT="eine reproduzierbare symbolische Aufruf-Spec erheben">
<icon BUILTIN="flag-yellow"/>
@ -91497,6 +91498,16 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785840998" ID="ID_663732870" MODIFIED="1728785852800" TEXT="Funktions-ID generieren">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1730426912428" ID="ID_1568293923" LINK="#ID_1347337581" MODIFIED="1730426982203" TEXT="tats&#xe4;chlich kann hier einfach der Qualifier aus dem im Turnout durchgereicht werden"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1730427234835" ID="ID_1719129337" MODIFIED="1730427243992" TEXT="diese Information mu&#xdf; durchgef&#xe4;delt werden">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1730427251935" ID="ID_162913631" MODIFIED="1730427287787" TEXT="sie mu&#xdf; im Turnout greifbar sein">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1730427274867" ID="ID_1511400718" MODIFIED="1730427287787" TEXT="also durch den WeavingBuilder durchlaufen">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728785867907" ID="ID_394739045" MODIFIED="1728785872687" TEXT="Spec generieren">
<icon BUILTIN="flag-yellow"/>
@ -91732,15 +91743,79 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719185943913" ID="ID_393811539" MODIFIED="1719185992634" TEXT="was ist die Identit&#xe4;t einer Node?">
<icon BUILTIN="help"/>
<node CREATED="1730424187705" ID="ID_529100852" MODIFIED="1730424340366" TEXT="Gleichheit und Wiederauffinden spielen nur eine untergeordnete Rolle">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...im Grunde ist die Identit&#228;t zun&#228;chst einmal, da&#223; es die Node gibt, da&#223; sie an einer Speicheradresse sitzt; im aktuellen Design ist es jedoch nicht notwendig, die Node anhand der Identit&#228;t finden zu k&#246;nnen, denn man findet sie &#252;ber die Verschaltung auf eine Exit-Node
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1730424347235" ID="ID_1202389221" MODIFIED="1730424362860" TEXT="aber die Identit&#xe4;t mu&#xdf; stabil und reproduzierbar sein">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1730424574342" ID="ID_415297248" MODIFIED="1730424597749" TEXT="stabil genug um den Cache-Key darauf aufzubauen"/>
<node CREATED="1730424602715" ID="ID_1250793796" MODIFIED="1730424617979" TEXT="reproduzierbar auch &#xfc;ber mehrere Builder-L&#xe4;ufe hinweg"/>
</node>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1719186031309" ID="ID_1908240557" MODIFIED="1719186091788" TEXT="kann man die Identit&#xe4;t eines Turnout feststellen?">
<icon BUILTIN="help"/>
<node CREATED="1730424622368" ID="ID_1606715255" MODIFIED="1730424665485" TEXT="ist nicht notwendig an die Node-ID gebunden, wohl aber an die Vorl&#xe4;ufer-Turnouts"/>
<node CREATED="1730424724953" ID="ID_1465368594" MODIFIED="1730424744993" TEXT="mu&#xdf; genau dann abweichen wenn die Berechnung f&#xfc;r den User sichtbar abweicht"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1730424832928" ID="ID_635779650" MODIFIED="1730424849856" TEXT="&#x27f9; kann keine automatische L&#xf6;sung sein">
<icon BUILTIN="yes"/>
<node CREATED="1730424871440" ID="ID_1403973228" MODIFIED="1730425076682" TEXT="denn sie kann nicht allein auf Basis technischer Informationen gew&#xe4;hlt werden">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Rein technische Informationen w&#228;ren z.B. ein Funktions-Symbol im Executable oder Quellcode oder eine Parametersignatur; von solchen Daten kommt man niemals direkt zu einem Urteil &quot;&#228;quivalent f&#252;r den User&quot;
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1730425268920" ID="ID_909157635" MODIFIED="1730425292593" TEXT="es mu&#xdf; der Stream-Implementation-Type f&#xfc;r jeden Input und Output eingehen"/>
<node CREATED="1730425303443" ID="ID_1906269130" MODIFIED="1730426066823" TEXT="diese Infos stammen sogar aus einem h&#xf6;heren Builder-Level">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
mindestens Level-3, denn auf Level-2 gehen wir bereits davon aus, da&#223; Buffer-Typen blindlings passen
</p>
</body>
</html></richcontent>
<linktarget COLOR="#3b536f" DESTINATION="ID_1906269130" ENDARROW="Default" ENDINCLINATION="349;0;" ID="Arrow_ID_1942413132" SOURCE="ID_1472232983" STARTARROW="None" STARTINCLINATION="-709;40;"/>
</node>
</node>
<node CREATED="1730425565641" ID="ID_604426019" MODIFIED="1730425587094" TEXT="zum Bauen ist es nur ein Qualifier">
<icon BUILTIN="idea"/>
<node CREATED="1730425592229" ID="ID_860467437" MODIFIED="1730425601727" TEXT="dieser k&#xf6;nnte Term-Format haben"/>
<node CREATED="1730425603459" ID="ID_1645034941" MODIFIED="1730425876702" TEXT="die konkrete Form wird von Level-3 durchgereicht"/>
<node CREATED="1730425640342" ID="ID_980953176" MODIFIED="1730425779328" TEXT="mit diesem Term wird das Node-Symbol dekoriert"/>
</node>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1720293853511" ID="ID_812742662" MODIFIED="1729984903706" TEXT="wozu brauchen wir die NodeID?">
<linktarget COLOR="#a04a55" DESTINATION="ID_812742662" ENDARROW="Default" ENDINCLINATION="-535;46;" ID="Arrow_ID_1587975762" SOURCE="ID_1542786980" STARTARROW="None" STARTINCLINATION="125;23;"/>
<icon BUILTIN="help"/>
<node CREATED="1714778001228" ID="ID_631143493" MODIFIED="1729985050623" TEXT="geht in einen strukturgebundenen Cache-Key ein">
<arrowlink COLOR="#5c536b" DESTINATION="ID_1999491710" ENDARROW="Default" ENDINCLINATION="-1732;155;" ID="Arrow_ID_1638495806" STARTARROW="None" STARTINCLINATION="944;56;"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1730426487861" HGAP="26" ID="ID_1029554662" MODIFIED="1730426503853" TEXT="Achtung: hier stets lib::Literal verwenden" VSHIFT="9">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1730426506218" ID="ID_1519213018" MODIFIED="1730426514356" TEXT="weil dessen Hash auf der Zeichenkette beruht"/>
<node CREATED="1730426515129" ID="ID_1785519096" MODIFIED="1730426603629" TEXT="lib::Symol stattdessen erzeugt einen Hash aus dem Symbol-Table-Entry">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...und dieser ist zwar global eindeutig, andererseits aber auch implementation-defined und f&#252;r jeden Programmlauf anders
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node CREATED="1729985123726" ID="ID_1784608228" MODIFIED="1729985265663" TEXT="die Node selber tr&#xe4;gt nur den reinen Struktur-Anteil bei">
<richcontent TYPE="NOTE"><html>
@ -91752,6 +91827,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
<node CREATED="1729985279723" ID="ID_1289414475" MODIFIED="1729985284963" TEXT="ihre Vorl&#xe4;ufer"/>
<node CREATED="1730425782228" ID="ID_1571203922" MODIFIED="1730425787280" TEXT="das Node-Symbol">
<node CREATED="1729985298574" ID="ID_374581825" MODIFIED="1729985319433" TEXT="der Kontext (Domain-Ontology) der sie gebaut hat"/>
<node CREATED="1729985326069" ID="ID_277740057" MODIFIED="1729986093675" TEXT="eine (stabile, generische) ID des Proc-Asset, welches sie implementiert">
<richcontent TYPE="NOTE"><html>
@ -91766,6 +91842,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<arrowlink COLOR="#6f4685" DESTINATION="ID_169575397" ENDARROW="Default" ENDINCLINATION="-2831;-132;" ID="Arrow_ID_1915206342" STARTARROW="None" STARTINCLINATION="2041;85;"/>
</node>
</node>
</node>
<node CREATED="1729986148559" ID="ID_521096008" MODIFIED="1729986156049" TEXT="l&#xe4;uft auf eine Entry-ID hinaus">
<node CREATED="1729986157374" ID="ID_457217896" MODIFIED="1729986190097">
<richcontent TYPE="NODE"><html>
@ -91775,8 +91852,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
es sollte eine <i>human-readable</i>-Auspr&#228;gung geben
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1729986233815" ID="ID_435456030" MODIFIED="1729986359464" TEXT="sowie ein (ebenfalls textuelles) Spec-Format">
<arrowlink COLOR="#5e5572" DESTINATION="ID_1032840307" ENDARROW="Default" ENDINCLINATION="-1323;101;" ID="Arrow_ID_1310977916" STARTARROW="Default" STARTINCLINATION="1366;-77;"/>
@ -91880,8 +91956,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Und das ganz bewu&#223;t nur auf Basis eines intuitiven Verst&#228;ndnisses der Anforderungen und API-Strukturen einer in C geschriebenen Media-Handling-Library &#8212; also explizit <i>ohne direkte Analyse konkreter Libraries wie FFmpeg oder GStreamer. </i>Denn mein Ziel ist, zun&#228;chst eine Hohlform zu bekommen, eine Auspr&#228;gung der inneren Anforderungen, aus meinem generellen Verst&#228;ndnis des Sachverhalts, sowie der bisher geschaffenen Implementierung der Render-Nodes. Die entstehende Struktur soll sich zun&#228;chst gradlinig entwickeln k&#246;nnen, und dann erst sp&#228;ter, in weiteren Prototyping-Schritten auf konkrete Anforderungen adapteiert werden.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1729957835172" ID="ID_510878392" MODIFIED="1729962777843" TEXT="doch selbst der Weg dorthin erfordert Prototyping im Detail">
<richcontent TYPE="NOTE"><html>
@ -91891,8 +91966,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Inkrementelles Prototyping schafft mir hier einen Mittelweg zwischen deduktivem top-down-Ansatz und einem induktiven bottom-up-Aufbau; ich gehe aus von einigen, intuitiv gew&#228;hlten Formen in der Mitte des auszuspannenden Raumes und stelle von dort einen ersten Durchgang her. Die Belange der Performance und die Datenstruktur spielen dabei ebenso eine Rolle, wie das Streben nach Klarheit, welches die geschaffene Struktur nachhalltig macht.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<arrowlink COLOR="#ad4f61" DESTINATION="ID_1199569608" ENDARROW="Default" ENDINCLINATION="16;78;" ID="Arrow_ID_1294596979" STARTARROW="None" STARTINCLINATION="229;11;"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1719964416438" ID="ID_860129802" MODIFIED="1729962194929" TEXT="Form und Struktur des Weaving-Patterns" VSHIFT="102">
<arrowlink COLOR="#ff6936" DESTINATION="ID_495934512" ENDARROW="Default" ENDINCLINATION="-884;1900;" ID="Arrow_ID_1128127655" STARTARROW="None" STARTINCLINATION="709;49;"/>
@ -131057,15 +131131,41 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
<node CREATED="1702417443905" ID="ID_1866421635" LINK="https://issues.lumiera.org/tags?ticket=on&amp;q=scheduler" MODIFIED="1702417451493" TEXT="Tag: scheduler "/>
<node CREATED="1702417466861" ID="ID_1157756797" LINK="https://issues.lumiera.org/tags?ticket=on&amp;q=render" MODIFIED="1702417479593" TEXT="Tag: render"/>
</node>
<node CREATED="1702417634936" ID="ID_1386373109" MODIFIED="1702417639795" TEXT="Einstiegspunkte">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1702417728259" ID="ID_59461823" MODIFIED="1702417764767" TEXT="Scheduler-Entwicklung">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1702417634936" ID="ID_1386373109" MODIFIED="1730237958457" TEXT="Einstiegspunkte">
<icon BUILTIN="forward"/>
<node BACKGROUND_COLOR="#dcc6a0" COLOR="#532935" CREATED="1702417728259" ID="ID_59461823" LINK="https://issues.lumiera.org/ticket/1280" MODIFIED="1730237953174">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<u>Scheduler-Entwicklung</u>: #1280 build Scheduler implementation
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1702417736098" ID="ID_1167157478" MODIFIED="1702417764767" TEXT="Engine-Steuerung">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#dcc6a0" COLOR="#532935" CREATED="1702417754512" ID="ID_68212415" LINK="https://issues.lumiera.org/ticket/235" MODIFIED="1730423012845">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<u>Render-Processing</u>: #235 Render/Playback process high-level design
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1702417754512" ID="ID_68212415" MODIFIED="1702417764767" TEXT="Render-Processing">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#dcc6a0" COLOR="#532935" CREATED="1702417736098" ID="ID_1167157478" LINK="https://issues.lumiera.org/ticket/1284" MODIFIED="1730237953172">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<u>Engine-Steuerung</u>: #1284 Render Engine operational control
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#dcc6a0" COLOR="#4d2953" CREATED="1730238113336" ID="ID_1984051383" LINK="https://issues.lumiera.org/ticket/7" MODIFIED="1730238164132" STYLE="fork" TEXT="{ #7 Rendering }">
<edge COLOR="#857486" STYLE="bezier" WIDTH="thin"/>
<font NAME="SansSerif" SIZE="10"/>
</node>
</node>
</node>
@ -132842,8 +132942,7 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
</li>
</ul>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1729986054035" ID="ID_1203183623" MODIFIED="1729986066758" TEXT="mutma&#xdf;lich hier auch Meta-Infos, Beschreibung, Dokumentations-Link"/>
</node>