Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
103 lines
4 KiB
Text
103 lines
4 KiB
Text
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Idea_
|
|
|*Date* | _2008-03-06_
|
|
|*Proposed by* | Ichthyostega
|
|
|====================================
|
|
|
|
|
|
Design the handling of Parameters and Automation
|
|
------------------------------------------------
|
|
Parameters of Plugin Components and/or Render Nodes play a role at various
|
|
levels of the application.
|
|
Thus it seems reasonable to do a formal requirements analysis and design prior
|
|
to coding.
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
Regarding components directly participating in the render (which might be
|
|
implemented by plugins), we distinguish between *configuration* (static) and
|
|
*parameters* (dynamic). The point of reference for this distinction is the
|
|
render process: a plugin configuration may well be variable in some manner,
|
|
e.g. the plugin may provide different flavours of the same algorithm. But this
|
|
choice has to be fixed prior to feeding the corresponding plugin asset to the
|
|
builder. Contrary to such fixed configuration setup, the _parameters_ are
|
|
considered to be _variable_ during the rendering process. They can be changed
|
|
on-the-fly from GUI, and they may be automated. Probably, each Render Node will
|
|
have at least one such _parameter_ -- namely a bypass switch.
|
|
|
|
|
|
Tasks
|
|
^^^^^
|
|
|
|
* we need to work out an introspection mechanism for parameters
|
|
- asses what different types of parameters we need
|
|
- find out how much structured parameters will be (do simple values suffice?)
|
|
- define how parameters can be discovered/enumerated
|
|
- define a naming scheme for parameters, so they can be addressed
|
|
unambiguously
|
|
* value parameters have a value range. Work out how to handle this
|
|
* parameters may need a specific presentation in the GUI
|
|
- linear/logarithmic scale, scale reference
|
|
- selecting the right widget
|
|
|
|
So...
|
|
|
|
. find out to which extent we need these properties
|
|
. find out what parts of the App will have what requirements?
|
|
. chose a best fitting implementation based on this information
|
|
|
|
A closely related issue is the handling of *Automation*. The current draft
|
|
calls for an abstract interface `ParamProvider`, which just allows the
|
|
Plugin or RenderComponent to pull a current value, without knowing if the
|
|
`ParamProvider` is a GUI widget or an automation data set with interpolation.
|
|
The component using the param value should not need to do any interpolation.
|
|
We should re-asses and refine this draft as needed. Note: Render Nodes are
|
|
stateless; this creates some tricky situations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alternatives
|
|
^^^^^^^^^^^^
|
|
?? (any ideas?)
|
|
|
|
One alternative would be _not to recognise_ that this is a problematic requirement,
|
|
and just to hack away and ``solve'' each obstacle in an ad-hoc manner.
|
|
Unfortunately I'm unable to take this ``alternative'' seriously.
|
|
|
|
Another approach could be to reject the idea of ``parameters'' being _something special_
|
|
and rather to treat them as some kind of _different medium_ -- which would subject
|
|
a _parameter stream_ to pull-processing. This seems to be an interesting angle, since
|
|
going that route would remove the topic of parameters and automation from the core
|
|
render engine altogether. However, I am not _bold enough_ to embrace this approach
|
|
as a solution -- since I can not see to what extent such a shift would _actually_
|
|
change anything of the actual functionality to be implemented or remove any overhead.
|
|
|
|
Ichthyostega:: '2025-09-10'
|
|
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
The rationale of this RfC is to conduct some requirement analysis before the
|
|
point where the aforementioned features will actually be required to continue
|
|
with the coding work. In an ideal world, such analysis would be carried out
|
|
in parallel by someone knowledgeable enough to recognise the difficulties.
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
This seems to be one of those nasty features which do not garner any engagement
|
|
nor spur any creativity. At some point you'll just happen to need it, and then,
|
|
I'm afraid the analysis and planning work will incur significant delay...
|
|
|
|
Ichthyostega:: '2025-09-10'
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|