Commit graph

10 commits

Author SHA1 Message Date
6207f475eb Invocation: define aspects of ProcID to cover
Building a correct processing-identification is a complex and challenging task; only some aspects can be targeted and implemented right now, as part of the »Playback Vertical Slice«
 * components of the ProcID
 * parsing the argument-spec
 * dispatch of detail information function to retrieve source ports
2025-01-11 17:05:53 +01:00
1aae4fdcdd Invocation: build complex Node tree ... ideas for verification
* this changeset builds a complex processing network for the first time
 * furthermore, some ideas towards verification are spelled out

''verification not implemented''
2025-01-08 17:39:38 +01:00
806db414dd Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
 * there is no entity "Lumiera.org" which holds any copyrights
 * Lumiera source code is provided under the GPL Version 2+

== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''

The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!

The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
a84dbd7bfb Invocation: develop an abbreviated node spec
showing the Node-symbol and a reduced rendering of
either the predecessor or a collection of source nodes.

For this we need functionality to traverse the node graph depth-first
and collect all leaf nodes (which are the source nodes without predecessor);
such can be implemented with the help of the expandAll() functionality
of `lib::IterExplorer`. In addition we need to collect, sort and deduplicate
all the source-node specs; since this is a common requirement, a new
convenience builder was added to `lib::IterExplorer`
2024-11-05 03:56:38 +01:00
85e2966975 Invocation: implement deduplication of spec strings
* verify hash and identity of the generated `ProcID` records
 * also verify format of the generated Proc-Spec for a `Turnout`
2024-11-04 03:14:41 +01:00
53ac1911e7 Invocation: render a processing-spec for a port 2024-11-04 02:02:58 +01:00
5df93f01fc Invocation: pass symbolic spec through the node builder
...taking into account the prospecive usage context
where the builder expressions will be invoked from within
a media-library plug-in, using std::string_view to pass
the symbolic information seems like a good fit, because
the given spec will typically be assembled from some
building blocks, and thus in itself not be literal data.
2024-11-03 22:55:06 +01:00
4b6d812578 Invocation: provide access to a deduplicated ProcID
...as follow-up to yesterday's decisions
 - each Port will just feature a (stable) reference to a ProcID record
 - which is deduplicated and likewise refers to deduplicated symbolic tags
 - and further spec and hash values are computed on-demand by this entity

__Note__: all functionality belonging to the ''Builder'' can be assumed to run **non-concurrent**
2024-11-03 21:03:34 +01:00
f8642b3459 Invocation: consider how to establish a stable cache key
Building a precise Frame Cache is a tough job, and is doomed to fail
when attempting to tie cache invalidation to state changes. The only
viable path is to create a system of systematic tagging of processing
steps, and use this as foundation for chained hash values, linked
in accordance to the actual processing structure.

This is complicated by the secondary concern of maintaining memory efficacy
for the render node model, which can be expected to grow to massive scale.
And even while this invocation can not be fully devised right now,
an attempt can be made to build a foundation that is not outright
wasteful, by detaching the logical information from the specific
weaving pattern used for implementation, and by minimising the
representation in memory and computing the compound information
on-demand....
2024-11-03 03:06:54 +01:00
9f233f1e90 Invocation: Detail-planning of node invocation
* consider which operations to provide where
 * collect components to be built for a basic node wiring
 * define an entrance point for node invocation
2024-06-23 19:40:43 +02:00