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

clean-up: comb through the historical pages to fix markup errors

Browse source 
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.
This commit is contained in:
Fischlurch 2025-09-08 04:04:39 +02:00
parent ab2a363653
commit b556d2b770
94 changed files with 2987 additions and 2291 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/design/application/ApplicationStart.txt
View file

@ -98,7 +98,7 @@ within the engine independently, relying on worker jobs and a thread pool.
Initialisation and Lifecycle Initialisation and Lifecycle
---------------------------- ----------------------------
After some discussion,footnote:[See the After some discussion,footnote:[See the
link:{ldoc}/devel/rfc/GlobalInitialization.html[GlobalInitialisation] RfC link:{rfc}/GlobalInitialization.html[GlobalInitialisation] RfC
from spring 2008. In the beginning, we all agreed to ``keep matters simple'' from spring 2008. In the beginning, we all agreed to ``keep matters simple''
and build an `init()` function within one central piece of code everyone knows and build an `init()` function within one central piece of code everyone knows
and hooks into. However, while the outline of the application emerged, there and hooks into. However, while the outline of the application emerged, there

2
doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt
View file

@ -89,7 +89,7 @@ JoelHoldsworth:: '2008-07-22T22:25:58Z'
-- --
* SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better. * SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better.
-- jb [[DateTime(2008-07-21T21:58:48Z)]] -- jb '2008-07-21T21:58:48Z'
- Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps. - Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps.
+ +

2
doc/design/gui/GuiDiscussion/PieMenu.txt
View file

@ -4,7 +4,7 @@ Menu and Shortcuts
:Date: 2008-05-14 :Date: 2008-05-14
link:Lumiera/GuiBrainstorming/MenuAndShortcuts[] should explain most heavily discussed GUI features being related to Lumiera's GUI. This pace is a place where to discuss some of the more controversial GUI features proposed for Lumiera's GUI.
3x3 Menus, Version 1 3x3 Menus, Version 1

48
doc/design/gui/GuiDiscussion/Workspaces.txt
View file

@ -7,7 +7,7 @@ Workspaces
After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces. After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces.
I have my personal preferences, but my thinking is definitely incomplete - I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences. I have my personal preferences, but my thinking is definitely incomplete -- I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences.
Paradigm 1: Super-IDE Style Paradigm 1: Super-IDE Style
@ -18,7 +18,7 @@ The end result would be like getting multiple Xnests of Ion, and bear some simil
This would make sense if the normal workflow would involves many projects, and a lot of inter-project work. This would make sense if the normal workflow would involves many projects, and a lot of inter-project work.
There are some plusses: There are some pluses:
* It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility. * It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility.
@ -48,7 +48,7 @@ joelholdsworths's Conclusion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case. I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case.
I wonder what the proffessional video editors think. Please leave comments. I wonder what the professional video editors think. Please leave comments.
@ -57,48 +57,64 @@ Comments
-------- --------
Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still
I would like to make some execptions from the rule, because I see viable use-cases. I would like to make some exceptions from the rule, because I see viable use-cases.
As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can
include/dock a component from another project. This then becomes a \'real' import which means the first project notes include/dock a component from another project. This then becomes a \'real' import which means the first project notes
"display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and "display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and
gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not
part of project 2's session. Usecases are side by side comparsion and work on 2 or more pojects, arrange timelines for part of project 2's session. Use-cases are side by side comparison and work on 2 or more projects, arrange timelines for
easier drag and drop operations, make this config a project setting (you dont have to open all dependent projects and easier drag and drop operations, make this config a project setting (you don't have to open all dependent projects and
arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another
project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored
in a site-wide project withot timeline, but then you have all your production companies \'default' resources at in a site-wide project without timeline, but then you have all your production companies \'default' resources at
hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or
such for all kinds of previews, even external projects. + such for all kinds of previews, even external projects. +
-- link:ct[] [[DateTime(2009-01-29T03:03:22Z)]]
ct:: '2009-01-29T03:03:22Z'
- Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could - Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could
imagine to do with multiple projects + imagine to do with multiple projects +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:36:08Z)]] +
Ichthyostega:: '2009-01-29T03:36:08Z'
Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned
that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can
then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big
and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to
reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status
of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles, of the window which has focus anyways). And last but not least, the current GDL docks implement their own drag handles,
moving windows around has a big performance problem with some window managers, moving windows shall be the job of the moving windows around has a big performance problem with some window managers, moving windows shall be the job of the
window manager and not the job of the application, the only thing the application may do is hinting positions to the window manager and not the job of the application, the only thing the application may do is hinting positions to the
WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any
extra user experience, instead the user has to learn a new kind of window class. + extra user experience, instead the user has to learn a new kind of window class. +
-- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]]
ct:: '2009-01-29T03:15:03Z'
To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._ To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._
But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications: But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications:
perspectives, freely configurable pannels, multiple top level windows, something like palettes or tiling. perspectives, freely configurable panels, multiple top level windows, something like palettes or tiling.
When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation
don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..." don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..."
and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed. and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed.
I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show) I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show)
According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. + According to my own editing experiences, both film and sound, the ``bringing media into the project''-phase makes only a very small percentage
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]] of the overall time spent with a given project. Initially, after bringing in the raw footage,
for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage
and maybe try out some possible cuts and combinations in a throw-away fashion, just to get a feeling about the material.
Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having
multiple projects opened at the same time). What follows is a long fine tuning and augmenting phase.
So, for me, setting things up so I can work comfortably in a rather focused and limited part of the application could be
more important then exploring multiple projects at the same time. +
Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window (with one exception, that is fatal errors which will block the application until resolved). Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to cinelerra, but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. + Ichthyostega:: '2009-01-29T03:31:54Z'
-- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]]
Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes)
must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window
(with one exception, that is fatal errors which will block the application until resolved).
Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to Cinelerra,
but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log.
ct:: '2009-02-01T09:40:08Z'

2
doc/design/workflow/Verwijlen/FrosconMeeting.txt
View file

@ -21,7 +21,7 @@ Points discussed
---------------- ----------------
We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline], We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline],
as introduced by Final Cut X. as introduced by Final Cut X.
However, our link:{ldoc}/devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)] However, our link:{rfc}/ProcPlacementMetaphor.html[Placement concept (2008)]
which predates FCPX's release,footnote:[Final Cut Pro X was which predates FCPX's release,footnote:[Final Cut Pro X was
link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic
Timeline« is generally considered a novel concept introduced with this update. The initial reception Timeline« is generally considered a novel concept introduced with this update. The initial reception

6
doc/design/workflow/Verwijlen/WorkflowProposals.txt
View file

@ -37,11 +37,11 @@ I've seen different editors using different ways of working.
So if the aim for Lumiera is to be a general purpose video editing application, then we can So if the aim for Lumiera is to be a general purpose video editing application, then we can
not force any specific way of doing things and instead we should support many different not force any specific way of doing things and instead we should support many different
workflows, in other words: provide a platform with possibilities for each editor to make it workflows, in other words: provide a platform with possibilities for each editor to make it
their own (which will arguably be a harder goal to achieve). Instead of a "we know what's their own (which will arguably be a harder goal to achieve). Instead of a ``we know what's
best for you" approach I propose a "smart defaults with many options for configuration" best for you'' approach I propose a ``smart defaults with many options for configuration''
approach. approach.
* A big question is: who is "the user"? We aim to create a tool for professionals, but there are * A big question is: who is »the user«? We aim to create a tool for professionals, but there are
many types of professionals working in entirely different parts of the media industry or in many types of professionals working in entirely different parts of the media industry or in
other fields. In the previous paragraph it was mentioned that different types of content other fields. In the previous paragraph it was mentioned that different types of content
require different types of workflows. How to accommodate all of these different people who require different types of workflows. How to accommodate all of these different people who

41
doc/devel/meeting_summary/2008-02-01.txt
View file

@ -18,24 +18,35 @@ __Participants__
* Velmont * Velmont
Discuss the open points in [Lumiera/DesignProcess] --- do we need this formalism? Discuss the open points in the link:/x/DesignProcess.html[Design Process]
--------------------------------------------------------------------------------- -------------------------------------------------------------------------
At start of the project last summer, Cehteh made a http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process proposal]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue
* proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page. Do we need this formalism? --
* proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings
* "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped. At start of the project last summer, _Cehteh_ made a link:{rfc}/LumieraDesignProcess.html[»Design Process« proposal].
We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions.
One point in the agenda of future meetings will be to work through proposals in the queue.
* proposals in the `Idea' state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page.
* proposals in the `Draft' state are ready for conclusive discussion and will be treated in one of the next meetings
* `Final' proposals are either `Accepted' or `Dropped'. We don't differentiate the latter, but should write a short note why it was dropped.
* if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views * if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views
The development model The development model
--------------------- ---------------------
We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki. We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course)._ Cehteh_ is currently working on a Git web frontend which makes the codebase in the mob-repo web-editable like a wiki.
Will we need a stable version or an official branch? not yet — as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator. Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature — esp. when it fits into the core focus of the project — instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
Ichthyo proposes a new requirement: All devs should ensure the `master' branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator.
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature -- esp. when it fits into the core focus of the project -- instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion. And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion.
Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use. Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use.
We plan to make the discussion about GPL v3 a point on the agenda of the next meeting. We plan to make the discussion about GPL v3 a point on the agenda of the next meeting.
@ -43,11 +54,11 @@ Monthly meetings
---------------- ----------------
* make it thursday, not friday * make it thursday, not friday
* time for now 21:00 GMT — if some (potential) participants have problems with this time, please speak up (maybe alternating times?) * time for now 21:00 GMT -- if some (potential) participants have problems with this time, please speak up (maybe alternating times?)
* write a short status report for each mayor part *prior* to the meeting (saves us time). Maybe add an TODO list there * write a short status report for each mayor part *prior* to the meeting (saves us time). Maybe add an TODO list there
* go through the open issues for the design process drafts * go through the open issues for the design process drafts
* publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the link:TiddlyWiki[] and on pipapo.org * publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the TiddlyWiki and on `pipapo.org`
* News, Protocols and the agenda of the next meeting can be found at link:MonthlyMeetings[this page here] * News, Protocols and the agenda of the next meeting can be found at link:{ldoc}/devel/meeting_summary/index.html[Monthly meetings page]
* next meeting on first Thursday in March (6.3.2008) * next meeting on first Thursday in March (6.3.2008)
@ -71,11 +82,11 @@ Since the render nodes are stateless they can be driven in multiple threads (but
The naming discussion The naming discussion
--------------------- ---------------------
The discussion looks healthy so far... People can add new proposals on the http://www.pipapo.org/pipawiki/Lumiera/Names[pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-) The discussion looks healthy so far... People can add new proposals on the [pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-)
Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being: Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being:
* should not be an existing project * should not be an existing project
* should be "googleable" * should be ``googleable''
* should not be offensive * should not be offensive
* should have one of the free top level domains (.net, .org) * should have one of the free top level domains (.net, .org)
* should be compatible with educational institutions (sorry, no pr0nedit :) * should be compatible with educational institutions (sorry, no pr0nedit :)

143
doc/devel/meeting_summary/2008-03-06.txt
View file

@ -26,8 +26,8 @@ Boilerplate
Organization of this meeting Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* cehteh writes the protocol * _Cehteh_ writes the protocol
* hermanr does chairman * _Hermanr_ does chairman
Leftovers from last meeting Leftovers from last meeting
@ -41,80 +41,93 @@ Go through Ideas and Drafts in design process
Idea: time_handling Idea: time_handling
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[] link:{rfc}/TimeHandling.html[time handling]
Point 1 is superseded by using gavl. Point 1 is superseded by using Gavl.
Points 2 and 3 are still valid. Points 2 and 3 are still valid.
Ichthyo asked gmerlin if there are any problems according gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). Gmerlin acknowledges that he doesnt see any problems. _Ichthyo_ asked _Gmerlin_ if there are any problems according Gavl for the points 2 (position of frames) and 3 (position for keyframes and automation).
_Gmerlin_ acknowledges that he does not see any problems.
Oracle2025 brings interlacing on topic "are you aware that automations and keyframes could/should also apply to fields?". We agree that this must be handled "in interlacing, a frame is a pair of 2 subsequent fields". _Oracle2025_ brings interlacing on topic ``are you aware that automations and keyframes could/should also apply to fields?''.
We agree that this must be handled ``in interlacing, a frame is a pair of 2 subsequent fields''.
Conclusion: Conclusion:: Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting
Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting
Idea: Unit tests in Python Idea: Unit tests in Python
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python[] link:{rfc}/UnitTests_Python.html[RfC: Unit Tests in Python]
We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal. We have a testsuite based on _Cehtehs_ `test.sh` which superseeds this proposal.
Conclusion: Conclusion:: Drop it.
Drop it.
Idea: Todo Lists Idea: Todo Lists
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists[] link:{rfc}/TodoLists.html[Todo Lists] to organise tasks to be done....
This Idea is in a very early state an not yet mature. This idea is in a very early state an not yet mature.
Cehteh explains: "I want something which doesn't need much human care and i want one big \'milestones' thing and a small \'mini-task' thing". Ichthyo refines this as "Roadmap" and "Near time task list". We agree that this shall not be too strict. There are some ideas floating, like adding this things to the testsuite or use the wiki. Ichthyo shows how he uses the tiddlywiki's task macro (http://ichthyostega.de/cin3/wiki/renderengine.html#PlanningNodeCreatorTool[]). He likes it but doubts its usefulness when it is used without guessing the hours/days of work. Cehteh explains: ``I want something which doesn't need much human care and i want one big »milestones«
thing and a small »mini-task« thing''. Ichthyo refines this as »Roadmap« and »Near time task list«.
We agree that this shall not be too strict. There are some ideas floating, like adding this things
to the testsuite or use the wiki. _Ichthyo_ shows how he uses the TiddlyWiki's `task macro`.
He likes it but doubts its usefulness when it is used without guessing the hours/days of work.
Conclusion: Conclusion:: We use the TiddlyWiki task macro thing for now...
We use the Tiddlywiki task macro thing for now.
Draft: CCodingStyleGuide Draft: CCodingStyleGuide
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide[] link:{rfc}/CCodingStyleGuide.html[C-coding style guide]
Ichthyo tells that the discussion on the wiki page made this clear now. Cehteh explains that he uses this style with success for diffrent projects. We make clear that this is meant for C, in C++ we use namespaces. Overall we agree that code shall be self-documenting. _Ichthyo_ tells that the discussion on the wiki page made this clear now.
_Cehteh_ explains that he uses this style with success for different projects.
We make clear that this is meant for C, in C++ we use namespaces.
Overall we agree that code shall be self-documenting.
Conclusion: Conclusion:: Make it final.
Make it final.
Draft: DevelopmentFramework Draft: DevelopmentFramework
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework[] link:{rfc}/DevelopmentFramework.html[Development Framework]
Cehteh explains that he will transfer this propoal to a tiddlywiki covering compatibility guides and dependencies. We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet. _Cehteh_ explains that he will transfer this propoasl to a TiddlyWiki covering compatibility guides and dependencies.
We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet.
A short discussion about build systems came up, we still use autotools and scons in parallel, delaying the decision later. oracle2025 mentioned that scons could be used for development and autotools for release. No decision about that everyone has different opinions. But we agree that it works as is. A short discussion about build systems came up, we still use Autotools and SCons in parallel, delaying the decision later.
_Oracle2025_ mentioned that SCons could be used for development and Autotools for release.
No decision about that everyone has different opinions. But we agree that it works as is.
Conclusion: Conclusion::
Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that. Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that.
Draft: Skills Collection Draft: Skills Collection
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection[] link:{rfc}/SkillsCollection.html[RfC: Collection of Skills]
This might be only useful if there are more developers working on the project. This might be only useful if there are more developers working on the project.
Conclusion: Conclusion::
Leave in draft state for now. Leave in draft state for now.
Draft: Architecture Overview Draft: Architecture Overview
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] link:{rfc}/ArchitectureOverview.html[Architecture Overview]
Ichthyo drawn a diagram showing the planned architecture. Cehteh raises concerns about codecs/plugins/effects in backend. After that there was some discussion about details. Cehteh suggests to place plugins in a extra box, gmerlin suggests that \'plugins' don't fit into the diagram, there should be "filters", "sources",..; Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements. _Ichthyo_ has drawn a diagram to show the planned architecture.
_Cehteh_ raises concerns about codecs/plugins/effects in backend.
After that there was some discussion about details.
_Cehteh_ suggests to place plugins in a extra box, _Gmerlin_ suggests that ``plugins'' don't fit into the diagram,
there should be ``filters'', ``sources'',..;
Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements.
Conclusion: Conclusion::
Good idea, needs some refinements, work in progress. Good idea, needs some refinements, work in progress.
@ -122,47 +135,65 @@ Conclusion:
Call for Design Call for Design
--------------- ---------------
Ichthyo explains that the wants the overall design a bit more formalized. He put this topic on the agenda to remind that we have to work it out in link:DesignProcess[] and already started to make some design proposals. Ichthyo explains that the wants the overall design a bit more formalized.
He put this topic on the agenda to remind that we have to work it out in link:/x/DesignProcess.html[the Design Process]
and already started to make some design proposals.
Conclusion: Conclusion::
Things need to be worked out in link:DesignProcess[], take a look and review it. Things need to be worked out as RfC -- take a look and review it.
Naming Naming
------ ------
Raffa, Velmont, goibhniu and others collected and managed proposed names past weeks which finally ended in a community voting. Results are at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_9fad0d1d10c23d38[] _Raffa_, _Velmont_, _Goibhniu_ and others collected and managed proposed names past weeks which finally ended in a community voting.
Lumiera won, Lumiera.org is free and no one of in this meeting has objections against this name. Velmont offers to register and pay for the lumiera.org domain which will be hosted on our own server (see topic below). Hermanr raises concerns if it is ok when the name is registered on another site and by another person than the server, cehteh explains that he like this distribution where doable and no one other objects. Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. After a short discussion we agree that we use the full name and no abbreviation. We now have to rename the source and the wiki. Anyone renames the sourcecode where he is responsible for. Cehteh will go over the pipapo.org wiki and rename things. Results are at [purple]#<broken-URL>#. The name *Lumiera* won,
"`Lumiera.org`" is free and no one of in this meeting has objections against this name.
_Velmont_ offers to register and pay for the Lumiera.org domain which will be hosted on our own server (see topic below).
_Hermanr_ raises concerns if it is ok when the name is registered on another site and by another person than the server,
_Cehteh_ explains that he like this distribution of responsibilities where doable and no one other objects.
Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds.
After a short discussion we agree that we use the full name and no abbreviation.
We now have to rename the source and the wiki. Anyone renames the source code where he is responsible for.
_Cehteh_ will go over the `pipapo.org` wiki and rename things.
Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co. Finally we express our great thanks to the people who put the efforts into the name selection, thanks _Raffa_, _Velmont_, _Goibhniu_ & co.
Conclusion: Conclusion::
Projectname is Lumiera, we have a lot things to rename. Project name is *Lumiera*, we have a lot things to rename.
Project Server, setup, organization, administration Project Server, setup, organization, administration
--------------------------------------------------- ---------------------------------------------------
Some people gathered together and rented a server at http://www.hetzner.de[hetzner.de] which will host some free project pages and personal sites. Cehteh is the one who signed for the server and officially respobsible for it. Some people gathered together and rented a server at https://www.hetzner.com/[hetzner.de] which will host some free project pages and personal sites.
_Cehteh_ is the one who signed for the server and will be officially responsible for it.
The server is split into isolated \'vservers' which are created as needed. Idea is to work cooperatively to get the best out of its resources. The server is split into isolated »VServers« which are created as needed. Idea is to work cooperatively to get the best out of its resources.
For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. Velmont offered to help with lumiera.org, hermanr takes care of cinelerra.org, raffa will help with maintaining the webpages. oracle2025 will care for developer chroots, build and test environments. cehteh will make a page on pipapo.org which reflects the current server setup http://www.pipapo.org/pipawiki/RootServerSetup[]. There are still a lot jobs to do! For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things.
_Velmont_ offered to help with Lumiera.org, _Hermanr_ takes care of Cinelerra.org, _Raffa_ will help with maintaining the webpages.
_Oracle2025_ will care for developer `chroots`, build and test environments.
_Cehteh_ will make a page on pipapo.org which reflects the current server setup [purple]#<broken-URL>#. There are still a lot jobs to do!
Cehteh asked about how to manage emergency root access on the host/root server when he is unreachable. There where several suggestions between one root key for all who pay for the server to shared key schemes. We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access. _Cehteh_ asked about how to manage emergency root access on the host/root server when he is unreachable.
There where several suggestions between one root key for all who pay for the server to shared key schemes.
We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access.
The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer vserver shared between all developers. Maybe a shared mail server. The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer VServer shared between all developers. Maybe a shared mail server.
Hermanr asked about how to handle distribution of large media files. There was some discussion about bittorrent vs http. We concluded to work that out as needed. _Hermanr_ asked about how to handle distribution of large media files. There was some discussion about Bittorrent vs HTTP. We concluded to work that out as needed.
In the forthcoming discussion about cehteh stresses that "it is a public server, if you place confidential information unencrypted on it, its you fault". Ssh keys shall be kept secret by the users but we can't enforce policies on those. In the forthcoming discussion about security, _Cehteh_ stresses that ``it is a public server, if you place confidential information unencrypted on it, its you fault''.
SSH keys shall be kept secret by the users but we can't enforce policies on those.
Ichthyo asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, cehteh explains that webgit isn't ready yet but should be useable in a few days (pipapo.org will use that too). Velmont suggest a \'real' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org. _Ichthyo_ asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, _Cehteh_ explains that webgit isn't ready yet but should be useble in a few days (pipapo.org will use that too).
_Velmont_ suggest a ``real'' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org.
Hermanr asked Velmont about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things. _Hermanr_ asked _Velmont_ about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things.
Ichthyo asks about keeping the Lumiera project pages on pipapo.org until the server is ready, this is ok. _Ichthyo_ asks about keeping the Lumiera project pages on pipapo.org until the server is ready, _Cehteh_ confirms this is OK.
Conclusions: Conclusions::
We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org. We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org.
@ -170,10 +201,16 @@ Conclusions:
GPL3 pros cons, license rationale GPL3 pros cons, license rationale
--------------------------------- ---------------------------------
Ichthyo and cehteh would like to investigate a license change to GPLv3, neither of us has experience with problems this _Ichthyo_ and _Cehteh_ would like to investigate a license change to GPLv3, neither of us has experience with problems this might raise.
might raise. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. The others here thinking that "GPLv2 or later" would be most-compatible. Gmerlin tells that he uses some "GPLv2 only" mplayer code in gavl which is itself "GPLv2 or later". Cehteh explains that "GPLv2 only" code is a problem, where "GPLv2 or later" is not. Ichthyo raises concerns that the Support library may need to be LGPL, cehteh mentions that it would likely be enough if we only apply that to the plugin-loader. After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses.
The others here thinking that ``GPLv2 or later'' would be most-compatible. _Gmerlin_ tells that he uses some ``GPLv2 only'' MPlayer code in Gavl,
which is itself ``GPLv2 or later''. _Cehteh_ explains that ``GPLv2 only'' code is a problem, where ``GPLv2 or later'' is not.
_Ichthyo_ raises concerns that the Support library may need to be LGPL,
while _Cehteh_ mentions that it would likely be enough if we only apply that to the plugin-loader.
After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses
and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner.
Conclusion: Conclusion::
Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible. Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible.
@ -185,5 +222,5 @@ The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see
Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions. Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions.
Conclusion: Conclusion::
Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed! Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed!

113
doc/devel/meeting_summary/2008-04-03.txt
View file

@ -20,7 +20,7 @@ Boilerplate
Organization of this meeting Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* sakalli writes the protocol, ichthyo will help reviewing it * _sakalli_ writes the protocol, ichthyo will help reviewing it
Recurring Topics Recurring Topics
@ -32,20 +32,25 @@ Call for volunteers
------------------- -------------------
(which tasks are to do, how can we interest people...?) (which tasks are to do, how can we interest people...?)
There was a sense that there are people willing to help but they might need direction or cannot do actual coding. But there is also a lot of tasks that could be done by beginners and non-programmers. These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. Examples of such tasks: There was a sense that there are people willing to help but they might need direction or cannot do actual coding.
But there is also a lot of tasks that could be done by beginners and non-programmers.
These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers.
Examples of such tasks:
* Protocol writing * Protocol writing
* maintaining to do lists and isolating tasks * maintaining to do lists and isolating tasks
* constant code and documentation review * constant code and documentation review
* unit/functional testing * unit/functional testing
* header file "task force" - some fundamentals discussed by the developers on libopenvideo should find their way into basic .h files * header file ``task force'' - some fundamentals discussed by the developers on libopenvideo should find their way into basic `.h` files
* installing and maintaining project tracking and automated builds/tests on the server * installing and maintaining project tracking and automated builds/tests on the server
See http://www.lumiera.org/wiki/todo.html#Tasks[] See [purple]#<URL for a TODO wiki used at that time>#
It was also noted that at current phase some basic development is still needed before we can accommodate a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example. It was also noted that at current phase some basic development is still needed before we can accommodate
a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example.
To make it easier for "beginners" to get aquainted with the program it was decided that one *official Lumiera GIT repository* should be established. To make it easier for ``beginners'' to get acquainted with the program it was decided that
one *official Lumiera GIT repository* should be established. (-> `git://git.lumiera.org/LUMIERA`)
@ -53,7 +58,17 @@ Project announcements/registration
---------------------------------- ----------------------------------
(freshmeat, gnu, etc...) any takers? (freshmeat, gnu, etc...) any takers?
The discussion was about advertising the project on various sites. There were some concerns raised that it is too early to do too much publicity at the moment. That the right time should be shortly before the first public release. But there is also some value in registering to the project in planning/alpha stage to interest people such as prospective coders. It was noted that the http://www.linux.com/feature/126441[article on linux.com] resulted in a lot of people contacting ichthyo and cehteh. http://plot.bek.no/pipermail/piksel/2008-January/003328.html["I believe in Cinelerra"] by Leo Germani also generated a lot of traffic by developers. Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on. The discussion was about advertising the project on various sites.
There were some concerns raised that it is too early to do too much publicity at the moment;
the right time should be shortly before the first public release. But there is also some value
in registering to the project in planning/alpha stage to interest people such as prospective coders.
It was noted that the
https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com]
resulted in a lot of people contacting Ichthyo and Cehteh.
»I believe in Cinelerra«
by Leo Germani also generated a lot of traffic by developers.
[purple]#<lost content at `http://plot.bek.no/pipermail/piksel/2008-January/003328.html`>#
Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on.
Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful) Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful)
@ -62,51 +77,76 @@ Conclusion: volunteer needed to coordinate publicity (not overly urgent, but hel
Informal talk about the GUI Informal talk about the GUI
--------------------------- ---------------------------
Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: GUI and backend should be completely separated and communicate via pipes. It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. Some comments: Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo:
GUI and backend should be completely separated and communicate via pipes.
It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used.
Some comments:
* cehteh standalone gui is a nice to have, but implementation details have to be worked out * _cehteh_: standalone gui is a nice to have, but implementation details have to be worked out
* gmerlin Video playback can be separated in a separate X connection * _gmerlin_: Video playback can be separated in a separate X connection
* cehteh suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later * _cehteh_ suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later
* rgareus IMHO you want to share memory for the video-frame buffer beween the player and backend - with pipes you'll go the video-jack way. * _rgareus_ IMHO you want to share memory for the video-frame buffer between the player and backend - with pipes you'll go the video-jack way.
joelholdsworth is a new developer in the group and had showed interest in developing the GUI. he stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language. _JoelHoldsworth_ is a new developer in the group and had showed interest in developing the GUI.
He stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards
to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm.
There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME).
Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language.
Cario was suggested to be used for implementing the canvas in the timeline view. Cario was suggested to be used for implementing the canvas in the timeline view.
The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. Tracks can be nested. Use tiling windows and dockeable views and tools palettes. For example some configuration within session/renderpipeline may cause some pluggable elements to be added to the gui. A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). A video track renders thumbnails, automation curves on top. The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins.
Tracks can be nested. Use tiling windows and dockable views and tools palettes.
For example some configuration within session / render-pipeline may cause some pluggable elements to be added to the gui.
A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews).
A video track renders thumbnails, automation curves on top.
Workflow is another important aspect to take into account in the design. A lot of information needs to come from editors and users in the design process. Different thoughts about the workflow: Workflow is another important aspect to take into account in the design.
A lot of information needs to come from editors and users in the design process.
Some thoughts about the workflow:
* Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed. * Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed.
* We dont have the resources to develop a "workflow" in the formal manner, we will go the "propose and comment" route. * We dont have the resources to develop a »workflow« in the formal manner, we will go the ``propose and comment'' route.
* We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects. * We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects.
Customisation is deemed important. Some points brought up in the discussion: Customisation is deemed important. Some points brought up in the discussion:
* sakalli: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well. * _sakalli_: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well.
* cehteh: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional * _cehteh_: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional
* Customization should be possible without recompile, but not too cheap. * Customization should be possible without recompile, but not too cheap.
* There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization. * There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization.
* The whole gui in a script with some performance critical widgets coded in C/C++ * The whole gui in a script with some performance critical widgets coded in C/C++
* Some parts should just be customizable, other parts should be kept fixed. * Some parts should just be customizable, other parts should be kept fixed.
* cehteh suggested to start out by making a \'high level' description with no language/toolkit in mind .. what widgets do we need etc and after that to work on the skeleton mockup. * cehteh suggested to start out by making a ``high level'' description with no language/toolkit in mind ...
* cehteh / hermanr: Lumiera should allow to choose theme independently from desktop .. because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour what widgets do we need? etc and after that to work on the skeleton mockup.
* _cehteh_ + _hermanr_: Lumiera should allow to choose theme independently from desktop ...
because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour
ichthyo brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. _Ichthyo_ brings up the role of customization for the middle layer and gives an overview of his plans for the new participants.
He had good experiences with a rule based aproach in various projects. He wants to embed a Prolog interpreter that can answer to "configuration queries". There is a "builder" component in the middle layer to derive the render nodes graph based on a "high level model", which is visible to the user (in the GUI) and based on these configuration queries. He had good experiences with a rule based approach in various projects. He wants to embed a Prolog interpreter that can answer
to ``configuration queries''. There is a ``builder'' component in the middle layer to derive the render nodes graph based on
a ``high level model'', which is visible to the user (in the GUI) and based on these configuration queries.
Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, not the way "how dings are done" but the way "how things are related". Example: how to configure some effects when the footage is interlaced. Additionally, we want to have some global swithces, which could control these rules, like "I want maximum quality", or "I want as much as possible set up automatically". The prolog rules are stored in the session and can be editd by advanced users. Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue but it would have consequences for the GUI. Rationale for using prolog is: The rules are very readable because they rather represent facts and relations,
not the way ``how things are done'' but the way ``how things are related''.
Example: how to configure some effects when the footage is interlaced.
Additionally, we want to have some global switches, which could control these rules,
like ``I want maximum quality'', or ``I want as much as possible set up automatically''.
The prolog rules are stored in the session and can be edited by advanced users.
Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue
but it would have consequences for the GUI.
some discussion: some discussion:
* joelholdsworth: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc. * _joelholdsworth_: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc.
* rules within the middle layer/session could bind to some properties exposed in the GUI * rules within the middle layer/session could bind to some properties exposed in the GUI
* gmerlin joelholdsworth: Agree, but point out that this can become difficult * _gmerlin_, _joelholdsworth_: Agree, but point out that this can become difficult
* cehteh joelholdsworth: skeleton and plugins who attach into some gui areas, so you can add custom widgets * _cehteh_ + _joelholdsworth_: skeleton and plugins who attach into some GUI areas, so you can add custom widgets
* ichthyo: also the ability to attach "tags" to various objects, so the rules can bind on those tags * _ichthyo_: also the ability to attach ``tags'' to various objects, so the rules can bind on those tags
* cehteh: maybe a standard set of widgets, not really completely custom ones (gmerlin agrees) * _cehteh_: maybe a standard set of widgets, not really completely custom ones (_gmerlin_ agrees)
* joelholdsworth: probably you need to be able to do both well * _joelholdsworth_: probably you need to be able to do both well
* joelholdsworth in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer * _joelholdsworth_ in many apps the value/colour/string set works perfectly well,
but in Lumiera the controls will likely need to be much richer
Some brainstorming points about usability: Some brainstorming points about usability:
@ -116,20 +156,23 @@ Some brainstorming points about usability:
One extra point: One extra point:
* we have agreed to make all of the big interfaces between the layers as plain C interfaces, because this is the most widely supported common denominator. * we have agreed to make all of the big interfaces between the layers as plain C interfaces,
because this is the most widely supported common denominator.
GUI CONCLUSION GUI CONCLUSION
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
* joelholdsworth is now the official GUI maintainer for Lumiera! * _joelholdsworth_ is now the official GUI maintainer for Lumiera!
* sakalli, hermanr, ichthyo announced interest in contributing to discussions about GUI, workflows and usability. gmerlin noted that he knows some gtk secrets and is willing to help out here too. * _sakalli_, _hermanr_, _ichthyo_ announced interest in contributing to discussions about GUI, workflows and usability.
* _gmerlin_ noted that he knows some GTK secrets and is willing to help out here too.
Froscon application Froscon application
------------------- -------------------
http://www.froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. Cehteh will be there as well as Ichthyo. Question is wether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june. https://froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented.
Cehteh will be there as well as Ichthyo. Question is whether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june.
We made no decision about official presence but most likely there will be a developer meeting if nothing else. We made no decision about official presence but most likely there will be a developer meeting if nothing else.
@ -139,7 +182,7 @@ Timecode metadata discussion
---------------------------- ----------------------------
This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records. This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records.
Conclusion: Gmerlin does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further. Conclusion: _Gmerlin_ does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further.
_A (shortended) digest of the timecode and metadata discussion is attached below_ _A (shortended) digest of the timecode and metadata discussion is attached below_

134
doc/devel/meeting_summary/2008-05-08.txt
View file

@ -24,44 +24,45 @@ Organization of this meeting
Webpage-Infrastructure, Maintenance Webpage-Infrastructure, Maintenance
----------------------------------- -----------------------------------
Cehteh put this on topic because it's really urgent to bring up some _Cehteh_ put this on topic because it's really urgent to bring up some
infrastructure to manage the information we produce. infrastructure to manage the information we produce.
The Lumiera pages on pipapo.org were always meant as intermediary The Lumiera pages on pipapo.org were always meant as intermediary
solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh solution. Pipapo.org gets much spam on the MoinMoin wiki and _Cehteh_
expresses that he wants to move pipapo.org to a new infrastructure expresses that he wants to move pipapo.org to a new infrastructure
based on asciidoc and git he created based on Asciidoc and Git he created
(see http://git.pipapo.org/uWiki.html[]). This system is barely useable (see [purple]#`http://git.pipapo.org/uWiki.html` <broken-URL>#).
This system is barely usable
and needs lots of work to be completed. It would be nice to use it for and needs lots of work to be completed. It would be nice to use it for
Lumiera too, if the others agree. Maintaining and extending Lumiera too, if the others agree. Maintaining and extending
(scripting) needs someone who knows shell scripting and doesn't need (scripting) needs someone who knows shell scripting and doesn't need
to be done by the core devs freeing their resources to work on to be done by the core devs freeing their resources to work on
Lumiera. Cehteh expresses that none of the people who proposed to Lumiera. _Cehteh_ expresses that none of the people who proposed to
help before showed up yet. WesLappy tells he might help (addendum not help before showed up yet. WesLappy tells he might help (addendum not
this week, because he is busy). this week, because he is busy).
Next there was a suggestion by cehteh to convert the tiddlywikis to Next there was a suggestion by _Cehteh_ to convert the TiddlyWikis to
asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel Asciidoc. Ichthyo expresses that he likes the TiddlyWikis, Joel
mentions that they feel a little odd. Generally we all agree that mentions that they feel a little odd. Generally we all agree that
they have some problems in sense of workflow and merging. they have some problems in sense of workflow and merging.
Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and _Ichthyo_ makes the suggestion to keep the TiddlyWikis as scrapbook and
build up \'official' documentation based on their content in build up ``official'' documentation based on their content in
whatever-we-use-then (asciidoc) documentation system. All agree on whatever-we-use-then (Asciidoc) documentation system. All agree on
this approach. this approach.
Back to the new wiki, cehteh suggests to make stricter access rules to Back to the new wiki, _Cehteh_ suggests to make stricter access rules to
prevent spam: "There will be a group of \'Validated' people which prevent spam: ``There will be a group of `Validated' people which
following rules: only Validated people can edit general content and following rules: only `Validated' people can edit general content and
\'Validated' people can add new people to \'Validated' themselves". That `Validated' people can add new people to `Validated' themselves''. That
means that we can have a lightweight self-administrating means that we can have a lightweight self-administrating
authentication where new people have to be introduced by someone who authentication where new people have to be introduced by someone who
is already there. is already there.
Ichthyo suggests to send a reply to Serge G. who send an introduction _Ichthyo_ suggests to send a reply to Serge G., who send an introduction
to the cinelerra mailing list expressing that he would like to help. to the cinelerra mailing list expressing that he would like to help.
Raffa will take care of content/design as much her time/knowledge permits. _Raffa_ will take care of content/design as much her time/knowledge permits.
Conclusion Conclusion
@ -69,25 +70,25 @@ Conclusion
* We really need someone to help with the webpage scripting. * We really need someone to help with the webpage scripting.
* Documentation needs to be well organized and moved over. * Documentation needs to be well organized and moved over.
* Content of the pipapo.org moinmoin wiki should be moved over. * Content of the pipapo.org MoinMoin wiki should be moved over.
* The new website should be well organized with a nice looking frontpage * The new website should be well organized with a nice looking front page
* All other documentation should be below that * All other documentation should be below that
Whats pending in link:DesignProcess[] Whats pending in the DesignProcess / RfC
------------------------------------- ----------------------------------------
MistakestoAvoid MistakestoAvoid
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[] link:{rfc}_dropped/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design]
rick_777 wrote a "MistakestoAvoid" page which explains some possible _rick_777_ wrote a "MistakestoAvoid" page which explains some possible
gotchas. We basically agree with most points there while we already gotchas. We basically agree with most points there while we already
decided to address some things differently than he suggested. One decided to address some things differently than he suggested. One
noteable difference is that we do not intent to provide a windows notable difference is that we do not intent to provide a windows
version of Lumiera, which was explained in serveral places. Cehteh version of Lumiera, which was explained in several places. _Cehteh_
added some comments to the page explaining some things. added some comments to the page explaining some things.
@ -96,29 +97,28 @@ nothing more to discuss in \'Ideas', we go over to \'Drafts'
ArchitectureOverview ArchitectureOverview
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[] link:{rfc}/ArchitectureOverview.html[RfC: Architecture Overview]
Cehteh suggests to put that drawing under version control, as .fig. _Cehteh_ suggests to put that drawing under version control, as .fig.
Ichthyo explains that it is already a .SVG and that he does not like Ichthyo explains that it is already a `.SVG` and that he does not favour `.fig`.
.fig.
Conclusion: We agree to keep it as .SVG, add it to the repository and Conclusion:: We agree to keep it as `.SVG`, add it to the repository and
improve/complete it. improve/complete it.
GitSubmoduleTransistion GitSubmoduleTransistion
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion[] link:{rfc}/GitSubmoduleTransistion.html[RfC: Git Submodules]
Another suggestion made by cehteh is to make managing of subprojects Another suggestion made by _Cehteh_ is to make managing of subprojects
within the sourcetree easier. Joel and ichthyo oppose that it is not within the sourcetree easier. _Joel_ and _Ichthyo_ object that it is not
really needed now and needs more understanding of git. Ichthyo really needed now and needs more understanding of Git. _Ichthyo_
suggests that the documentation might be separated into its own git, suggests that the documentation might be separated into its own Git,
he further explains that the things are not settled yet and we don't he further explains that the things are not settled yet and we don't
know if we will some rearrangements and movements of files between know if we will some rearrangements and movements of files between
modules. modules.
Conclusion: We transform the documentation to a submodule and see how Conclusion:: We transform the documentation to a submodule and see how
it works. Other things will be decided much later. it works. Other things will be decided much later.
@ -126,19 +126,19 @@ it works. Other things will be decided much later.
GlobalInitialization GlobalInitialization
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization[] link:{rfc}/GlobalInitialization.html[RfC: Global Init]
This topic is discussed and agreed on the link:DesignProcess[] page already. This topic is discussed and agreed on the RfC page already.
Conclusion: finalize it Conclusion:: finalize it
MasterRepositorySetup MasterRepositorySetup
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup[] link:{rfc}/MasterRepositorySetup.html[RfC: Shared Master Repository]
Setting up an master repository was decided on the last meeting. Setting up an master repository was decided on the last meeting.
cehteh now set one up which also does some automatic, but intended _Cehteh_ now set one up which also does some automatic, but intended
fragile merging from subsystem maintainer branches. fragile merging from subsystem maintainer branches.
1. it updates automatically for the maintainers repo for conflict 1. it updates automatically for the maintainers repo for conflict
free fast-forwards free fast-forwards
@ -146,7 +146,7 @@ fragile merging from subsystem maintainer branches.
The others agree on the setup. The others agree on the setup.
Ichthyo stresses that maintainers shall watch that their \'master' Ichthyo stresses that maintainers shall watch that their `master'
branch should compile cleanly and pass the testsuite always, test branch should compile cleanly and pass the testsuite always, test
which are not operational should be tagged as PLANNED. We all which are not operational should be tagged as PLANNED. We all
agree, while cehteh's master is currently in a broken state (note: agree, while cehteh's master is currently in a broken state (note:
@ -155,9 +155,9 @@ fixed now).
Then a short discussion about building and synchronizing the docs Then a short discussion about building and synchronizing the docs
follows. Problem is that docs build in maintainer branches are follows. Problem is that docs build in maintainer branches are
different for each branch, rsyncing them up to the server will always different for each branch, rsyncing them up to the server will always
change a lot of things. We agree that the \'official' docs shall be change a lot of things. We agree that the ``official'' docs shall be
build from the LUMIERA/master repository, preferably on the \'devel' build from the LUMIERA/master repository, preferably on the "devel"
vserver which has to be set up. VServer which has to be set up.
Conclusions: Make this final, setup build environment in the devel Conclusions: Make this final, setup build environment in the devel
server and build docs there. server and build docs there.
@ -166,28 +166,28 @@ server and build docs there.
NoBugFlags NoBugFlags
~~~~~~~~~~ ~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags[] link:{rfc}/NoBugFlags.html[RfC: NoBug flags]
Defining a debugging control hierarchy. This is work in progress and Defining a debugging control hierarchy. This is work in progress and
cehteh explains that he works it out and deploys it, this depends on _Cehteh_ explains that he works it out and deploys it, this depends on
the link:GlobalInitialization[] decided earlier. the link:{rfc}/GlobalInitialization.html[GlobalInitialization] decided earlier.
Conclusion: accepted, finish and finalize it. Conclusion:: accepted, finish and finalize it.
Further Technical Discussion Further Technical Discussion
---------------------------- ----------------------------
Ichthyo asks how the GUI will be pulled up. Since he didn't attend IRC _Ichthyo_ asks how the GUI will be pulled up. Since he didn't attend IRC
discussions recently he has no information yet whats going on. We discussions recently he has no information yet whats going on. We
explain him that we already made some discussions. Integrate the GUI explain him that we already made some discussions. Integrate the GUI
into the build system probably linked as library, nothing finally into the build system probably linked as library, nothing finally
decided yet. Communication will go over the plugin/interface facility decided yet. Communication will go over the plugin/interface facility
(Plain C API). This things should be worked out and documented in (Plain C API). This things should be worked out and documented in
link:DesignProcess[]. link:/x/DesignProcess.html[RfCs].
Cehteh made a small tool `./admin/headercheck` which will gradually _Cehteh_ made a small tool `./admin/headercheck` which will gradually
extended to proof that headers are sufficiently selfstanding. extended to proof that headers are sufficiently selfstanding.
@ -195,42 +195,42 @@ extended to proof that headers are sufficiently selfstanding.
Progress Progress
-------- --------
Cehteh finished low level file handling and working in mmaping and _Cehteh_ finished low level file handling and working on mmapping and
frameprovider next. When thats finished, the finalization of the frameprovider next. When thats finished, the finalization of the
Plugin loader and interface definition things is the most urgent thing. Plugin loader and interface definition things is the most urgent thing.
Ichthyo works on the builder internals and next on some sort of _Ichthyo_ works on the builder internals and next on some sort of
"connection manager". ``connection manager''.
Joel goes on with GUI programming and integrating it into the source _Joel_ goes on with GUI programming and integrating it into the source
tree next. tree next.
Gmerlin and cehteh discuss about how to handle the index files which _Gmerlin_ and _cehteh_ discuss about how to handle the index files which
avdecoder uses internally. cehteh would like to manage them in the avdecoder uses internally. _cehteh_ would like to manage them in the
Lumiera backend to, because filehandles are a precious resource. Lumiera backend to, because filehandles are a precious resource.
Gmerlin explains that this index files are just loaded and kept in _Gmerlin_ explains that this index files are just loaded and kept in
memory. So this poses no problem for filehandle exhaustion. We will memory. So this poses no problem for filehandle exhaustion. We will
discuss this further via email. discuss this further via email.
Cehteh suggests that we should think about some kind of _Cehteh_ suggests that we should think about some kind of
preferences/registry sometime next to store default configs. preferences/registry sometime next to store default configs.
Following a discussion about how messages are passed between GUI and A a discussion followed about how messages are passed between GUI and
core. Generally we will use the interfaces defined by the plugin core. Generally we will use the interfaces defined by the plugin
system. Gmerlin says that he uses message queues in \'gmerlin', Joel system. _Gmerlin_ says that he uses message queues in `gmerlin', _Joel_
requests that a lot of things should be done synchronous and he wants requests that a lot of things should be done synchronous and he wants
to avoid message queues. Cehteh suggests to use use the scheduler for to avoid message queues. _Cehteh_ suggests to use use the scheduler for
GUI things too. For the parts where the GUI interacts with the high GUI things too. For the parts where the GUI interacts with the high
level proc model ichthyo and joel agree on working something level proc model _ichthyo_ and _joel_ agree on working something
(synchronous) out. Ichthyo stresses that the edit core is not (synchronous) out. _Ichthyo_ stresses that the edit core is not
threadsafe by design and relies on the backends scheduler. threadsafe by design and relies on the backends scheduler.
The underlying builder might sometimes to expensive for synchronous The underlying builder might sometimes to expensive for synchronous
calls (ichthyo plans a rule system there) this needs to be worked out. calls (_ichthyo_ plans a rule system there) this needs to be worked out.
Ichthyo explains that the builder needs to detect cycles and check if _Ichthyo_ explains that the builder needs to detect cycles and check if
the high level model is translateable into the low level model (in the high level model is translateable into the low level model (in
case plugins git removed and so on). Parts in the render graph which case plugins git removed and so on). Parts in the render graph which
are not \'doable' should be flagged as erroneous but not dropped since are not ``doable'' should be flagged as erroneous but not dropped since
one doesn't want to loose project information when loading a project one doesn't want to loose project information when loading a project
on a machine with different installed plugins. In any case it should be on a machine with different installed plugins. In any case it should be
possible that the GUI gets immediate synchronous feedback for such possible that the GUI gets immediate synchronous feedback for such

46
doc/devel/meeting_summary/2008-06-06.txt
View file

@ -23,41 +23,61 @@ Discuss Ideas and Drafts in design process
------------------------------------------ ------------------------------------------
There are no new design proposals and no proposals that can be finalized. 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. 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 Idea: Design the Render Nodes interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface[] link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface]
*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. _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 ``experimenta'' 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 _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. Conclusion:: ``currently in work''. For now, grow interfaces on demand.
Idea: Placement Metaphor used within the high-level view of Proc-Layer Idea: Placement Metaphor used within the high-level view of Proc-Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] link:{rfc}/ProcPlacementMetaphor.html[RfC: Placement Metaphor]
In the course of the discussion, *Ichthyo* explains the rationale In the course of the discussion, _Ichthyo_ explains the rationale
* one common mechanism for sticking objects together and putting them into the session * 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) * 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 * 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 * 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. _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. 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. 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. 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. * 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 simplified 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: * 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) . 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 . 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

65
doc/devel/meeting_summary/2008-07-06.txt
View file

@ -23,7 +23,7 @@ Boilerplate
Organization of this meeting Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* dmj726 intends to write the protocol * dmj726 intends to write the protocol
* ichtyo is chairman * _Ichthyo_ is chairman
* there is no agenda, so this is a freeform meeting * there is no agenda, so this is a freeform meeting
Leftovers from last meeting Leftovers from last meeting
@ -37,18 +37,21 @@ Because there are quite some new participants, an introduction of the project Lu
There are 3 core devs: There are 3 core devs:
* ichthyo: proc layer, render graph, in the middle, C++, he maintains scons * _Ichthyo_: proc layer, render graph, in the middle, C++, he maintains SCons
* cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git * _Cehteh_: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git
* joelholdsworth: GUI in C++/Gtkm * _JoelHoldsworth_: GUI in C++/Gtkmm
Other people involved: Other people involved:
* rcbarnes: ui designer and coder * _rcbarnes_: ui designer and coder
* raffa: web content * _raffa_: web content
* Simav: gives a hand when and where he can * _Simav_: gives a hand when and where he can
* Teld: web infrastructure * _Teld_: web infrastructure
The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list.
cehteh: The foundations of the design are already done but a lot of detail needs to be worked out.
_Cehteh_ and _Ichtyo_ provide a non exhaustive list.
_Cehteh_:
* improvement of the testsuite (simple Bash) * improvement of the testsuite (simple Bash)
* start of a worker thread manager (Posix knowledge required) * start of a worker thread manager (Posix knowledge required)
@ -58,35 +61,53 @@ cehteh:
* system administration * system administration
* setup of a build/test environment on the server * setup of a build/test environment on the server
* setup and maintain postfix/dovecot by a mail administrator * setup and maintain postfix/dovecot by a mail administrator
ichtyo:
_Ichthyo_:
* asset management (keeping track of all media files, captures, clips, scenes) * asset management (keeping track of all media files, captures, clips, scenes)
* session loading saving and the issues of compound documents * session loading saving and the issues of compound documents
* session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK * session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK
* flesh out the more high level "edit operations" and the interface to UNDO * flesh out the more high level ``edit operations'' and the interface to UNDO
* Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand). * Prolog integration after the first integration round has been reached.
The Prolog interpreter will do some of the more advanced configuration
(example: if effect XYZ is used, then deinterlace beforehand).
* integration with some sort of production support software (like Celtx) * integration with some sort of production support software (like Celtx)
cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin.
_Cehteh_ emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit
as long as he communicates and acknowledges with the persons involved.
_Ichthyo_ points out that the plugin structure is very important: anything that is not legally completely clean
(e.g. proprietary technology), should be factored out into a sister project and be loaded as plugin.
Issues and questions that come up Issues and questions that come up
--------------------------------- ---------------------------------
* handling of config errors. * handling of config errors. +
When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work. When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane.
Therefore, the config system will be built to log a warning and the user code does not need to care.
The user just gets an alert and the application continues to work.
* scripting language. * scripting language.
There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple. +
--
There will be a scripting interface. _Ichthyo_ does not want scripts everywhere, only at *well defined interfaces*.
That implies also that scripts _cannot just do anything,_ only that what is permitted in a controlled way.
The meeting agrees on that. _Cehteh_ wants one default language and proposes Lua: light, simple.
Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants. Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants.
--
* editing on small devices (eeePC) * editing on small devices (eeePC) +
Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented. Problem: video editors GUIs are some of the most elaborate and complicated GUIs.
However, basic functions consist of only a few buttons. Proxy editing could be a solution.
It is decided that it is not a primary goal now. First the basics have to be implemented.
* uWiki. * uWiki. +
uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems. uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems.
* \'musical\' timeline in bars and beats * ``musical'' timeline in bars and beats +
The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[] The questions of syncing and linking things together are already on the core agenda: the so-called placement concept.
Discussion is still going on, especially with the GUI developer _JoelHoldsworth_.
See for detailed information: link:{rfc}/ProcPlacementMetaphor.html[RfC Placement Metaphor]
Next meeting Next meeting

12
doc/devel/meeting_summary/2008-09-04.txt
View file

@ -29,11 +29,11 @@ There are no leftovers
Mailing Lists Mailing Lists
------------- -------------
* any improvements should be reported to cehteh * any improvements should be reported to _cehteh_
* need volunteers to be moderators. The only volunteers are cehteh and joelholdsworh_ * need volunteers to be moderators. The only volunteers are _cehteh_ and _joelholdsworh_
* moderating the ML might not be that big a job - we might not get that much spam * moderating the ML might not be that big a job - we might not get that much spam
* it's preferable to allow people to post to the mailing list even if they're not subscribed * it's preferable to allow people to post to the mailing list even if they're not subscribed
* cehteh eventually wants the mailing list to interact with uwiki. * _cehteh_ eventually wants the mailing list to interact with uwiki.
Plugin Interfaces Plugin Interfaces
----------------- -----------------
@ -41,7 +41,7 @@ Plugin Interfaces
* this includes enumerating structured data within the plugins. It might sometimes be desirable to store this in a text file, but in this case still the list will be exported through the interfaces. If this were not the case, it would not be possible to make plugins which are wrappers of LADSPA plugins for example. * this includes enumerating structured data within the plugins. It might sometimes be desirable to store this in a text file, but in this case still the list will be exported through the interfaces. If this were not the case, it would not be possible to make plugins which are wrappers of LADSPA plugins for example.
* For a lumiera plugin there is only one entry point, thats an interface itself which bootstraps all the other interfaces in that plugin. * For a lumiera plugin there is only one entry point, thats an interface itself which bootstraps all the other interfaces in that plugin.
Lib Dependancy Problems Lib Dependency Problems
----------------------- -----------------------
* we've agreed to stick to one compatibility level: Debian/Lenny for perhaps up to 3 years from now * we've agreed to stick to one compatibility level: Debian/Lenny for perhaps up to 3 years from now
* others will be supported - RedHat etc. * others will be supported - RedHat etc.
@ -49,7 +49,7 @@ Lib Dependancy Problems
Builds and Buildbot Builds and Buildbot
------------------- -------------------
* ichthyo asks for help setting up a test/build server * ichthyo asks for help setting up a test/build server
* We now have build scripts based on scons and autotools. * We now have build scripts based on SCons and Autotools.
* All current build systems have different problems. * All current build systems have different problems.
* ichthyo will take care of the Debian packages for Lumiera and NoBug * ichthyo will take care of the Debian packages for Lumiera and NoBug
@ -69,6 +69,6 @@ The next meeting will be held Thursday, 2 oct 21:00 utc.
Comment Comment
~~~~~~~ ~~~~~~~
re "ichthyo asks for help setting up a test/build server" for "Debian" re ``ichthyo asks for help setting up a test/build server'' for "Debian"
see "Build Server" at [purple]#<broken-URL># see "Build Server" at [purple]#<broken-URL>#

100
doc/devel/meeting_summary/2008-10-10.txt
View file

@ -11,7 +11,7 @@ __Participants__
* ichthyo * ichthyo
* joelholdsworth * joelholdsworth
* alcarinque * alcarinque
* !KenSentMe * KenSentMe
* Plouj * Plouj
* raffa * raffa
* thorwil * thorwil
@ -30,7 +30,7 @@ The Lumiera Logo
---------------- ----------------
Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution. Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution.
This summer, one of the proposals by http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts[explained] his reservation. Prior to this meeting some people joined a brainstorming session and came up with http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png[another design] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users. This summer, one of the proposals by link:{img}/LumieraLogoLeonardoRiberio.2008.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and explained [purple]#<broken-URL># his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest: Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest:
@ -48,7 +48,7 @@ Conclusion
There will be a Lumiera Logo contest. There will be a Lumiera Logo contest.
* we should further discuss requirements on the Mailinglist until the end of the next week * we should further discuss requirements on the Mailinglist until the end of the next week
* the '''deadline for submissions''' will be the next meeting (Nov 12 2008) * the *deadline for submissions* will be the next meeting (Nov 12 2008)
* then, after a pre-selection phase, the vote shall be conducted prior to the December meeting. * then, after a pre-selection phase, the vote shall be conducted prior to the December meeting.
Some minimal technical requirements will be enforced: Some minimal technical requirements will be enforced:
@ -63,7 +63,7 @@ Some minimal technical requirements will be enforced:
Besides, we give some artistic guidelines Besides, we give some artistic guidelines
* it should be recognisable * it should be recognisable
* it should contain something like a sign, not just "Lumiera" in a fancy font * it should contain something like a sign, not just ``Lumiera'' in a fancy font
* it should not rely on transparencies, gradients and subtle shades, * it should not rely on transparencies, gradients and subtle shades,
* it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented * it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented
@ -75,22 +75,22 @@ Raffa volunteers to help organizing the contest and the voting.
Recurring Topics: design proposals Recurring Topics: design proposals
---------------------------------- ----------------------------------
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts. Discussion of open link:/x/DesignProcess.html[design process] drafts.
Mistakes to avoid Mistakes to avoid
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[Mistakes to avoid in the Lumiera Design] link:{rfc}/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design]
We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things
* we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here. * we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here.
* the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements. * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to underpin these statements.
While it is certainly ''desirable'' to be cross-platform as much as possible and especially '''target Microsoft Windows''', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform. While it is certainly _desirable_ to be cross-platform as much as possible and especially *target Microsoft Windows*, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform.
While it is certainly ''desirable'' to make the application as robust as possible, we don't see how '''using multiple separate processes''' could help us with this goal ''without creating major scalability or performance problems'' due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner. While it is certainly _desirable_ to make the application as robust as possible, we don't see how *using multiple separate processes* could help us with this goal _without creating major scalability or performance problems_ due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner.
__Conclusion__: drop it [underline]#Conclusion#: drop it
on the question of separate processes on the question of separate processes
@ -101,8 +101,8 @@ The only practical solution would be to separate the GUI. Separating backend and
Tag Clouds Tag Clouds
~~~~~~~~~~ ~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources[Tag clouds on resources] link:{rfc}/TagCloudsOnResources.html[Tag clouds on resources] +
Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator["Delectus"] Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: link:/x/Delectus.html[»Delectus«]
__Conclusion__: drop it __Conclusion__: drop it
@ -111,7 +111,7 @@ __Conclusion__: drop it
Overview of Lumiera Architecture Overview of Lumiera Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[Architecture Overview] link:{rfc}/ArchitectureOverview.html[Architecture Overview]:
The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT. The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT.
__Conclusion__: accept it, change the image to a link __Conclusion__: accept it, change the image to a link
@ -121,7 +121,7 @@ __Conclusion__: accept it, change the image to a link
EDLs as Meta-Clips EDLs as Meta-Clips
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips[EDLs are meta-clips] link:{rfc}/EDLsAreMetaClips.html[EDLs are meta-clips] +
This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do. This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do.
__Conclusion__: accepted __Conclusion__: accepted
@ -131,7 +131,7 @@ __Conclusion__: accepted
The Builder The Builder
~~~~~~~~~~~ ~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder[Builder in the Proc-Layer] link:{rfc}/ProcBuilder.html[Builder in the Proc-Layer] +
Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph) Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph)
__Conclusion__: accepted __Conclusion__: accepted
@ -141,7 +141,7 @@ __Conclusion__: accepted
High-level Model High-level Model
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel[Overview of the High-level model within the Proc-Layer] link:{rfc}/ProcHighLevelModel.html[Overview of the High-level model within the Proc-Layer] +
Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review. Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review.
__Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation? __Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation?
@ -151,8 +151,16 @@ __Conclusion__: leave it for now, maybe retract it from the design proposals and
Lua scripting language Lua scripting language
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage[use Lua as required scripting language] link:{rfc}/ScriptingLanguage.html[use Lua as required scripting language] +
All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as ''required'' scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here) All core devs agree with this decision.
_Joelholdsworth_ points out that he is fine with Lua, just he didn't want to write the GUI in it.
_Ichthyo_ adds that Lua is probably the best choice from today's mainstream scripting languages,
because it is very lightweight. He further points out, that having Lua as _required_ scripting language
does not rule out using other popular languages (Python, Ruby) for scripting.
Just they aren't required for running Lumiera.
_Cehteh_ will have a look at the details as soon as possible,
but has currently other more urgent things in the queue.
(_Plouj_ shows interest to help here)
__Conclusion__: accepted __Conclusion__: accepted
@ -161,8 +169,8 @@ __Conclusion__: accepted
Time Handling Time Handling
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[time handling] link:{rfc}/TimeHandling.html[time handling] +
A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done ''on demand.'' Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time. A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done _on demand._ Joelholdsworth says sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time.
__Conclusion__: accepted __Conclusion__: accepted
@ -171,7 +179,7 @@ Note: the proposed rigid testsuite for time handling is necessary only when we i
Interface naming convention Interface naming convention
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
See the design proposal http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces[Interface Namespaces]. While working on the plugin loader, '''Cehteh''' and '''nasa''' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry. See the design proposal link:{rfc}/InterfaceNamespaces.html[Interface Namespaces]. While working on the plugin loader, _Cehteh_ and _nasa_ did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry.
__Conclusion__: accepted __Conclusion__: accepted
@ -180,13 +188,23 @@ general Topics
Config System Config System
------------- -------------
'''cehteh''' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type). _Cehteh_ landed the first version of this subsystem and asked for review and testing. Currently it's ``work with no progress'', but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type).
Use of Namespaces Use of Namespaces
----------------- -----------------
Currently there is no clear uniform rule regarding namespaces use. *Joelholdsworth* places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, *Ichthyo* deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below lumiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. *Cehteh* argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces. Currently there is no clear uniform rule regarding namespaces use.
_JoelHoldsworth_ places his code within lumiera::gui and below.
He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies
and all of Lumiera should comply and put anything below a lumiera:: root.
On the contrary, _Ichthyo_ deliberately moved his implementation code away from the central `lumiera::`
interface hierarchy into shallow namespaces and avoids nesting.
He argues that having all code below `lumiera::` effectively makes this namespace global or forces it to be void of any function;
rather he'd prefer to import every interface explicitly into the implementation namespace.
_Cehteh_ argues that having a global `lumiera::`, even if empty,
would mark a general claimand stand for the uniformity of the project.
Generally, there should be some correspondence between folders and namespaces.
No conclusion yet, to be discussed further. No conclusion yet, to be discussed further.
@ -194,9 +212,13 @@ No conclusion yet, to be discussed further.
Interface Definition Language Interface Definition Language
----------------------------- -----------------------------
In his work on the plugin loader, '''Cehteh''' created a first draft how to export an interface, and calls for review. An example can be found in http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776[tests/backend/test-interfaces.c] In his work on the plugin loader, _Cehteh_ created a first draft how to export an interface, and calls for review.
An example can be found in
https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/backend/test-interfaces.c;h=09fa25afa3cb57b79a2717d0bf3a8253afeba000;hb=ebcc5c7fd2d8700f3375e3309b724ac2517a0f40[tests/backend/test-interfaces.c]
An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language An interface is a list of »slots« mapping functions. The interface descriptor is itself realised as interface,
and thus can be versioned, extended and specialised.
By use of some glue code and macros we create a simple Interface Definition Language
* after exporting a header with the C interface, including the types to be used... * after exporting a header with the C interface, including the types to be used...
* LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface) * LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface)
@ -204,22 +226,33 @@ An interface is a list of "slots" mapping functions. The interface descriptor is
* LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors) * LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors)
* LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core * LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core
* LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin) * LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin)
* besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps
onto an existing function directly
The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently. The plugin loading system cares for mapping the given implementation function to the interface slots.
Interfaces from the core need to be registered before they can be used,
while for plugins this is done automatically on loading the module.
The client code later just calls `interface_open()` and `interface_close()`
where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader,
registry and/or plugin-DB shall manage it transparently.
Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number. Version numbering starts with 1 and uses minor version numbers for compatible changes
and major version numbers for everything that breaks existing assumptions.
Version number zero is reserved for experimental work and per definition always the most recent version number.
The system is designed to be very flexible and extensible, but this foundation really needs thorough review. The system is designed to be very flexible and extensible, but this foundation really needs thorough review.
Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code. _Joelholdworth_ expresses some concern regarding the UUIDs in octal notation used within the interface description.
_Cehteh_ explains they never need to be specified by client code.
They are just distinctive IDs and provided for some special case within the plugin loader / serializer.
He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring.
The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code.
Conclusion Conclusion
~~~~~~~~~~ ~~~~~~~~~~
looks good, agreement by all core devs. Looks good, agreement by all core devs. +
+
Should be reviewed and investigated in detail to find any hidden problems. Should be reviewed and investigated in detail to find any hidden problems.
@ -227,6 +260,7 @@ Should be reviewed and investigated in detail to find any hidden problems.
Next meeting Next meeting
------------ ------------
There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday... There were some problems with the meeting schedule. Using the first week of month seems to be problematic.
We'll try with second Wednesday...
The next meeting is scheduled for '''Wednesday Nov 12 2008 19:30 UTC''' at #lumiera The next meeting is scheduled for **Wednesday Nov 12 2008 19:30 UTC** at #lumiera

4
doc/devel/meeting_summary/2008-11-12.txt
View file

@ -48,7 +48,7 @@ eg. fader, panner, blur.
_joelholdsworth_ points out that configurability can't replace real GUI and workflow design. _joelholdsworth_ points out that configurability can't replace real GUI and workflow design.
He quotes from a recent Blender GUI discussion He quotes from a recent Blender GUI discussion
[quote, the Belnder UI reviews] [quote, the Blender UI reviews]
____________________________________________________________________ ____________________________________________________________________
Lastly, I’d like to address another misconception, this time about customizability. Lastly, I’d like to address another misconception, this time about customizability.
There has been a notion that the solution to most of the UI problems can be solved with added customizability. There has been a notion that the solution to most of the UI problems can be solved with added customizability.
@ -71,7 +71,7 @@ from the defaults to match another 3D application such as Maya or Softimage XSI
for users of those applications to adapt to Blender. for users of those applications to adapt to Blender.
____________________________________________________________________ ____________________________________________________________________
Consequently, Joel wants to try just doing the UI _right_, then add a little bit of customization back in here and there. Consequently, _Joel_ wants to try just doing the UI _right_, then add a little bit of customization back in here and there.
Additionally, agreement is to have a kind-of ``perspective switcher'' (like in Eclipse), so saving different Additionally, agreement is to have a kind-of ``perspective switcher'' (like in Eclipse), so saving different
panel layouts would be covered easily panel layouts would be covered easily

8
doc/devel/meeting_summary/2008-12-10.txt
View file

@ -33,7 +33,7 @@ Discussion of open link:/x/DesignProcess.html[design process] drafts.
EDL vs Sequence EDL vs Sequence
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in [wiki:self:../DesignProcess/TimelineSequenceOutput Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows. There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in link:{rfc}/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows.
__Conclusion__: the name Sequence will be used instead of EDL __Conclusion__: the name Sequence will be used instead of EDL
@ -45,7 +45,7 @@ Ichtyo explains that the idea is that between layers only the C Language interfa
Threads Threads
~~~~~~~ ~~~~~~~
The UI will mostly run on a single thread, i.e. gtk_main will run in this GUI thread and when it terminates, the GUI is "done" and signals back that it is done. Cehteh points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation The UI will mostly run on a single thread, i.e. »gtk_main« will run in this GUI thread and when it terminates, the GUI __is ``done''__ and signals back that it is done. _Cehteh_ points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation.
@ -55,12 +55,12 @@ General Topics
Video format Video format
~~~~~~~~~~~~ ~~~~~~~~~~~~
Kirk asks to what video format footage has to be converted so that it can be used in Lumiera. Ichtyo and cehteh point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way. _Kirk_ asks to what video format footage has to be converted so that it can be used in Lumiera. _Ichtyo_ and _Cehteh_ point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way.
Knowledge base Knowledge base
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Kirk has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. Kirk proposes to help in this area. _Kirk_ has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. _Kirk_ proposes to help in this area.

56
doc/devel/meeting_summary/2009-01-14.txt
View file

@ -36,54 +36,72 @@ Conclusion
~~~~~~~~~~ ~~~~~~~~~~
Two groups are created, each of these have someone responsible to bring them forward. Two groups are created, each of these have someone responsible to bring them forward.
The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This 'supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it. The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This `supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it.
Work discussion will proceed on the Mailing List but following the directions stated during the IRC meetings. + Work discussion will proceed on the Mailing List but following the directions stated during the IRC meetings. +
Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. [[BR]] Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization. Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. +
Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization.
Group 1 [WORKFLOW] Group 1 [WORKFLOW]
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
. director/supervisor: nikola_ (Nikola Duper) . director/supervisor: _nikola_ (Nikola Duper)
Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. + Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout.
The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.[[BR]] The core dev responsible for the GUI is joelholdsworth (Joel Holdsworth).[[BR]] One of the group goals is to make the dev point of view dialogate with the editor point of view.
The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. + - The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. [[BR]] It thinks about ergonomics.
- The core dev responsible for the GUI is _joelholdsworth_ (Joel Holdsworth).
- One of the group goals is to create a dialogue between the developer's point of view and the editor's point of view.
The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs.
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. +
It considers aspects of ergonomics.
Group 2 [ARTWORK] Group 2 [ARTWORK]
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
. director/supervisor: raffa (Raffaella Traniello) . director/supervisor: _raffa_ (Raffaella Traniello)
The group discuss about logo, themes, the look and feel... The group discuss about logo, themes, the look and feel...
Getting the 'non-coders' community to help Getting the 'non-coders' community to help
------------------------------------------ ------------------------------------------
goibhniu proposes an issue tracker. _goibhniu_ proposes an issue tracker.
The documentation needs love: it's currently horribly scattered all around. + * The documentation needs love: it's currently horribly scattered all around.
All the content needs to be converted to asciidoc and to the git repo at lumiera.org.[[BR]] Waiting for uWiki, the site will be in asciidoc+git [[BR]] The site needs a structure or other means to increase discoverability of all our information[[BR]] goibhniu proposes organizing a "sprint" to help get people involved and set a date for it (documentation migration/organisation) * All the content needs to be converted to asciidoc and to the git repo at lumiera.org.
* Waiting for uWiki, the site will be in asciidoc+git
* The site needs a structure or other means to increase discoverability of all our information
* _goibhniu_ proposes organizing a ``sprint'' to help get people involved and set a date for it (documentation migration/organisation)
Conclusion Conclusion
~~~~~~~~~~ ~~~~~~~~~~
* goibhniu volunteers to set up Trac. * _goibhniu_ volunteers to set up *Trac*.
* raevol volunteers to maintain it. * _raevol_ volunteers to maintain it.
* The link:AsciiDoc[] Day idea will be discussed at the next meeting. * The »*AsciiDoc Day*« idea will be discussed at the next meeting.
Possible GUI-Integration: Display a frame? Possible GUI-Integration: Display a frame?
------------------------------------------ ------------------------------------------
There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack. There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack.
For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later. For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality.
The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend.
It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning.
It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server.
It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks.
For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later.
The devs agreed to meet up on Saturday to get the latest version up and running. The devs agreed to meet up on Saturday to get the latest version up and running.
http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[] NOTE: Demonstration in https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/common/guifacade.cpp;h=60a16d0f67bd95b43e44662daa9c0525235e14f5;hb=5f10e65852de2c51364c2e2a5a1cf29cae81c6b2#l64[guifacade.cpp]
(The thread shall be forked from within the GUI code not from the facade) (The thread shall be forked from within the GUI code not from the facade)
This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday? This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday?
It was discussed whether joelholdsworth should wait for cehteh to make a playback interface or use a dummy one for now. Cehteh wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Icythyo has been using the link:GuiNotification[] as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which cehteh and joelholdsworth planned to flesh out in the near future. It was discussed whether _joelholdsworth_ should wait for _cehteh_ to make a playback interface or use a dummy one for now.
_Cehteh_ wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Ichythyo has been using the `GuiNotification` as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which _cehteh_ and _joelholdsworth_ planned to flesh out in the near future.
# Errors, Assertions, Checks, Dev- and Release-Builds # Errors, Assertions, Checks, Dev- and Release-Builds
@ -97,7 +115,7 @@ in new nobug you can do:
alpha code here alpha code here
) )
it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead. it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead.
(http://www.lumiera.org/nobug.html)[] (https://nobug.pipapo.org/[NoBug])
beta and release builds shall be possible with nobug soon .. waiting for metta to integrate the new test.sh beta and release builds shall be possible with nobug soon .. waiting for metta to integrate the new test.sh
test.sh with regex is awesome because you can test output which contains no exact things like addresses, version numbers, times test.sh with regex is awesome because you can test output which contains no exact things like addresses, version numbers, times
@ -106,7 +124,7 @@ and running the testsuite under valgrind works properly now
Workflow/Interface Workflow/Interface
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say "don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup". This is where the tree of tracks plays an important role because each track with its children forms a group. Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say ``don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup''. This is where the tree of tracks plays an important role because each track with its children forms a group.
There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI. There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI.

6
doc/devel/meeting_summary/2009-09-09.txt
View file

@ -29,7 +29,7 @@ This success wouldn't be possible without a lot of people helping. +
So lets say: *Thank you all*! So lets say: *Thank you all*!
We plan to be there again next year with another Lumiera meeting (possibly We plan to be there again next year with another Lumiera meeting (possibly
all the 3 core devs present). _Ichthyo_ consideres to do a dedicate talk all the 3 core devs present). _Ichthyo_ considers to do a dedicate talk
(in German). (in German).
Participation as a group to other possible events has been considered for + Participation as a group to other possible events has been considered for +
@ -60,7 +60,7 @@ If later on there will be funding for development (not just covering expenses)
that would require a different approach and special communication with the that would require a different approach and special communication with the
community. community.
_daniieel_ proposes to put a price to each request in "buglist". + _daniieel_ proposes to put a price to each request in ``buglist''. +
The proposal is discussed and dismissed. The proposal is discussed and dismissed.
@ -71,7 +71,7 @@ The news in the homepage makes the project look alive. But this is not
enough to communicate the state of the Lumiera development. Two enough to communicate the state of the Lumiera development. Two
solutions are proposed: solutions are proposed:
* The website needs to be reorganized and made accessible. andrewjames * The website needs to be reorganized and made accessible. _andrewjames_
volunteers to work on it. volunteers to work on it.
* Quarterly development news will be published in the devel section of the * Quarterly development news will be published in the devel section of the
website. The devs will post drafts to the mailing list and encourage the website. The devs will post drafts to the mailing list and encourage the

14
doc/devel/meeting_summary/2011-03-09.txt
View file

@ -25,6 +25,8 @@ The new website is finally online.
How do we proceed with the graphical layout? How do we proceed with the graphical layout?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[caption="☉Transcript☉ "]
----------------------------
21:37 <fsiddi> the template code is not ready yet 21:37 <fsiddi> the template code is not ready yet
21:37 <fsiddi> and there are some incorrect uses of tags in the current one 21:37 <fsiddi> and there are some incorrect uses of tags in the current one
21:37 <fsiddi> so i will go on coding a static html layout 21:37 <fsiddi> so i will go on coding a static html layout
@ -32,6 +34,7 @@ How do we proceed with the graphical layout?
... ...
21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area 21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area
for the tutorial part for the tutorial part
----------------------------
image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"] image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"]
@ -69,6 +72,9 @@ until the sun burns out.
engines will not respect it. Private logs or other logs not publically available engines will not respect it. Private logs or other logs not publically available
are fine though. are fine though.
.-- Discussion about relevance of IRC logs --
[caption="☉Transcript☉ "]
----------------------------
22:40 <cehteh> well ... IRC should *not* be for persistent documentation .. we shall 22:40 <cehteh> well ... IRC should *not* be for persistent documentation .. we shall
force/educate ourself to document things (and decisions) properly, irc force/educate ourself to document things (and decisions) properly, irc
should be volatile should be volatile
@ -96,6 +102,7 @@ are fine though.
22:50 <skangas_> This means I personally always prefer shorter summaries of a 22:50 <skangas_> This means I personally always prefer shorter summaries of a
discussion to IRC logs, given that they do not leave anything discussion to IRC logs, given that they do not leave anything
important out. important out.
----------------------------
VoIP discussions over Mumble? VoIP discussions over Mumble?
----------------------------- -----------------------------
@ -116,8 +123,11 @@ highly insecure.
Version numbering Version numbering
----------------- -----------------
Hermann has written an rfc for version numbers. _Ichthyo_ has written an link:{rfc}/VersionNumberScheme.html[RfC for version numbers].
.-- Discussion about a version number scheme for Lumiera --
[caption="☉Transcript☉ "]
----------------------------
23:19 <cehteh> so in my words: we will have a usuall major.minor.patch for releases 23:19 <cehteh> so in my words: we will have a usuall major.minor.patch for releases
23:20 <cehteh> and major+1~develtag for devel snapshots 23:20 <cehteh> and major+1~develtag for devel snapshots
23:20 <cehteh> where develtag is a timestamp 23:20 <cehteh> where develtag is a timestamp
@ -201,6 +211,8 @@ Hermann has written an rfc for version numbers.
could be automatized) could be automatized)
23:26 <cehteh> remember in test.sh i reserved the 90-99* area for 'bugs' 23:26 <cehteh> remember in test.sh i reserved the 90-99* area for 'bugs'
23:26 <cehteh> we may put some blocking tests there which prevent staging 23:26 <cehteh> we may put some blocking tests there which prevent staging
----------------------------
Next meeting Next meeting
------------ ------------

41
doc/devel/meeting_summary/2011-04-13.txt
View file

@ -16,9 +16,12 @@ _Protocol written by Ichthyo_
.organisational .organisational
- IRC meeting summaries will be moved into the main Git tree, below 'doc/devel' - IRC meeting summaries will be moved into the main Git tree, +
- mostly shortened and tidied IRC logs, plus summary of conclusions \+ decisions below 'doc/devel'
- ``winter quarterly coding news'': this time just paste _Ichthyo's_ contribution into the website - mostly shortened and tidied IRC logs, +
plus summary of conclusions + decisions
- ``winter quarterly coding news'': +
this time just paste _Ichthyo's_ contribution into the website
- the next ``coding news'' probably in May? - the next ``coding news'' probably in May?
@ -344,17 +347,18 @@ _Cehteh_ points out that this new policy should at least be anounced on the Mail
Recurring Topic: Design process entries Recurring Topic: Design process entries
--------------------------------------- ---------------------------------------
Discussion of open link:/documentation/devel/rfc.html[design process] drafts. Discussion of open link:/x/DesignProcess.html[design process] drafts.
Since some time, no further discussion happened regarding the currently _pending_ Since some time, no further discussion happened regarding the currently _pending_
RfC entries. Agreement is that we should again return to the former routine and RfC entries. Agreement is that we should again return to the former routine and
revisit the relevant design process entries in each developer meeting. revisit the relevant design process entries in each developer meeting.
-> link:{rfc}/ApplicationInstall.html[RfC: Application Install]
.-- the Application Install proposal -- .-- the Application Install proposal --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
[2011-04-14 00:48:25] <cehteh> link:{ldoc}/devel/rfc_pending/ApplicationInstall.html [2011-04-14 00:48:25] <cehteh> the pending ApplicationInstall RfC
[2011-04-14 00:48:40] <ichthyo> maybe only pick out some interestin ones or some which are quick to decide [2011-04-14 00:48:40] <ichthyo> maybe only pick out some interestin ones or some which are quick to decide
[2011-04-14 00:49:06] <cehteh> well i want to go over all pending .. then we can put notes there "boring for the next meeting" [2011-04-14 00:49:06] <cehteh> well i want to go over all pending .. then we can put notes there "boring for the next meeting"
[2011-04-14 00:49:42] <cehteh> for example this application install .. is boring .. you did a lot work, imo you can finalize it [2011-04-14 00:49:42] <cehteh> for example this application install .. is boring .. you did a lot work, imo you can finalize it
@ -372,7 +376,9 @@ revisit the relevant design process entries in each developer meeting.
Delectus Shot Evaluator Delectus Shot Evaluator
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
Agreement to _park_ it until someone else comes up to advance this topic further. Agreement to _park_
link:{rfc}/DelectusShotEvaluator.html[the »Delectus« RfC], +
until someone else comes up to advance this topic further.
Clip Cataloging System Clip Cataloging System
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
@ -386,6 +392,7 @@ Keep _pending_ -- _ichthyo_ will expand on that
Lumiera Forward Iterator Lumiera Forward Iterator
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/LumieraForwardIterator.html[RfC]
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
@ -405,6 +412,7 @@ Lumiera Forward Iterator
Design the Render Nodes interface Design the Render Nodes interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/DesignRenderNodesInterface.html[RfC]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
@ -421,7 +429,8 @@ Design the Render Nodes interface
Developer Documentation Structure Developer Documentation Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--> see link:https://issues.lumiera.org/ticket/763[Ticket #763] - -> link:{rfc}/DeveloperDocumentationStructure.html[RfC]
- -> see link:https://issues.lumiera.org/ticket/763[Ticket #763]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
@ -440,6 +449,7 @@ Developer Documentation Structure
Engine Interface Overview Engine Interface Overview
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/EngineInterfaceOverview.html[RfC]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
@ -464,12 +474,14 @@ Engine Interface Overview
Feature Bundle Feature Bundle
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Expected to be very important in the far future, but we don't have the This link:{rfc}/FeatureBundle_PluggableModules.html[RfC: Reature Bundle]
is expected to be very important in the far future, but we don't have the
resources to work on that right now, so _park_ it. resources to work on that right now, so _park_ it.
Marble Mode Marble Mode
~~~~~~~~~~~ ~~~~~~~~~~~
-> link:{rfc}/MarbleMode.html[RfC: Marble Mode]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
@ -492,7 +504,8 @@ Marble Mode
Normalized Device Coordinates Normalized Device Coordinates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
still very rough, but basically agreed. + The proposal for link:{rfc}/NormalizedDeviceCoordinates.html[Normalized Device Coordinates]
is still very rough, but basically agreed upon.
While it needs more work, it's a bit out of focus right now, so _park it. While it needs more work, it's a bit out of focus right now, so _park it.
@ -509,6 +522,8 @@ link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal
Render Optimizer, Resource Management and Profiling Render Optimizer, Resource Management and Profiling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- -> link:{rfc}/ResourceManagementProfiling.html[RfC: Profiling]
- -> link:{rfc}/ResourceManagementBudgeting.html[RfC: Budgeting]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
@ -545,12 +560,13 @@ Render Optimizer, Resource Management and Profiling
Roadmap Roadmap
~~~~~~~ ~~~~~~~
The link:{rfc}/rfc/Roadmap-first.html[Roadmap document] The link:{rfc}/Roadmap-first.html[Roadmap document]
was erroneously not marked as final; + was erroneously not marked as final; +
Seemingly it was decided upon in 2009 already ... Seemingly it was decided upon in 2009 already ...
Stream Type System Stream Type System
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
-> link:{rfc}/StreamTypeSystem.html[RfC]
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
@ -577,6 +593,8 @@ Stream Type System
Threads Signals and important management tasks Threads Signals and important management tasks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/ThreadsSignalsAndImportantManagementTasks.html[RfC]
.-- Discussion of details -- .-- Discussion of details --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
@ -620,7 +638,8 @@ in multiple timelines. We pretty much agree on that, thus it counts as _finalise
Use Cases Use Cases
~~~~~~~~~ ~~~~~~~~~
This is an heavyweight proposal regarding the high-level design and general handling of the -> link:{rfc}/UseCases.html[This RfC]
is a heavyweight proposal regarding the high-level design and general handling of the
Application. This would be really a topic to be discussed in conjection with the ``Workflow'' Application. This would be really a topic to be discussed in conjection with the ``Workflow''
-- the idea was to have a working group focussed these topics entirely, but there is no one -- the idea was to have a working group focussed these topics entirely, but there is no one
in charge of that right now. Thus _park_ it for the time being. in charge of that right now. Thus _park_ it for the time being.

4
doc/devel/meeting_summary/2012-09-12.txt
View file

@ -86,7 +86,6 @@ Workflow between the Master and the Documentation repository
There was some confusion how the master and the documentation There was some confusion how the master and the documentation
repository relate to each other. repository relate to each other.
We agreed on merging back and forth between in a bidirectional way, We agreed on merging back and forth between in a bidirectional way,
but doing this lazy on demand. but doing this lazy on demand.
@ -104,8 +103,7 @@ information and documentation will appear at
https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org] https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org]
soon. Stay tuned. soon. Stay tuned.
Thanks to Lenny for helping with the documentation and Simon for the Thanks to Lenny for helping with the documentation and Simon for the Logo.
Logo.

4
doc/devel/meeting_summary/2023-09-13.txt
View file

@ -92,7 +92,7 @@ integrated into the website infrastructure.
Library solutions for Video Display Library solutions for Video Display
----------------------------------- -----------------------------------
_Benny_ conducted some research regarding library solutions for *video display*, notably _Benny_ conducted some research regarding library solutions for *video display*, notably
ffmpeg, GStreamer and libVLC. It was rather easy to code up an "hello world" example based on ffmpeg, GStreamer and libVLC. It was rather easy to code up an ``hello world'' example based on
GStreamer, while it was difficult to find suitable documentation regarding the ffmpeg based GStreamer, while it was difficult to find suitable documentation regarding the ffmpeg based
solution. Moreover, GStreamer seems to have a much more active and helpful community. solution. Moreover, GStreamer seems to have a much more active and helpful community.
@ -116,7 +116,7 @@ support framework.
Next meeting Next meeting
------------ ------------
The next meeting will be Wednesday Oct 11, 20:00 UTC. The next meeting will be Wednesday **Oct 11, 20:00 UTC**.
You are welcome to join. You are welcome to join.
'''' ''''

2
doc/devel/meeting_summary/2023-10-11.txt
View file

@ -65,7 +65,7 @@ but a replacement solution was identified, which still needs to be integrated.
Next meeting Next meeting
------------ ------------
The next meeting will be Wednesday Nov 8, 20:00 UTC. The next meeting will be Wednesday **Nov 8, 20:00 UTC**.
You are welcome to join. You are welcome to join.
'''' ''''

2
doc/devel/meeting_summary/2023-11-08.txt
View file

@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI.
Next meeting Next meeting
------------ ------------
The next meeting will be Wednesday Dec 13, 20:00 UTC. The next meeting will be Wednesday **Dec 13, 20:00 UTC**.
You are welcome to join. You are welcome to join.
'''' ''''

2
doc/devel/meeting_summary/2024-01-10.txt
View file

@ -78,7 +78,7 @@ process and resource management within the Lumiera render engine itself.
Next meeting Next meeting
------------ ------------
The next Lumiera meeting is scheduled for Wednesday, Feb 14 at 20:00 UTC. The next Lumiera meeting is scheduled for Wednesday, **Feb 14 at 20:00 UTC**.
Should this be inconvenient for you, please speak up on, for example, Should this be inconvenient for you, please speak up on, for example,
link:http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera[lumiera@lists.lumiera.org] link:http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera[lumiera@lists.lumiera.org]
and let us know of when you would prefer to attend. and let us know of when you would prefer to attend.

4
doc/devel/meeting_summary/index.txt
View file

@ -326,7 +326,7 @@ Topics
~~~~~~ ~~~~~~
* organisational (protocol, agenda, leftovers?) * organisational (protocol, agenda, leftovers?)
* Logo Contest progress, discussion about how to do the pre selection * Logo Contest progress, discussion about how to do the pre selection
* rename "EDL" into "Sequence" * rename »EDL« into »Sequence«
* link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] * link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output]
* GUI/Proc Interface and collaboration * GUI/Proc Interface and collaboration
* Threading questions regarding gtk-main and main() * Threading questions regarding gtk-main and main()
@ -500,7 +500,7 @@ Topics
~~~~~~ ~~~~~~
* boilerplate (protocol, whats left from last meeting, next meeting) * boilerplate (protocol, whats left from last meeting, next meeting)
* Go through Ideas and Drafts in design process * Go through Ideas and Drafts in design process
* "Call for design" for some features relevant for the whole Application: * ``Call for design'' for some features relevant for the whole Application:
- parameters and automation - parameters and automation
- render node interface - render node interface
- handling of compound sessions - handling of compound sessions

20
doc/devel/rfc/AllPluginInterfacesAreC.txt
View file

@ -1,12 +1,12 @@
Design Process : All Plugin Interfaces Are C Design Process : All Plugin Interfaces Are C
============================================ ============================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2007-06-29_ |*Date* | _2007-06-29_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
@ -39,7 +39,7 @@ Implementation Proposal
* first member is a _size_ which will be initialized by the actual * first member is a _size_ which will be initialized by the actual
implementation implementation
* followed by function pointers defining the interface, see: * followed by function pointers defining the interface, see:
link:{ldoc}/devel/rfc/CCodingStyleGuide.html[C-coding style guide] link:{rfc}/CCodingStyleGuide.html[C-coding style guide]
* everything added is considered immutable for this interface version * everything added is considered immutable for this interface version
* new functions are added to the end (thus changing size) * new functions are added to the end (thus changing size)
@ -162,7 +162,7 @@ outweigh the drawbacks.
ct:: '2007-07-03 05:51:06' ct:: '2007-07-03 05:51:06'
C is the only viable choice here. Perhaps some sort of "test bench" could be C is the only viable choice here. Perhaps some sort of ``test bench'' could be
designed to rigorously test plugins for any problems which may cause Lumiera to designed to rigorously test plugins for any problems which may cause Lumiera to
become unstable (memory leaks etc). become unstable (memory leaks etc).
@ -185,7 +185,7 @@ Ichthyostega:: '2023-10-24 22:55:23'
Conclusion Conclusion
---------- ----------
Initially there was agreement over the general direction set out by this proposal. Initially there was agreement over the general direction set out by this proposal.
However, _Ichthyo_ was always sceptical regarding the benefits of a generic plug-in However, _Ichthyo_ was always skeptical regarding the benefits of a generic plug-in
Architecture. Experience with high-profile projects based on such a concept seem Architecture. Experience with high-profile projects based on such a concept seem
to show both tremendous possibilities, especially regarding user involvement, but to show both tremendous possibilities, especially regarding user involvement, but
at the same time also indicate serious problems with long-term sustainability. at the same time also indicate serious problems with long-term sustainability.
@ -205,4 +205,4 @@ https://issues.lumiera.org/report/17[»Focus Topics«] for further development.
......... .........
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

20
doc/devel/rfc/ApplicationInstall.txt
View file

@ -3,12 +3,12 @@ ApplicationInstall
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _Di 11 Jan 2011 17:00:55 CET_ |*Date* | _Di 11 Jan 2011 17:00:55 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
[abstract] [abstract]
********************************************************************************* *********************************************************************************
@ -121,7 +121,7 @@ Tasks
* build the executables in a way to allow relative resolution of the * build the executables in a way to allow relative resolution of the
internal shared modules ([green]#✔ done#) internal shared modules ([green]#✔ done#)
* replace the compiled-in path definitions for plugin loading by a * replace the compiled-in path definitions for plugin loading by a
configurable bootstrap ([green]#✔#) configurable bootstrap ([green]#✔ done#)
* add an working library implementation for a config loader ([green]#✔ done#) * add an working library implementation for a config loader ([green]#✔ done#)
* add a mechanism for establishing the path of the current execubable. + * add a mechanism for establishing the path of the current execubable. +
This is _non-portable_ ([green]#✔ done#) This is _non-portable_ ([green]#✔ done#)
@ -130,7 +130,7 @@ Tasks
* try to extract the path search code from the existing config loader, * try to extract the path search code from the existing config loader,
or build a new solution based on standard libraries ([green]#✔ done#) or build a new solution based on standard libraries ([green]#✔ done#)
* introduce an output root directory into the buildsystem, allowing * introduce an output root directory into the buildsystem, allowing
for package builds ([green]#✔#) for package builds ([green]#✔ done#)
* define a _Debian packaging_ as proof-of-concept ([green]#✔ done#) * define a _Debian packaging_ as proof-of-concept ([green]#✔ done#)
@ -199,7 +199,7 @@ as they are known to lead to maintenance problems.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -219,7 +219,7 @@ which reminded me of several small issues, which seem to become unhealthy when l
around unfixed for such a long time. Probably I'll start a clean-up initiative and around unfixed for such a long time. Probably I'll start a clean-up initiative and
try to bring these points to discussion separately. try to bring these points to discussion separately.
So 13 Feb 2011 20:04:00 CET Ichthyostega <prg@ichthyostega.de> Ichthyostega:: 'So 13 Feb 2011 20:04:00 CET'
//endof_comments: //endof_comments:

90
doc/devel/rfc/ApplicationStructure.txt
View file

@ -1,12 +1,13 @@
Design Process : Application Structure Design Process : Application Structure
====================================== ======================================
[grid="all"]] [options="autowidth"]
`------------`---------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2008-11-05_ |*Date* | _2008-11-05_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------ |====================================
Application Structure Application Structure
--------------------- ---------------------
@ -20,8 +21,8 @@ So far we came up with a simplified BACKEND/PROC/GUI structure where each of
this entities defines its own sub subcomponents. We agreed to glue that all this entities defines its own sub subcomponents. We agreed to glue that all
together with some portable versioned interfaces system, but details where not together with some portable versioned interfaces system, but details where not
laid out yet. At the time of this writing the interface system and plugin laid out yet. At the time of this writing the interface system and plugin
loader are reasonable finished to be usable (some small refinements to do). We loader are reasonable finished to be usable (some small refinements to do).
recently discussed some details on IRC on how to engage this without a We recently discussed some details on IRC on how to engage this without a
definitive decision. The topic of this proposal is to make a detailed definitive decision. The topic of this proposal is to make a detailed
description towards how the application components being glued together. description towards how the application components being glued together.
@ -31,12 +32,12 @@ this parts are actually be, except that the GUI should be optional for headless
operation. I suggested to make as much as possible pluginable to make it easier operation. I suggested to make as much as possible pluginable to make it easier
to validate our interfaces and try different things out. to validate our interfaces and try different things out.
Now I introduce 'lumiera' here, this will become a new component in Now I introduce `"lumiera"` here, this will become a new component in
./src/lumiera being the driver application for bootstraping all the rest: `./src/lumiera` being the driver application for bootstraping all the rest:
Then our application structure looks somewhat like (please refine): Then our application structure looks somewhat like (please refine):
* the 'lumiera' loader * the Lumiera loader
- commandline handling - commandline handling
- interface & plugin system - interface & plugin system
- session manager core - session manager core
@ -60,24 +61,24 @@ Then our application structure looks somewhat like (please refine):
- preferences - preferences
- ... - ...
Furthermore the interface&plugin system is flexible enough to provide things Furthermore the interface and plugin system is flexible enough to provide things
independently of their origin (if it is build in or a plugin/dynamic library). independently of their origin (if it is build in or a plugin/dynamic library).
So deployment (where to link these things) is secondary. So deployment (where to link these things) is secondary.
'lumiera' will then be the executable the user starts up, what exactly gets `"lumiera"` will then be the executable the user starts up,
initialized and booted up is then matter what exactly gets initialized and booted up is then matter
of configuration and commmandline options (and maybe lua scripting?). of configuration and commandline options (and maybe Lua scripting?).
Tasks Tasks
^^^^^ ^^^^^
* create the 'lumiera' directory * create the `lumiera` directory
- setup the build system - setup the build system
- move config, plugin and interfaces therein - move config, plugin and interfaces therein
- lua support can be done later - Lua support can be done later
* write the main() part of the application * write the `main()` part of the application
- start config system - start config system
- parse commandline opts - parse commandline opts
* librificate all other components (backend, proc gui) * librificate all other components (backend, proc gui)
@ -92,17 +93,17 @@ Pros
^^^^ ^^^^
* flexible plugin based architecture * flexible plugin based architecture
- later: loads only things which are necessary for a given task ** later: loads only things which are necessary for a given task
* very fast startup * very fast startup
* things which cant be used on a given environment can be left out (no gui on * things which can't be used on a given environment can be left out (no gui on
a headless system, no $DISPLAY set) a headless system, no `$DISPLAY` set)
* inter dependencies between interfaces and plugins are automatically tracked. * inter dependencies between interfaces and plugins are automatically tracked.
Cons Cons
^^^^ ^^^^
Ichthyo raised concerns that this kind of flexibility might attract other _Ichthyo_ raised concerns that this kind of flexibility might attract other
people to write things which are not in our intention and break future design people to write things which are not in our intention and break future design
and compatibility. We need to carefully document and define interfaces that and compatibility. We need to carefully document and define interfaces that
people don't abuse those! people don't abuse those!
@ -112,7 +113,7 @@ people don't abuse those!
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
We discussed the startup/main() through the GUI as it is currently done, it We discussed the startup / `main()` through the GUI as it is currently done, it
would be also possible to produce some more executables (lumigui, luminode, would be also possible to produce some more executables (lumigui, luminode,
lumiserver, ....). But I think we agreed that a common loader is the best way lumiserver, ....). But I think we agreed that a common loader is the best way
to go. to go.
@ -122,7 +123,7 @@ Rationale
~~~~~~~~~ ~~~~~~~~~
I just think this is the best way to ensure a enduring design even for future I just think this is the best way to ensure a enduring design even for future
changes we can not forsee yet. changes we can not foresee yet.
@ -139,19 +140,21 @@ agreed on it.
From reading the above text, this proposal seems to capture that. But I am From reading the above text, this proposal seems to capture that. But I am
somewhat unsure if the purpose of this proposal isn't rather to load just a somewhat unsure if the purpose of this proposal isn't rather to load just a
micro kernel and the pull up components according to configuration. Because I *micro kernel* and then pull up components according to configuration. Because
wouldn't accept such an architecture, and I clearly stated so right at the I wouldn't accept such an architecture, and I clearly stated so right at the
beginning of our project. I accepted a very flexible and language neutral beginning of our project. I accepted a very flexible and language neutral
plugin system on the condition the core remains in control, stays plugin system on the condition that the core remains in control, stays
''reasonable'' monolithic and componentization doesn't handicap us in creating ``reasonable'' monolithic and componentization doesn't handicap us in creating
an architecture based on abstractions and exploiting the proven design an architecture based on abstractions and exploiting the proven design
patterns. patterns.
Ichthyo:: '2008-11'
It has that flexibility, yes. But that means not that we have to abuse it in It has that flexibility, yes. But that means not that we have to abuse it in
any way. The main() there and thus the bootstrap of the application is under any way. The main() there and thus the bootstrap of the application is under
our tight control, if we want to reject scriptable/highly configurable our tight control, if we want to reject scriptable/highly configurable
bootstrapping there then we can just do so. Thats more a social than a bootstrapping there then we can just do so. Thats more a social than a
technical decision. I personally don't like if a design is 'nannying' and puts technical decision. I personally don't like if a design is ``nannying'' and puts
too much constraints into unforeseen areas. If the computer can do some task too much constraints into unforeseen areas. If the computer can do some task
better than we, it shall do it. This still means that I want to stay very much better than we, it shall do it. This still means that I want to stay very much
in control, it should only do some tedious, error-prone managing tasks for me. in control, it should only do some tedious, error-prone managing tasks for me.
@ -161,40 +164,43 @@ define anything. The interface system gets it right and we wont need to care
for the order initialization. I added that because I consider such as for the order initialization. I added that because I consider such as
absolutely important for plugins which might be supplied by third parties where absolutely important for plugins which might be supplied by third parties where
we have no control over. But I now realized that we can nicely use that for our we have no control over. But I now realized that we can nicely use that for our
own internal things too. Imo thats some very valuable service. own internal things too. IMO thats some very valuable service.
-- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]]
ct:: '2008-11-08T06:26:18Z'
Some further minor details: We didn't finish the discussion about namespaces on Some further minor details: We didn't finish the discussion about namespaces on
the last meeting. (I know I still have to write up a proposal showing the two the last meeting. (I know I still have to write up a proposal showing the two
or three alternatives I see regarding namespace organisation). But probably, or three alternatives I see regarding namespace organisation). But probably,
"lumiera::" will be our top level interface namespace and then probably the `"lumiera::"` will be our top level interface namespace and then probably the
lumiera directory will be taken by that. I see no problem also putting some `./lumiera` directory will be taken by that. I see no problem also putting some
startup facilities in there, but generally, it shouldn't contain implementation startup facilities in there, but generally, it shouldn't contain implementation
code, only headers and abstract classes. If that's going to become a problem, code, only headers and abstract classes. If that's going to become a problem,
we should consider to use a separate package for the startup, e.g. "src/boot". we should consider to use a separate package for the startup, e.g. "src/boot".
Another point is, you need not write a main, because there is already one. Another point is, you need not write a `main()`, because there is already one.
Please have a look at it, especially with regards to the Please have a look at it, especially with regards to the
[wiki:self:../GlobalInitialization global initialisation]. Further, last year link:{rfc}/GlobalInitialization.html[global initialisation]. Furthermore, last year
I've investigated boost::program_options and think it's fine. I use it for my I've investigated boost::program_options and think it's fine. I use it for my
test class runner since then. I don't think there is any reason why we should test class runner since then. I don't think there is any reason why we should
bother with parsing options (most config is pulled up from the session). I bother with parsing options (most config is pulled up from the session). I
don't think we get much program options, maybe something to set a GUI skin. don't think we get much program options, maybe something to set a GUI skin.
Moreover, I've written last year a thin wrapper around the commandline and Moreover, I've written last year a thin wrapper around the commandline and
integrated it with the boost options parser such that user code can receive the integrated it with the boost options parser such that user code can receive the
remaining options as a vector of std::strings. Please have a look at remaining options as a vector of `std::string`s. Please have a look at
link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main] https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main]
for an usage example. I really want our Lumiera main to be clean and expressive for an usage example. I really want our Lumiera main to be clean and expressive
in the way showed there. Probably the most important part of the startup is in the way showed there. Probably the most important part of the startup is
pulling up the session core; because of that I think most of the startup pulling up the session core; because of that I think most of the startup
process falls into the realm of the Proc-Layer. Within Proc, I don't want any process falls into the realm of the Proc-Layer. Within Proc, I don't want any
significant string manipulations done with C-strings and I don't want raw significant string manipulations done with C-strings and I don't want raw
arrays when we can use std::vector. arrays when we can use std::vector.
-- link:Ichthyostega[] [[DateTime(2008-11-06T19:28:13Z)]]
I 'dropped' this now because we do it somewhat differently now and I dont want Ichthyostega:: '2008-11-06T19:28:13Z'
to document this here :P
-- link:ct[] [[DateTime(2009-02-03T17:28:28Z)]] I _dropped_ this now because we do it somewhat differently now and I don't want
to document this here 😛
ct:: '2009-02-03T17:28:28Z'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

39
doc/devel/rfc/ArchitectureOverview.txt
View file

@ -1,12 +1,12 @@
Architecure Overview Architecure Overview
==================== ====================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-03-06_ |*Date* | _2008-03-06_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Architecure Overview Architecure Overview
-------------------- --------------------
@ -15,7 +15,8 @@ This proposal intends to capture envisioned Architecture of the Application.
image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture] image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture]
^The SVG source of this drawing is ^The SVG source of this drawing is
link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^ https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]·
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=HEAD[(current: 2022)]^
Description Description
@ -33,7 +34,7 @@ Description
* the user/GUI manipulates a high-level model whereas rendering is based on a * the user/GUI manipulates a high-level model whereas rendering is based on a
corresponding low-level model corresponding low-level model
* stored Session (state) is comprised of high-level model, a collection of * stored Session (state) is comprised of high-level model, a collection of
Assets and accompaning configuration Assets and accompanying configuration
* (possibly) several storage backends, abstracted out by a common interface * (possibly) several storage backends, abstracted out by a common interface
@ -52,27 +53,29 @@ Comments
the next scene to appear relative to the last scene played. In the first, the next scene to appear relative to the last scene played. In the first,
you want to keep the scenes always synced up against the audio, while in the you want to keep the scenes always synced up against the audio, while in the
latter, you just want the scenes to appear one after another. latter, you just want the scenes to appear one after another.
--- link:PercivalTiglao[] [[DateTime(2008-07-16T05:32:45Z)]]
PercivalTiglao:: '2008-07-16T05:32:45Z'
* Yes, indeed, that is what I am planning. The drawing above just doesn't show * Yes, indeed, that is what I am planning. The drawing above just doesn't show
every connection. The interaction between high-level model and rules system every connection. The interaction between high-level model and rules system
mostly goes via the "session defaults", which are facts ''and'' rules. Thus, mostly goes via the ``session defaults'"'', which are facts _and_ rules. Thus,
in your example, the user would just use the "default placement". My in your example, the user would just use the ``default placement'"''. My
Intention was to use '''tags''' to quite some extent. The user would be able Intention was to use *tags* to quite some extent. The user would be able
to tag the source footage, and then rules can kick in when a certain tag to tag the source footage, and then rules can kick in when a certain tag
applies. Incidentally, integrating prolog is immediately on the agenda, applies. Incidentally, integrating prolog is immediately on the agenda,
because first we want to flesh out the very basic system and get to work because first we want to flesh out the very basic system and get to work
basic rendering. Until then, I use a "mock" implementation of the basic rendering. Until then, I use a _mock implementation_ of the
query/rules system, which just returns some hard wired defaults. query/rules system, which just returns some hard wired defaults.
-- link:Ichthyostega[] [[DateTime(2008-09-04T15:38:21Z)]]
Ichthyostega:: '2008-09-04T15:38:21Z'
Conclusion Conclusion
---------- ----------
Accepted. The drawing was moved into the GIT tree, hopefully it will be Accepted. The drawing was moved into the GIT tree. +
maintained in future. It was upgraded and reworked
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=0b9f2e2c3139cad542013caac593cb5972a2e3f6[in 2022]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

95
doc/devel/rfc/CCodingStyleGuide.txt
View file

@ -1,12 +1,12 @@
Design Process : C Coding Style Guide Design Process : C Coding Style Guide
===================================== =====================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-07-03_ |*Date* | _2007-07-03_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
@ -24,17 +24,17 @@ In the following I'll explain a C coding style I used frequently for other
projects. Take this as suggestion for parts written in C (it definitely makes projects. Take this as suggestion for parts written in C (it definitely makes
no sense for C++). We probably don't need to enforce this style for normal C no sense for C++). We probably don't need to enforce this style for normal C
code, but for the related code, but for the related
link:/rfc/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«] link:{rfc}/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«]
it really makes sense to have some well defined style. it really makes sense to have some well defined style.
Function names follow the rule: Function names follow the rule:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.`namespace[\_object][\_verb[\_subjects]][\_version]` .`namespace[\_object][\_verb[\_subjects]][\_version]`
* namespace is \'lumiera_\' appended with some subsystem tag * namespace is `lumiera_` appended with some subsystem tag
(`lumiera_plugin_audio_`) (`lumiera_plugin_audio_`)
* object is the type of the \'this\' object we are addressing, maybe followed * object is the type of the `this' (or `self') object we are addressing,
by the object we are returning maybe followed by the object we are returning
* verb is the action to take, (new, copy, free, set, clear,.. etc.) if omitted * verb is the action to take, (new, copy, free, set, clear,.. etc.) if omitted
the action is `get` the action is `get`
* subjects is a descriptive list of the arguments which the action takes, this * subjects is a descriptive list of the arguments which the action takes, this
@ -51,11 +51,11 @@ Prototypes follow the rule:
* function is the functionname as above * function is the functionname as above
* rettype is sensible to what object and verb define, setters return a pointer * rettype is sensible to what object and verb define, setters return a pointer
to the set'ed element if an allocation could be involved (or NULL on to the set'ed element if an allocation could be involved (or NULL on
failure), a int if the setter does some checks over the supplied argument (0 failure), a int if the setter does some checks over the supplied argument
indicates failure, !0 success), void for procedures and actions which can (`0` indicates failure, `!0` success), void for procedures and actions which can
never fail. never fail.
* Object is a pointer to refered object (\'this\' like C++) in rare cases * Object is a pointer to referred object (`this' like C++) in rare cases
(_new()) functions may be used without this self pointer, see below (`_new()`) functions may be used without this self pointer, see below
* `...` are the types and names of the arguments described in `subjects` of the * `...` are the types and names of the arguments described in `subjects` of the
name. name.
@ -76,9 +76,9 @@ typedef const namespace_foo ** const_NamespaceFoo_ref; // same for const object
Examples: Examples:
+++++++++ +++++++++
.`lumiera_plugin_audio_sample_normalize_limit_1 (AudioSample self, int limit)` .`lumiera_plugin_audio_sample_normalize_limit_1 (AudioSample self, int limit)`
* namespace is \'lumiera_plugin_audio\' * namespace is `lumiera_plugin_audio`
* operates on a \'sample\' object (and likely returns a pointer) * operates on a `sample' object (and likely returns a pointer)
* operation is \'normalize\' * operation is `normalize`
* takes one additional parameter describing the limit for normalization * takes one additional parameter describing the limit for normalization
* this is a version 1 interface we later define: * this is a version 1 interface we later define:
@ -97,9 +97,6 @@ Examples:
Tasks
^^^^^
Pros Pros
^^^^ ^^^^
@ -130,20 +127,20 @@ overhead to encode arguments to functionnames. But the intention here is to
make code easy readable and memorizeable, when one follows this scheme one does make code easy readable and memorizeable, when one follows this scheme one does
seldom need to lookup the docs about the API. In fact it sometimes even turns seldom need to lookup the docs about the API. In fact it sometimes even turns
out that one wants to use a functionname which isn't defined in the API, which out that one wants to use a functionname which isn't defined in the API, which
is a good indicator to add such to to the API. is a good indicator to add such a missing function to the API.
This scheme is not fully unambiguous but suffices for all practical task. It This scheme is not fully unambiguous but suffices for all practical task. It
encodes parameters like C++ does for overloading without strange mangling. All encodes parameters like C++ does for overloading without strange mangling. All
names are global in a well defined namespace which is very natural for C (other names are global in a well defined namespace which is very natural for C (other
OO like C styles involve structs and hand written vtables, with this scheme we OO like C styles involve structs and hand written CTables, with this scheme we
trampoline from this global names to vtables *only* if needed) trampoline from this global names to VTables _only if needed_)
Conclusion Conclusion
---------- ----------
Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06 Finalized at the link:{ldoc}/devel/meeting_summary/2008-03-06.html[2008-03-06 developer meeting]
@ -151,61 +148,69 @@ Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06
Comments Comments
-------- --------
I strongly object promoting such a thing as a general "Style Guide". It can be I strongly object promoting such a scheme as a general ``Style Guide''. It can be
a help or last resort if you are forced to work with improper tools (a a help or last resort if you are forced to work with improper tools (a
situation that's rather frequent in practice though). __As such it is well situation that's rather frequent in practice though). __As such it is well
chosen and practical__. chosen and practical__, however.
But basically, it shows several things: But basically, it shows several things:
* you are using a global namespace * you are using a global namespace
* you deal with way to fat interfaces * you deal with way to fat interfaces
* you mix deployment metadata (a version/compatibility check) with functional * you mix deployment metadata (a version/compatibility check) with functional
code code
All of this indicates some design style breakage, so it would be preferable to All of this indicates some design style breakage, so it would be preferable to
fix the design if possible. fix the design if possible.
The only part I'd like to support as a Style Guide is the rule of using the The only part I'd like to support as a Style Guide is the rule of using the
"verb+object" pattern for creating function names "verb+object" pattern for creating function names
-- link:Ichthyostega[] [[DateTime(2007-07-08T11:42:39Z)]]
Ichthyostega:: '2007-07-08T11:42:39Z'
Probably needs little explanation: Probably needs little explanation:
* you are using a global namespace * you are using a global namespace
This is only about C for names which get exported, C only has a global
** This is only about C for names which get exported, C only has a global
namespace and we need some way to get unique names. The namespace and we need some way to get unique names. The
link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] already uses link:{rfc}/AllPluginInterfacesAreC.html[RfC: Plugin Interfaces in C]
better/smaller namespaces by defining interfaces as C structs. The full blown already uses better/smaller namespaces by defining interfaces as C structs.
long names explained here are technically not needed when we use the plugin The full blown long names explained here are technically not needed when we use
system as proposed, I just shown them here for completeness. Next, when we the plugin system as proposed, I just shown them here for completeness. Next,
decide for alternative linking methods like static builds we would need to when we decide for alternative linking methods like static builds we would need to
declare all "verb+object" functions static, else there is a high probability of declare all "verb+object" functions static, else there is a high probability of
clashes. clashes.
* you deal with way to fat interfaces * you deal with way to fat interfaces
How can you tell that? This is only a nameing style. No interfaces mentioned
** How can you tell that? This is only a nameing style. No interfaces mentioned
here. I am all after small well defined specialized interfaces. here. I am all after small well defined specialized interfaces.
* you mix deployment metadata (a version/compatibility check) with functional * you mix deployment metadata (a version/compatibility check) with functional code
code
Yes, I cant figure out how to do it better but still lightweight in C. the ** Yes, I cant figure out how to do it better but still lightweight in C. the
_version thing is something I added here after the interfaces proposal. I work `_version` thing is something I added here after the interfaces proposal. I work
on a example how this will be used in a more friendly way. on a example how this will be used in a more friendly way.
Note again that this is a "nameing system", it is intended to be very verbose Note again that this is a ``naming system'', it is intended to be very verbose
and give unique declarative names. It is not about design! Design is done as and give unique declarative names. It is not about design! Design is done as
usual and only when things have to be exported as C symbols (both, exported and usual and only when things have to be exported as C symbols (both, exported and
C!!) this applies. This has zero implication for C++ code, zero implication C!!) this applies. This has zero implication for C++ code, zero implication
for C functions which are not exported (while I personally still prefer this for C functions which are not exported (while I personally still prefer this
style) and finally when we do the interfaces thing like I proposed, then the style) and finally when we do the interfaces thing like I proposed, then the
naming can be much simpler, see examples there or in my repository. naming can be much simpler, see examples there or in my repository.
-- link:ct[] [[DateTime(2007-07-10T08:03:06Z)]]
ct:: '2007-07-10T08:03:06Z'
Thanks, your explanation together with the example in git made the usage Thanks, your explanation together with the example in git made the usage
pattern much more clear. I think the _version postfix is esp. helpful on the pattern much more clear. I think the `_version` postfix is esp. helpful on the
names of the plugin interfaces (structs in C), and probably it will be a good names of the plugin interfaces (structs in C), and probably it will be a good
practice, to have one such common plugin interface on every "plugin extension practice, to have one such common plugin interface on every ``plugin extension
point", i.e. every point in the sytem, that can be extended by plugins. point'', i.e. every point in the system, that can be extended by plugins.
-- 217.110.94.1 [[DateTime(2007-07-10T17:23:33Z)]]
Ichthyostega:: '2007-07-10T17:23:33Z'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

75
doc/devel/rfc/ClipCatalogingSystem.txt
View file

@ -1,12 +1,12 @@
Design Process : Clip Cataloging System Design Process : Clip Cataloging System
======================================= =======================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-07-26_ |*Date* | _2008-07-26_
*Proposed by* link:JordanN[] |*Proposed by* | JordanN
------------------------------------- |====================================
Clip Cataloging System Clip Cataloging System
----------------------- -----------------------
@ -22,7 +22,7 @@ Organizations that work with video, and even home users, tend to have massive
collections of stock videos and images that they will need to find and use in collections of stock videos and images that they will need to find and use in
their projects. A Linux-based system is needed to help them to organize, tag, their projects. A Linux-based system is needed to help them to organize, tag,
and retrieve assets from those collections. Being able to find the clips the and retrieve assets from those collections. Being able to find the clips the
user needs and bring them into his timeline, will mean that the user will be user needs, and to bring them into his timeline, will mean that the user will be
able to more rapidly complete his project. able to more rapidly complete his project.
This could be implemented as a separate application, but integrated for use in This could be implemented as a separate application, but integrated for use in
@ -57,8 +57,6 @@ them correctly. Not clip-based, so the entire video must be imported and the
desired portion selected. desired portion selected.
Rationale
~~~~~~~~~
Comments Comments
@ -69,40 +67,49 @@ Comments
development power to do that now. If someone wants to work on that, please development power to do that now. If someone wants to work on that, please
contact me. General idea is to put all kinds of resources (Footage, Clips, contact me. General idea is to put all kinds of resources (Footage, Clips,
Effects, Subprojects, Sounds ....) into a database with then gets Effects, Subprojects, Sounds ....) into a database with then gets
tagged/attributed in different ways (implicit things like 'filename', 'type', tagged/attributed in different ways (implicit things like `filename', `type',
'length'; automatic deduceable things like 'Exposure', 'Timecode', ...; And `length'; automatic deducible things like `Exposure', `Timecode', ...; And
manual tags like: who was on set, location, ....). Then present this all in a manual tags like: who was on set, location, ...). Then present this all in a
*good* GUI (by default just showing filesysten like) but one can define *good* GUI (by default just showing filesysten like) but one can define
queries on this database and the generated views will then be storeable. queries on this database and the generated views will then be storeable.
Back to Lumiera, for now we will likely just use 'normal' file open dialogs
Back to Lumiera, for now we will likely just use ``normal'' file open dialogs
until the above system becomes available. until the above system becomes available.
-- link:ct[] [[DateTime(2008-07-26T08:31:42Z)]]
* Yes, it's indeed an important feature we should care for. But cehteh is ct:: '2008-07-26T08:31:42Z'
* Yes, it's indeed an important feature we should care for. But _cehteh_ is
right, we have more important things to do first. But feel free to target it. right, we have more important things to do first. But feel free to target it.
* Also, we'd need integration with production support systems, for example * Also, we'd need integration with production support systems, for example
http://celtx.com/[CELTX]. http://celtx.com/[CELTX].
* The interface to the Lumiera App would be to populate the asset manager with * The interface to the Lumiera App would be to populate the asset manager with
the required assets the required assets
-- link:Ichthyostega[] [[DateTime(2008-07-27T22:19:38Z)]]
Ichthyostega:: '2008-07-27T22:19:38Z'
Videos, Audio, Clips and Resources Manager by using plugins for FOSS GPL Connect to existing FOSS applications by plugin
"Library & Collections Management" programs. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The video and audio raw material, clips, etc could be managed using code that A Video-, Audio-, Clips and Resources Manager can be built by using plugins
is already available in project that carry out the same tasks. For example as for existing ``Library and Collections Management'' programs available under GPL,
or at least code from such applications could be used to carry out similar tasks.
For example as
library managers, or media (video, audio or CD) collections, Integrated library managers, or media (video, audio or CD) collections, Integrated
Library Systems (ILS). Library Systems (ILS).
Examples of a library management program ; Examples of a library management program:
. Kete - http://kete.net.nz/[] - https://web.archive.org/web/20080514220816/http://www.koha.org/[Koha]
. Koha - http://www.koha.org/[] · https://koha-community.org/[2025]
. link:GreenStone[] - http://www.greenstone.org/[] · https://en.wikipedia.org/wiki/Koha_(software)[Wikipedia]
. Evergreen - http://open-ils.org/faq.php[] · https://liblime.com/[LibLime (commercial)]
- https://web.archive.org/web/20080613192838/http://kete.net.nz/[Kete]
- https://www.greenstone.org/[GreenStone]
- https://evergreen-ils.org/frequently-anticipated-questions/[Evergreen]
An additional benefit to using "library" managers, is that it can handle An additional benefit to using ``library'' managers, is that it can handle
interloans, referencing of "other" (people's/organization's) libraries, interloans, referencing of ``other'' (people's / organization's) libraries,
numbering systems, descriptions, and classifications, thousands to millions of numbering systems, descriptions, and classifications, thousands to millions of
items, search systems, review and comment systems, plus the benefits of open items, search systems, review and comment systems, plus the benefits of open
source that allow the expansion of features easily. The use of task oriented source that allow the expansion of features easily. The use of task oriented
@ -113,16 +120,18 @@ working with cataloging systems for a long time is likely to do well. Plus it
can be readily improved, by people who do not have to know the first thing can be readily improved, by people who do not have to know the first thing
about how to design video editing programs. The program also gets improved about how to design video editing programs. The program also gets improved
because of it own community, which adds features or performance to Lumiera, because of it own community, which adds features or performance to Lumiera,
without even having to "drive" the development.. without even having to ``drive'' the development..
--link:Tree[][[DateTime(2008-08-27T20:38:00NZ)]].
Tree:: '2008-08-27T20:38:00NZ'
'''' ''''
Parked until someone cares Parked until someone cares
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Decided on Developer meeting Decided in link:{ldoc}/devel/meeting_summary/2011-04-13.html#_clip_cataloging_system[Developer meeting]
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter Christian Thaeter:: 'Tur 14 Apr 2011 02:52:30 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

38
doc/devel/rfc/CodingStyle.txt
View file

@ -1,12 +1,12 @@
Design Process : Coding Style Design Process : Coding Style
============================= =============================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-27_ |*Date* | _2007-06-27_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
@ -30,10 +30,10 @@ See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style
.Proposed: .Proposed:
* K&R by _ichthyo_ * K&R by _ichthyo_
* compact and well known ** compact and well known
* GNU by _cehteh_ * GNU by _cehteh_
* imo the best readability (albeit little strange) ** imo the best readability (albeit little strange)
* Lumiera might apply as official GNU project someday ** Lumiera might apply as official GNU project someday
Another question: __how to write identifiers?__ Another question: __how to write identifiers?__
@ -65,11 +65,11 @@ CT:: '2007-07-03 04:04'
Comments Comments
-------- --------
Since link:ct[] called spaces instead of tabs first, we should stick to that. I Since ct called spaces instead of tabs first, we should stick to that. I
think all other reasons will lead us to nowhere! think all other reasons will lead us to nowhere!
Although I'm used to a BSD/KNF-like coding style I will try the GNU one. After Although I'm used to a BSD/KNF-like coding style I will try the GNU one. After
all, the wikipedia page mentions no disadvantages of that style :) all, the wikipedia page mentions no disadvantages of that style 😊
MichaelPloujnikov:: '2007-06-27 17:17' MichaelPloujnikov:: '2007-06-27 17:17'
@ -77,12 +77,22 @@ MichaelPloujnikov:: '2007-06-27 17:17'
I just proposed K&R because it is widely accepted. Personally, I was never very I just proposed K&R because it is widely accepted. Personally, I was never very
fond of K&R style, I always preferred putting opening braces to the left. I fond of K&R style, I always preferred putting opening braces to the left. I
never used GNU style until now, but it looks somewhat appealing to me. (btw, never used GNU style until now, but it looks somewhat appealing to me. (btw,
ECLIPSE comes with presets for all this styles :-P ). Anyhow, I can adapt to ECLIPSE comes with presets for all this styles 😛 ). Anyhow, I can adapt to
most any style. The only thing I really dislike is using tabs (with the most any style. The only thing I really dislike is using tabs (with the
exception of database DDLs and CSound files, where tab are actually helpful) :) exception of database DDLs and CSound files, where tab are actually helpful) 😊
Ichthyo:: '2007-06-27 20:55' Ichthyo:: '2007-06-27 20:55'
Many years later -- we are still using GNU style and over time have developed
a »Lumiera flavour« which plays well with C++, templates and λ-functions.
A striking consequence is that the code looks light, favours short functions,
is rather vertically oriented and is easy to skim while scrolling.
-> see our link:/x/CodeStyle.html[Style guide].
Ichthyo:: '2025-09-05'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

45
doc/devel/rfc/ConfigLoader.txt
View file

@ -4,12 +4,12 @@ Config Loader
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-08-07_ |*Date* | _2008-08-07_
*Proposed by* **ct** |*Proposed by* | **ct**
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -67,7 +67,7 @@ Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -147,7 +147,7 @@ API
- lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. `--config-path-append=""` or `--config-path=""` - lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. `--config-path-append=""` or `--config-path=""`
* `lumiera_config_destroy(...)` * `lumiera_config_destroy(...)`
- frees all space allocated by the link:ConfigLoader[]. - frees all space allocated by the ConfigLoader.
* `lumiera_config_load(...)` * `lumiera_config_load(...)`
- reads *one* single configuration file that will include all settings from other files. - reads *one* single configuration file that will include all settings from other files.
@ -205,10 +205,12 @@ API
.foo.bar .foo.bar
======================================= =======================================
`integer_set("foo.bar", 123)` `integer_set("foo.bar", 123)`
looks up "foo.bar" looks up "foo.bar"
this returns as well file and line
it will be decided whether it's a system file or a user's config file. - this returns as well file and line
if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk - it will be decided whether it's a system file or a user's config file.
- if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk
set the value in the line. set the value in the line.
======================================= =======================================
@ -236,16 +238,15 @@ anchor:anchor_config[]lumiera_configfile
anchor:anchor_types[]provided TYPES anchor:anchor_types[]provided TYPES
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="header", cols="^,2^m,6"]
`--------------.--------------------------------------'------------------------------------------------------------ |====================================
config type C type semantic (example) |config type | C type | semantic (example)
------------------------------------------------------------------------------------------------------------------- |number |signed long long | also hex and octal (foo.bar = 12345 #comment)
number signed long long also hex and octal (foo.bar = 12345 #comment) |real |long double | differerent formats as well (foo.bar=1.2345 #comment)
real long double differerent formats as well (foo.bar=1.2345 #comment) |string |const char* | optionaly quoted string (foo.bar="this string" #this not)
string const char* optionaly quoted string (foo.bar="this string" #this not) |word |const char* | first optionaly quoted word of the config (foo.bar= first this # not)
word const char* first optionaly quoted word of the config (foo.bar= first this # not) |bool |int |common representations for bools (0,1,true,false,yes,no,on,off,set,clear)
bool int common representations for bools (0,1,true,false,yes,no,on,off,set,clear) |====================================
-------------------------------------------------------------------------------------------------------------------
... add more types on demand (ichthyo mentioned a tuple type for color triples etc.) ... add more types on demand (ichthyo mentioned a tuple type for color triples etc.)
@ -591,7 +592,7 @@ Discussion on irc
[02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin. [02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin.
[02:06] <__nasa__> Ooh [02:06] <__nasa__> Ooh
[02:06] <__nasa__> cool idea [02:06] <__nasa__> cool idea
[02:06] <cehteh> this is not really complicated to do but would give a big usage experience link:JustWorks[][TM] [02:06] <cehteh> this is not really complicated to do but would give a big usage experience JustWorks[TM]
[02:06] <__nasa__> ~/.lumi/config is the main configuration directory [02:06] <__nasa__> ~/.lumi/config is the main configuration directory
[02:06] <__nasa__> inside, there is a ~/.lumi/config/config.ini which is main configuration [02:06] <__nasa__> inside, there is a ~/.lumi/config/config.ini which is main configuration
[02:07] <cehteh> no callbacks .. the idea is that the config system is independent and nothing else need to register there, that makes it much easier [02:07] <cehteh> no callbacks .. the idea is that the config system is independent and nothing else need to register there, that makes it much easier

67
doc/devel/rfc/DataBackend.txt
View file

@ -1,12 +1,12 @@
Design Process : Data Backend Design Process : Data Backend
============================= =============================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2007-06-04_ |*Date* | _2007-06-04_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
DataBackend DataBackend
----------- -----------
@ -17,36 +17,34 @@ Description
~~~~~~~~~~~ ~~~~~~~~~~~
This just starts as braindump, I will refine it soon: This just starts as braindump, I will refine it soon:
. handle all files lumiera uses at runtime (media, edl, temp data) - handle all files lumiera uses at runtime (media, edl, temp data)
. manage filehandles, lumiera might use more more files than available - manage filehandles, lumiera might use more more files than available filehandles
filehandles - manage temporary data
. manage temporary data - do caching
. do caching - IO will be blocked where the backend tells the core where it can expect the data (not `read()`/`write()` like)
. io will be blocked where the backend tells the core where it can expect the - kindof garbage collector
data (not read()/write() like) - do prefetching
. kindof garbage collector - no/low latency for the core the prefetcher and other things ensure that data is available in time
. do prefetching - translate any input into a format which the lumiera core understands (demux, decode)
. no/low latency for the core the prefetcher and other things ensure that data - same for encoding to output formats
is available in time - offer a plugin API for encoders/decoders
. translate any input into a format which the lumiera core understands (demux, - maybe network backend for serving data to distributed rendernodes
decode) - can do some load control or management (trigger adaptive rendering if system is idle etc)
. same for encoding to output formats - pull based architecture
. offer a plugin API for encoders/decoders
. maybe network backend for serving data to distributed rendernodes
. can do some load control or management (trigger adaptive rendering if system
is idle etc)
. pull based arch
.Notes: .Notes:
* ichthyo wrote also some ideas on * ichthyo wrote also some ideas regarding
http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3/Architecture[Architecture] and a sketch/draft about http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Possibilities_at_hand[things possible in the middle layer] link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]...
Parked Parked
~~~~~~ ~~~~~~
The underlying principles remain valid, yet development took another The underlying principles remain valid, yet development took another
direction during the last years. Special frameworks for high-performance direction during the last years. Special frameworks for high-performance
asynchronous IO will be used for dedicated use cases. asynchronous IO will be used for dedicated use cases. A garbage collector
is not necessary, since Lumiera relies on deterministic memory management.
Furthermore, decoding, transcoding and encoding is handled as part of the
pipeline and not through a separate service.
Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~ Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~
@ -56,15 +54,18 @@ Comments
-------- --------
Sounds fairly complete to me Sounds fairly complete to me
-- link:Ichthyostega[] [[DateTime(2007-06-16T23:19:44Z)]]
Ichthyostega:: '2007-06-16T23:19:44Z'
Developement takes place in the repo now Developement takes place in the repo now
-- link:ct[] [[DateTime(2007-06-27T16:14:56Z)]]
ct:: '2007-06-27T16:14:56Z'
Development took another direction over the last years; Development took another direction over the last years;
the former »Backend« layer is restructured the former »Backend« layer is called »Vault« now and structured differently.
-- link:Ichthyostega[] [[DateTime(2023-10-24T22:45:55Z)]]
Ichthyostega:: '2023-10-24T22:45:55Z'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

117
doc/devel/rfc/DelectusShotEvaluator.txt
View file

@ -1,9 +1,12 @@
[grid="all"] Design Process : Delectus
`------------`----------------------- =========================
*State* _Parked_
*Date* _2008-09-21_ [options="autowidth"]
*Proposed by* link:nasa[] |====================================
------------------------------------- |*State* | _Parked_
|*Date* | _2008-09-21_
|*Proposed by* | nasa
|====================================
Delectus Shot Evaluator Delectus Shot Evaluator
@ -14,13 +17,11 @@ This is a brain dump about the shot evaluator subproject.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
.A collection of Ideas
Brainstorm on Delectus
~~~~~~~~~~~~~~~~~~~~~~
Some (many) of the ideas presented herein come from the various parties Some (many) of the ideas presented herein come from the various parties
involved in the Lumiera discussion list and IRC channel #lumiera. involved in the Lumiera Mailing List and IRC channel `#lumiera` -- here is the
http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[main discussion thread].
main discussion thread
Additionally, a lot of great concepts for how to streamline the interface are Additionally, a lot of great concepts for how to streamline the interface are
derived in part from https://www.kphotoalbum.org/[KPhotoAlbum]. derived in part from https://www.kphotoalbum.org/[KPhotoAlbum].
@ -42,7 +43,7 @@ support (please add more!) is:
As such, the tags themselves can have metadata. You can see where this is As such, the tags themselves can have metadata. You can see where this is
going... going...
Also, the tags are applied to "clips" -- which I use interchangeably between Also, the tags are applied to ``clips'' -- which I use interchangeably between
source material imported into the application and slice of that material that source material imported into the application and slice of that material that
tags are applied to. Any section of a video or audio source can have tags tags are applied to. Any section of a video or audio source can have tags
applied to it. applied to it.
@ -68,9 +69,9 @@ Some key points:
* Technically flawed footage can be both manual and computer classified. * Technically flawed footage can be both manual and computer classified.
* In some cases (e.g. documentaries, dialog) audio and video clips/footage can * In some cases (e.g. documentaries, dialog) audio and video clips/footage can
follow different section processes. follow different section processes.
It is possible to use video from footage with useless audio or use audio - It is possible to use video from footage with useless audio or use audio
from footage with useless video. from footage with useless video.
* "Interesting" is designed to be broad and is explained below. * ``Interesting'' as a category is meant be broad and is explained below.
* steps 2-5 can be performed in parallel by numerous people and can span many * steps 2-5 can be performed in parallel by numerous people and can span many
different individual clips. different individual clips.
@ -106,7 +107,7 @@ The key to adequate expressive power is as follows:
* Connection to on site documentation and pre-production documentation. When * Connection to on site documentation and pre-production documentation. When
making decisions about what material to use and how to classify it, it is making decisions about what material to use and how to classify it, it is
essential to use any tools and resources available. The two most useful are essential to use any tools and resources available. The two most useful are
onsite documentation (what worked/didn't work, how the weather was, pictures on-site documentation (what worked/didn't work, how the weather was, pictures
of the setup, etc all at the shoot) and pre-production (what the ideal scene of the setup, etc all at the shoot) and pre-production (what the ideal scene
would be, what is intended, etc). Anything else that would be useful should would be, what is intended, etc). Anything else that would be useful should
be supported as well. be supported as well.
@ -143,7 +144,7 @@ vice-versa.
Interesting Interesting
^^^^^^^^^^^ ^^^^^^^^^^^
An "interesting" clip is one that has potential -- either as a metadata piece An _interesting clip_ is one that has potential -- either as a metadata piece
(multimedia note, talent briefing, etc) or footage (for the final product OR (multimedia note, talent briefing, etc) or footage (for the final product OR
intermediary step). The main goal of the application is to find and classify intermediary step). The main goal of the application is to find and classify
interesting clips of various types as quickly as possible. interesting clips of various types as quickly as possible.
@ -181,10 +182,10 @@ that by having parts of individual clips, metadata, or other files be specific
to one aspect of the overall design. This allows for much more successful use to one aspect of the overall design. This allows for much more successful use
of the related information and a cleaner, streamlined layout. As an example, of the related information and a cleaner, streamlined layout. As an example,
metadata involving file size has no effect whatsoever on the vast majority of metadata involving file size has no effect whatsoever on the vast majority of
most major decisions -- the answer is almost always "whatever it takes." Thus, most major decisions -- the answer is almost always ``whatever it takes''. Thus,
it would not appear most of the time. Content narrowing means that it is easy it would not appear most of the time. Content narrowing means that it is easy
to add back footage -- "widen the view" one step, add it back, and "narrow the to add back footage -- ``widen the view'' one step, add it back, and ``narrow
view" again. the view'' again.
Multiple cuts Multiple cuts
@ -206,7 +207,7 @@ THE SCENE), take (what is actually going on IN THIS SPECIFIC RUN), and instance
(what is actually going on IN THIS CLIP). If editing a situation, the other (what is actually going on IN THIS CLIP). If editing a situation, the other
referenced clips AUTOMATICALLY add metadata and relevant sections. This can be referenced clips AUTOMATICALLY add metadata and relevant sections. This can be
as precise and nested as desired, though rough cuts for level one editing as precise and nested as desired, though rough cuts for level one editing
(first watchthrough after technically well executed clips have been selected) (first watch-through after technically well executed clips have been selected)
and more accurate ones for higher levels is the recommended method. and more accurate ones for higher levels is the recommended method.
@ -223,12 +224,12 @@ nasa's Laws of Tagging
(reasonable) number of tags. This is OK. All that is needed is the minimum (reasonable) number of tags. This is OK. All that is needed is the minimum
set of unique tags to progress to the next cycle without losing editing set of unique tags to progress to the next cycle without losing editing
intent or the ability to rapidly evaluate many situations. intent or the ability to rapidly evaluate many situations.
. Many tags are used many times. "Outdoors" will be a very, very common tag; so . Many tags are used many times. `Outdoors` will be a very, very common tag; so
will "redub." If conventional names are decided upon and stuck to, it is will `redub`. If conventional names are decided upon and stuck to, it is
significantly easier to map the complex interactions between different significantly easier to map the complex interactions between different
content situations. content situations.
. Avoid compound tags. Do not have "conversation_jill_joe" as a tag; use . Avoid compound tags. Do not have ``conversation_jill_joe'' as a tag; use
"conversation," "jill," and "joe" instead. It is very easy to search for ``conversation'', ``jill'', and ``joe'' instead. It is very easy to search for
multiple tags and very hard to link data that doesn't use overlapping tags. multiple tags and very hard to link data that doesn't use overlapping tags.
@ -257,15 +258,16 @@ sections are allowed.
Prompting Prompting for metadata is a laborious, time-consuming process. There Prompting Prompting for metadata is a laborious, time-consuming process. There
is no truly efficient way to do it. This application uses a method similar to is no truly efficient way to do it. This application uses a method similar to
link:KPhotoAlbum[]. When the space key is held and a letter is pressed, the tag _KPhotoAlbum_. When the space key is held and a letter is pressed, the tag
that corresponds to that letter is assigned to the track for the duration of that corresponds to that letter is assigned to the track for the duration of
the press. (If the space is pressed and no other key is pressed at the same the press. (If the space is pressed and no other key is pressed at the same
time, it stops the track.) For example, suppose that the following mapping is time, it stops the track.) For example, suppose that the following mapping is
present: present:
o = outside
x = extra o ⟼ outside
p = protagonist x ⟼ extra
c = closeup p ⟼ protagonist
c ⟼ closeup
Then holding SPACE over a section and pressing one of these keys would assign Then holding SPACE over a section and pressing one of these keys would assign
the tag to the audio AND video of the section over which the space was held. If the tag to the audio AND video of the section over which the space was held. If
@ -277,15 +279,18 @@ If LALT is held down instead of SPACE, the audio is effected instead. If RALT
is held, just the video is effected. is held, just the video is effected.
In order to support scenario/take/clip tagging: In order to support scenario/take/clip tagging:
The default is situation. If the keybinding to x is:
x = t:extra ; effect only take - The default is situation. If the keybinding to x is:
x = ts:extra ; effect take and scenario
x = c:extra ; extra only visible in this clip! ** x = t:extra ; effect only take
x = tc:extra ; this take and clip show the extra ** x = ts:extra ; effect take and scenario
etc ** x = c:extra ; extra only visible in this clip!
** x = tc:extra ; this take and clip show the extra
** ...
Other keyargs (the part in front of the colon) can be added to account for Other keyargs (the part in front of the colon) can be added to account for
other uses (e.g. l = all taken on the same location). other uses +
(e.g. l = all taken on the same location).
Tab is pressed to add metadata mappings. Tab is pressed to enter metadata edit Tab is pressed to add metadata mappings. Tab is pressed to enter metadata edit
mode; this pauses video. Then press any key to map; and type the tag to mode; this pauses video. Then press any key to map; and type the tag to
@ -306,12 +311,9 @@ defined:
If ESC is pressed, all currently ranged tags are ended. If ESC is pressed, all currently ranged tags are ended.
Finally, if single_quote is pressed without SPACE or {L,R}ALT down, it marks an Finally, if single_quote is pressed without SPACE or {L,R}ALT down, it marks an
"interesting location." Pressing SHIFT+single_quote goes to the next ``interesting location''. Pressing SHIFT+single_quote goes to the next
"interesting location" and pressing CNTRL+' goes to the previous "interesting ``interesting location'' and pressing CNTRL+' goes to the previous
location." This allows for very quick review of footage. ``interesting location''. This allows for very quick review of footage.
@ -335,28 +337,29 @@ The importance/value of the video for various factors uses, can vary through
the video. It would be helpful to have the ability to create continuous ratings the video. It would be helpful to have the ability to create continuous ratings
over the entire track. Ratings would be numerical. Automatic clip over the entire track. Ratings would be numerical. Automatic clip
selection/suggestion could be generated by using algorithms to compute the selection/suggestion could be generated by using algorithms to compute the
usefulness of video based on these ratings (aswell as "boolean usefulness of video based on these ratings (as well as ``boolean operations''
operations"/"binary decisions" done with tags). The ratings could be viewed rsp. ``binary decisions'' done with tags). The ratings could be viewed
just like levels are - color coded and ovelayed on track thumbnails. just like levels are - color coded and ovelayed on track thumbnails.
- Tree 2008-10-25 Tree:: '2008-10-25'
link:MultiView[] - useful for concurrent ratings input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MultiView - useful for concurrent ratings input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It would be convenient to have an ability to view the different tracks (of the It would be convenient to have an ability to view the different tracks (of the
same scene/time sequence) at once, so the viewer can input their ratings of the same scene/time sequence) at once, so the viewer can input their ratings of the
video "on the fly", including a priority parameter that helps decide which video ``on the fly'', including a priority parameter that helps decide which
video is better than what other video.See the GUI brainstorming for a viewer video is better than what other video.See the GUI brainstorming for a viewer
widget, and key combinations that allow both right and left hand input, that widget, and key combinations that allow both right and left hand input, that
could be used for raising/lowing ratings for up to six tracks at once. could be used for raising/lowing ratings for up to six tracks at once.
- Tree 2008-10-25 Tree:: 2008-10-25
I like the idea of rating clips (or rather, takes) a lot. It would be cool to I like the idea of rating clips (or rather, takes) a lot. It would be cool to
include both "hard," "relative," and "fuzzy" rating. Hard is an exactly defined include both `hard', `relative', and `fuzzy' rating. Hard is an exactly defined
value (scaled 0-1) that puts the clip in an exact location in the queue. value (scaled 0-1) that puts the clip in an exact location in the queue.
Relative means that one is higher or lower rated than another. Fuzzy is a Relative means that one is higher or lower rated than another. Fuzzy is a
slider which is approximate value, and there is some randomness. The best part slider which is approximate value, and there is some randomness. The best part
@ -367,7 +370,7 @@ sort of heap (think binary heap, at least for the data structure) which
determines the priorities and decides which clips are played. Then the highest determines the priorities and decides which clips are played. Then the highest
rated clips are played first, down to the worst. rated clips are played first, down to the worst.
- link:NicholasSA[] 2009-01-04 NicholasSA:: '2009-01-04'
Possible Collaboration with the people from Ardour? Possible Collaboration with the people from Ardour?
@ -384,7 +387,7 @@ I like the suggestion of sound classification with a similar (or, even better,
identical) evaluator. link:SoundMiner[] looks interesting, but like you say identical) evaluator. link:SoundMiner[] looks interesting, but like you say
very expensive. I'm a sound guy, so I feel your pain... very expensive. I'm a sound guy, so I feel your pain...
- link:NicholasSA[] 2009-01-04 NicholasSA:: '2009-01-04'
Parked Parked
@ -392,7 +395,7 @@ Parked
Decided on Developer meeting, until someone wants to investigate this further. Decided on Developer meeting, until someone wants to investigate this further.
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter ct:: 'Thu 14 Apr 2011 02:52:30 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

57
doc/devel/rfc/DesignParamAutomation.txt
View file

@ -1,23 +1,22 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _2008-03-06_ |*Date* | _2008-03-06_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Design the handling of Parameters and Automation Design the handling of Parameters and Automation
------------------------------------------------ ------------------------------------------------
Parameters of Plugin Components and/or Render Nodes play a role at various Parameters of Plugin Components and/or Render Nodes play a role at various
levels of the application. levels of the application.
+
Thus it seems reasonable to do a formal requirements analysis and design prior Thus it seems reasonable to do a formal requirements analysis and design prior
to coding. to coding.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
Regarding components directly participating in the render (which may be Regarding components directly participating in the render (which might be
implemented by plugins), we distinguish between *configuration* (static) and implemented by plugins), we distinguish between *configuration* (static) and
*parameters* (dynamic). The point of reference for this distinction is the *parameters* (dynamic). The point of reference for this distinction is the
render process: a plugin configuration may well be variable in some manner, render process: a plugin configuration may well be variable in some manner,
@ -34,8 +33,7 @@ Tasks
* we need to work out an introspection mechanism for parameters * we need to work out an introspection mechanism for parameters
- asses what different types of parameters we need - asses what different types of parameters we need
- find out how much structured parameters will be (do simple values - find out how much structured parameters will be (do simple values suffice?)
suffice?)
- define how parameters can be discovered/enumerated - define how parameters can be discovered/enumerated
- define a naming scheme for parameters, so they can be addressed - define a naming scheme for parameters, so they can be addressed
unambiguously unambiguously
@ -46,16 +44,16 @@ Tasks
So... So...
. find out to which extend we need these properties . find out to which extent we need these properties
. find out what parts of the App will have what requirements? . find out what parts of the App will have what requirements?
. chose a best fitting implementation based on this information . chose a best fitting implementation based on this information
A closely related issue is the handling of *Automation*. The current draft A closely related issue is the handling of *Automation*. The current draft
calls for an abstract interface "ParamProvider", which just allows the calls for an abstract interface `ParamProvider`, which just allows the
Plugin or RenderComponent to pull a current value, without knowing if 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 `ParamProvider` is a GUI widget or an automation data set with interpolation.
component using the param value should not need to do any interpolation. We The component using the param value should not need to do any interpolation.
should re-asses and refine this draft as needed. Note: Render Nodes are We should re-asses and refine this draft as needed. Note: Render Nodes are
stateless; this creates some tricky situations. stateless; this creates some tricky situations.
@ -68,17 +66,38 @@ Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
?? (any ideas?) ?? (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 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 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...
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Ichthyostega:: '2025-09-10'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

51
doc/devel/rfc/DesignRenderNodesInterface.txt
View file

@ -1,17 +1,18 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-03-06_ |*Date* | _2008-03-06_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Design the Render Nodes interface Design the Render Nodes interface
--------------------------------- ---------------------------------
In the current design, the low-level model is comprised of "Render Nodes"; In the current design, the low-level model is comprised of ``Render Nodes'';
Stean-Layer and Vault carry out some colaboration based on this node network. Steam-Layer and Vault carry out some collaboration based on this node network.
+
Three different interfaces can be identified Three different interfaces can be identified
* the node wiring interface * the node wiring interface
* the node invocation interface * the node invocation interface
* the processing function interface * the processing function interface
@ -22,22 +23,22 @@ Description
Render Nodes are created and wired by the Builder in the Steam-Layer. On the Render Nodes are created and wired by the Builder in the Steam-Layer. On the
other hand, the rendering process is controlled by the vault layer, which also other hand, the rendering process is controlled by the vault layer, which also
provides the implementation for the individual data processing tasks. To create provides the implementation for the individual data processing tasks. To create
a result, output nodes are ''pulled'' via the invocation interface, resulting a result, output nodes are _pulled_ via the invocation interface, resulting
in the affected nodes to recursively pull their predecessor(s). In the course in the affected nodes to recursively pull their predecessor(s). In the course
of this call sequence, the nodes activate their processing function to work on of this call sequence, the nodes activate their processing function to work on
a given set of buffers. Moreover, we plan to use the render network also for a given set of buffers. Moreover, we plan to use the render network also for
gathering statistics. gathering statistics.
'''Note''': Render Node is an internal interface used by Steam-Layer and NOTE: Render Node is an internal interface used by Steam-Layer and
activated by the Vault. Plugins are planned to be added via Adapter nodes. activated by the Vault. Plugins are planned to be added via Adaptor nodes.
Thus the Render Node interface needs ''not'' to be exported. Thus the Render Node interface needs _not_ to be exported.
the wiring interface the wiring interface
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
This part of the design defines how nodes can be combined and wired up by the This part of the design defines how nodes can be combined and wired up by the
builder to form a network usable for rendering. For this purpose, the builder to form a network usable for rendering. For this purpose, the
link:ProcNode[] is used as a shell / container, which is then configured by a `ProcNode' is used as a shell / container, which is then configured by a
Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is
preselected to use a combination of specific working modes: preselected to use a combination of specific working modes:
@ -59,18 +60,18 @@ corner case.
the invocation interface the invocation interface
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
this is intended to be a rather simple "call-style" interface, without much this is intended to be a rather simple ``call-style'' interface, without much
possibilites to influence the way things are happening. You pull a node and possibilities to influence the way things are happening. You pull a node and
will find the results in a provided buffer or the cache, but you can't even will find the results in a provided buffer or the cache, but you can't even
change the frame data type type of the result. Besides the node invocation, change the frame data type type of the result. Besides the node invocation,
functions for collecting statistics will be accessible here too (Probably these functions for collecting statistics will be accessible here too (Probably these
functions will be ''implemented'' in a classic-OO fashion by virtual functions, functions will be _implemented_ in a classic-OO fashion by virtual functions,
but that's another story) but that's another story)
the processing interface the processing interface
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
the individual nodes are configured to call a plain-C {{{process()}}} function the individual nodes are configured to call a plain-C `process()` function
and provide an array of buffer pointers to be used within this function. For and provide an array of buffer pointers to be used within this function. For
the purpose of invoking actual data processing, it is irrelevant if this the purpose of invoking actual data processing, it is irrelevant if this
function is implemented somewhere in the vault layer or provided by a plugin. function is implemented somewhere in the vault layer or provided by a plugin.
@ -81,7 +82,7 @@ processing function is supposed to do The Right Thing ^TM^
Tasks Tasks
^^^^^ ^^^^^
* What services do we expect from Render Nodes. What do we plan to do with a * What services do we expect from Render Nodes? What do we plan to do with a
render node? render node?
* What different kinds (if any) of Render Nodes can be foreseen? * What different kinds (if any) of Render Nodes can be foreseen?
* order the required functionality by Steam / Vault. Find out specific * order the required functionality by Steam / Vault. Find out specific
@ -98,7 +99,8 @@ Tasks
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
The purpose of this Design Entry is to give a summary; the questions and the The purpose of this Design Entry is to give a summary and to spur the discussion
regarding the responsibilities of Steam vs Vault; the questions and the
details of carrying out the operations are much more involved. details of carrying out the operations are much more involved.
Please see the Please see the
@ -113,15 +115,12 @@ for details
Comments
--------
Parked Parked
~~~~~~ ~~~~~~
We park this until we have time to revisit the details. It is accepted that we We park this until we have time to revisit the details. It is accepted that we
need to design this interfaces. need to design this interfaces.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

26
doc/devel/rfc/DeveloperDocumentationStructure.txt
View file

@ -3,12 +3,12 @@ Developer Documentation Structure
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _Mon Aug 2 18:03:25 2010_ |*Date* | _Mon Aug 2 18:03:25 2010_
*Proposed by* Cehteh + Ichthyo |*Proposed by* | Cehteh + Ichthyo
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
We describe here how to bring the Lumiera Developer Documentation into an simple We describe here how to bring the Lumiera Developer Documentation into an simple
@ -69,14 +69,16 @@ Tasks
~~~~~ ~~~~~
// List what would need to be done to implement this Proposal in a few words: // List what would need to be done to implement this Proposal in a few words:
* Go over the existing content and the remainder of the asciidoced tiddlywikis, * Go over the existing content and the remainder of the Asciidoced TiddlyWikis,
integrate this content either in directly into the "Lumiera: The inner Core" integrate this content either in directly into the
link:{ldoc}/technical/overview.html[»Lumiera: The inner Core«]
document or write separate documentation pages or RFC's. ([green]#✔ done#) document or write separate documentation pages or RFC's. ([green]#✔ done#)
* The 'proc' tiddlywiki is a bit special, we need a plan how to integrate this. * The »Renderengine« TiddlyWiki is a bit special, we need a plan how to integrate this.
[red yellow-background]#TBD#
* Create a facility to support the cross-linking between the various kinds of documents * Create a facility to support the cross-linking between the various kinds of documents
[yellow-background]#WIP# [red yellow-background]#TODO#
CAUTION: this issue with stable cross-links
-> link:{rfc}/WebsiteSupportMarkup.html[remains a concern]
Pros Pros
@ -121,7 +123,7 @@ developers.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbated (this proposal becomes a Final) //conclusion: When approvedd (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:

78
doc/devel/rfc/DevelopmentFramework.txt
View file

@ -1,12 +1,12 @@
Design Process : Development Framework Design Process : Development Framework
====================================== ======================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-08_ |*Date* | _2007-06-08_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
@ -22,11 +22,11 @@ needed/required for working on lumiera.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
.Tools required: .Tools required:
* unix like shell environment with standard tools * Unix like shell environment with standard tools
* we don't require a specific linux distribution * we don't require a specific linux distribution
* git 1.5.3 (not out yet, but really soon, we want submodules support) * Git 1.5.3 (not out yet, but really soon, we want submodules support)
* GNU toolchain, autoconf/automake (maybe scons or something else?) * GNU toolchain, autoconf/automake (maybe SCons or something else?)
* bouml (version case unresolved) * Bouml (version case unresolved)
.Tools suggested: .Tools suggested:
* doxygen * doxygen
@ -36,45 +36,44 @@ Description
Tasks Tasks
^^^^^ ^^^^^
* cehteh will setup a initial repository (see link:RepositorySetup[proposed * cehteh will setup a initial repository
structure]) (see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure])
* ichthyo has setup a debian-APT-depot at http://deb/ichthyostega.de[] and will * ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will
add backport packages there if necessary so the debian-people can stay near add backport packages there if necessary so the debian-people can stay near
Etch/stable in the next time Etch/stable in the next time
* ichthyo volunteers to get the new source into a debian package structure from * ichthyo volunteers to get the new source into a debian package structure from
start (same as the current cinelerra is) start (same as the current cinelerra is)
.And for later: .And for later:
* decide on a Unit Test framework (see link:UnitTests_Python[this Proposal]) * decide on a Unit Test framework
(see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests])
* can we get some continuous integration running somewhere (nightly builds, * can we get some continuous integration running somewhere (nightly builds,
testsuite)? testsuite)?
* find a viable toolchain for writing more formal documentation. * find a viable toolchain for writing more formal documentation.
link:ReStructured[] Text, Docbook etc? ReStructured Text, Docbook etc?
Pros
^^^^
Cons Cons
^^^^ ^^^^
* the GIT submodules are just not there atm. we need to come along with one * Git submodules are just not usable yet; we need to come along with one
monolitic large project until they are available. monolitic large project until they are available.
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
* use visual studio and .NET :P * use visual studio and .NET [big]#😇#
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
The project will be tied to a distributed infrastructure/git. With recent git The project will be tied to a distributed infrastructure based on Git. With recent
submodules support it should be easy to let contributors only checkpout/work on Git submodules support it should be easy to let contributors only checkpout/work on
parts of the tree (plugins, documentation, i18n, ...). We want to build up a parts of the tree (plugins, documentation, i18n, ...). We want to build up a
set of maintenance scripts in a ./admin dir. set of maintenance scripts in an `./admin` directory.
At the moment we go for rather bleeding edge tools, because we want to stay at At the moment we go for rather bleeding edge tools, because we want to stay at
a given version to avoid incompatibility problems. Later on a version switch a given version to avoid incompatibility problems. Later on a version switch
@ -91,12 +90,13 @@ scripting up and running very early in a project. I would like if the project
would take a rather conservative approach on the required Libs and Tools, so would take a rather conservative approach on the required Libs and Tools, so
that finally, when we get into a beta state, we can run/compile on the major that finally, when we get into a beta state, we can run/compile on the major
distros without too much pain. I wouldn't completely abandon the idea to target distros without too much pain. I wouldn't completely abandon the idea to target
\*bsd and osx as well later on. *bsd and osX as well later on.
I would propose to move Doxygen to "required". The Idea to use scons sounds I would propose to move Doxygen to ``required''. The Idea to use SCons sounds
quite appealing to me at the moment. Besides that, I think it could be moved to quite appealing to me at the moment. Besides that, I think this RfC could be
"Draft". moved to ``Draft''.
-- link:Ichthyostega[] [[DateTime(2007-06-17T00:18:40Z)]]
Ichthyostega:: '2007-06-17T00:18:40Z'
Moved to Draft. For Developer documentation I would prefer doxygen. For user Moved to Draft. For Developer documentation I would prefer doxygen. For user
documentation we can make a similar/same think like nicolasm did for documentation we can make a similar/same think like nicolasm did for
@ -106,26 +106,32 @@ current cin2 docs, i say its rather well done.
We need to factor out some of the proposals from this page to subpages (scons, We need to factor out some of the proposals from this page to subpages (scons,
documentation, testing,...) documentation, testing,...)
-- link:ct[] [[DateTime(2007-06-17T17:27:59Z)]]
It would really suck if we have to go through the experiences described ct:: '2007-06-17T17:27:59Z'
http://freshmeat.net/articles/view/889/[here]. I have experienced parts of that
It would really suck if we have to go through the experiences described in the article
https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«].
I have experienced parts of that
in the past. I have only some beginner experience with writing autotoolized in the past. I have only some beginner experience with writing autotoolized
projects (mostly based on trial-and-error) and no experience in any other build projects (mostly based on trial-and-error) and no experience in any other build
system (such as scons). As such, I still believe that autotools can be system (such as scons). As such, I still believe that autotools can be
manageable (for me personally) once the initial hurdle of learning is overcome. manageable (for me personally) once the initial hurdle of learning is overcome.
I all for Doxygen documentation. Related to documentation are I all for Doxygen documentation. Related to documentation are
http://www.splint.org/[splint] http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking].
http://www.splint.org/manual/html/appC.html[annotations] (comments). I suggest See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)].
that we consider using such a tool for QA. Like link:ct[] said, this should be I suggest
that we consider using such a tool for QA. Like ct said, this should be
discussed in a subpage. discussed in a subpage.
I agree with using currently bleeding-edge tools. I agree with using currently bleeding-edge tools.
* _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct)
We have now a \'compatibility wiki\', finalized this proposal
-- link:ct[] [[DateTime(2008-03-26T13:43:26Z)]] We have now a ``compatibility wiki'', finalized this proposal
ct:: '2008-03-26T13:43:26Z'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

50
doc/devel/rfc/DistributedDevelopmentFramework.txt
View file

@ -1,12 +1,12 @@
Design Process : Distributed Development Framework Design Process : Distributed Development Framework
================================================== ==================================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-07_ |*Date* | _2007-06-07_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Distributed Development Framework Distributed Development Framework
@ -29,20 +29,6 @@ Tasks
* Serveral (shell?) scripts which ease the use * Serveral (shell?) scripts which ease the use
Pros
~~~~
Cons
~~~~
Alternatives
~~~~~~~~~~~~
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
@ -57,9 +43,27 @@ Rationale
Comments Comments
-------- --------
Made this 'final', this proposal got accepted and is already in use without Made this `final', this proposal got accepted and is already in use without
much discussion much discussion
-- link:ct[] [[DateTime(2007-06-27T16:07:13Z)]]
ct:: '2007-06-27T16:07:13Z'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] [underline]#Historical remark#: Not sure what this RfC was meant to propose; +
During the next year, an ambitious side-project named »*uwiki*« was started,
with the goal to provide a wiki-like web frontend based on completely self-contained
storage in a Git repository, without requiring any kind of data base. This project,
however -- in spite of some compelling prototype implementations -- was abandoned;
it became clear that such a system can not be bootstrapped from a lightweight,
minimalist setup and would require a significant amount of web development
rather -- a task no one was willing to take on.
Yet the Lumiera project succeeded in building a web presence based on
https://asciidoc-py.github.io/[Asciidoc] sources checked into Git, with a lightweight
commit-hook script to automatically publish any changes on git-push -- a scheme
which comes close to the gist of this RfC.
Ichthyo:: '2025-09-08'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

164
doc/devel/rfc/EDLsAreMetaClips.txt
View file

@ -1,18 +1,18 @@
EDL's Are Meta-Clips EDL's Are Meta-Clips
==================== ====================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-07-15_ |*Date* | _2008-07-15_
*Proposed by* link:PercivalTiglao[] |*Proposed by* | PercivalTiglao
------------------------------------- |====================================
EDLs Are Meta-Clips EDLs Are Meta-Clips
------------------- -------------------
One very useful property of EDLs is the ability to contain other EDLs and treat One very useful property of EDLs is the ability to contain other EDLs and to
these "inner" EDLs as a unit. The most logical implementation of this is to __treat these ``inner'' EDLs as an unit__. The most logical implementation of this
have EDLs themselves be able to be treated as an Clip-MObject. Recursion is is to have EDLs themselves be able to be treated as an Clip-MObject. Recursion is
known to be a powerful feature that is relatively simple to understand. By known to be a powerful feature that is relatively simple to understand. By
making EDLs recursive, some higher level features can be more easily making EDLs recursive, some higher level features can be more easily
implemented by taking advantage of this fact. implemented by taking advantage of this fact.
@ -39,14 +39,13 @@ being forced to render the file to disk first.
The usability benefits are obvious. The usability benefits are obvious.
In all examples, rendering the main EDL implies that all of the "inner EDLs" In all examples, rendering the main EDL implies that all of the ``inner EDLs''
have to be re-rendered if the inner EDL was modified. That is one of the only have to be re-rendered if the inner EDL was modified. That is one of the only
requirements. requirements.
Tasks Tasks
~~~~~ ^^^^^
* Consider usability issues from the current Cinelerra userbase. * Consider usability issues from the current Cinelerra userbase.
* Have the EDL Object (or create a proxy class) that extends MObject, Clip, * Have the EDL Object (or create a proxy class) that extends MObject, Clip,
AbstractMO, or some other class that would create this kind of behaviour. AbstractMO, or some other class that would create this kind of behaviour.
@ -54,21 +53,19 @@ Tasks
File2 contains File1. This might produce infinite recursion while attempting File2 contains File1. This might produce infinite recursion while attempting
to render the EDL. to render the EDL.
* Implement higher level features in the GUI. * Implement higher level features in the GUI.
* Create "Compound Tracks" which contain multiple tracks within them. * Create ``Compound Tracks'' which contain multiple tracks within them.
* Create a GUI that can handle multiple open EDLs at the same time. * Create a GUI that can handle multiple open EDLs at the same time.
Pros Pros
~~~~ ^^^^
* A low level feature that would greatly ease the creation of high level features.
* A low level feature that would greatly ease the creation of high level
features.
* Multiple applications. * Multiple applications.
* Eases the use and maintenance of Stock Footage. * Eases the use and maintenance of Stock Footage.
Cons Cons
~~~~ ^^^^
* Possibly would have to rewrite a lot of code at the Engine level?? * Possibly would have to rewrite a lot of code at the Engine level??
* Caching / Efficiency issues arise. * Caching / Efficiency issues arise.
- Handling multiple instances of Lumiera running might be difficult. E.g. - Handling multiple instances of Lumiera running might be difficult. E.g.
@ -77,53 +74,57 @@ Cons
- Or maybe even multiple instances of Lumiera across computers that are - Or maybe even multiple instances of Lumiera across computers that are
connected to the same Drive. File1 is opened in Computer1 and File2 is connected to the same Drive. File1 is opened in Computer1 and File2 is
opened in Computer2. opened in Computer2.
* A corrupted "inner EDL" or Stock Footage would "poison" the whole project. * A corrupted ``inner EDL'' or Stock Footage would ``poison'' the whole project.
Alternatives Alternatives
~~~~~~~~~~~~ ~~~~~~~~~~~~
* Pre-Rendering Clips * Pre-Rendering Clips
- Unlike the current proposal, you would be unable to reedit sock footage on - Unlike the current proposal, you would be unable to re-edit sock footage on
the mass scale and reapply it to the whole project. the mass scale and re-apply it to the whole project.
- Moreover, rendering either introduces a generation loss or requires huge - Moreover, rendering either introduces a generation loss or requires huge
storage for raw (uncompressed) video. storage for raw (uncompressed) video.
* Loading the resources of the EDL -- This is an alternative way to load EDLs. * Loading the resources of the EDL -- This is an alternative way to load EDLs.
This should also be supported. It would be an expected feature from the old This should also be supported. It would be an expected feature from the old
Cinelerra2 userbase. Cinelerra-2 user base.
Comments Comments
-------- --------
* I got the inspiration of this idea from an email discussion between Rick777 I got the inspiration of this idea from an email discussion with _Rick777_
discussing the Saya Video Editor. -- link:PercivalTiglao[] discussing the Saya Video Editor.
[[DateTime(2008-07-17T13:34:08Z)]]
* Hi Percival, thanks for writing this proposal. This is indeed a feature which PercivalTiglao:: '2008-07-17T13:34:08Z'
was much discussed in the last months and I consider it to be included almost
for sure. We always used the term '''meta-clip''' for this feature, thus I Hi Percival, thanks for writing this proposal. This is indeed a feature which
edited the headline (I hope you don't mind). was much discussed in the last months and I consider it to be included almost
* Regarding the implementation, I choose a slightly different approach for the for sure. We always used the term *meta-clip* for this feature, thus I
``proc layer'' (actually, it's not yet there, but planned right from start, as I edited the headline (I hope you don't mind).
consider this meta-clip feature to be of uttermost importance): I'd prefer to
add it at the level of the media source which is used by a clip. The Regarding the implementation, I choose a slightly different approach for the
rationale is, that at the level of the clip, there is no (or almost no) ``proc layer'' (actually, it's not yet there, but planned right from start, as I
different behaviour if a clip pulls from a media file, from an life input or consider this meta-clip feature to be of uttermost importance): I'd prefer to
from another EDL. Thus, the implementation would be for a meta-clip to use a add it at the level of the media source which is used by a clip. The
special media asset, which represents the output of the other EDL. rationale is, that at the level of the clip, there is no (or almost no)
* Basically, the implementation is quite simple and doesn't necessiate much different behaviour if a clip pulls from a media file, from an life input or
additional code (the power of recursion at work!). Further, I don't see any from another EDL. Thus, the implementation would be for a meta-clip to use a
caching or efficiency problems. As you already pointed out, there are two special media asset, which represents the output of the other EDL.
fundamental problems
- We need a cycle detector when building the low-level model. ''But'' we Basically, the implementation is quite simple and doesn't necessitate much
additional code (the power of recursion at work!). Further, I don't see any
caching or efficiency problems. As you already pointed out, there are two
fundamental problems
- We need a cycle detector when building the low-level model. _But_ we
don't need it solely because of meta-clips, we also need such a facility don't need it solely because of meta-clips, we also need such a facility
the moment we allow relatively free wiring of input-output connections the moment we allow relatively free wiring of input-output connections
(which we do plan anyway). My proposal is to flag the respective MObjects (which we do plan anyway). My proposal is to flag the respective MObjects
as erroneous, which should be visualized accordingly in the GUI as erroneous, which should be visualized accordingly in the GUI
- We need a thouroughly complete handling for multichannel video and audio - We need a thoroughly complete handling for multichannel video and audio
throughout the whole application. We need to get rid of the distinction throughout the whole application. We need to get rid of the distinction
into "video" and "audio" tracks. ''But'' again, this is not due to into »video« and »audio« tracks. _But_ again, this is not due to
meta-clips solely, we should do so anyway because of multichannel spatial meta-clips solely, we should do so anyway because of multichannel spatial
audio, 3D video and other advanced media to come. Thus, when every media is audio, 3D video and other advanced media to come. Thus, when every media is
multichannel by default, and the builder can sort and handle connections multichannel by default, and the builder can sort and handle connections
@ -131,11 +132,13 @@ Comments
to do right from start), putting a meta-clip which pulls output from N to do right from start), putting a meta-clip which pulls output from N
channels with various mixed stream types from another EDL is not really a channels with various mixed stream types from another EDL is not really a
problem. problem.
* The other "cons" listed above actually aren't directly connected or due to
the existence of meta-clips, thus I wouldn't list them here. The other »cons« listed above actually aren't directly connected or due to
- yes, it ''is'' true, concurrent changes to the session files may screw up the existence of meta-clips, thus I wouldn't list them here.
things. But is this really an issue the Lumiera App should handle at all??
- yes, ''any corrupted part'' of the serialized session can mess up things. - yes, it _is_ true, concurrent changes to the session files may screw up things.
But is this really an issue the Lumiera App should handle at all?
- yes, _any corrupted part_ of the serialized session can mess up things.
This is a real threat (see Cinelerra), but not limited to meta-clips. It is This is a real threat (see Cinelerra), but not limited to meta-clips. It is
especially important, as you can expect users to work for months or years especially important, as you can expect users to work for months or years
with a single session. Thus the integrity of the session is a value to be with a single session. Thus the integrity of the session is a value to be
@ -143,24 +146,53 @@ Comments
layer that all important objects can only be created or re-created by some layer that all important objects can only be created or re-created by some
specialized factory, which in turn has the responsibility of never creating specialized factory, which in turn has the responsibility of never creating
a corrupted object. a corrupted object.
-- link:Ichthyostega[] [[DateTime(2008-07-27T22:15:01Z)]]
* I'll think about closures around seralized artefacts, the serialized stream Ichthyostega:: '2008-07-27T22:15:01Z'
can then be validated, unsupported or corrupted parts can be tagged as
erroneous (means they become virtually readonly but they must be preserved) I'll think about closures around seralized artifacts, the serialized stream
and circumvented. A lot of details have to be worked out here, iirc ichthyo can then be validated, unsupported or corrupted parts can be tagged as
already planned support for 'erroneous' nodes in the datamodell. I also think erroneous (means they become virtually readonly but they must be preserved)
about some debugable plaintext dump format (maybe XML) then real corrupt and circumvented. A lot of details have to be worked out here, iirc ichthyo
things can be fixed manually with some efforts. Otherwise we handle gigabytes already planned support for `erroneous' nodes in the data model. I also think
of video data and our most valuable resource is the few MB sized session about some debuggable plaintext dump format (maybe XML) then real corrupt
file. I really aim to make that as robust as possible. Adding backups and things can be fixed manually with some efforts. Otherwise we handle gigabytes
redundancy there wont hurt. of video data and our most valuable resource is the few MB sized session
-- link:ct[] [[DateTime(2008-07-30T16:03:04Z)]] file. I really aim to make that as robust as possible. Adding backups and
redundancy there wont hurt.
ct:: '2008-07-30T16:03:04Z'
Conclusion Conclusion
---------- ----------
This Design Entry concerns whether to include such a feature and discusses the This Design Entry deals with the question whether to include such a feature and
general questions when doing so. As we for sure include meta-clip, and so so it discusses the general questions when doing so. Since we are determined to
exactly in the way described here, this proposal is 'final' now. include this kind of _meta-clip_ anyway, and will most likely do in a way
similar as described here, this can be considered __`final'__.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] This conclusion was drawn at the
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_edls_as_meta_clips[October.2008 developer meeting].
''''
[TIP]
===========
Terminology is somewhat in flux regarding this topic:
- »EDL« is a technical term from the Cinelerra-2 code base. The acronym actually
stands for **E**dit **D**ecision **L**ist, which is a term from traditional
film making and production organisation -- and does not really map properly
into the usage possible with digital technology. For that reason, the Lumiera
project _dropped_ this notion subsequently.
- close to the ideas presented in this text is the concept of a ``Sequence'',
which in Lumiera designates a ``Fork'' (tree of tracks) with an arrangement
of clips attached.
- as of 2025, we typically use the following terminology:
** a _Virtual Clip_ is how such a nested structure is integrated
** such a clip in turn uses a _Virtual Medium_
** which is based on the _Binding_ of a _Nested Sequence_
===========
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

46
doc/devel/rfc/EngineInterfaceOverview.txt
View file

@ -4,12 +4,12 @@ Engine Interface Overview
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _2010-04-16_ |*Date* | _2010-04-16_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Overview Engine Interface(s) Overview Engine Interface(s)
@ -42,7 +42,7 @@ Render Process
The render process brackets an ongoing calculation as a whole. It is not to be The render process brackets an ongoing calculation as a whole. It is not to be
confused with a operating system process or thread; rather it is a point of confused with a operating system process or thread; rather it is a point of
reference for the relevant entities in the Stage and Steam-Layer in need to reference for the relevant entities in the Stage and Steam-Layer in need to
connect to such a "rendering", and it holds the specific definitions for this connect to such a ``rendering'', and it holds the specific definitions for this
calculation series. A render process calculation series. A render process
_corresponds to a single data stream_ to be rendered. Thus, when the play _corresponds to a single data stream_ to be rendered. Thus, when the play
controller of some timeline in the model is controller of some timeline in the model is
@ -51,7 +51,7 @@ processes exist.
* there is an displayer- or output slot, which got allocated on creation * there is an displayer- or output slot, which got allocated on creation
of the process of the process
* the process disposes calculated data frames "into" this slot * the process disposes calculated data frames _into this slot_
* the process can be paused/started and stopped (aborted, halted). * the process can be paused/started and stopped (aborted, halted).
* some processes allow for changing parameters dynamically (e.g. speed, * some processes allow for changing parameters dynamically (e.g. speed,
direction) direction)
@ -60,7 +60,7 @@ processes exist.
.Process parameters .Process parameters
A process is linked to a single stream data format (a -> A process is linked to a single stream data format (a ->
link:StreamTypeSystem.html[stream implementation type]). + link:{rfc}/StreamTypeSystem.html[stream implementation type]). +
It is configured with _frame quantisation_ and _timings_, and a _model port_ It is configured with _frame quantisation_ and _timings_, and a _model port_
identifier and _channel selector_. identifier and _channel selector_.
@ -246,7 +246,7 @@ Rationale
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -261,11 +261,33 @@ Requirements and details of the design are sufficiently clear meanwhile.
Ther seems to be not much room for alternative approaches, given our Ther seems to be not much room for alternative approaches, given our
general planning for the application general planning for the application
Mi 11 Mai 2011 19:27:12 CEST Ichthyostega <prg@ichthyostega.de> Ichthyostega:: 'Wed 11 Mai 2011 19:27:12 CEST' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] [underline]#Historical remark#: In hindsight, it seems I did post that RfC
(and the corresponding link:{rfc}/EngineInterfaceSpec.html[Specification RfC]) not so much
to ask for input and further ideas, rather as a _call for help_. Last year (2024), I had
to revisit the code written in 2010/11, and it looks like I was struggling desperately at
that time to thread a pathway into a void. During the early stages of the project, _Cehteh_
and myself had agreed to place the boundary between ``Proc'' and ``Backend'' (today designated
as Steam and Vault) at the entrance to the link:/x/Scheduler.html[Scheduler] -- but there was
no scheduler yet, not even a design draft at that time, and the scope of what it was assumed to do
seemed to be ``vanishing'': basically ``the Backend'' wanted a pool of lightweight, stateless,
unconnected requests, which could be treated as a problem of the ``embarrassingly parallel''
kind (to use computer science parlance). So nothing to serve as an anchor or point of reference
for finding a pathway.
This RfC is a summary of design work already completed, asking for validation. I could
not see if this path would lead to anywhere at that time -- and subsequently abandoned that
topic in half-finished state. Currently (since 2024) I am picking up that work and it seems
to be durable. However -- it might be worth mentioning that this RfC indeed spurred an
link:{ldoc}/devel/meeting_summary/2011-05-11.html#scheduler[extended technical discussion]
at the May-2011 developer meeting, maybe the last of this kind of inspiring exchanges
on equal terms.
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

33
doc/devel/rfc/EngineInterfaceSpec.txt
View file

@ -3,12 +3,12 @@ Engine Interface Spec
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Mi 11 Mai 2011 17:53:16 CEST_ |*Date* | _Mi 11 Mai 2011 17:53:16 CEST_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
[abstract] [abstract]
******************************************************************************** ********************************************************************************
@ -54,7 +54,7 @@ Requirements Specification
Functionality description in detail Functionality description in detail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> see the link:EngineInterfaceOverview.html[Engine/Interface overview] for -> see the link:{rfc}/EngineInterfaceOverview.html[Engine/Interface overview] for
a description of the involved entities and for definitions for common terms. a description of the involved entities and for definitions for common terms.
Definitions Definitions
@ -173,8 +173,8 @@ Tasks
Discussion Discussion
~~~~~~~~~~ ~~~~~~~~~~
Pros //Pros
^^^^ //^^^^
// add a fact list/enumeration which make this suitable: // add a fact list/enumeration which make this suitable:
// * foo // * foo
// * bar ... // * bar ...
@ -188,8 +188,8 @@ The requirements placed on life changes are quite high
Alternatives //Alternatives
^^^^^^^^^^^^ //^^^^^^^^^^^^
//alternatives: explain alternatives and tell why they are not viable: //alternatives: explain alternatives and tell why they are not viable:
@ -206,7 +206,7 @@ and break it down into tangible functionality on the implementation level.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -216,7 +216,9 @@ Comments
-------- --------
//comments: append below //comments: append below
Discussed in the May developers meeting. Seems to be basically acceptable. Discussed in the
link:{ldoc}/devel/meeting_summary/2011-05-11.html#irctranscript[May.2011 developers meeting].
Seems to be basically acceptable.
_Cehteh_ proposed some small adjustments: _Cehteh_ proposed some small adjustments:
- making the _QualityOfService_ rather a strategy to be queried - making the _QualityOfService_ rather a strategy to be queried
@ -225,10 +227,11 @@ _Cehteh_ proposed some small adjustments:
- introducing a separate scheduler/queue for time scheduled tasks, like - introducing a separate scheduler/queue for time scheduled tasks, like
with rater soft realtime requirements with rater soft realtime requirements
So 15 Mai 2011 00:55:24 CEST Ichthyostega <prg@ichthyostega.de> Ichthyostega:: 'Sun 15 Mai 2011 00:55:24 CEST' ~<prg@ichthyostega.de>~
TIP: see also the related link:{rfc}/EngineInterfaceOverview.html#_comments[overview RfC]
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

75
doc/devel/rfc/FeatureBundle_PluggableModules.txt
View file

@ -1,20 +1,20 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-09-03_ |*Date* | _2008-09-03_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Describe pluggable modules by a "Feature Bundle" Describe pluggable modules by a »Feature Bundle«
------------------------------------------------ ------------------------------------------------
This proposal builds upon Cehteh's Plugin Loader, which is the fundamental This proposal builds upon _Cehteh_'s Plugin Loader, which is the fundamental
mechanism for integrating variable parts into the application. mechanism for integrating variable parts into the application.
It targets the special situation when several layers have to cooperate in order It targets the special situation when several layers have to cooperate in order
to provide some pluggable functionality. The most prominent example are the to provide some pluggable functionality. The most prominent example are the
"effects plugins" visible for the user. Because, in order to provide such an ``effect plugins'' visible for the user. Because, in order to provide such an
effect effect
* the engine needs a processing function * the engine needs a processing function
@ -38,8 +38,10 @@ base. Each extension point can be addressed by a fixed textual ID, e.g.
Now, to provide a pluggable extension for such an Extension Point, we use a Now, to provide a pluggable extension for such an Extension Point, we use a
*Feature Bundle* Such a Feature Bundle is comprised of *Feature Bundle* Such a Feature Bundle is comprised of
* a Deployment Descriptor (provided as "structured data" -- TODO: define the * a Deployment Descriptor (provided as ``structured data'' --
actual data format) +
^[red]#TODO#: define the actual data format)^
* the corresponding resources mentioned by this Deployment Descriptor * the corresponding resources mentioned by this Deployment Descriptor
The Deployment Descriptor contains The Deployment Descriptor contains
@ -77,7 +79,7 @@ We do _not_ provide a meta-language for defining requirements of an Extension
Point, rather, each extension point has hard wired requirements for a Feature Point, rather, each extension point has hard wired requirements for a Feature
Bundle targeted at this extension point. There is an API which allows code Bundle targeted at this extension point. There is an API which allows code
within lumiera to access the data found in the Feature Bundle's Deployment within lumiera to access the data found in the Feature Bundle's Deployment
Descriptor. Using this API, the code operating and utilizing the Extension Descriptor. Using this API, the code operating and utilising the Extension
Point has to check if a given feature bundle is usable. Point has to check if a given feature bundle is usable.
It is assumed that these Feature Bundles are created / maintained by a third It is assumed that these Feature Bundles are created / maintained by a third
@ -85,7 +87,7 @@ party, which we call a *Packager*. This packager may use other resources from
different sources and assemble them as a Feature Bundle loadable by Lumiera. Of different sources and assemble them as a Feature Bundle loadable by Lumiera. Of
course, Lumiera will come with some basic Feature Bundles (e.g. for colour course, Lumiera will come with some basic Feature Bundles (e.g. for colour
correction, sound panning,....) which are maintained by the core dev team. correction, sound panning,....) which are maintained by the core dev team.
(please don't confuse the "packager" mentioned here with the packager creating (please don't confuse the ``packager'' mentioned here with the packager creating
RPMs or DEBs or tarballs for installation in a specific distro). Additionally, RPMs or DEBs or tarballs for installation in a specific distro). Additionally,
we may allow for the auto-generation of Feature Bundles for some simple cases, we may allow for the auto-generation of Feature Bundles for some simple cases,
if feasible (e.g. for LADSPA plugins). if feasible (e.g. for LADSPA plugins).
@ -97,16 +99,16 @@ In most cases, the resources referred by a Feature Bundle will be Lumiera
Plugins. Which means, there is an Interface (with version number), which can be Plugins. Which means, there is an Interface (with version number), which can be
used by the code within lumiera for accessing the functionality. Besides, we used by the code within lumiera for accessing the functionality. Besides, we
allow for a number of further plugin architectures which can be loaded by allow for a number of further plugin architectures which can be loaded by
specialized loader code found in the core application. E.g. Lumiera will specialised loader code found in the core application. E.g. Lumiera will
probably provide a LADSPA host and a GStreamer host. If such an adapter is probably provide a LADSPA host and a GStreamer host. If such an adapter is
applicable depends on the specific Extension point. applicable depends on the specific Extension point.
The ResourceID is the identifyer by which an Extension point tries to find The ResourceID is the identifier by which an Extension point tries to find
required resources. For example, the Extension Point "Effect" will try to find required resources. For example, the Extension Point "Effect" will try to find
an ResourceID called "ProcFunction". There may be several Entries for the same an ResourceID called "ProcFunction". There may be several Entries for the same
ResourceID, but with distinct SubID. This can be used to provide several ResourceID, but with distinct SubID. This can be used to provide several
implementations for different platforms. It is up to the individual Extension implementations for different platforms. It is up to the individual Extension
Pont to impose additional semantic requirements to this SubID datafield. (Which Point to impose additional semantic requirements to this SubID data field. (Which
means: define it as we go). Similarly, it is up to the code driving the means: define it as we go). Similarly, it is up to the code driving the
individual Extension point to define when a Feature Bundle is fully usable, individual Extension point to define when a Feature Bundle is fully usable,
partially usable or to be rejected. For example, an partially usable or to be rejected. For example, an
@ -117,32 +119,19 @@ can't access the properties describing the media stream type this effect is
supposed to handle. supposed to handle.
Besides binary plugins, other types of resources include: Besides binary plugins, other types of resources include:
* a set of properties (key/value pairs) * a set of properties (key/value pairs)
* a script, which is executed by the core code using the Extension Point and * a script, which is executed by the core code using the Extension Point and
which in turn may access certain interfaces provided by the core for "doing which in turn may access certain interfaces provided by the core for
things" ``doing things''
Probably there will be some discovery mechanism for finding (new) Feature Probably there will be some discovery mechanism for finding (new) Feature
Bundles similar to what we are planning for the bare plugins. It would be a Bundles similar to what we are planning for the bare plugins. It would be a
good idea to store the metadata of Feature Bundles in the same manner as we good idea to store the metadata of Feature Bundles in the same manner as we
plan to store the metadata of bare plugins in a plugin registry. plan to store the metadata of bare plugins in a plugin registry.
Discussion
~~~~~~~~~~
Tasks
^^^^^
Pros
^^^^
Cons
^^^^
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
@ -156,7 +145,7 @@ The purpose of this framework is to decouple the core application code from the
details of accessing external functionality, while providing a clean details of accessing external functionality, while providing a clean
implementation with a basic set of sanity checks. Moreover, it allows us to implementation with a basic set of sanity checks. Moreover, it allows us to
create an unique internal description for each loaded module, and this create an unique internal description for each loaded module, and this
description data e.g. is what is stored as an "Asset" into the user session. description data e.g. is what is stored as an _Asset_ into the user session.
Today it is well understood what is necessary to make a real component Today it is well understood what is necessary to make a real component
architecture work. This design proposal deliberately avoids to create a architecture work. This design proposal deliberately avoids to create a
@ -179,17 +168,19 @@ Comments
From a fast reading, I like this, some things might get refined. For example From a fast reading, I like this, some things might get refined. For example
I'd strongly suggest to make the Deployment Descriptor itself an Interface I'd strongly suggest to make the Deployment Descriptor itself an Interface
which is offered by a plugin, all data will then be queried by functions on which is offered by a plugin, all data will then be queried by functions on
this interface, not by some 'dataformat'. Also Resource ID's and a lot other this interface, not by some ``dataformat''. Also Resource ID's and a lot other
metadata can be boiled down to interfaces: names, versions, uuid of these metadata can be boiled down to interfaces: names, versions, UUID of these
instead reiventing another system for storing metadata. My Idea is to make the instead reinventing another system for storing metadata. My Idea is to make the
link:Plugin/Interface[] system self-describing this will also be used to Plugin/Interface system self-describing this will also be used to
bootstrap a session on itself (by the serializer which is tightly integrated) bootstrap a session on itself (by the serializer which is tightly integrated)
-- link:ct[] [[DateTime(2008-09-04T09:28:37Z)]] 2008-09-04 09:28:37
ct:: '2008-09-04T09:28:37Z'
Parked Parked
~~~~~~ ~~~~~~
Needs to ne reviewed some time later. Needs to ne reviewed some time later.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

16
doc/devel/rfc/GitCommitMessageFormat.txt
View file

@ -3,12 +3,12 @@ Git Commit Message Format
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _Fr 31 Aug 2012 03:54:14 CEST_ |*Date* | _Fr 31 Aug 2012 03:54:14 CEST_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -156,7 +156,7 @@ confuse the toolchain (builddrone) but this failures shall not be critical.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -177,4 +177,4 @@ Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~<ct@pipapo.org>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

45
doc/devel/rfc/GitSubmoduleTransistion.txt
View file

@ -1,9 +1,9 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-04-09_ |*Date* | _2008-04-09_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Use Git Submodules to organize the project Use Git Submodules to organize the project
@ -14,33 +14,34 @@ work out the details and define a turnover point in time.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
There is a git-filter-branch command which helps in doing the dirty work There is a `git-filter-branch` command which helps in doing the dirty work
isolating commits which touch certain dirs. This can moderately easily be used isolating commits which touch certain dirs. This can moderately easily be used
to create a new repository with a rewritten history containing only sub parts to create a new repository with a rewritten history containing only sub parts
of the original history. of the original history.
The basic idea is that one developer who wants to works on a certain subsystem The basic idea is that one developer who wants to works on a certain subsystem
clones the 'official' master and then updates and tracks only the development clones the ``official'' master and then updates and tracks only the development
state of a certain subsystem. state of a certain subsystem.
Tasks Tasks
^^^^^ ^^^^^
* what shall be in the master repository? * what shall be in the master repository?
* boilerplate files, license, build infrastructure ** boilerplate files, license, build infrastructure
* the _admin_ dir with supplemental scripts ** the _admin_ dir with supplemental scripts
* define which submodules shall be defined? * define which submodules shall be defined?
* _doc/devel_ ** _doc/devel_
* _doc/user_ ** _doc/user_
* _wiki_ ** _wiki_
* _uml_ ** _uml_
* _src/backend_ ** _src/backend_
* _src/proc_ ** _src/proc_
* _src/gui_ ** _src/gui_
* _src/lib_ ** _src/lib_
Not yet decided: Not yet decided:
* _tests_ move them into the _src/$subsystem_ as symlink?
* _tests_ move them into the `"src/$subsystem"` as symlink?
* _src/tool_ * _src/tool_
@ -82,6 +83,8 @@ Comments
We concluded that that submodules are not yet needed with exception for the We concluded that that submodules are not yet needed with exception for the
./doc folder. Parked for now. ./doc folder. Parked for now.
-- ct 2008-07-26 09:09:57
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2008-07-26 09:09:57'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

52
doc/devel/rfc/GlobalInitialization.txt
View file

@ -3,12 +3,12 @@ GlobalInitialization
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2008-04-05_ |*Date* | _2008-04-05_
*Proposed by* CT <ct@pipapo.org> |*Proposed by* | CT <ct@pipapo.org>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -21,7 +21,7 @@ Description
Setup a `src/common/lumiera_init.c` file which contains following functions: Setup a `src/common/lumiera_init.c` file which contains following functions:
* `int lumiera_init(s.b.)` initializes the subsystems, global registries, * `int lumiera_init(s.b.)` initializes the subsystems, global registries,
link:NoBug[] and other things. Must be called once at startup. NoBug and other things. Must be called once at startup.
* `void lumiera_destroy(void)` shuts down, frees resources, cleans up. * `void lumiera_destroy(void)` shuts down, frees resources, cleans up.
Calling 'lumiera_init()' twice or more should be a fatal abort, calling Calling 'lumiera_init()' twice or more should be a fatal abort, calling
@ -39,7 +39,9 @@ Tasks
// * first step ([green]#✔ done#) // * first step ([green]#✔ done#)
// * second step [yellow-background]#WIP# // * second step [yellow-background]#WIP#
// * third step [red yellow-background]#TBD# // * third step [red yellow-background]#TBD#
Implement this. [red yellow-background]#it was never implemented this way# Implement this.
WARNING: [red yellow-background]#it was never implemented this way#
Discussion Discussion
@ -90,7 +92,7 @@ order and makes debugging easier since it is a serial, well defined sequence.
Conclusion Conclusion
---------- ----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
_This RfC was the plan_. We agreed on it, and then we forgot about it. _This RfC was the plan_. We agreed on it, and then we forgot about it.
@ -104,7 +106,8 @@ scheme:
- by policy, clean-up and unwinding is always considered _optional_ -- but we - by policy, clean-up and unwinding is always considered _optional_ -- but we
care to implement a complete shutdown and memory unwinding for sake of sanity. care to implement a complete shutdown and memory unwinding for sake of sanity.
This RfC is marked as *dropped*, since it doesn't reflect what the implementation does. + This RfC is marked as *dropped*, since it doesn't reflect what the implementation does.
Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~<prg@ichthyostega.de>~ Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~<prg@ichthyostega.de>~
@ -130,7 +133,8 @@ there too, so it gets issued automatically.
loading of a existing session will bring the proc layer up into fully loading of a existing session will bring the proc layer up into fully
operational state + operational state +
Ichthyo:: 'DateTime(2008-04-09T02:13:02Z' Ichthyo:: 'DateTime(2008-04-09T02:13:02Z'
* About link:NoBug[] initialization: I've seen that you made a `nobugcfg` where
* About NoBug initialization: I've seen that you made a `nobugcfg` where
you centralized all nobug setup. Problem here is that a change in that file you centralized all nobug setup. Problem here is that a change in that file
forces a whole application rebuild. I'd like to factor that out that each forces a whole application rebuild. I'd like to factor that out that each
subsystem and subsubsystem does its own `NOBUG_FLAG_INIT()` initializations, subsystem and subsubsystem does its own `NOBUG_FLAG_INIT()` initializations,
@ -158,7 +162,7 @@ Backend tests then only call `lumiera_backend_init()` and don't need to do the
whole initialization, same could be done for `lumiera_proc_init()` and whole initialization, same could be done for `lumiera_proc_init()` and
`lumiera_gui_init()`. Note about the library: I think the lib shall not depend `lumiera_gui_init()`. Note about the library: I think the lib shall not depend
on such an init, but I would add one if really needed. on such an init, but I would add one if really needed.
+
CT:: '2008-04-09T19:19:17Z' CT:: '2008-04-09T19:19:17Z'
@ -171,7 +175,7 @@ After reconsidering I think we have several different problems intermixed here.
usage pattern of the flags (btw. the idea of making a flag hierarchy is very usage pattern of the flags (btw. the idea of making a flag hierarchy is very
good!) will be much different in the backend, the proc layer and the gui. good!) will be much different in the backend, the proc layer and the gui.
- Initialisation of the very basic services is tricky, as always. Seemingly - Initialisation of the very basic services is tricky, as always. Seemingly
this includes link:NoBug[]. Of course one wants to use assertions and some this includes NoBug. Of course one wants to use assertions and some
diagnostics logging already in constructor code, and, sadly enough it can't diagnostics logging already in constructor code, and, sadly enough it can't
be avoided completely to run such already in the static initialisation phase be avoided completely to run such already in the static initialisation phase
before entering main(). My current solution (putting `NOBUG_INIT` it in the before entering main(). My current solution (putting `NOBUG_INIT` it in the
@ -180,7 +184,7 @@ After reconsidering I think we have several different problems intermixed here.
- Then there is the initialisation of common services. For these, it's just - Then there is the initialisation of common services. For these, it's just
fine to do a dedicated call from main (e.g. to init the backend services and fine to do a dedicated call from main (e.g. to init the backend services and
for creating the basic empty session for proc and firing off the event loop for creating the basic empty session for proc and firing off the event loop
for the GUI). I think it's no problem to ''disallow'' any IO, any accessing for the GUI). I think it's no problem to __disallow any IO,__ any accessing
of services in the other layers prior to this point. of services in the other layers prior to this point.
- What is with shutdown? personally, I'd like to call a explicit shutdown hook - What is with shutdown? personally, I'd like to call a explicit shutdown hook
at the end of main and to disallow any IO and usage of services outside each at the end of main and to disallow any IO and usage of services outside each
@ -188,7 +192,7 @@ After reconsidering I think we have several different problems intermixed here.
to require every destructor to be called and everything to be deallocated, to require every destructor to be called and everything to be deallocated,
meaning that quite a lot of code is running after the end of main() -- most meaning that quite a lot of code is running after the end of main() -- most
of which is library generated. + of which is library generated. +
Ichthyo:: '2008-04-12T04:56:49Z Ichthyo:: '2008-04-12T04:56:49Z'
Some comments... Some comments...
@ -202,7 +206,7 @@ Some comments...
- What is with shutdown?... - What is with shutdown?...
* Mostly agreed, I suggest to make all initialization code once-only, a * Mostly agreed, I suggest to make all initialization code once-only, a
second call shall bail out (under link:NoBug[]), all shutdown code shall be second call shall bail out (under NoBug), all shutdown code shall be
callable multiple times where subsequent calls are no-ops, this allows us callable multiple times where subsequent calls are no-ops, this allows us
to register at least some things in atexit() handlers, while we should add to register at least some things in atexit() handlers, while we should add
an explicit clean shutdown too, whenever that (or the atexit) handlers get an explicit clean shutdown too, whenever that (or the atexit) handlers get
@ -219,7 +223,7 @@ OK. So now I've done the following:
- Moved lumiera.h and nobugcfg.h to proc/lumiera.hpp and nobugcfg.hpp (i.e. - Moved lumiera.h and nobugcfg.h to proc/lumiera.hpp and nobugcfg.hpp (i.e.
consider them now as Proc-Layer only) consider them now as Proc-Layer only)
- Changed Appconfig to support simple lifecycle hooks, especially a - Changed Appconfig to support simple lifecycle hooks, especially a
`ON_BASIC_INIT`. Rationale is that I don't have a lot of "magic" code in the `ON_BASIC_INIT`. Rationale is that I do not have a lot of ``magic'' code in the
Appconfig ctor, rather each subsystem in need of a basic initialisation can Appconfig ctor, rather each subsystem in need of a basic initialisation can
install a small callback. It can do so for other lifecycle events too. install a small callback. It can do so for other lifecycle events too.
- Added the usual magic static ctor to install those callbacks in case they - Added the usual magic static ctor to install those callbacks in case they
@ -233,7 +237,7 @@ OK. So now I've done the following:
for the backend there too, either directly or by registering an callback, for the backend there too, either directly or by registering an callback,
just as it fits in better. just as it fits in better.
- This system is extensible: for example I plan to let the - This system is extensible: for example I plan to let the
link:SessionManager[] issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events. SessionManager issue `ON_SESSION_INIT` and `ON_SESSION_CLOSE` events.
E.g. AssetManager could now just install his callbacks to clean up the E.g. AssetManager could now just install his callbacks to clean up the
internal Asset registry + internal Asset registry +
Ichthyo:: '2008-04-14T03:40:54Z' Ichthyo:: '2008-04-14T03:40:54Z'
@ -243,8 +247,8 @@ absolutely necessary (like flushing the session file, closing display and
network connections, writing a backup or committing to a database). I see no network connections, writing a backup or committing to a database). I see no
problem with bypassing the standard dtor calls in a release build (they add problem with bypassing the standard dtor calls in a release build (they add
no value besides diagnostics and even may cause a lot of pages to be swapped no value besides diagnostics and even may cause a lot of pages to be swapped
in). We could even make this a policy ("don't rely on destructors or in). We could even make this a policy (``don't rely on destructors or
automatic shutdown code to do any cleanup of permanent importance") automatic shutdown code to do any cleanup of permanent importance'')
.State -> Final .State -> Final
I made this final now, details are still in progress to be worked out, but we I made this final now, details are still in progress to be worked out, but we
@ -255,7 +259,7 @@ CT:: '2008-07-26T09:08:11Z'
.State -> Dropped .State -> Dropped
//add reason //add reason
Years later, I'm just stumbling accross this RfC, and it looks somewhat Years later, I'm just stumbling across this RfC, and it looks somewhat
outdated and ``misaligned'' IMHO. outdated and ``misaligned'' IMHO.
* this RfC proposes only one tiny and lightweight feature. * this RfC proposes only one tiny and lightweight feature.
@ -267,16 +271,16 @@ outdated and ``misaligned'' IMHO.
did take: today, Lumiera does the _exact opposite_ of this proposal, did take: today, Lumiera does the _exact opposite_ of this proposal,
there is *no central init call* -- we use *modularised hooks* instead there is *no central init call* -- we use *modularised hooks* instead
and each subsystem is self contained. We even have a subsystem manager and each subsystem is self contained. We even have a subsystem manager
to handle dependencies in startup and shtudown. to handle dependencies in startup and shutdown.
For this reason, I mark this RfC as *dropped* now. + For this reason, I mark this RfC as *dropped* now. +
In case there is further need of discussion regarding this topic, In case there is further need of discussion regarding this topic,
we should preferably start a new RfC. we should preferably start a new RfC.
Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~<prg@ichthyostega.de>~ Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

56
doc/devel/rfc/HowToProceed.txt
View file

@ -1,12 +1,12 @@
Design Process : How to proceed Design Process : How to proceed
=============================== ===============================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-16_ |*Date* | _2007-06-16_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
How To Proceed How To Proceed
-------------- --------------
@ -15,7 +15,7 @@ How we start...
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
. Rewiew this wiki, link:DesignProcess[] .. do we want this formalism?. . Rewiew this wiki, link:/x/DesignProcess.html[RfCs] ... do we want this formalism?.
. Setup git repos. . Setup git repos.
. Each developer makes a design sketch (bouml/wiki) about the subsystem he . Each developer makes a design sketch (bouml/wiki) about the subsystem he
wants to care that is: wants to care that is:
@ -25,32 +25,26 @@ Description
Please add yourself above, contact people already working on something when you Please add yourself above, contact people already working on something when you
want to join. want to join.
Tasks
~~~~~
Pros
~~~~
Cons
~~~~
Alternatives
~~~~~~~~~~~~
Rationale
~~~~~~~~~
Comments Comments
-------- --------
* "Do we want this formalism": this level for formalism seems right at the * ``Do we want this formalism'' -- it feels right at the moment. +
moment. It will work only if we agree on it and do it always in this way. It will work only if we agree on it and do it always in this way.
Every important (large scale) Issue, Question and Decision should be noted Every important (large scale) Issue, Question and Decision should be noted
here and we need to be sure that nothing gets lost. here and we need to be sure that nothing gets lost.
* For the time being this formalism is enough. Later on, I fear, we will need a
bit more (and some Tool support)
-- link:Ichthyostega[] [[DateTime(2007-06-17T00:24:14Z)]]
* Accepted, deployed, done ... Final
-- link:ct[] [[DateTime(2007-06-27T16:13:25Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2007-06'
* For the time being this degree of formalism is enough. +
Later on, I am afraid, we will need a bit more (and some Tool support)...
Ichthyostega:: '2007-06-17T00:24:14Z'
* Accepted, deployed, done ... Final
ct:: '2007-06-27T16:13:25Z'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

87
doc/devel/rfc/InterfaceNamespaces.txt
View file

@ -1,12 +1,12 @@
Design Process : Interface Namespaces Design Process : Interface Namespaces
===================================== =====================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-09-18_ |*Date* | _2008-09-18_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Interface Namespaces Interface Namespaces
-------------------- --------------------
@ -18,17 +18,18 @@ Description
What are the goals? What are the goals?
* We need unique identifiers. * We need unique identifiers.
* We dont want anyone to register at us, this shall be a free system. * We do not require anyone to register with us, this shall be a free system.
* There are 2 kinds, one bound to persons and one to projects as whole. * There are two kinds, one bound to persons and one to projects as whole.
* Uniquenes, not identity is the goal, plugins could even be provided * Uniqueness, not identity is the goal, plugins could even be provided
anonymously. anonymously.
* This is the lowest level interface stuff, usually you'll deal with a * This is the lowest level interface stuff, usually you'll deal with a
high-level descriptor interface which provides much better (human readable) high-level descriptor interface which provides much better (human readable)
metainformation about a plugin. meta information about a plugin.
* The names should follow C identifier rules and either not to hard to deciper * The names should follow C identifier rules and either not to hard to decipher
for a human or completely abstracted into a numeric ID like gpg id or uuid for a human or completely abstracted into a numeric ID like GPG id or UUID
* Conclusion followed some mailinglist and IRC discussion: (see * Conclusion followed some discussion on IRC and in the
http://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html)[] https://lists.lumiera.org/pipermail/lumiera/2008-September/000054.html[Mailinglist(2008-09)]
First part: unique prefix First part: unique prefix
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
@ -36,7 +37,7 @@ First part: unique prefix
Domain names and emails names encoding Domain names and emails names encoding
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Domain names in lowercase, dots and special chars removed, first char must be a Domain names in lowercase, dots and special chars removed, first char must be a
aphphanumeric character (if it is numeric, just write it out): alphanumeric character (if it is numeric, just write it out):
------------------------------------------------------------ ------------------------------------------------------------
lumiera.org -> lumieraorg lumiera.org -> lumieraorg
@ -47,7 +48,7 @@ aphphanumeric character (if it is numeric, just write it out):
These are used when the provider is a project and not an individual person. These are used when the provider is a project and not an individual person.
If the provider of a interface is a individual person then he encodes his email If the provider of a interface is a individual person then he encodes his email
address in a similar way The @ sign is encoded as uppercase "AT": address in a similar way The @ sign is encoded as uppercase `"AT"`:
------------------------------------------------------------ ------------------------------------------------------------
@ -57,8 +58,8 @@ address in a similar way The @ sign is encoded as uppercase "AT":
Abstract identifiers Abstract identifiers
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
As alternative method one can use his gpg (or pgp) key ids or full As alternative method one can use his GPG (or PGP) key ids or full
fingerprints. These are encoded as uppercase 'PGP' or 'GPG' followed with a fingerprints. These are encoded as uppercase `"PGP"` or `"GPG"` followed with a
sequence of hex digits (both upper and lower case allowed): sequence of hex digits (both upper and lower case allowed):
@ -67,8 +68,8 @@ sequence of hex digits (both upper and lower case allowed):
PGP09FF1387811ADFD4AE84310960DEA1B8AC4F4FF4 PGP09FF1387811ADFD4AE84310960DEA1B8AC4F4FF4
------------------------------------------------------------ ------------------------------------------------------------
Next completely random identifiers (uuid's) are used by prefixing them with Next completely random identifiers (UUIDs) are used by prefixing them with
uppercase "UID" followed by some alphanumeric characters (no underline), no uppercase `"UID"` followed by some alphanumeric characters (no underline), no
encoding is specified but must conform to be a C identifier, shall give a encoding is specified but must conform to be a C identifier, shall give a
entropy of 128 bits: entropy of 128 bits:
@ -76,27 +77,28 @@ entropy of 128 bits:
UIDd557753400ad4ac6912773b1deb4d99d UIDd557753400ad4ac6912773b1deb4d99d
------------------------------------------------------------ ------------------------------------------------------------
Remarks: this are now quite a lot more or less unique encodings, notably we .Remarks
could allow them all, they dont clash with each other. They would be parseable This are now quite a lot more or less unique encoding, notably we
if needed, but we never ever need to parse them, they are just taken as whole could allow them all, they do not clash with each other. They would be parseable
and have no other meaning then being unique. if needed, but we never ever need to parse them, they are just taken as whole
and have no other meaning then being unique.
Following Parts: hierachic namespace Following Parts: hierarchic namespace
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lumiera itself will use some hierachic naming scheme for it interface Lumiera itself will use some hierarchical naming scheme for it interface
declarations and implementations. The details will be layed out next, declarations and implementations. The details will be layed out next,
genereally thinks look like: generally thinks look like:
------------------------------------------------------------ ------------------------------------------------------------
lumieraorg_backend_frameprovider lumieraorg_backend_frameprovider
lumieraorg_plugin_video lumieraorg_plugin_video
------------------------------------------------------------ ------------------------------------------------------------
it is suggested that anyone providing plugins for lumiera follows this and it is suggested that anyone providing plugins for Lumiera follows this and
extends it with his own identifier: extends it with his own identifier:
for examle joecoder``@freevideo.org writes a ultrablur then its identifier for example `joecoder@freevideo.org` writes a »ultrablur« then its identifier
would look like: would look like:
------------------------------------------------------------ ------------------------------------------------------------
@ -108,7 +110,7 @@ would look like:
Tasks Tasks
~~~~~ ~~~~~
The above described scheme will be implemented and used by me (cehteh). The above described scheme will be implemented and used by _cehteh_.
@ -117,26 +119,29 @@ Rationale
~~~~~~~~~ ~~~~~~~~~
I believe that writing plugins for Lumiera shall be simple. We do not want some I believe that writing plugins for Lumiera shall be simple. We do not want some
central registry or management. Anyone shall be able to just start to write central registry or management. Anyone shall be able to just start to write
plugins. But that puts some reponsibility on the namespace so that all plugins plugins. But that puts some responsibility on the namespace so that all plugins
can coexist and their names don't clash. The above describes a very simple and can coexist and their names don't clash. The above describes a very simple and
flexible nameing system which anyone can follow. It produces names which should flexible naming system which anyone can follow. It produces names which should
be sufficiently unique for practical purposes. It leaves alternatives for be sufficiently unique for practical purposes. It leaves alternatives for
providing plugins as institutuion, individual or even anonymously. providing plugins as institution, individual or even anonymously.
Conclusion Conclusion
---------- ----------
Accepted by October.2008 developer meeting Accepted by the
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_interface_naming_convention[October.2008 developer meeting]
Addendum Internal Interfaces Addendum: Internal Interfaces
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interfaces which are internal and not meant for public use have 2 underscores Interfaces which are internal and not meant for public use have 2 underscores
after the prefix (eg: `lumieraorg__`). These interfaces must not be used by after the prefix (eg: `lumieraorg__` ). These interfaces must not be used by
third party plugins, they are subject of unannounced changes or removal and third party plugins, they are subject of unannounced changes or removal and
make no guarantee about backwards compatibility. When we spot someone using make no guarantee about backwards compatibility. When we spot someone using
this interfaces we ''will break'' his plugin ''intentionally''! this interfaces we will *break this plugin* intentionally!
-- link:ct[] [[DateTime(2008-10-24T03:43:43Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2008-10-24T03:43:43Z'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

16
doc/devel/rfc/LayerNames.txt
View file

@ -3,12 +3,12 @@ LayerNames
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _Fr 05 Oct 2018 15:05:58 CET_ |*Date* | _Fr 05 Oct 2018 15:05:58 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -139,7 +139,7 @@ to consult anyone, since -- right now -- I am working alone on the code base.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -204,5 +204,5 @@ Ichthyostega:: '2018-11-15 19:38:32 +0100' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

55
doc/devel/rfc/LumieraDesignProcess.txt
View file

@ -1,12 +1,12 @@
Design Process : Lumiera Design Process Design Process : Lumiera Design Process
======================================= =======================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-03_ |*Date* | _2007-06-03_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Define a Lumiera design process Define a Lumiera design process
------------------------------- -------------------------------
@ -17,25 +17,25 @@ Description
~~~~~~~~~~~ ~~~~~~~~~~~
Just use this Wiki to make it easy to add proposals in a well defined manner. Just use this Wiki to make it easy to add proposals in a well defined manner.
I'd like to introduce a slightly formalized process for the ongoing Lumiera I'd like to introduce a slightly formalized process for the ongoing Lumiera planning:
planning:
* Every proposal is instantiated as 'Idea', the author gives other people the * Every proposal is instantiated as `*Idea*', the author gives other people the
opportunity to review and comment on it with extreme prejudice, while still opportunity to review and comment on it with extreme prejudice, while still
working out details. working out details.
* When the the 'Idea' in a proper form and worked out in most details it * When the the `Idea' in a proper form and worked out in most details it
becomes a 'Draft'. This 'Draft' need to be carefully reviewed, commented, becomes a `*Draft*' -- such a `Draft' need to be carefully reviewed,
perhaps corrected and rated by the other Developers. commented and perhaps corrected and rated by the other Developers.
* At some point we may decide that a 'Draft' becomes a 'Final' (I leave it * At some point we may decide that a `Draft' becomes a `*Final*' (I leave it
open how this decision shall be done for now). 'Final' Documents will be open how this decision shall be done for now). `Final' RfC documents will be
imported into repository. imported into the Git repository.
* Sometimes proposals will become dropped for some reason, this is indicated * Sometimes proposals will become dropped for some reason, this is indicated
by changing their state to 'Dropped', they still stay in the system for by changing their state to `*Dropped*', they still stay in the system for
further reference. further reference.
Tasks Tasks
~~~~~ ~~~~~
* We need to refine the `Lumiera/DesignProcessTemplate`. * We need to build and refine a ``Design Process Template''.
Pros Pros
~~~~ ~~~~
@ -57,8 +57,10 @@ Alternatives
~~~~~~~~~~~~ ~~~~~~~~~~~~
* We could use some forum, Trac, Mailinglist or whatever instead. * We could use some forum, Trac, Mailinglist or whatever instead.
* Just for Design documentation 0I would give http://bouml.free.fr/[Bouml] a * Just for Design documentation I would give
try. For myself, I am not very fond of UML Design tools, while Bouml looks https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml] a
try. +
For myself, I am not very fond of UML Design tools, while Bouml looks
quite promising and we could maintain the UML model in git repositories quite promising and we could maintain the UML model in git repositories
which would be more favorable than this centralized wiki. The backside is which would be more favorable than this centralized wiki. The backside is
that this needs even more agreement between the developers, everyone has to that this needs even more agreement between the developers, everyone has to
@ -68,17 +70,16 @@ Alternatives
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
Wiki works it is simple to use and just flexible enough to handle the task. I Wiki already works, it is simple to use and just flexible enough to handle the task.
don't go to install any other software for such tasks on my server. While the I won't go to install any other software for such tasks on my server. While the
design progresses I'd propose to move our work into git repositories and design progresses I'd propose to move our work into Git repositories and
eventually phase this wiki pages out anyways. I'd rather like to start out eventually phase this wiki pages out anyways. I'd rather like to start out
distributed/git right away .. but git gives us only a fine storage layer, for a distributed/git right away ... but git gives us only a fine storage layer, for a
design process we need some good presentation layer (later when using git and design process we need some good presentation layer (later when using Git and
starting the implementation everyones favorite editor serves for that) I have starting the implementation everyones favorite editor serves for that) I have
no better ideas yet to solve the presentation problem other than using this no better ideas yet to solve the presentation problem other than using this
wiki (or maybe bouml). wiki (or maybe bouml).
Comments ''''
--------
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

133
doc/devel/rfc/LumieraForwardIterator.txt
View file

@ -1,20 +1,20 @@
Design Process: Lumiera Forward Iterator Design Process: Forward Iterator
======================================== ================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2009-11-01_ |*Date* | _2009-11-01_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
The situation focussed by this concept is when an API needs to expose a The situation addressed by this concept is when an API needs to expose a
sequence of results, values or objects, instead of just yielding a function sequence of results, values or objects, instead of just yielding a function
result value. As the naive solution of passing an pointer or array creates result value. The naive solution of passing an pointer or array creates
coupling to internals, it was superseded by the GoF coupling to internals, and thus was superseded by the GoF
https://en.wikipedia.org/wiki/Iterator[Iterator pattern]. Iteration can be https://en.wikipedia.org/wiki/Iterator[Iterator pattern]. Iteration can be
implemented by convention, polymorphically or by generic programming; we use implemented by _convention_, _polymorphism_ or by _generic programming;_
the latter approach. we use the latter approach.
Lumiera Forward Iterator concept Lumiera Forward Iterator concept
@ -24,18 +24,18 @@ An Iterator is a self-contained token value, representing the promise to pull a
sequence of data sequence of data
- rather then deriving from an specific interface, anything behaving - rather then deriving from an specific interface, anything behaving
appropriately _is a Lumiera Forward Iterator._ appropriately _can be used as Lumiera Forward Iterator._
- the client finds a typedef at a suitable, nearby location. Objects of this - the client finds a typedef at a suitable, nearby location. Objects of this
type can be created, copied and compared. iterator type can be created, copied and compared.
- any Lumiera forward iterator can be in _exhausted_ (invalid) state, which - any Lumiera forward iterator can be in _exhausted_ (invalid) state, which
can be checked by +bool+ conversion. can be checked by `bool` conversion.
- especially, default constructed iterators are fixed to that state. - Notably, all default constructed iterators are fixed to that state.
Non-exhausted iterators may only be obtained by API call. Non-exhausted iterators may only be obtained by API call.
- the exhausted state is final and can't be reset, meaning that any iterator - the exhausted state is final and can not be reset, implying that any iterator
is a disposable one-way-off object. is a disposable one-way-off object.
- when an iterator is _not_ in the exhausted state, it may be _dereferenced_ - when an iterator is _not_ in the exhausted state, it may be _dereferenced_
(+*i+), yielding the ``current'' value (`*i`) to yield the ``current value''
- moreover, iterators may be incremented (+++i+) until exhaustion. - moreover, iterators may be incremented (`++i`) until exhaustion.
Discussion Discussion
@ -43,26 +43,24 @@ Discussion
The Lumiera Forward Iterator concept is a blend of the STL iterators and The Lumiera Forward Iterator concept is a blend of the STL iterators and
iterator concepts found in Java, C#, Python and Ruby. The chosen syntax should iterator concepts found in Java, C#, Python and Ruby. The chosen syntax should
look familiar to C++ programmers and indeed is compatible to STL containers and look familiar to C++ programmers and indeed is compatible to STL containers and
ranges. To the contrary, while a STL iterator can be thought off as being just ranges. However, while a STL iterator can be thought off as being actually ``just
a disguised pointer, the semantics of Lumiera Forward Iterators is deliberately a disguised pointer'', the semantics of Lumiera Forward Iterators is deliberately
reduced to a single, one-way-off forward iteration, they can't be reset, reduced to a single, one-way-off forward iteration, they can't be reset or
manipulated by any arithmetic, and the result of assigning to an dereferenced manipulated by any arithmetic, and the result of assigning to an dereferenced
iterator is unspecified, as is the meaning of post-increment and stored copies iterator is unspecified, as is the meaning of post-increment and stored copies
in general. You _should not think of an iterator as denoting a position_ -- in general. You _should not think of an iterator as something to describe a position_ --
just a one-way off promise to yield data. rather it is a one-time promise to pull some data.
Another notable difference to the STL iterators is the default ctor and the Another notable difference to the STL iterators is the default ctor and the
+bool+ conversion. The latter allows using iterators painlessly within +for+ `bool` conversion. The latter allows using iterators painlessly within `for`
and +while+ loops; a default constructed iterator is equivalent to the STL and `while` loops; a default constructed iterator is equivalent to the STL
container's +end()+ value -- indeed any _container-like_ object exposing container's `end()` value -- and indeed, any _container-like_ object exposing
Lumiera Forward Iteration is encouraged to provide such an +end()+-function, Lumiera Forward Iteration is encouraged to provide such an `end()`-function,
additionally enabling iteration by +std::for_each+ (or Lumiera's even more additionally enabling iteration by +std::for_each+.
convenient
+util::for_each()+).
Implementation notes Implementation notes
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
*iter-adapter.hpp* provides some helper templates for building Lumiera Forward *`iter-adapter.hpp`* provides some helper templates for building Lumiera Forward
Iterators. Iterators.
- _IterAdapter_ is the most flexible variant, intended for use by custom - _IterAdapter_ is the most flexible variant, intended for use by custom
@ -80,7 +78,7 @@ Implementation notes
Similar to the STL habits, Lumiera Forward Iterators should expose typedefs for Similar to the STL habits, Lumiera Forward Iterators should expose typedefs for
+pointer+, +reference+ and +value_type+. Additionally, they may be used for +pointer+, +reference+ and +value_type+. Additionally, they may be used for
resource management purposes by ``hiding'' a ref-counting facility, e.g. resource management purposes by ``carrying'' a ref-counting facility, e.g.
allowing to keep a snapshot or restult set around until it can't be accessed allowing to keep a snapshot or restult set around until it can't be accessed
anymore. anymore.
@ -94,7 +92,7 @@ relies on that interface for discovering session contents. Besides that, we
need more implementation experience. need more implementation experience.
Some existing iterators or collection-style interfaces should be retro-fitted. Some existing iterators or collection-style interfaces should be retro-fitted.
See https://issues.lumiera.org/ticket/349[Ticket #349]. + See https://issues.lumiera.org/ticket/349[Ticket #349].
Moreover, we need to Moreover, we need to
gain experience about mapping this concept down into a flat C-style API. gain experience about mapping this concept down into a flat C-style API.
@ -111,17 +109,16 @@ Alternatives
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
APIs should be written such as not tie them to the current implementation. APIs should be written in a way that avoids to tie them to the current implementation.
Exposing iterators is known to create a strong incentive in this direction and Exposing iterators is known to create a strong incentive in this direction and
thus furthers the creation of clean APIs. thus furthers the creation of clean APIs.
Especially in Steam-Layer we utilise already several iterator implementations, Especially in Steam-Layer we employ already several iterator implementations,
but without an uniform concept, these remain just slightly disguised but without an uniform concept, these remain just slightly disguised
implementation types of a specific container. Moreover, the STL defines various implementation types of a specific container. Furthermore, the STL defines
and very elaborate iterator concepts. Ichthyo considers most of these an several quite elaborate iterator concepts. _Ichthyo_ considers most of these an
overkill and an outdated aproach. Many modern programming languages build with overkill and an outdated implementation-centric approach. Many modern programming
success on a very simple iterator concept, which allows once to pull a sequence languages rely on a very simple iterator concept with much success.
of values -- and nothing more.
Thus the idea is to formulate a concept in compliance with STL's forward Thus the idea is to formulate a concept in compliance with STL's forward
iterator -- but augmented by an stop-iteration test. This would give us basic iterator -- but augmented by an stop-iteration test. This would give us basic
@ -136,15 +133,15 @@ Comments
-------- --------
//comments: append below //comments: append below
Now in use since more then a year, without turning up any serious problems. This scheme is now in use since more then a year, without turning up any serious problems.
The only _minor concern_ I can see is that this concept, as such, doesn't solve The only _minor concern_ I can see is that this concept, as such, does not solve the
the problem with exposing implementation details of the underlying container on the API. problem with exposing implementation details of the underlying container on the API.
Similar to STL Iterators, the actual implementation representation is only disguised Similar to STL Iterators, the actual implementation representation is only disguised
behind a 'typedef'. But, generally speaking, this is an inevitable consequence of the behind a `typedef'. But, generally speaking, this is an inevitable consequence of the
``zero overhead'' abstraction. For the cases when an indirection (via VTable) is feasible, ``zero overhead'' abstraction. For the cases when an indirection (via VTable) is feasible,
I've created the 'IterSource' template, which sticks to this Lumiera Forward Iterator I've created the **`IterSource`** template, which adheres to this Lumiera Forward Iterator
concept, but provides an opaque frontend, allowing to decouple completely from the concept, yet provides an opaque frontend, allowing to decouple completely from the
actual implementation. Besides that, over time I've written several standard adapters actual implementation. Besides that, over time, I have written several standard adaptors
for the most common STL containers, plus Map, key and value extractors. for the most common STL containers, plus Map, key and value extractors.
Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST' Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST'
@ -155,19 +152,21 @@ would require a ``deep copy'' of any underlying data structures.
Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~<prg@ichthyostega.de>~ Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~<prg@ichthyostega.de>~
NOTE: Lumiera Forward Iterators can be made to work together with the NOTE: Lumiera Forward Iterators can be made to work together conveniently
'range for loop', as introduced with C++11. The preferred solution with the »Range-for Loop«, as introduced with C++11. The preferred
is to define the necessary free functions `begin` and `end` for ADL. solution is to define the necessary free functions `begin` and `end`
This is best done on a per implementation base. We consider a generic for ADL. This is best done on a per implementation base.
solution not worth the effort
This is to say, these two concepts can be made to work together well. While, Considered at a conceptual level, this may seem surprising, since the
at a conceptual level, they are not really compatible, and build on a Range-Iteration from the C++ standard and our Forward-Iteration do not mesh
different understanding: The standard for-loop assumes ``a container'', up completely, and build upon a different understanding: The standard Range-`for`
while our Forward Iterator Concept deals with ``abstract data sources''. Loop assumes ``a container'', or at least ``a data range'', while our
The user needs to understand the fine points of that conceptual difference: Forward Iterator Concept deals with ``abstract data sources''. So
these are two concepts operating at a different level of abstraction,
yet able to be stacked upon each other. However, the user needs
to understand the fine points of those conceptual differences:
- if you apply the range-`for` construct on a container, you can iterate - if you apply the Range-`for` construct on a container, you can iterate
as often as you like. Even if the iterators of that container are as often as you like. Even if the iterators of that container are
implemented in compliance with the Lumiera Forward Iterator concept. implemented in compliance with the Lumiera Forward Iterator concept.
- but if you apply the range-`for` construct on _a given iterator_, - but if you apply the range-`for` construct on _a given iterator_,
@ -184,9 +183,17 @@ Ichthyostega:: 'Sa 04 Jul 2015 22:57:51 CEST' ~<prg@ichthyostega.de>~
Final Final
~~~~~ ~~~~~
Accepted on developer meeting Accepted on
link:{ldoc}/devel/meeting_summary/2011-04-13.html#_lumiera_forward_iterator[developer meeting]
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter Christian Thaeter:: 'Thur 14 Apr 2011 02:52:30 CEST'
TIP: The Lumiera Forward Iterator became a widely used scheme.
One notable extension built on top is the _filter pipeline_ template `IterExplorer`.
Another point worth mentioning is that such an iterator can not only yield values
(as described in this RfC), but may also expose a reference into an underlying
_State Core_ -- which makes high-performance collaboration protocols possible,
while keeping all participants opaque.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

21
doc/devel/rfc/MakeSconsTheOfficialBuildSystem.txt
View file

@ -3,23 +3,24 @@ Make Scons the official build System
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _Mi 11 Jan 2012 21:45:58 CET_ |*Date* | _Mi 11 Jan 2012 21:45:58 CET_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
_Bless SCons the default build system for Lumiera._ _Bless SCons into the default build system for Lumiera._
******************************************************************************** ********************************************************************************
Description Description
----------- -----------
//description: add a detailed description: //description: add a detailed description:
So far we using autotools and scons in parallel. Over time the need arose to have one So far we are using Autotools and SCons in parallel.
Over time the need arose to have one
reliable supported build system. This shall be SCons. reliable supported build system. This shall be SCons.
@ -65,7 +66,7 @@ Rationale
Conclusion Conclusion
---------- ----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
result of discussions and evaluation during the last years result of discussions and evaluation during the last years
@ -84,5 +85,5 @@ Christian Thaeter:: 'Wed 11 Jan 2012 22:28:36 CET' ~<ct@pipapo.org>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

52
doc/devel/rfc/Manifest.txt
View file

@ -1,17 +1,17 @@
Design Process : Manifest Design Process : Manifest
========================= =========================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-09_ |*Date* | _2007-06-09_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Manifest A Community Manifest
-------- --------------------
This Proposal describe the general ideas how the community will work together This Proposal describes the general ideas how the community will work together
to create Lumiera. to create Lumiera.
@ -27,13 +27,17 @@ Background
~~~~~~~~~~ ~~~~~~~~~~
Cinelerra is quite an old project, there is an original version from Cinelerra is quite an old project, there is an original version from
Heroinewarrior.com and a community fork http://cinelerra-cv.wikidot.com/[Cinelerra-CV]. https://web.archive.org/web/20070519111115/http://heroinewarrior.com/index.php3[»Heroine Virtual« LTD]
aka »Heroine Warrior« and a community maintained version
https://web.archive.org/web/20070519204838/http://cv.cinelerra.org/[Cinelerra-CV]. ~(http://cinelerra-cv.wikidot.com/[2025])~
The original author claims that there was no-one producing useable input despite their The original author claims that there was no-one producing useable input despite their
requests while cinelerra was in development, and indeed the Cinelerra-CV community only requests while Cinelerra was in development, and indeed the Cinelerra-CV community only
feeds back the source released by the original author into their SVN repository feeds back the source released by the original author into their SVN repository
and maintains few fixes. There is not much development going on. Some people and maintains few fixes. There is not much development going on. Some people
have created new functionality/features from time to time which have rarely have created new functionality/features from time to time which they need
been merged into the main repository and maintained by themselves. to maintain by themselves, since extensions have rarely
been merged back into the main repository.
The Cinelerra community is a quite loose group of individuals, there is some The Cinelerra community is a quite loose group of individuals, there is some
fluctation on the developer base and almost all developers have day jobs which fluctation on the developer base and almost all developers have day jobs which
@ -62,7 +66,7 @@ without maintaining the bad sides again:
. *Make it easy to contribute* . *Make it easy to contribute*
Even if it is favorable when we have people which are continously working on Even if it is favorable when we have people which are continously working on
Lumiera, it's a fact that people show up, send a few patches and then Cinelerra, it is a fact that people show up, send a few patches and then
disappear. The development model should be prepared for this by: disappear. The development model should be prepared for this by:
.. Good documentation .. Good documentation
.. Well defined design and interfaces .. Well defined design and interfaces
@ -104,9 +108,27 @@ things where they are not profound, help each other, make things right instead
of blaming someone. Everyone should rate himself at what he can do best on the of blaming someone. Everyone should rate himself at what he can do best on the
project. project.
Comments Comments
-------- --------
[underline]#This document is one of the **first RfC**s# published in *Summer 2007*, +
as a new community movement was about to form, with the goal to improve Cinelerra
for real, in a new version Cinelerra-3.
Early in 2008, this initiative had turned into a new project, with the
https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen]
name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries
were migrated from _Cehteh_'s `pipapo.org` Wiki to the
https://web.archive.org/web/20110513134311/http://lumiera.org/[new Lumiera website],
thereby mass-renaming all references Cinelerra -> Lumiera
While this »Manifest« captures well the open minded spirit of the new project,
actual development never happened in the ``community driven'' everyone pulls-from
everyone style; rather, there were immediately two, later three _core devs,_
which integrated sometimes large, yet mostly small contributions by other people.
After 2012, _Ichthyo_ kept the project going as a single developer, backed by
a small group of supporters.
Ichthyostega:: '2025-09-15'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

80
doc/devel/rfc/MarbleMode.txt
View file

@ -1,16 +1,18 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-10-10_ |*Date* | _2008-10-10_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
the Marble Mode the Marble Mode
--------------- ---------------
''dual working styles -- build up from small pieces of clay or cut away the
unneeded parts from a block of marble'' [quote]
``dual working styles -- build up from small pieces of clay +
or cut away the unneeded parts from a block of marble''
While the usual UI of video editors quite well supports a working style While the usual UI of video editors quite well supports a working style
assembling the result from small building blocks by relying on clips (media assembling the result from small building blocks by relying on clips (media
@ -21,43 +23,44 @@ objects)
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
This proposal stems from an discussion on the Mailinglist starting with the This proposal stems from an discussion on the Mailinglist starting with the
quote from Walter Murch "Marble and Clay". quote from Walter Murch »Marble and Clay«.
+ +
It is thought to be in support and to complement nasa's It is thought to be in support and to complement _nasa_'s
link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator] link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator]
The central Idea is to remove the difference between "viewing", i.e. the media The central Idea is to remove the difference between ``viewing'' ⟷ ``editing'',
viewer and the timeline/Sequence on the other hand. Lumiera is designed to i.e. the media viewer and the timeline/Sequence on the other hand.
handle multiple Sequences, which can even arbitrarily be embedded in one Lumiera is designed to handle multiple Sequences, which can even be embedded
another (the so called _meta-clips_ ). Basically, Sequences are a comparatively arbitrarily in one another (the so called _virtual clips_ or _meta-clips_).
Basically, Sequences are a comparatively
cheap resource, so the idea is to create a new Sequence on-the-fly to do the cheap resource, so the idea is to create a new Sequence on-the-fly to do the
viewing already based on a complete timeline. It is up to the user finally to viewing already based on a complete timeline. It is up to the user finally to
promote one of these workbench-like timelines to become "the" master timeline. promote one of these workbench-like timelines to become ``the'' master timeline.
To make this usable, in the GUI there should be a slightly different To make this usable, in the GUI there should be a slightly different
representation which aims at reducing vertical screen usage. Also the track representation which aims at reducing vertical screen usage. Also the track
heads could be reduced, e.g. we don't need controls for mixing and panning, the heads could be reduced, e.g. we don't need controls for mixing and panning, the
effect stacks could be reduced to a simple mark indicating that there is any effect stacks could be reduced to a simple mark indicating that there is any
effect in a given time range, anything concerned with the fine points of effect in a given time range, anything concerned with the fine points of
wiring, tweaking effects and controling automation could be left out wiring, tweaking effects and controlling automation could be left out
deliberately. This would allow us to have several independant timelines deliberately. This would allow us to have several independent timelines
above/below each other. There could be at least two, maybe even three or four above/below each other. There could be at least two, maybe even three or four
"slots" which could be allocated by a timeline to display. Every time you open ``slots'' which could be allocated by a timeline to display. Every time you open
a new media, a new Sequence will be created on the fly and a new timeline a new media, a new Sequence will be created on the fly and a new timeline
display of this Sequence will be available, replacing the least recently used display of this Sequence will be available, replacing the least recently used
timeline display slot. Of course, re-visiting an already opened media will timeline display slot. Of course, re-visiting an already opened media will
bring back the corresponding timeline in the state you left it, with markers, bring back the corresponding timeline in the state you left it, with markers,
notes, maybe even trimmings and added clips. Contrast this GUI mode with the notes, maybe even trimmings and added clips. Contrast this GUI mode with the
usual working mode (the "clay mode"), where there is _one_ central timeline, usual working mode (the »clay mode«), where there is _one_ central timeline,
probably with tabs to switch between multiple independant Sequences (including probably with tabs to switch between multiple independent Sequences (including
the ones which actually are embedded in another timeline as meta-clips) the ones which actually are embedded in another timeline as meta-clips)
Basically, each of these timelines has a separate, independant transport, but Basically, each of these timelines has a separate, independent transport, but
transports can be locked together, and in locked state you can displace/offset transports can be locked together, and in locked state you can displace/offset
the locked partners relative to one another. Moreover, there would be at least the locked partners relative to one another. Moreover, there would be at least
two viewer windows which would be automatically connected to recieve the ouput two viewer windows which would be automatically connected to receive the output
of the timelines as new timelines are placed in the visible slots to work with. of the timelines as new timelines are placed in the visible slots to work with.
To round things up, we need good keybindings for navigtation, and of course you To round things up, we need good key bindings for navigation, and of course you
can liberally mark parts and spill them over to another timeline, either can liberally mark parts and spill them over to another timeline, either
overwriting or shifting existing footage there. overwriting or shifting existing footage there.
@ -72,7 +75,7 @@ Initially this new Sequence would be anonymous. But the moment you do the first
non-trivial modification there (like adding a label, trimming off parts, adding non-trivial modification there (like adding a label, trimming off parts, adding
/deleting tracks), the new Sequence would be promoted to be a named and /deleting tracks), the new Sequence would be promoted to be a named and
persisted entity, which from then on could itself serve as a new persisted entity, which from then on could itself serve as a new
"pseudo-media". It would appear as an asset on its own (probably in a special ``pseudo-media''. It would appear as an asset on its own (probably in a special
sub category), and it could be used as a source to create clips from. This way, sub category), and it could be used as a source to create clips from. This way,
you could work with your media, prepare it, augment it even by adding effects you could work with your media, prepare it, augment it even by adding effects
like colour correction. And because it's a real Sequence, you could do like colour correction. And because it's a real Sequence, you could do
@ -80,22 +83,22 @@ non-trivial things there right in-place, like adding new sub-tracks, placing
other media on them -- and then later on use this prepared media like a real other media on them -- and then later on use this prepared media like a real
media captured from camera source. media captured from camera source.
Finally, there should be the possibility to "play" a clip bin, thereby Finally, there should be the possibility to ``play'' a clip bin, thereby
on-the-fly creating a new Sequence filled with all the clips in the order they on-the-fly creating a new Sequence filled with all the clips in the order they
were arranged in the bin. This would yield a bridge to the more clip-oriented were arranged in the bin. This would yield a bridge to the more clip-oriented
working style and also provide a cheap implementation of the "sparse timeline" working style and also provide a cheap implementation of the ``sparse timeline''
or "storyboard mode" or ``storyboard mode''
Tasks Tasks
^^^^^ ^^^^^
* have several switchable _perspectives_ or working modes in the GUI * have several switchable _perspectives_ or working modes in the GUI
* associate a _workflow state_ whith each Sequence, to track when an Sequence * associate a _workflow state_ with each Sequence, to track when an Sequence
is just anonymous, gets a named entity, is a clip-bin-tied Sequence, or is just anonymous, gets a named entity, is a clip-bin-tied Sequence, or
finally is the master Sequence connected to the global output pipes section. finally is the master Sequence connected to the global output pipes section.
* work out the details of the "display slot allocation" * work out the details of the ``display slot allocation''
* provide an "opening media" compound function, comprised of * provide an ``opening media'' compound function, comprised of
* creating the clip covering the whole media (./) (already implemented) * creating the clip covering the whole media (./) (already implemented)
* creating a new Sequence and populating it with this clip * creating a new Sequence and populating it with this clip
* make locked-together transports work * make locked-together transports work
@ -115,12 +118,12 @@ Tasks
Rationale Rationale
^^^^^^^^^ ^^^^^^^^^
Lumiera is not pioneering the video editing by computers. We are sort of Lumiera is not pioneering the video editing by computers. We are sort of
second-generation (or even third generation) of computer based editing systms. second-generation (or even third generation) of computer based editing systems.
The tradition of conventional, film based editing clearly shows us these two The tradition of conventional, film based editing clearly shows us these two
quite different working approaches, which obviously can have quite some impact quite different working approaches, which obviously can have quite some impact
on the resulting style and rythm of the final movie. The distinguishing on the resulting style and rhythm of the final movie. The distinguishing
property of the working style to be supported by the "marble mode" is that it property of the working style to be supported by the »marble mode«s is that it
bypasses the state of creating and organizing clips, but rather directly bypasses the state of creating and organising clips, but rather directly
evolves the footage into the final cut. This working style is dual to the evolves the footage into the final cut. This working style is dual to the
common clip based approach, none of them is superior or inferior, thus we common clip based approach, none of them is superior or inferior, thus we
should actively support both working styles. should actively support both working styles.
@ -136,12 +139,13 @@ Comments
Final Final
~~~~~ ~~~~~
Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_marble_mode[Apr.2011 developer meeting]. +
Everyone likes this and we want to have this. But this is rather a concept Everyone likes this and we want to have this. But this is rather a concept
which needs a lot more discussion for the implementation. Further details may which needs a lot more discussion for the implementation. Further details may
follow where these thingsare worked out. follow where these things are worked out.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

90
doc/devel/rfc/MasterRepositorySetup.txt
View file

@ -1,12 +1,12 @@
Design Process : Shared Master Repository Design Process : Master Repository
========================================= ==================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-04-08_ |*Date* | _2008-04-08_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Shared Master Repository setup Shared Master Repository setup
------------------------------ ------------------------------
@ -15,42 +15,66 @@ This describes how the shared MASTER is set up and syncronized.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
We have now a shared master repository in /git/LUMIERA. The public/anonymous We have now a shared master repository in
git url is 'git://git.lumiera.org/LUMIERA', for people with ssh access it is https://git.lumiera.org/?p=LUMIERA;a=summary[/git/LUMIERA].
pushable at 'git.lumiera.org:/git/LUMIERA'.
The repository is maintained by cehteh. It updates daily by a script. - The public/anonymous git url is [yellow-background]#`git://git.lumiera.org/LUMIERA`#
- for people with ssh access it is pushable at [purple]#`UID@git.lumiera.org:/git/LUMIERA`#.
There are the following branches updated from their respective maintainer The repository is maintained by _cehteh_. It updates daily by a script.
repositories:
[grid="all"] There are the following branches updated from their respective maintainer repositories:
`-------------`----------------------------------------------------`----------------------------
*BRANCHNAME* *DESCRIPTION*
*Automatic updated from*
'master' Stable branch, use this as generic entry point. cehteh,
ichthyo
'library' Support library development cehteh,
ichthyo
'proc' Render core development ichthyo
'backend' Data backend development, cehteh
'gui' GUI development joel
------------------------------------------------------------------------------------------------
Automatic syncronization is only done for 'fast-forward' updates, conflicting [options="header", cols="^m,3<,2e"]
|====================================
|BRANCHNAME | DESCRIPTION | Updated from...
| master | Stable branch; generic entry point. | cehteh, ichthyo
| library | Support library development | cehteh, ichthyo
| proc | Render core development | ichthyo
| backend | Data backend development, | cehteh
| gui | GUI development | joel
|====================================
Automatic syncronization is only done for `fast-forward' updates, conflicting
changes are rejected. It is still possible to manually push to this repository changes are rejected. It is still possible to manually push to this repository
to override automatic syncronization. to override automatic syncronization.
Please suggest changes for this setup when required (new branches, difefrent
maintainers, ...)
Comments Comments
-------- --------
Instead this polling @daily update maintainers might use git hooks on their Instead of this polling @daily update, maintainers might use git hooks on their
repos to push relevant things, be careful not to push cruft or tags (which tags repos to push relevant things, be careful not to push cruft or tags (which tags
shall be present here is not yet resolved -> no tags for now) shall be present here is not yet resolved -> no tags for now)
-- link:ct[] [[DateTime(2008-04-08T21:48:51Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2008-04-08T21:48:51Z'
''''
[underline]#Historical remark#: This RfC describes the setup we used up to ~2012. +
After that point, I was working alone basically (not counting occasional small contributions),
and consequently the current state could be found in the ``ichthyo'' Git repository
most of the time -- yet the shared master repository is still updated occasionally,
as is a mirror at https://github.com/Ichthyostega/Lumiera/[Github]
This summer I decided to switch the project over to the
link:{ldoc}/technical/code/GitBranching.html[Git-flow] branching model,
knowing from my own professional background that this scheme is a good fit
for this kind of project.
This has the consequence however that the usage pattern described in this RfC
*becomes obsolete*, as actual development mostly takes place on development or
feature branches now, consolidating all progress into the branch `integration`.
The branch `master` carries only tested and released code going forward.
That being said -- the shared master at [yellow-background]#`git://git.lumiera.org/LUMIERA`#
still contains the _official_ state of the Lumiera codebase, while
actual development is published first in a repository per developer
(so effectively in
https://git.lumiera.org/?p=lumiera/ichthyo;a=summary[the Ichthyo repository]
for the time being);
development is consolidated intermittently into the
https://git.lumiera.org/?p=LUMIERA;a=summary[LUMIERA Git].
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

396
doc/devel/rfc/MistakestoAvoid.txt
View file

@ -1,18 +1,17 @@
Design Process : Mistakes to avoid Design Process : Mistakes to avoid
================================== ==================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2008-04-21_ |*Date* | _2008-04-21_
*Proposed by* link:rick_777[] |*Proposed by* | rick_777
------------------------------------- |====================================
Mistakes to avoid in the Lumiera design Mistakes to avoid in the Lumiera design
--------------------------------------- ---------------------------------------
As a multimedia user and experienced programmer, I've found various flaws As a multimedia user and experienced programmer, I've found various flaws
present in open source Non Linear Video editors. Here I will list the problems present in open source Non Linear Video editors. Here I will list the problems
and their proposed (or mandatory) solutions. Please forgive me if some of the and their proposed (or mandatory) solutions. Please forgive me if some of the
@ -22,10 +21,8 @@ wiki.
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
As a multimedia user and experienced programmer, I've found the following flaws As a multimedia user and experienced programmer, I've found the following flaws
present in open source Non Linear Video editors (your mileage may vary) : present in open source Non Linear Video editors (your mileage may vary):
. Frequent crashes (which most of the time make you lose your work) . Frequent crashes (which most of the time make you lose your work)
. Reinventing the wheel for every new project . Reinventing the wheel for every new project
@ -41,15 +38,14 @@ I will expand on the problems and their proposed (or mandatory) solutions.
1. Frequent crashes 1. Frequent crashes
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Frequent Crashes and unsaved work. |*Problem* | Frequent Crashes and unsaved work.
*Severity* CRITICAL. |*Severity* | CRITICAL.
*Solution* Isolating the UI from the rendering and data handling (also |*Solution* | Isolating the UI from the rendering and data handling (also improves the extensibility)
improves the extensibility) |*Required* | Yes
*Required* Yes |*Workarounds* | Auto-save (however it's not a real solution for the problem)
*Workarounds* Auto-save (however it's not a real solution for the problem) |====================================
--------------------------------------------------------------------
Working with multimedia (video / audio) editing is a magnet for segfaults Working with multimedia (video / audio) editing is a magnet for segfaults
(crashes) due to the handling of pointers and compression algorithms. A bug in (crashes) due to the handling of pointers and compression algorithms. A bug in
@ -59,7 +55,7 @@ doesn't go to the root of the problem.
My proposal is to move the low-level handling of video to a separate process, My proposal is to move the low-level handling of video to a separate process,
which then will do the processing - if it crashes, the UI will only report an which then will do the processing - if it crashes, the UI will only report an
error with a dialog (i.e. "the process crashed. Try again?"), but you work will error with a dialog (i.e. ``the process crashed. Try again?''), but you work will
stay safe. I'm not sure of the implementation difficulties that arise from stay safe. I'm not sure of the implementation difficulties that arise from
having a shared memory buffer for rendering / processing, but one thing is having a shared memory buffer for rendering / processing, but one thing is
certain: Whenever you move the cursor or rewind a part of a clip in your certain: Whenever you move the cursor or rewind a part of a clip in your
@ -73,34 +69,42 @@ Comments
I am not sure yet about separating things into processes, generally it is clear I am not sure yet about separating things into processes, generally it is clear
that this would be more robust but there are some performance impacts and that this would be more robust but there are some performance impacts and
programming problems (massisve amounts of data in shared memory). But most programming problems (massive amounts of data in shared memory). But most
importantly, when a subprocess gets a job and crashes on it, it won't complete importantly, when a subprocess gets a job and crashes on it, it won't complete
the job, we don't have a choice except gracefully abort it. From a user the job, we don't have a choice except gracefully abort it. From a user
perspective "It doesn't work!" there is no much difference to a complete crash. perspective ``It doesn't work!'' there is no much difference to a complete crash.
Well and yes we aim to make it crash proof rather, crashes a bugs and have to Well and yes we aim to make it crash proof rather, crashes a bugs and have to
be fixed, point. be fixed, period.
Lumiera will never ever loose work, we don't plan to make a project file, Lumiera will never ever loose work, we don't plan to make a project file,
autosafe way. Lumiera will keep projects in an internal database like format auto-save way. Lumiera will keep projects in an internal database like format
which consists of a Dumpfile and a contingous written logfile. After a which consists of a Dumpfile and a continuous written logfile. After a
crash/powerdown whatever, this log just gets replayed. The advantages are crash/power-down whatever, this log just gets replayed. The advantages are
countless, imagine persistent, selective undo and so on. Any other format countless, imagine persistent, selective undo and so on. Any other format
(cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins. (Cinelerra2 XML, MXF, ...) will be realized by importer/exporter plugins.
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]]
ct:: '2008-04-21T11:27:23Z'
Hereby I confirm that this comment still represents the stance of the
Lumiera project regarding this crucial issue. We _should not tolerate_
crashes, rather report them and contribute to improvements or alternatives.
And all user actions in Lumiera are captured as an _Event Log,_ which can
be replayed any time (and in altered form) to recreate any state of the edit.
ichthyo:: '2025-09-15'
2. Reinventing the wheel for every new project 2. Reinventing the wheel for every new project
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Various projects compete and reinvent the wheel |*Problem* | Various projects compete and reinvent the wheel
*Severity* Serious (Slows down development time. A lot) |*Severity* | Serious (Slows down development time. A lot)
*Solution* Multi-tier design, turn the data handling into a backend and use |*Solution* | Multi-tier design, turn the data handling into a backend and use whatever UI you prefer
whatever UI you prefer |*Required* | Yes. Better now that the project hasn't started
*Required* Yes. Better now that the project hasn't started |====================================
---------------------------------------------------------------------
Imagine the Linux kernel was tied to the window manager. You would have to Imagine the Linux kernel was tied to the window manager. You would have to
stick with KDE or GNOME and you couldn't improve it! Fortunately it's not like stick with KDE or GNOME and you couldn't improve it! Fortunately it's not like
@ -112,7 +116,7 @@ the project and change the UI to one that supports skinning, without having to
do the complicated video-processing stuff. do the complicated video-processing stuff.
Separating the processes has an equivalent for web programming, it's called Separating the processes has an equivalent for web programming, it's called
"separation of concerns", or multi-tier design. When you suddenly change the »Separation of Concerns«, or multi-tier design. When you suddenly change the
database engine, you don't need to change the whole program, just the database database engine, you don't need to change the whole program, just the database
module. Same goes for changing the UI from HTML to XML or Flash. If they're module. Same goes for changing the UI from HTML to XML or Flash. If they're
separate modules that only communicate through a clearly defined API. separate modules that only communicate through a clearly defined API.
@ -129,7 +133,7 @@ an engine to do the thinking.
So I suggest to split the project into four separate tiers (not necessarily So I suggest to split the project into four separate tiers (not necessarily
processes): processes):
. User interface - communicates with the "project" tier, handles the user . User interface - communicates with the ``project tier'', handles the user
events and does the calls. events and does the calls.
. The project tier - the main part of the video editor. This one invokes the . The project tier - the main part of the video editor. This one invokes the
renderer and decides which effects to apply, saving them as mere parameters renderer and decides which effects to apply, saving them as mere parameters
@ -142,7 +146,7 @@ processes):
the background while we keep working on the project (after all the project is the background while we keep working on the project (after all the project is
just a set of data stating which effects to apply to which tracks, and which just a set of data stating which effects to apply to which tracks, and which
files are used for the tracks) - instead of just having a window saying files are used for the tracks) - instead of just having a window saying
"Rendering, please wait". Even Adobe Premiere Pro suffered from this problem. ``Rendering, please wait''. Even Adobe Premiere Pro suffered from this problem.
This means that if we put enough effort, we can surpass commercial software This means that if we put enough effort, we can surpass commercial software
in certain areas. Note that the rendering engine uses the same API than the in certain areas. Note that the rendering engine uses the same API than the
project tier, as it works on a copy of the project when doing the final project tier, as it works on a copy of the project when doing the final
@ -161,35 +165,47 @@ Comments
^^^^^^^^ ^^^^^^^^
Please look at our design drafts, things will be separated (little different Please look at our design drafts, things will be separated (little different
than you describe here). We reuse things which are benefitful (gavl, ffmpeg, than you describe here). We reuse things which are beneficial (gavl, ffmpeg,
..) but we are also aware that we reinvent the wheel for some things by ..) but we are also aware that we reinvent the wheel for some things by
intention. Lumieras goal is not just to glue some existing libraries together intention. Lumiera's goal is not just to glue some existing libraries together
under a new gui, there are already a lot projects trying this way. We rather under a new Gui, there are already a lot projects trying this way. We rather
aim for a ''Professional'' high performance Video editing solution which does aim for a ''Professional'' high performance Video editing solution which does
some things in a different (maybe more complex) way. We do not use existing some things in a different (maybe more complex) way. We do not use existing
frameworks like MLT or gstreamer because we believe that these do not fit our frameworks like MLT or GStreamer because we believe that these do not fit our
goals (gstreamer will be supported through plugins). We do not produce yet goals (GStreamer will be supported through plugins). We do not intend to produce
another multimedia framework library (this only happen by coincidence) to be yet another multimedia framework library to be used by others.
used by others.
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] ct:: '2008-04-21T11:27:23Z'
This entry captures in a succinct way the reason *why we build Lumiera*.
However, this also touches on a deeper theme: +
Whenever we solve a _substantial problem_, we are tied and bound to our solution,
and we have to stick to it. Thus, by solving such a problem _for real_,
we loose the ability to do ``anything we want, anytime''.
Since we are human, we have to pick one path and forgo all the
other, possible ones. _Doing so is not a ``mistake''._
Now one might try to escape from this dilemma, by defining _flexibility_
or _sovereignty_ as the actual problem. It seems even feasible to address
this by turning it into a schematism -- and then you are bound to that one.
ichthyo:: '2025-09-15'
3. Lack of a user-friendly and extensible UI. 3. Lack of a user-friendly and extensible UI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Often, editors provide a very poor and buggy interface. |*Problem* | Often, editors provide a very poor and buggy interface.
Examples: Jahshaka doesn't even provide tooltips for the various tools, and |*Severity* | From Annoying to Serious.
the documentation is poor; In Cinelerra I've noticed some bugs when using the |*Solution-1* | Use a library that allows you to use different widget libraries, like wxWidgets.
open dialog, I'd rather have the KDE one, thanks. |*Required* | Recommended, but not obligatory.
*Severity* From Annoying to Serious. |*Solution-2* | Write different user interfaces, but they'd be hard to maintain.
*Solution 1* Use a library that allows you to use different widget |*Required* | No.
libraries, like wxWidgets. |====================================
*Required* Recommended, but not obligatory.
*Solution 2* Write different user interfaces, but they'd be hard to maintain.
*Required*, No.
---------------------------------------------------------------------
This problem is complicated, we need a good framework for handling the tracks. This problem is complicated, we need a good framework for handling the tracks.
Perhaps this could become a separate project. Ideas are welcome. Perhaps this could become a separate project. Ideas are welcome.
@ -198,31 +214,49 @@ Perhaps this could become a separate project. Ideas are welcome.
Comments Comments
^^^^^^^^ ^^^^^^^^
Joel started working on a GUI recently and making good progress. The UI should Joel started working on a GUI recently and makes good progress. The UI should
finally be quite flexible as it mostly provides a skeletion where plugins finally be quite flexible as it mostly provides a skeleton where plugins
render to. We have quite a lot ideas about the UI and user input is welcome. render to. We have quite a lot ideas about the UI and user input is welcome.
The UI is currently the most separate tier in the design, i'd like to make it a The UI is currently the most separate tier in the design, i'd like to make it a
plugin itself which is loaded when lumiera is started in a gui mode, but it is plugin itself which is loaded when Lumiera is started in a Gui mode, but it is
to early to say how exactlly it will be integrated, except that we all agree to early to say how exactly it will be integrated, except that we all agree
that GUI is optional and Lumiera can also run headless, script driven. that GUI is optional and Lumiera can also run headless, script driven.
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]]
ct:: '2008-04-21T11:27:23Z'
It is many years later now; we indeed do load our GUI as a plug-in,
yet have not gained much by this move. The reason is, what we actually need
for editing video is hard to implement in _any_ toolkit. Once you start solving
_that_ problem, you are bound in very intricate ways to the specific toolkit
you just happened to choose (in our case, this is GTK).
In a nutshell, being ``user-friendly and extensible'' is not something to
be solved at an _abstract, generic level_ -- we'll have to face the fact
that _a beginner_ will have quite different demands than a experienced
professional. And Lumiera is a tool for professionals. Being beginner
friendly is certainly desirable, yet it remains a secondary goal, and
we have not even made so much inroads regarding the primary goal.
ichthyo:: '2025-09-15'
4. Lack of support for certain video formats or codecs 4. Lack of support for certain video formats or codecs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Lack of support for certain video formats or codecs. |*Problem* | Lack of support for certain video formats or codecs.
*Severity* Critical. |*Severity* | Critical.
*Workarounds* 1. Give a help page for the user to do his own conversion, but |*Workarounds* | 1. Give a help page for the user to do his own conversion, but
this is very inelegant, annoying, and a waste of time. 2. Provide conversion this is very inelegant, annoying, and a waste of time.
on the fly, and keep a separate "preprocessed" copy of the imported clip in a 2. Provide conversion on the fly, and keep a separate
separate directory. This is a nice middle ground, IMHO. _preprocessed copy_ of the imported clip in a
*Solution* Use a wrapper library as stated in problem # 2, having a separate directory. This is a nice middle ground, IMHO.
plugin-based design is recommended. |*Solution* | Use a wrapper library as stated in problem # 2, having a
*Required* Yes. plugin-based design is recommended.
--------------------------------------------------------------------- |*Required* | Yes.
|====================================
Some editors like Cinelerra are hardwired into using one format, or have a Some editors like Cinelerra are hardwired into using one format, or have a
phobia to certain formats / codecs (i.e. DivX AVI's). If we separate the phobia to certain formats / codecs (i.e. DivX AVI's). If we separate the
@ -236,25 +270,33 @@ compatibility for future formats.
Comments Comments
^^^^^^^^ ^^^^^^^^
Lumiera is a video editor we don't care (*cough*, not really true) about video Lumiera is a video editor we don't care (\*cough*, not really true) about video
formats. Everything which comes In and goes Out is defined in plugins which formats. Everything which comes In and goes Out is defined in plugins which
handle video formats. We currently decided to use 'gavl' because it is a nice handle video formats.
small library which does exactly what we want. Later on gstreamer and other
such kinds of decoder/encoder/processing-pipe libs will be realized. ct:: '2008-04-21T11:27:23Z'
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]]
So this point is not hard to solve (use plugins), yet this obvious
solution creates a lot of much more tricky problems. In Lumiera,
we attempt to actually solve those secondary problems, instead of
just stating ``this can be solved by plug-ins'' (as most other
existing software does). Unfortunately, this makes the project
very complex. The chosen path seems feasible, yet honestly,
I do not know if we'll ever make it.
ichthyo:: '2025-09-15'
5. Lack of documentation 5. Lack of documentation
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Some video editors have very poor documentation (and that's an |*Problem* | Some video editors have very poor documentation (and that's an understatement)
understatement *cough* Jahshaka *cough* ) |*Severity* | Critical.
*Severity* Critical. |*Solution* | Have a team for the documentation.
*Solution* Have a team for the documentation. |*Required* | Yes.
*Required* Yes. |====================================
---------------------------------------------------------------------
Nuff said. Nuff said.
@ -262,7 +304,7 @@ Nuff said.
Comments Comments
^^^^^^^^ ^^^^^^^^
Quote from https://openhub.net/p/lumiera/[Openhub.net]: Quote from https://openhub.net/p/lumiera/[Openhub.net (formerly »Ohloh«)]:
------------------------------------------------------------ ------------------------------------------------------------
Extremely well-commented source code Extremely well-commented source code
@ -274,25 +316,37 @@ projects on Ohloh.
------------------------------------------------------------ ------------------------------------------------------------
Nuff saied... Oh well, about user docs we like to get that impressive ratings ``Nuff said''... +
there too, any helpers? Oh well, about user docs we like to get that impressive ratings there too, any helpers?
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]]
ct:: '2008-04-21T11:27:23Z'
Here I'd like to add that writing is hard -- any writing, not only writing code --
and writing text that other people can understand and which is accurate at
the same time is even harder. It requires a lot of resources, and typically
developers are not good at writing in a way that is understandable by
``average joe'', while people good at writing nice text seem to have quite
some problems with understanding the thinking style pertinent to
software engineering. So, let's say: ``we keep trying''
ichthyo:: '2025-09-15'
6. Lack of cross-platform support 6. Lack of cross-platform support
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Where's my Windows version? |*Problem* | Where's my Windows version?
*Severity* Blocker |*Severity* | Blocker
*Solution* Use a cross-platform toolkit for the UI. |*Solution* | Use a cross-platform toolkit for the UI.
*Required* Depends, do you plan to make it Cross-Platform? |*Required* | Depends, do you plan to make it Cross-Platform?
-------------------------------------------------------------------- |====================================
A good example for this is the Code::Blocks IDE, which was thought of being A good example for this is the Code::Blocks IDE, which was thought of being
cross-platform from the beginning. Curiously, at first the project was cross-platform from the beginning. Curiously, at first the project was
Windows-only, and its only F/OSS alternative was Dev-C++ from Bloodshed (eew). Windows-only, and its only F/OSS alternative was Dev-C\++ from Bloodshed (eew).
Otherwise you'd have to stick with proprietary applications like Visual C++. Otherwise you'd have to stick with proprietary applications like Visual C++.
In Linux there were various IDE's, but they were Linux-only. Since Code::Blocks In Linux there were various IDE's, but they were Linux-only. Since Code::Blocks
@ -310,27 +364,44 @@ Comments
^^^^^^^^ ^^^^^^^^
We refuse to make it cross platform intentionally. Most things are written We refuse to make it cross platform intentionally. Most things are written
portable, POSIX compatible, some might need platform specific fixes. But our in a portable style, and POSIX compatible; some might need platform specific fixes.
target is primary Linux (because thats what we use) secondary any other Free OS But our target is primary Linux (because that's what we use) secondary any other Free OS
(hopefully we find some testers/maintainers for that). Lumiera ''might'' run on (hopefully we find some testers/maintainers for that). Lumiera _might_ run on
OSX and patches will be accepted, but it is not a free platform so we don't OSX and patches will be accepted, but it is not a free platform so we don't
care by ourself. Windows due its diffrent system interfaces will be hard to care by ourselves. Windows due its different system interfaces will be hard to
port, if someone wants to do that, have fun, we will accept patches to, but we port, if someone wants to do that, have fun, we will accept patches to, but we
do not support it in *any* way by ourself. do not support it in *any* way by ourselves.
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]]
ct:: '2008-04-21T11:27:23Z'
For a typical ``business'' application, this is largely a problem of the UI;
we tend to solve that problem by using web technology nowadays, of relying
on similar _frameowork solutions_. Doing so however incurs significant cost;
the following point -- scripting languages -- is one of the symptoms.
However, video processing is still a technology pushing the limits.
We can address this either by aiming at an industrial setup, where the
actual processing is done in a server farm. Or you can limit yourself
to what can be achieved on a personal computer -- which requires to
keep priorities straight and deliberately abandon unnecessary
secondary goals and ``nice to haves''
The Lumiera project follows the second path. +
What is _essential_ thus becomes a question of philosophy, or politics.
ichthyo:: '2025-09-15'
7. Dependency on scripted languages like Python, which make installation a mess 7. Dependency on scripted languages like Python, which make installation a mess
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"] [options="autowidth"]
`------------`------------------------------------------------------ |====================================
*Problem* Installation can be a mess if we depend on scripted languages. |*Problem* | Installation can be a mess if we depend on scripted languages.
*Severity* Annoying, the end user might just conform with another project |*Severity* | Annoying, the end user might just conform with another project that ``just works''.
that "just works". |*Solution* | Make it in C++ or other easily-compilable language.
*Solution* Make it in C++ or other easily-compilable language. |*Required* | VERY recommended.
*Required* VERY recommended. |====================================
---------------------------------------------------------------------
I've had to install several packages for my distro (whose repository is not as I've had to install several packages for my distro (whose repository is not as
large as others like Ubuntu's) from source. Some of them depend on very large as others like Ubuntu's) from source. Some of them depend on very
@ -342,62 +413,79 @@ work on a common language, like C++.
Comments Comments
^^^^^^^^ ^^^^^^^^
At some point a scripting language ''will'' be required, yet to drive the At some point a scripting language _will_ be required, be it to drive the
testsuite, make headless rendering work and so on. We need to provide testsuite, make headless rendering work and so on. This
installation instructions and/or even bundle this language with Lumiera. This will likely become a small embedded language like Lua...
will likely become a small embedded language like Lua or some kind of forth (or details need to be worked out.
maybe some scheme?) it should not depend on strange modules which are not part
of the core scripting language distribution (or we shall provide them too), ct:: '2008-04-21T11:27:23Z'
needs to be worked out.
-- link:ct[] [[DateTime(2008-04-21T11:27:23Z)]] This decision was revised and changed. Lumiera is written in C++ and
will certainly require some special media processing plug-ins, but
it will _not require any scripting language_ for core tasks.
Yet a script runner and script driven use is on the main agenda,
since that is an essential feature for large scale media editing projects,
where at least some kind of quality render happens on a cloud platform.
Our goal is to stick to widely used and commonly packaged software and
libraries whenever possible.
ichthyo:: '2025-09-15'
Author's comments
^^^^^^^^^^^^^^^^^
Some of the measures stated in this document are optional, but separating the
processes for the rendering engine, editor and User Interface are the optimal
solution and required to avoid common problems.
Discussion Discussion
---------- ----------
Some of the measures stated in this document are optional, but separating the
processes for the rendering engine, editor and User Interface are the optimal
solution and required to avoid common problems.
rick_777:: '2008-04'
Mostly we agree with the general statements in this Design Entry. But there are Mostly we agree with the general statements in this Design Entry. But there are
some points which don't stand the test of a detailed technical discussion. For some points which don't stand the test of a detailed technical discussion. For
example, you simply can't state it's a 'mistake' not to write code which example, you simply can't state it's a ``mistake'' not to write code which
similarly runs on windows and *nix. Well. You could try to write it in Java. similarly runs on windows and *nix. Well. You could try to write it in Java.
See my point? While today it's quite feasible to write office stuff or banking See my point? While today it's quite feasible to write office stuff or banking
applications in a cross-platform manner, a video editor still is a different applications in a cross-platform manner, a video editor still is a different
kind of a beast. kind of a beast.
A similar argumentation holds true for the question, wether or not to use A similar argumentation applies to the question, whether or not to use
separate processes and IPC. While it certainly is a good idea to have the X separate processes and IPC. While it certainly is a good idea to have the X
server or a database running in a separate process, the situation is really server or a database running in a separate process, the situation is really
quite different for editing video. Hopefully it's clear why. quite different for editing video. Doing that with collaborating processes
and shared memory is anything than trivial, and brings its own set of
Could you please rework this Design Entry in a way that we can finalize difficulties and limitations. So I would not rule it out, yet it
(accept) it? is clearly not the ``only true solution''
Could you please rework this Design Entry in a way that we can finalise
(accept) it? +
--
* Please remove the section about windows * Please remove the section about windows
* Please separate out things needing technical discussion and are not just * Please separate out things needing technical discussion and are not just
"mistakes", thus retaining only the big picture statements (on which we all ``mistakes'', thus retaining only the big picture statements (to which
agree) the core developers of Lumiera largely agree). Notably...
* How to secure the application against crashes
* If it is viable/desirable to run the gui in a separate process really needs ** Securing the application against crashes is a non-trivial task
in-depth technical discussion (create a new Design Entry for this) ** If it is viable/desirable to run the Gui in a separate process really
* How to deal with the dependencies problem in combination with needs in-depth technical discussion (create a new Design Entry for this)
plugins/extensions and script languages ** How to deal with the dependencies problem in combination with
-- link:Ichthyostega[] [[DateTime(2008-10-05T01:51:50Z)]] plugins/extensions and script languages
--
Ichthyostega:: '2008-10-05T01:51:50Z'
Conclusion Conclusion
---------- ----------
The October.2008 dev meeting decided to 'drop' this design proposal as is. The
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_mistakes_to_avoid[October.2008 dev meeting]
decided to __`drop'__ this design proposal as is.
Basically, this text just tells us "to make Lumiera good", and especially it In a nutshell, leaving out all the technicalities, this text just tells us
contains a mixture of topics ``to make Lumiera good''. Beyond that, it contains a mixture of topics:
* We fully agree to 80% of the statements made there, but we think those * We fully agree to 80% of the statements made there, but we think those
statements are so very basic and self-evident as to be considered off-topic statements are so very basic and self-evident as to be considered off-topic
@ -407,21 +495,21 @@ contains a mixture of topics
which we don't agree. And it fails to provide sufficient (technically sound) which we don't agree. And it fails to provide sufficient (technically sound)
arguments to prove these statements. arguments to prove these statements.
While it is certainly 'desirable' to be cross-platform as much as possible and While it is certainly _desirable_ to be cross-platform as much as possible and
especially '''target Microsoft Windows''', we don't see much possibilities with especially _target Microsoft Windows_, we don't see much possibilities with
today's mainstream technology to build an application which is as today's mainstream technology to build an application which is as
technologically demanding as a video editor is. We would end up developing two technologically demanding as a video editor is. We would end up developing two
or even three sister applications, or we are forced to sacrifice performance or even three sister applications, or we are forced to sacrifice performance
for portability. When put up to face such options, we have a clear preference for portability. When put up to face such options, we have a clear preference
to concentrate on a really free and open platform. to concentrate on a really free and open platform.
While it is certainly 'desirable' to make the application as robust as While it is certainly _desirable_ to make the application as _robust_ as
possible, we don't see how '''using multiple separate processes''' could help possible, we don't see how ``using multiple separate processes'' could help
us with this goal ''without creating major scalability or performance us with this goal _without creating major scalability or performance
problems'' due to the use of shared memory. And, yet more important: we don't problems_, due to the use of shared memory. And, yet more important: we don't
share the basic assumption made in the proposal, namely that video processing share the basic assumption made in the proposal, namely that video processing
is inherently dangerous. We think the basic algorithms involved are is inherently dangerous. We think the basic algorithms involved are
sufficiently well-known and understandable to implement them in a sound manner. sufficiently well-known and understandable to implement them in a sound manner.
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

50
doc/devel/rfc/MonthlyDeveloperMeetingOnIRC.txt
View file

@ -1,12 +1,12 @@
Design Process : IRC Developer Meeting Design Process : IRC Developer Meeting
====================================== ======================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-15_ |*Date* | _2007-06-15_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
IRC Developer Meeting IRC Developer Meeting
@ -26,26 +26,19 @@ Things like:
* Who needs help for something * Who needs help for something
* Make Decisions about pending proposals * Make Decisions about pending proposals
We should make small 'to be talked about' list beforehand (on the wiki) and We should make small ``to be talked about'' list beforehand (on the wiki) and
write an also small protocol afterwards about the decisions made. write an also small protocol afterwards about the decisions made.
I'd suggest to do this first Friday of each month at 21:00GMT, thats late I'd suggest to do this first Friday of each month at 21:00GMT, that's late
evening in Europe and afternoon in USA. Details need to be acknowledged. evening in Europe and afternoon in USA. Details need to be acknowledged.
Tasks
~~~~~
Pros
~~~~
Cons Cons
~~~~ ~~~~
* Inflexible - People's lives and schedules can easily change within a few * Inflexible -- People's lives and schedules can easily change within a few
months thus making them unavailable for further meetings months thus making them unavailable for further meetings
@ -57,41 +50,44 @@ Alternatives
resolve scheduling conflicts. resolve scheduling conflicts.
Rationale
~~~~~~~~~
Comments Comments
-------- --------
* A short meeting every week is a must. "meeting" means a fair amount of the * A short meeting every week is a must; ``meeting'' means a fair amount of the
developers involved show up and there is a possibility to point at current developers involved show up and there is a possibility to point at current
problems. We could make a Full Meeting in the way proposed by problems. We could make a Full Meeting in the way proposed by
link:MichaelPloujnikov[] additionally. But even one week can be dangerousely MichaelPloujnikov additionally. But even one week can be dangerousely
long in software developement, esp. when the dev process is so open and long in software developement, esp. when the dev process is so open and
distributed. distributed.
* Personally, I am OK with Friday 21GMT * Personally, I am OK with Friday 21GMT
-- link:Ichthyostega[] [[DateTime(2007-06-17T00:29:54Z)]]
Ichthyostega:: '2007-06-17T00:29:54Z'
* Friday 21GMT is only good for me starting in two weeks until September. After * Friday 21GMT is only good for me starting in two weeks until September. After
that it's booked for the Winter. Thursday 21GMT would be better. that it's booked for the Winter. Thursday 21GMT would be better.
-- link:MichaelPloujnikov[] [[DateTime(2007-06-17T03:09:36Z)]]
MichaelPloujnikov:: '2007-06-17T03:09:36Z'
* Also Ok for me * Also Ok for me
-- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]]
ct:: '2007-06-17T17:20:37Z'
* I think this (monthly) meeting should not be too frequent and address more * I think this (monthly) meeting should not be too frequent and address more
global project directions, having a more frequent meeting rather makes it global project directions, having a more frequent meeting rather makes it
more unattractive and time consuming for slightly involved people. This does more unattractive and time consuming for slightly involved people. This does
not means that we cant meet more often, but this should be acknowledged not mean that we can't meet more often, but this should be acknowledged
between people who work together on some features/subsystems. That would also between people who work together on some features/subsystems. That would also
have the benefit that such small groups are very flexible to meet, even daily have the benefit that such small groups are very flexible to meet, even daily
on hot phases and able to acknowledge times when all members can attend. And on hot phases and able to acknowledge times when all members can attend. And
later if timing is not that good only one person of such a subproject/group later if timing is not that good only one person of such a subproject/group
may attend to the monthly meeting and report/collect information there. Its may attend to the monthly meeting and report/collect information there. Its
likely hard enough to get many developers to meet at one time in month (when likely hard enough to get many developers to meet at one time in month (when
we have more devs than now :P) we have more devs than now 😜)
-- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2007-06-17T17:20:37Z'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

25
doc/devel/rfc/NoBugFlags.txt
View file

@ -1,16 +1,16 @@
NoBug logging flag hierachy NoBug logging flag hierachy
=========================== ===========================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-04-05_ |*Date* | _2008-04-05_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
link:NoBug[] logging flag hierachy NoBug logging flag hierachy
---------------------------------- ---------------------------
https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags. https://nobug.pipapo.org/[NoBug] allows hierachical organization of logging flags.
Propose a documentation/planning about the setup. Propose a documentation/planning about the setup.
@ -28,9 +28,8 @@ NOTE: outdated information. Have a look at `include/logging.h`
Tasks Tasks
~~~~~ ~~~~~
* Needs a file.c defining the common root see * Needs a file.c defining the common root see
link:{ldoc}/devel/rfc/GlobalInitialization.html[RfC: Global Initialization] link:{rfc}/GlobalInitialization.html[RfC: Global Initialization]
* Everyone needs to setup this hierachy by NOBUG_DEFINE_FLAG_PARENT (flag, * Everyone needs to setup this hierachy by `NOBUG_DEFINE_FLAG_PARENT (flag, parent_flag);`
parent_flag);
Pros Pros
@ -62,4 +61,6 @@ Ichthyostega:: 'Di 29 Okt 2013 05:52:34 CET' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

51
doc/devel/rfc/NormalizedDeviceCoordinates.txt
View file

@ -1,16 +1,16 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2009-01-14_ |*Date* | _2009-01-14_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Normalized Device Coordinates Normalized Device Coordinates
----------------------------- -----------------------------
AkhIL pointed me out to some blender problem and how renderman fixes that. We _AkhIL_ pointed out to me some blender problem and how ``renderman'' fixes that.
should use this too. We should use this too.
@ -54,33 +54,14 @@ Just snippet from IRC log:
Tasks
^^^^^
Discussion
~~~~~~~~~~
Pros
^^^^
Cons
^^^^
Alternatives
^^^^^^^^^^^^
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
TBD ^[red]#to be written#^
@ -91,22 +72,22 @@ Comments
One issue where I always assumed we'd need to define something of this sort is One issue where I always assumed we'd need to define something of this sort is
for proxy editing. Especially this is a problem in conjunction with masks. for proxy editing. Especially this is a problem in conjunction with masks.
Basically, this means a bit more of "vector graphics". With film/video editing, Basically, this means a bit more of ``vector graphics''. With film/video editing,
this was rather unusual, but with the advent of more and new digital video/film this was rather unusual, but with the advent of more and new digital video/film
formats it gets more and more important. Also, our considerations regarding formats it gets more and more important. Also, our considerations regarding
time handling and quantisation to single frames somewhat fit into this line of time handling and quantisation to single frames somewhat fit into this line of
thought. Up to now, rather the standard way of thinkin was to use a "project thought. Up to now, rather the standard way of thinking was to use a ``project
framerate" and a fixed resolution in pixels. But we certainly can do better. framerate'' and a fixed resolution in pixels. But we certainly can do better.
-- Ichthyostega 18:09:50 Ichthyostega:: '2009-01-14 18:09:50'
Parked Parked
~~~~~~ ~~~~~~
deferred for later, generally accepted. deferred for later, generally accepted.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

124
doc/devel/rfc/OfficialAssemblyLanguage.txt
View file

@ -1,12 +1,12 @@
Design Process : Official Assembly Language Design Process : Official Assembly Language
=========================================== ===========================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2008-08-01_ |*Date* | _2008-08-01_
*Proposed by* link:PercivalTiglao[] |*Proposed by* | PercivalTiglao
------------------------------------- |====================================
Official Assembly Language Official Assembly Language
@ -16,7 +16,7 @@ I describe here an optimization that might have to be be taken into account at
the design level. At very least, we should design our code with the design level. At very least, we should design our code with
auto-vectorization in mind. At the most, we can choose to manually write parts auto-vectorization in mind. At the most, we can choose to manually write parts
of our code in assembly language and manually vectorize it using x86 SSE of our code in assembly language and manually vectorize it using x86 SSE
Instructions or !PowerPC !AltiVec instructions. By keeping these instructions Instructions or PowerPC AltiVec instructions. By keeping these instructions
in mind, we can easily achieve a large increase in speed. in mind, we can easily achieve a large increase in speed.
@ -44,14 +44,14 @@ assembly-level libraries somewhere in our code.
Tasks Tasks
~~~~~ ^^^^^
* Choose an ``Official'' assembly language / platform.
* Choose an "Official" assembly language / platform.
* Review the SIMD instructions avaliable for that assembly language. * Review the SIMD instructions avaliable for that assembly language.
* For example, the Pentium 2 supports MMX instructions. Pentium 3 supports MMX ** For example, the Pentium 2 supports MMX instructions.
and SSE Instructions. Early Pentium4s support MMX, SSE, and SSE2 ** Pentium 3 supports MMX and SSE Instructions.
instructions. Core Duo supports upto SSE4 instructions. AMD announced SSE5 ** Early Pentium4s support MMX, SSE, and SSE2 instructions.
instructions to come in 2009. ** Core Duo supports upto SSE4 instructions.
** AMD announced SSE5 instructions to come in 2009.
* Consider SIMD instructions while designing the Render Nodes and Effects * Consider SIMD instructions while designing the Render Nodes and Effects
architecture. architecture.
* Write the whole application in C/C++ / Lua while leaving sections to optimize * Write the whole application in C/C++ / Lua while leaving sections to optimize
@ -60,8 +60,7 @@ Tasks
Pros Pros
~~~~ ^^^^
Assuming we go all the way with an official assembly language / platform... Assuming we go all the way with an official assembly language / platform...
* Significantly faster render and previews. (Even when using a high-level * Significantly faster render and previews. (Even when using a high-level
@ -71,10 +70,8 @@ Assuming we go all the way with an official assembly language / platform...
Cons Cons
~~~~ ^^^^
* Earlier architectures of that family will be significantly slower or unsupported
* Earlier architectures of that family will be significantly slower or
unsupported
* Other architectures will rely on C / C++ port instead of optimized assembly * Other architectures will rely on C / C++ port instead of optimized assembly
* Redundant Code * Redundant Code
@ -112,50 +109,57 @@ optimization avaliable in the future, then we should be good.
Comments Comments
-------- --------
* I have to admit that I don't know too much about SSE instructions aside from I have to admit that I don't know too much about SSE instructions aside from
the fact that they can operate on 128-bits at once in parallel and there are the fact that they can operate on 128-bits at once in parallel and there are
some cache tricks involved when using them. (you can move data in from memory some cache tricks involved when using them. (you can move data in from memory
without bringing in the whole cache line). Nonetheless, keeping these without bringing in the whole cache line). Nonetheless, keeping these
assembly level instructions in mind will ease optimization of this Video assembly level instructions in mind will ease optimization of this Video
Editor. Some of the instructions are high-level enough that they may effect Editor. Some of the instructions are high-level enough that they may effect
design decisions. Considering them now while we are still in early stages of design decisions. Considering them now while we are still in early stages of
development might prove to be advantagous. Optimize early? Definitely not. development might prove to be advantageous. Optimize early? Definitely not.
However, if we don't consider this means of optimization, we may design However, if we don't consider this means of optimization, we may design
ourselves into a situation where this kind of optimization becomes ourselves into a situation where this kind of optimization becomes
impossible. impossible.
* I don't think we should change any major design decisions to allow for I don't think we should change any major design decisions to allow for
vectorization. At most, we design a utility library that can be easily vectorization. At most, we design a utility library that can be easily
optimized using SIMD instructions. Render Nodes and Effects can use this optimized using SIMD instructions. Render Nodes and Effects can use this
library. When this library is optimized, then all Render Nodes and Effects library. When this library is optimized, then all Render Nodes and Effects
can be optimized as well. -- link:PercivalTiglao[] can be optimized as well.
[[DateTime(2008-08-01T16:12:11Z)]]
* Uhm, the Lumiera core (backend, proc, gui) doesn't do any numbercrunching. PercivalTiglao:: '2008-08-01T16:12:11Z'
This is all delegated to plugins (libgavl, effects, encoders). I think we
don't need any highly assembler/vector optimized code in the core (well, lets
see). This plugins and libraries are somewhat out of our scope and thats good
so, the people working on it know better than we how to optimize this stuff.
It might be even worthwile to try if when we leave all vectorization out, if
then the plugins can use the vector registers better and we gain overall
performance!
-- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]]
* Another idea about a probably worthwhile optimization: gcc can instumentate The Lumiera core (backend, proc, gui) doesn't do any number crunching.
code for profileing and then do arc profileing and build it a second time Any actual media processing will be delegated to plugins (lib-Gavl, effects, encoders).
with feedback what it learnd from the profile runs, this mostly affects I think we don't need any highly assembler/vector optimized code in the core (well, lets see).
branch prediction and can give a reasonable performance boost. If somone This plugins and libraries are somewhat out of our scope and that's good so, the people working
likes challenges, prepare the build system to do this: on it know better than we how to optimize this stuff.
. build it with -fprofile-arcs
. profile it by running ''carefully'' selected benchmarks and tests. It might be even worthwhile to try if when we leave all vectorization out,
. rebuild it again this time with -fbranch-probabilities if then the plugins can use the vector registers better and we gain overall
performance!
ct:: '2008-08-03T02:27:14Z'
Another idea about a probably worthwhile optimization: GCC can instrument
code for profiling and then do arc profiling and build it a second time
with feedback what it learned from the profile runs, this mostly affects
branch prediction and can give a reasonable performance boost. If someone
likes challenges, prepare the build system to do this: +
--
. build it with `-fprofile-arcs`
. profile it by running _carefully selected_ benchmarks and tests.
. rebuild it again this time with `-fbranch-probabilities`
. PROFIT . PROFIT
-- link:ct[] [[DateTime(2008-08-03T02:27:14Z)]] --
* I've discussed general ideas around, and I agree now that "core Lumiera" is ct:: '2008-08-03T02:27:14Z'
not the place to think of these kinds of optimizations. So I'll just move
this over to dropped. -- link:PercivalTiglao[] I've discussed general ideas around, and I agree now that ``core Lumiera''
[[DateTime(2008-08-04T18:33:58Z)]] is not the place to think of these kinds of optimizations.
So I'll just move this RfC to dropped.
PercivalTiglao:: '2008-08-04T18:33:58Z'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

28
doc/devel/rfc/ProcBuilder.txt
View file

@ -1,12 +1,12 @@
Design Process: Builder within the Steam-Layer Design Process: Builder
============================================== =======================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-03-06_ |*Date* | _2008-03-06_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Builder within the Steam-Layer Builder within the Steam-Layer
------------------------------ ------------------------------
@ -42,7 +42,7 @@ configuration down into the low-level model using generic rules.
Pros Pros
^^^^ ^^^^
* Separation, decoupling * Separation, decoupling
* Architectural approach instead of just hacking away... * Architectural aproach instead of just hacking away...
Cons Cons
^^^^ ^^^^
@ -55,14 +55,14 @@ This design was chosen as a direct consequence of the problems encountered in
the Cinelerra-2 codebase. the Cinelerra-2 codebase.
* Separating this way allows us to take on different viewpoints on what is * Separating this way allows us to take on different viewpoints on what is
"good" and "efficient". ``good'' and ``efficient''.
* In the low-level view simplicity and efficiency of computation is the main * In the low-level view simplicity and efficiency of computation is the main
criterion. criterion.
* Whereas in the high-level view a good modeling of the problem domain and * Whereas in the high-level view a good modeling of the problem domain and
maximum flexibility is preferable. maximum flexibility is preferable.
* The high-level view is taken out of the critical code path, allowing for * The high-level view is taken out of the critical code path, allowing for
advanced and even experimental technologies without endangering the whole advanced and even experimental technologies without endangering the whole
application's usability. In the low-level realm, 'speed' is measured in ms, application's usability. In the low-level realm, _speed_ is measured in ms,
whereas in the high-level domain, speed is rather measured in 100ms. whereas in the high-level domain, speed is rather measured in 100ms.
* The separation creates distinct interfaces and allows people with very * The separation creates distinct interfaces and allows people with very
different skill sets to work in parallel at the various levels of the App. different skill sets to work in parallel at the various levels of the App.
@ -72,6 +72,8 @@ Conclusion
---------- ----------
This proposal reflects a distinct approach taken right from start. This proposal reflects a distinct approach taken right from start.
Marked 'final' at October.2008 developer meeting Marked __`final'__ at the
link:{}/devel/meeting_summary/2008-10-10.html#_the_builder[October.2008 developer meeting]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

61
doc/devel/rfc/ProcHighLevelModel.txt
View file

@ -1,15 +1,15 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2008-08-16_ |*Date* | _2008-08-16_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
High-level model in the Steam-Layer High-level model in the Steam-Layer
----------------------------------- -----------------------------------
The purpose of this link:DesignProcess[] entry is to collect together The purpose of this DesignProcess entry is to collect together
informations regarding the design and structure of the high-level model of informations regarding the design and structure of the high-level model of
Lumiera's Steam-Layer. Most of the information presented here is already written Lumiera's Steam-Layer. Most of the information presented here is already written
down somewhere, in the down somewhere, in the
@ -21,7 +21,7 @@ tracks, which further helped to shape the model as presented here.
While the low-level model holds the data used for carrying out the actual media While the low-level model holds the data used for carrying out the actual media
data processing (=rendering), the high-level model is what the user works upon data processing (=rendering), the high-level model is what the user works upon
when performing edit operations through the GUI (or script driven in when performing edit operations through the GUI (or script driven in
"headless"). Its building blocks and combination rules determine largely what ``headless''). Its building blocks and combination rules determine largely what
structures can be created within the structures can be created within the
http://www.lumiera.org/wiki/renderengine.html#Session[Session]. On the whole, http://www.lumiera.org/wiki/renderengine.html#Session[Session]. On the whole,
it is a collection of it is a collection of
@ -68,8 +68,8 @@ possible to create cyclic connections by such arbitrary wiring, which will be
detected by the builder and flagged as an error. detected by the builder and flagged as an error.
While pipes have a rather rigid and limited structure, it is allowed to make While pipes have a rather rigid and limited structure, it is allowed to make
several connections to and from any pipe &mdash; even connections requiring an several connections to and from any pipe -- even connections requiring an
stream type conversion. It is not even necessary to specify ''any'' output stream type conversion. It is not even necessary to specify _any_ output
destination, because then the wiring will be figured out automatically by destination, because then the wiring will be figured out automatically by
searching the context and finally using some general rule. Connecting multiple searching the context and finally using some general rule. Connecting multiple
outputs to the input of another pipe automatically creates a *mixing step* outputs to the input of another pipe automatically creates a *mixing step*
@ -96,9 +96,9 @@ sort of a loose clustering of objects: it will derive the position from the
placement it is attached to. Note that while the length and the in/out points placement it is attached to. Note that while the length and the in/out points
are a _property of the MObject_ , it's actual location depends on how it is are a _property of the MObject_ , it's actual location depends on how it is
_placed_ and thus can be maintained quite dynamically. Note further that _placed_ and thus can be maintained quite dynamically. Note further that
effects can have an length on their own, thus by using these attachement effects can have an length on their own, thus by using these attachment
mechaics, the wiring and configuration within the high-level model can be quite mechanics, the wiring and configuration within the high-level model can be quite
time dependant. time defendant.
image:{imgd}/high-level2.png[] image:{imgd}/high-level2.png[]
@ -122,10 +122,10 @@ Example of an complete Session
image:{imgd}/high-level3.png[] image:{imgd}/high-level3.png[]
The Session contains several independent The Session contains several independent
http://www.lumiera.org/wiki/renderengine.html#EDL[EDL]s plus an output bus link:/wiki/renderengine.html#EDL[EDL]s plus an output bus
section ( *global Pipes* ). Each EDL holds a collection of MObjects placed section (**global Pipes**). Each EDL holds a collection of MObjects placed
within a *tree of tracks* . Within Lumiera, tracks are a rather passive means within a *tree of tracks* . Within Lumiera, tracks are a rather passive means
for organizing media objects, but aren't involved into the data processing for organising media objects, but aren't involved into the data processing
themselves. The possibility of nesting tracks allows for easy grouping. Like themselves. The possibility of nesting tracks allows for easy grouping. Like
the other objects, tracks are connected together by placements: A track holds the other objects, tracks are connected together by placements: A track holds
the list of placements of its child tracks. Each EDL holds a single placement the list of placements of its child tracks. Each EDL holds a single placement
@ -138,7 +138,7 @@ track is anchored to some external entity (label, sync point in sound, etc),
all objects placed relatively to this track will adjust and follow all objects placed relatively to this track will adjust and follow
automatically. This relation between the track tree and the individual objects automatically. This relation between the track tree and the individual objects
is especially important for the wiring, which, if not defined locally within an is especially important for the wiring, which, if not defined locally within an
MObject's placement, is derived by searching up this track tree and utilizing MObject's placement, is derived by searching up this track tree and utilising
the wiring plug locating pins found there, if applicable. In the default the wiring plug locating pins found there, if applicable. In the default
configuration, the placement of an EDL's root track contains a wiring plug for configuration, the placement of an EDL's root track contains a wiring plug for
video and another wiring plug for audio. This setup is sufficient for getting video and another wiring plug for audio. This setup is sufficient for getting
@ -151,7 +151,7 @@ Besides routing to a global pipe, wiring plugs can also connect to the source
port of an *meta-clip*. In this example session, the outputs of EDL-2 as port of an *meta-clip*. In this example session, the outputs of EDL-2 as
defined by locating pins in it's root track's placement, are directed to the defined by locating pins in it's root track's placement, are directed to the
source ports of a source ports of a
http://www.lumiera.org/wiki/renderengine.html#VirtualClip[meta-clip] placed link:/wiki/renderengine.html#VirtualClip[meta-clip] placed
within EDL-1. Thus, within EDL-1, the contents of EDL-2 appear like a within EDL-1. Thus, within EDL-1, the contents of EDL-2 appear like a
pseudo-media, from which the (meta) clip has been taken. They can be adorned pseudo-media, from which the (meta) clip has been taken. They can be adorned
with effects and processed further completely similar to a real clip. with effects and processed further completely similar to a real clip.
@ -159,7 +159,7 @@ with effects and processed further completely similar to a real clip.
Finally, this example shows an *automation* data set controlling some parameter Finally, this example shows an *automation* data set controlling some parameter
of an effect contained in one of the global pipes. From the effect's POV, the of an effect contained in one of the global pipes. From the effect's POV, the
automation is simply a automation is simply a
http://www.lumiera.org/wiki/renderengine.html[ParamProvider], i.e a function link:/wiki/renderengine.html#ParamProvider[ParamProvider], i.e a function
yielding a scalar value over time. The automation data set may be implemented yielding a scalar value over time. The automation data set may be implemented
as a bézier curve, or by a mathematical function (e.g. sine or fractal pseudo as a bézier curve, or by a mathematical function (e.g. sine or fractal pseudo
random) or by some captured and interpolated data values. Interestingly, in random) or by some captured and interpolated data values. Interestingly, in
@ -186,7 +186,7 @@ Pros
^^^^ ^^^^
* very open and modular, allows for creating quite dynamic object behaviour in * very open and modular, allows for creating quite dynamic object behaviour in
the sessison the Session
* implementation is rather simple, because it relies on a small number of * implementation is rather simple, because it relies on a small number of
generic building blocks generic building blocks
@ -213,11 +213,11 @@ Alternatives
_Use the conventional approach:_ hard-wire a _reasonable simple_ structure and _Use the conventional approach:_ hard-wire a _reasonable simple_ structure and
code the behaviour of tracks, clips, effects and automation explicitly, code the behaviour of tracks, clips, effects and automation explicitly,
providing separate code to deal with each of them. Use the hard-wired providing separate code to deal with each of them. Use the hard-wired
assumption that a clip consists of "video and audio". Hack in any advanced assumption that a clip consists of ``video and audio''. Hack in any advanced
features (e.g. support multi-camera takes) as GUI macros. Just don't try to features (e.g. support multi-camera takes) as GUI macros. Just don't try to
support things like 3D video and spatial audio (anything beyond stereo and support things like 3D video and spatial audio (anything beyond stereo and
5.1). Instead, add a global "node editor" to make the geeks happy, allowing to 5.1). Instead, add a global »node editor« to make the geeks happy, allowing to
wire everything to everything, just static and global of course. wire everything to everything, just static and global of course. 😈
@ -226,9 +226,9 @@ Rationale
Ichthyo developed this design because the goal was to start out with the level Ichthyo developed this design because the goal was to start out with the level
of flexibility we know from Cinelerra, but try to do it considering all of flexibility we know from Cinelerra, but try to do it considering all
consequences right from start. Besides, the observation is that the development consequences right from start. Besides, the observation is that the development
of non-mainstream media types like steroscopic (3D) film and really convincing of non-mainstream media types like stereoscopic (3D) film and really convincing
spatial audio (beyond the ubiquitous "panned mono" sound) is hindered not by spatial audio (beyond the ubiquitous ``panned mono'' sound) is hindered not by
technological limitations, but by pragmatism preferring the "simple" hard wired technological limitations, but by pragmatism preferring the ``simple'' hard wired
approach. approach.
@ -242,10 +242,11 @@ Comments
Final Final
~~~~~ ~~~~~
Description of the Lumiera high level model as is. Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. +
This is a description of the Lumiera high level model as-is.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

73
doc/devel/rfc/ProcPlacementMetaphor.txt
View file

@ -1,15 +1,19 @@
[grid="all"] Design Process : Placement Metaphor
`------------`----------------------- ====================================
*State* _Final_
*Date* _2008-03-06_ [options="autowidth"]
*Proposed by* link:Ichthyostega[] |====================================
------------------------------------- |*State* | _Final_
|*Date* | _2008-03-06_
|*Proposed by* | Ichthyostega
|====================================
Placement Metaphor used within the high-level view of Steam-Layer Placement Metaphor used within the high-level view of Steam-Layer
----------------------------------------------------------------- -----------------------------------------------------------------
besides the [wiki:self:../ProcBuilder Builder], one of the core ideas of the
``Proc-Layer'' (as being currently implemented by Ichthyo) is to utilize besides the link:{rfc}/ProcBuilder.html[Builder], one of the core ideas of
the Lumiera application, as envisioned and implemented currently, is to utilise
_Placement_ as a single central metaphor for object association, location and _Placement_ as a single central metaphor for object association, location and
configuration within the high-level model. The intention is to prefer _rules_ configuration within the high-level model. The intention is to prefer _rules_
over fixed _values._ Instead of ``having'' a property for this and that, we over fixed _values._ Instead of ``having'' a property for this and that, we
@ -18,24 +22,24 @@ query for information when it is needed.
The proposed use of *Placement* within the steam layer spans several, The proposed use of *Placement* within the steam layer spans several,
closely related ideas: closely related ideas:
* use the placement as a universal means to stick the "media objects" together * using the placement as a universal means to stick the ``media objects'' together
and put them on some location in the timeline, with the consequence of a and put them on some location in the timeline, with the consequence of a
unified and simplified processing. unified and simplified processing.
* recognize that various _location-like_ degrees of freedom actually form a * recognise that various _location-like_ degrees of freedom actually form a
single _``configuration space''_ with multiple (more than 3) dimensions. single _``configuration space''_ with multiple (more than 3) dimensions.
* distinguish between _properties_ of an object and qualities, which are * distinguish between _properties_ of an object and qualities, which are
caused by ``placing'' or ``locating'' the object in _configuration space_ caused by ``placing'' or ``locating'' the object in _configuration space_
- _propetries_ belong to the object, like the blur value, the media source - _properties_ belong to the object, like the blur value, the media source
file, the sampling/frame rate of a source file, the sampling/frame rate of a source
- _location qualities_ exist only because the object is ``at'' a given - _location qualities_ exist only because the object is ``at'' a given
location in the graph or space, most notably the start time, the output location in the graph or space, most notably the start time, the output
connection, the layering order, the stereoscopic window depth, the sound connection, the layering order, the stereoscopic window depth, the sound
pan position, the MIDI instrument pan position, the MIDI instrument
* introduce a _way of placement_ independent of properties and location * introduce a _way of placement_ independent of properties and location
qualities, describing if the placement _itself_ is _absolute, relative or qualities, describing if the Placement _itself_ is _absolute, relative or
even derived_ even derived_
* open especially the possibility to _derive_ parts of the placement from * open especially the possibility to _derive_ parts of the Placement from
the context by searching over connected objects and then up the fork (``tree of tracks''); the context by searching over connected objects and then up the _Fork_ (``tree of tracks'');
this includes the possibility of having rules for resolving unspecified this includes the possibility of having rules for resolving unspecified
qualities. qualities.
@ -71,7 +75,7 @@ On the contrary, using the *Placement* metaphor has the implication of
switching to a query-driven approach. switching to a query-driven approach.
* it gives us one single instrument to express the various kinds of relations * it gives us one single instrument to express the various kinds of relations
* the _kind of placement_ becomes an internal value of the _placement_ (as * the _kind of placement_ becomes an internal value of the _Placement_ (as
opposed to the object) opposed to the object)
* some kinds of placement can express rule-like relations in a natural fashion * some kinds of placement can express rule-like relations in a natural fashion
* while there remains only one single mechanism for treating a bunch of * while there remains only one single mechanism for treating a bunch of
@ -124,7 +128,7 @@ Pros
* modular and extensible * modular and extensible
* allows much more elaborate handling of media objects then the conventional * allows much more elaborate handling of media objects then the conventional
approach, while both the simple standard case and the elaborate special case approach, while both the simple standard case and the elaborate special case
are "first class citizens" and completely integrated in all object are ``first class citizens'' and completely integrated in all object
treatment. treatment.
@ -133,7 +137,7 @@ Cons
^^^^ ^^^^
* difficult to grasp, breaks with some habits * difficult to grasp, breaks with some habits
* requires a separate resolution step * requires a separate resolution step
* requires to ''query'' for object properties instead of just looking up a * requires to _query_ for object properties instead of just looking up a
fixed value fixed value
* forces the GUI to invent means for handling object placement which may go * forces the GUI to invent means for handling object placement which may go
beyond the conventional beyond the conventional
@ -149,13 +153,12 @@ Use the conventional approach
* media objects are assigned with fixed time positions * media objects are assigned with fixed time positions
* they are stored directly within a grid (or tree) of tracks * they are stored directly within a grid (or tree) of tracks
* layering and pan are hard wired additional properties * layering and pan are hard wired additional properties
* implement an additional auto-link macro facility to attach sound to video * implement an additional auto-link macro facility to attach sound to a video clip
* implement a magnetic snap-to for attaching clips seamless after each other * implement a magnetic snap-to for attaching clips seamless after each other
* implement a splicing/sliding/shuffling mode in the UI * implement a splicing/sliding/shuffling mode in the UI
* provide a output wiring tool in the GUI * provide a output wiring tool in the GUI
* provide macro features for this and that.... * provide macro features for this and that.... +
^(hopefully I made clear by now _why_ I don't want to take the conventional approach)^
^hopefully I made clear by now _why_ I don't want to take the conventional approach^
@ -171,23 +174,23 @@ the conventional approach was dictated by technological limitations.
* the ususal layering based on tracks constantly forces the user to place * the ususal layering based on tracks constantly forces the user to place
clips in a unnatural and unrelated fashion and tear apart clips which belong clips in a unnatural and unrelated fashion and tear apart clips which belong
closely together closely together
* the conventional approach of having a fixed "pan control" in specialized * the conventional approach of having a fixed ``pan control'' in specialized
"audio tracks" constantly hinders the development of more natural and ``audio tracks'' constantly hinders the development of more natural and
convincing sound mixing. It favors a single sound system (intensity based convincing sound mixing. It favors a single sound system (intensity based
stereophony) for no good reason. stereophony) for no good reason.
* handling of stereoscopic (3D) video/film is notoriously difficult within the * handling of stereoscopic (3D) video/film is notoriously difficult within the
conventional, hard wired approach conventional, hard wired approach
* building more elaborate sound scapes and sound design is notoriously * building more elaborate soundscapes and sound design is notoriously
difficult to maintain, because the user is forced to use hidden "side difficult to maintain, because the user is forced to use hidden
chains", magic rules and re-build details in external applications, because ``side chains'', magic rules and re-build details in external applications,
of the lack of flexible integration of control data alongside with the main because of the lack of flexible integration of control data alongside
data. with the main data.
The high-level model is close to the problem domain, it should provide means to The high-level model is close to the problem domain, it should provide means to
express the (naturally complex) relationships between media objects. Using an express the (naturally complex) relationships between media objects. Using an
abstract and unified concept is always better then having a bunch of seemingly abstract and unified concept is always better then having a bunch of seemingly
unrelated features, even if they may be more easy to grasp for beginners. unrelated features, even if they may be more easy to grasp for beginners.
Moreover, the Placement concept deliberately brings in an rule based approach, Moreover, the Placement concept deliberately leads to a _rule based approach_,
which well fits into the problem domain. Finally, there is sort-of a visionary which well fits into the problem domain. Finally, there is sort-of a visionary
aspect involved here: _Ichthyo_ thinks that nowadays, after image and sound are aspect involved here: _Ichthyo_ thinks that nowadays, after image and sound are
no longer bound to physical media, there is potential for new workflows to be no longer bound to physical media, there is potential for new workflows to be
@ -205,7 +208,7 @@ Comments
Placement Metaphor Placement Metaphor
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
Re: [quote]
``Finally, there is sort-of a visionary aspect involved here: ``Finally, there is sort-of a visionary aspect involved here:
Ichthyo thinks that nowadays, after image and sound are no longer bound to Ichthyo thinks that nowadays, after image and sound are no longer bound to
physical media, there is potential for _new workflows_ to be physical media, there is potential for _new workflows_ to be
@ -225,13 +228,15 @@ use, and decision rules based on these parameters.
This feature/capability is likely to stamp the Lumiera project as a flagship This feature/capability is likely to stamp the Lumiera project as a flagship
benchmark in more ways than one, for some time. benchmark in more ways than one, for some time.
. --link:Tree[][[DateTime(2008-08-23T12:54:00NZ)]]. Tree:: '2008-08-23T12:54:00NZ'
Final Final
~~~~~ ~~~~~
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_proc_high_level_model_and_placement_concept[Apr.2011 developer meeting]. +
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

111
doc/devel/rfc/RefactorLiblumieraOut.txt
View file

@ -3,87 +3,81 @@ Refactor Liblumiera Out
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Fr 22 Apr 2011 10:46:50 CEST_ |*Date* | _Fr 22 Apr 2011 10:46:50 CEST_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
[abstract]
******************************************************************************** ********************************************************************************
liblumiera contains alot useful and reuseable code which is already in use by .Abstract
other projects `liblumiera` contains a lot of useful and re-useable code
which is already in use by other projects
******************************************************************************** ********************************************************************************
Description Description
----------- -----------
//description: add a detailed description: //description: add a detailed description:
Over the time we've put some efforts into the liblumiera. I've added Over the time we've put some efforts into the liblumiera. I have added
some from my code which predates the lumiera project which I am using some from my code which predates the Lumiera project and which I am using
on many other projects. This now caused that I maintain this sources in on many other projects. This means that I would have to maintain thsese
different unrelated projects and have to cross merge and update stuff sources in different unrelated projects and have to cross merge and update
when I do updates and fixes somewhere. I think its time to factor the several copies of the same code when I do updates and fixes somewhere.
reuseable parts out into a independent library (like glib does for I think its time to factor the re-useable parts out into a independent
gtk), in fact I had this plan long ago. library (similar to what Glib does for GTK). In fact, I had this plan long ago.
.What parts are eligible for a standalone library .What parts are eligible for a standalone library
Anything which is something tool alike and useful for other projects and not Anything which is something tool alike and useful for other projects and not
tied to Lumiera only. This are the algorithms/datastructures, allocators, tool tied to Lumiera only. This are the algorithms/datastructures, allocators, tool
macros. Additionally some of the src/common things should be moved into the macros. Additionally some of the src/common things should be moved into the
library. I give some lists below. library. I give some lists below.
.How to name it .How to name it
Long time ago my plan was to name it `ctlib' or `cehlib' but meanwhile there is
Long time ago my plan was to name it 'ctlib' or 'cehlib' but meanwhile there is
enough code done by others. So I'd propose a more neutral name, still enough code done by others. So I'd propose a more neutral name, still
'lumieralib' or 'lulib' would be approbiate. The only thing we have to account `lumieralib' or `lulib' would be appropriate. The only thing we have to account
for is that some parts which are too specific for Lumiera and should not be for is that some parts which are too specific for Lumiera and should not be
integrated into this spinoff need either to stay in a lumiera-internal lib integrated into this spinoff need either to stay in a lumiera-internal lib
(src/lib/) as currently or being moved to the respective subsystems using them (src/lib/) as currently or being moved to the respective subsystems using them
(src/backend, src/proc, src/common, ...), so the names should not clash. (src/backend, src/proc, src/common, ...), so the names should not clash.
.C, C++ ... .C, C++ ...
For myself I need the C parts, while there is C\++ code which interfaces to the
For myself I need the C parts, while there is C++ code which interfaces to the C implementations and also a lot code which does nice C\++ things on its own.
C implementations and also a lot code which does nice C++ things on its own.
This possibly means that we should in fact make 2 packages out of this, one C This possibly means that we should in fact make 2 packages out of this, one C
and one C++ library (where the C++ part is more than just the wrappers, but and one C\++ library (where the C++ part is more than just the wrappers, but
also the tools and tricks which are currently in src/lib/ and reuseable). also the tools and tricks which are currently in 'src/lib/' and reuseable).
.Who maintains it .Who maintains it
Despite of being a spin-off I think we don't want to change anything from our
Despite a spin of I think we don't want to change anything from our current current practice and maintain it by the Lumiera developers. In part I feel
practice and maintain it by the Lumiera developers. For many parts I feel responsible for it, while it is really a part of the Lumiera codebase,
responsible for it, but its really a part of the Lumiera codebase, despite despite of being independently useable.
independently useable.
.How to maintain it .How to maintain it
We need to decide about build system and documentation system. As build system We need to decide about build system and documentation system. As build system
we may right start using scons. For documentation the situation is a but we may right start using SCons. For documentation the situation is somewhat
different since some of my code uses pipadoc/asciidoc and other uses doxygen. different since some of my code uses pipadoc/asciidoc and other uses doxygen.
.What not to do .What not to do
Some of the code is currently quite specific to Lumiera while it could be made Some of the code is currently quite specific to Lumiera while it could be made
more generic. This is *NOT* subject of this RFC we may or may not do such a more generic. This is _NOT_ subject of this RfC -- we may or may not do such a
refactoring but this RFC and any work resulting from this should only restrict refactoring but this RfC and any work resulting from this should be restricted
to simple things like necessary namespace and variable renaming and integration to simple things like necessary namespace and variable renaming and integration
in the build system. in the build system.
C Parts C Parts
------- ~~~~~~~
Library Library
~~~~~~~ ^^^^^^^
What belongs to the library What belongs to the library
Containers Containers
^^^^^^^^^^ ++++++++++
* cuckoo hashing (cuckoo.c|h) * cuckoo hashing (cuckoo.c|h)
* linked lists (llist.h slist.h) * linked lists (llist.h slist.h)
* cache lists (mrucache.c|h) * cache lists (mrucache.c|h)
@ -91,29 +85,29 @@ Containers
* priority queues (not done yet) * priority queues (not done yet)
Runtime tools Runtime tools
^^^^^^^^^^^^^ +++++++++++++
* error handling (error.h error.c) used by the other facilities too * error handling (error.h error.c) used by the other facilities too
* clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor * clib convinience wrapers (safeclib.c|h) needs better name, maybe refactor
into new facilities into new facilities
Multithreading Multithreading
^^^^^^^^^^^^^^ ++++++++++++++
* locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock ...) * locking, condition variables etc. (condition.c|h (rec)mutex.c|h, rwlock ...)
Memory management Memory management
^^^^^^^^^^^^^^^^^ +++++++++++++++++
* Memory pools (mpool.c|h) * Memory pools (mpool.c|h)
* Temporary buffers (tmpbuf.c|h) * Temporary buffers (tmpbuf.c|h)
Metaprogramming Metaprogramming
^^^^^^^^^^^^^^^ +++++++++++++++
* preprecessor tools (ppmpl.h) move common preprocessor macros here * preprecessor tools (ppmpl.h) move common preprocessor macros here
* polymorphic call helper for C (vcall.h) * polymorphic call helper for C (vcall.h)
Interface system and module loader Interface system and module loader
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++++++
except for some hardcoded references to 'lumiera_org' and '.lum' plugin names except for some hardcoded references to `lumiera_org' and `.lum' plugin names
this is quite generic, possibly moving this over could be postponed, but might this is quite generic, possibly moving this over could be postponed, but might
eventually be done. eventually be done.
@ -124,26 +118,26 @@ interfaceregistry.c interfaceregistry.h plugin.c plugin_dynlib.c plugin.h
------ ------
The 'config' system could become a candidate too if it ever gets finished and The ``config system'' could become a candidate too if it ever gets finished and
proved useful, but for the time being its better kept in Lumiera. proves itself useful, but for the time being it's better kept in Lumiera.
Not Library Not Library
~~~~~~~~~~~ ^^^^^^^^^^^
Too specific to Lumiera: Tied specifically to Lumiera:
----- -----
luid.c luid.h time.h luid.c luid.h time.h
----- -----
C++ Parts C++ Parts
--------- ~~~~~~~~~
For most of the C++ parts I am not sure, ichthyo should decided upon these For most of the C++ parts I am not sure, _ichthyo_ should decide upon these
(please edit this here) (please edit this here)
Library Library
~~~~~~~ ^^^^^^^
These look 'generic' or wrap the C parts: These look 'generic' or wrap the C parts:
------ ------
singleton-factory.hpp singleton.hpp singleton-policies.hpp singleton-factory.hpp singleton.hpp singleton-policies.hpp
@ -154,7 +148,7 @@ util.hpp variant.hpp
------ ------
Not Sure Not Sure
~~~~~~~~ ^^^^^^^^
------ ------
access-casted.hpp advice advice.hpp allocation-cluster.cpp access-casted.hpp advice advice.hpp allocation-cluster.cpp
allocation-cluster.hpp bool-checkable.hpp cmdline.cpp cmdline.hpp del-stash.hpp allocation-cluster.hpp bool-checkable.hpp cmdline.cpp cmdline.hpp del-stash.hpp
@ -175,12 +169,14 @@ option.hpp query subsys.cpp subsys.hpp subsystem-runner.hpp
Not Library Not Library
~~~~~~~~~~~ ^^^^^^^^^^^
------ ------
logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/* logging.cpp nobug-init.cpp nobug-init.hpp streamtype.cpp streamtype.hpp test/*
time/* time.cpp tree.hpp time/* time.cpp tree.hpp
----- -----
Tasks Tasks
~~~~~ ~~~~~
// List what needs to be done to implement this Proposal: // List what needs to be done to implement this Proposal:
@ -213,17 +209,14 @@ Cons
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
//alternatives: explain alternatives and tell why they are not viable: //alternatives: explain alternatives and tell why they are not viable:
Do nothing and handle fixes on a case by case base.
Rationale
---------
//rationale: Give a concise summary why it should be done *this* way:
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -237,4 +230,4 @@ Comments
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

68
doc/devel/rfc/RenderOptimizer.txt
View file

@ -1,14 +1,14 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2007-06-07_ |*Date* | _2007-06-07_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Render Optimizer Render Optimizer
---------------- ----------------
Render only parts of a frame which are necessary for the Output; Optimize Render only parts of a frame which are necessary for the Output;
render pipeline for efficiency optimize render pipeline for efficiency
Description Description
@ -28,62 +28,30 @@ output as the original sequence of effects.
Tasks
^^^^^
Discussion
~~~~~~~~~~
Pros
^^^^
Cons
^^^^
Alternatives
^^^^^^^^^^^^
Rationale
~~~~~~~~~
Comments Comments
-------- --------
Possible classification for video filters: Possible classification for video filters:
1. The filter only changes the color of each pixel in the same way 1. The filter only changes the color of each pixel in the same way
2. The filter deforms the image but leaves the color 2. The filter deforms the image but leaves the color
3. The filter makes complex things. The only additional hint it can export is 3. The filter makes complex things. The only additional hint it can export is
the the number of referenced past frames, if such a limit exists (sometimes it
number of referenced past frames, if such a limit exists (sometimes it
doesn't). doesn't).
Filters of type 1 and type 2 never use any previous frames, and are strictly Filters of type 1 and type 2 never use any previous frames, and are strictly
one frame in - one frame out. Filters of type 1 can always be swapped with one frame in -- one frame out. Filters of type 1 can always be swapped with
filters of type 2, the output is the same. All other filters cannot be swapped filters of type 2, the output is the same. All other filters cannot be swapped
in general. in general.
The good news is, that: The good news is, that:
1. All commonly used filters are either type 1 or type 2 1. All commonly used filters are either type 1 or type 2
(type 3 are more the fun effects) (type 3 are more the fun effects)
2. Filters of type 2 are colormodel agnostic 2. Filters of type 2 are colormodel agnostic
3. If a filter of type 1 makes only linear transformations of the color 3. If a filter of type 1 makes only linear transformations of the color vectors +
vectors (new_color = matrix * old_color), (i.e.: new_color ≔ matrix · old_color),
the matrix can be transformed from e.g. RGB to YUV, so these filters can then the matrix can be transformed from e.g. RGB to YUV, so these filters can
always work in both colorspaces directly always work in both colorspaces directly
@ -91,10 +59,10 @@ Parked
~~~~~~ ~~~~~~
Generally this is accepted but needs some more polishing when we go over it. Generally this is accepted but needs some more polishing when we go over it.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

130
doc/devel/rfc/RepositorySetup.txt
View file

@ -1,12 +1,12 @@
Design Process: Repository Setup Design Process: Repository Setup
================================ ================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-09_ |*Date* | _2007-06-09_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Repository Setup Repository Setup
---------------- ----------------
@ -31,18 +31,15 @@ far incomplete
works for this) works for this)
------------------------------------------------------------ ------------------------------------------------------------
The cinelerra2 sources are put into oldsrc on a per-case base. The Cinelerra-2 sources are put into `oldsrc` on a per-case base.
We want to use the new GIT feature of "Superprojects and Submodules" when it is We want to use the new GIT feature of ``Superprojects and Submodules'' when it is
ready for general use. Then we will transform several subtrees into separate ready for general use. Then we will transform several subtrees into separate
GIT repos which will be linked to from the main Project (then called the GIT repos which will be linked to from the main Project (then called the
"Superproject") as submodules. _Superproject_) as _Submodules_.
Tasks
~~~~~
Pros Pros
^^^^ ^^^^
* Because its a text-like structure, it is partially self-documenting * Because its a text-like structure, it is partially self-documenting
@ -52,70 +49,79 @@ Pros
Cons Cons
^^^^ ^^^^
* Can get large and confusing * Can get large and confusing
* has no real "portal" or entrance point for people wanting to join * has no real ``portal'' or entrance point for people wanting to join
Alternatives
^^^^^^^^^^^^
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
Every important document, draft, text and code (including) prototypes should be Every important document, draft, text and code (including) prototypes should be
checked into one SCM (or a set of related SCMs). This repo should be "almost checked into one SCM (or a set of related SCMs). This Repo should be ``almost
everything" you need for the project. Because we try to use a distributed everything'' you need for the project. Because we try to use a distributed
developement model, every dev can/should have his own copy and fed his changes development model, every dev can/should have his own copy and fed his changes
back. back.
This 'Repository aproach' avoids the problems of a central infrastructure and This ``Repository approach'' avoids the problems of a central infrastructure and
helps cut down project management time. Basically, every dev is responsible helps cut down project management time. Basically, every dev is responsible
himself for getting every important piece of information added into "the himself for getting every important piece of information added into ``the
general view of matters" in a consitent way. general view of matters'' in a consistent way.
Comments Comments
-------- --------
- Basically the structure is just fine. - Basically the structure is just fine.
- Maybe add a "pastebin" somewhere in the dev-documentation area? - Maybe add a ``pastebin'' somewhere in the dev-documentation area?
- I would add the source tree roots at level 2, so we can have several - I would add the source tree roots at level 2, so we can have several
submodules here: submodules here:
* oldsrc ** oldsrc
* cin3 ** cin3
* prototype ** prototype
link:Ichthyostega[]
- Draft now. Ichthyostega:: 6/2007
- Yes I left source dirs out but this sounds fine, note that with git, there is
no problem to reorganize the repo (in contrast to CVS) later. We can fix
things afterward when we find better ways. -- link:ct[]
[[DateTime(2007-06-17T17:36:46Z)]]
- Whats prototype for? won't that be better a branch? -- link:ct[]
[[DateTime(2007-06-17T22:04:39Z)]]
- I just wanted to show there could be additional things beside the main tree
(later to be separete submodules). The example was meant as a classical
throwaway prototype. But I agree, in our case we just start hacking at the
new tree and make feature/tryout/prototype branches...
- The point I wanted to make is: every directory 2 levels deep in the source
tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely
self-contained tree which can be built without needing anything of the rest
of the repo. Thats an prerequisite for moving to Submodules IMHO. But you
seem rather to put the sourcetree-roots 1 level deep. As we have just two
trees at the moment (and can easily reorganize), I have no objections against
this. The only point I really care is to try to keep the source tree
self-contained without any dependencies to the rest of the "design GIT"
(because of this Superprojects-Submodules thing...) -- link:Ichthyostega[]
[[DateTime(2007-06-17T23:45:06Z)]]
- We could make the trees deeper than one level, I didn't intended 1-level
depth. but also be careful with that not to make it too complex. While I am
not sure if we want a complete oldsrc, that just adds weight and confusion
for now (lets see). Neither I am fully decided about the hierachy in /src
(want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name
it rather 'effects' than 'plugins'?). While I am quite sure that I want to
separate /oldssrc and /src quite much (in /src should only be new stuff or
stuff which is carefully reviewed, with known license and author). --
link:ct[] [[DateTime(2007-06-18T08:38:43Z)]]
- I made this proposal 'final' now further details are likely better worked out
in the git repository (and we already started to define things there) see
./admin/treeinfo.sh -- link:ct[] [[DateTime(2007-06-27T16:01:52Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Yes I left source dirs out but this sounds fine, note that with git, there is
no problem to reorganize the repo (in contrast to CVS) later. We can fix
things afterward when we find better ways.
ct:: '2007-06-17T17:36:46Z'
Whats prototype for? won't that be better a branch?
ct:: '2007-06-17T22:04:39Z'
I just wanted to show there could be additional things beside the main tree
(later to be separate submodules). The example was meant as a classical
throwaway prototype. But I agree, in our case we just start hacking at the
new tree and make feature/tryout/prototype branches...
The point I wanted to make is: every directory 2 levels deep in the source
tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely
self-contained tree which can be built without needing anything of the rest
of the repo. Thats an prerequisite for moving to Submodules IMHO. But you
seem rather to put the sourcetree-roots 1 level deep. As we have just two
trees at the moment (and can easily reorganize), I have no objections against
this. The only point I really care is to try to keep the source tree
self-contained without any dependencies to the rest of the ``design GIT''
(because of this Superprojects-Submodules thing...)
Ichthyostega:: '2007-06-17T23:45:06Z'
We could make the trees deeper than one level, I didn't intended 1-level
depth. but also be careful with that not to make it too complex. While I am
not sure if we want a complete oldsrc, that just adds weight and confusion
for now (lets see). Neither I am fully decided about the hierarchy in /src
(want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name
it rather 'effects' than 'plugins'?). While I am quite sure that I want to
separate /oldssrc and /src quite much (in /src should only be new stuff or
stuff which is carefully reviewed, with known license and author).
ct:: '2007-06-18T08:38:43Z'
I made this proposal 'final' now further details are likely better worked out
in the Git repository (and we already started to define things there) see
./admin/treeinfo.sh
ct:: '2007-06-27T16:01:52Z'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

143
doc/devel/rfc/ResourceManagementBudgeting.txt
View file

@ -3,19 +3,20 @@ Resource Management: Budgeting
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Fri Jul 23 20:33:32 2010_ |*Date* | _Fri Jul 23 20:33:32 2010_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
[abstract] [abstract]
****************************************************************************** ******************************************************************************
The Profiler will give some Idea about how much Resources can me used to The link:{rfc}/ResourceManagementProfiling.html[Profiler]
will give some Idea about how much Resources can be used to
optimally utilize the system. Knowing this number leads to the next challenge, optimally utilize the system. Knowing this number leads to the next challenge,
distributing the resources to different subsystems, jobs and objects. I here distributing the resources to different subsystems, jobs and objects. Here, I
introduce a budgeting system which takes care for this. introduce a budgeting system which takes care of this.
****************************************************************************** ******************************************************************************
@ -33,6 +34,60 @@ available for anyone.
Tasks
~~~~~
// List what would need to be done to implement this Proposal in a few words:
* define a sufficiently well defined goal first, to describe
what shall and can be achieved through budgeting ...
* then develop a plausible model of suitable control and regulation mechanisms
* very likely, practical tests will be required to show the feasibility of
effective automatic regulation over a significant span of different
use cases!
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
Cons
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//Conclusion
//----------
//conclusion: When approved (this proposal becomes a Final) write some
// conclusions about its process:
Comments
--------
//comments: append below
[source,C] [source,C]
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
typedef ssize_t budget_count; typedef ssize_t budget_count;
@ -64,58 +119,36 @@ struct budget
}; };
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
ct:: '2010-07-23 20:55:49 CEST'
....
​
​
​
....
[[caveat]]
[underline]#Many years later,# I'd like to confirm that this RfC describes
a part of the *core vision*: +
the engine shall make best use of limited resources.
Tasks CAUTION: The same caveats as for the
~~~~~ link:{rfc}/ResourceManagementProfiling.html#caveat[Profiling]
// List what would need to be done to implement this Proposal in a few words: do apply here as well...
// * item ...
I'd recommend to be extremely cautions to take any achievement for granted
for this topic, which is known to be notoriously difficult and insidious.
With _budgeting alone,_ we may be able to prevent overload of the system,
yet for anything beyond that, we need an actual optimisation strategy.
Ichthyostega:: '2025-09-17'
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
Cons
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not
viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final) write some
conclusions about its process:
Comments
--------
//comments: append below
//endof_comments: //endof_comments:
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

152
doc/devel/rfc/ResourceManagementProfiling.txt
View file

@ -3,31 +3,34 @@ Resource Management: Profiling
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Fri Jul 23 19:34:29 2010_ |*Date* | _Fri Jul 23 19:34:29 2010_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
[abstract] [abstract]
****************************************************************************** ******************************************************************************
From the beginning on we planned some kind of 'profiling' to adapt dynamically Right from the beginning of the project we planned some kind of _profiling_
to workload and machine capabilities. I describe here how statistic data can be to adapt dynamically to current workload and machine capabilities.
gathered in a generic way. This will later work together with other components I describe here how statistic data can be gathered in a generic way.
This will later work together with other components
tuning the system automatically. tuning the system automatically.
****************************************************************************** ******************************************************************************
-> link:{rfc}/ResourceManagementBudgeting.html[RfC: use gathered data for budgeting...]
Description Description
----------- -----------
//description: add a detailed description: //description: add a detailed description:
I just introduce some ideas about the planned profiling framework here, nothing I just introduce some ideas about the planned profiling framework here, nothing
is defined/matured yet this is certainly subject for futher discussion and is defined/matured yet this is certainly subject for further discussion and
refinement. refinement.
.Requirements/Evaluation generic:: Requirements/Evaluation generic::
Profiling should be sufficiently abstracted to have a single set of Profiling should be sufficiently abstracted to have a single set of
datastructures and algorithms to work on a broad range of subjects datastructures and algorithms to work on a broad range of subjects
being profiled. Moreover the profiling core just offers unitless being profiled. Moreover the profiling core just offers unitless
@ -49,7 +52,7 @@ refinement.
such false alarms. Workload also changes over time we need to find some such false alarms. Workload also changes over time we need to find some
way to measure the current/recent workload an grand total over the way to measure the current/recent workload an grand total over the
whole application runtime is rather uninteresting. While it is also whole application runtime is rather uninteresting. While it is also
important that we adapt slow enough not to get into some osccilating important that we adapt slow enough not to get into some oscillating
cycle. cycle.
active or passive system:: active or passive system::
@ -59,10 +62,60 @@ refinement.
Tasks
~~~~~
// List what would need to be done to implement this Proposal in a few words:
* develop a concept to outline what we actually want to observe ...
* refine this into a model to describe the observables
* derive an assessment of the specific requirements and challenges of this measurement
* use _this_ as the starting-point for an implementation draft ...
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
Cons
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//Conclusion
//----------
//conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process:
Comments
--------
//comments: append below
.Brainstorming in Code .Brainstorming in Code
[source,C] [source,C]
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
@ -127,56 +180,45 @@ struct profile
}; };
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
ct:: '2010-07-23 20:33:13 CEST'
Tasks ....
~~~~~ ​
// List what would need to be done to implement this Proposal in a few words: ​
// * item ... ​
....
[[caveat]]
[underline]#Many years later,# I'd like to confirm that we need and want some
kind of profiling in the engine, for the purpose described in this RfC, which is
to fine-tune our operation parameters dynamically.
We should however be _careful_ not to settle down onto an implementation in our
mind _before_ having conducted a proper *requirement analysis*. Starting from
the valid idea what can be done with profiling and statistic, the first thing
to map out is what we actually want to achieve and to which degree this can
be reasonably achieved. From there we should head towards a model to
describe what we want to observe, and only from there we'll be able
to pick suitable measurement methods.
Discussion ^(I have just added these step to the ``Tasks'' section)^
~~~~~~~~~~
Pros WARNING: we should drop the pre-established conception that what we capture
^^^^ here is simple, and can be squeezed into a single data representation.
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
If it turns out that we're headed towards high-throughput processing,
we should keep possible solutions at the architecture level in mind, before
focusing on details of the implementation. Messaging systems and lock-free
data structures have made significant progress over the last decade.
-> see also my link:{rfc}/ResourceManagementBudgeting.html#caveat[remark to RfC:Budgeting]
Cons Ichthyostega:: '2025-09-17'
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not
viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final) write some
conclusions about its process:
Comments
--------
//comments: append below
//endof_comments: //endof_comments:
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

144
doc/devel/rfc/Roadmap-first.txt
View file

@ -1,28 +1,30 @@
[grid="all"] Design Process : Roadmap
`------------`----------------------- ========================
*State* _Final_
*Date* _2009-01-30_ [options="autowidth"]
*Proposed by* link:Ichthyostega[] |====================================
------------------------------------- |*State* | _Final_
|*Date* | _2009-01-30_
|*Proposed by* | Ichthyostega
|====================================
Roadmap up to Lumiera 1.0 A Roadmap leading to Lumiera 1.0
------------------------- --------------------------------
As the very basic architecture questions seem to settle down now, it seems to As the very basic architecture questions seem to settle down now, it seems to
be time to create a first Roadmap skeleton for the project. A specific approach be time to create a first Roadmap skeleton for the project. A specific approach
is proposed: we should define criteria allowing us to judge when we've reached is proposed: we should define criteria allowing us to judge when we've reached
a certain level plus we should define features to be ''excluded'' at a certain a certain level plus we should define features to be _excluded_ at a certain
level. We should level. We should _not_ define _Features_ to go into a certain level.
''not'' define ''Features'' to go into a certain level.
''the following text is copied from the Lumiera TIP: the following text is copied from the Lumiera
https://issues.lumiera.org/roadmap[Trac]'' https://issues.lumiera.org/roadmap[Trac]
Description: Milestones up to first Release Description: Milestones up to the first stable Release
------------------------------------------- ------------------------------------------------------
Milestone integration: cooperating parts to render output Milestone integration: cooperating parts to render output
@ -30,16 +32,16 @@ Milestone integration: cooperating parts to render output
For this milestone to be reached, the basic subsystems of Lumiera need to be For this milestone to be reached, the basic subsystems of Lumiera need to be
designed, the most important interfaces between the parts of the application designed, the most important interfaces between the parts of the application
exist in a first usable version, and all the facilities on the rendering code exist in a first usable version, and all the facilities on the rendering code
path are provided at least in a dummy version and are '''capable of cooperating path are provided at least in a dummy version and are *capable of cooperating
to create output'''. Based on Lumiera's design, this also means that the basic to create output*. Based on Lumiera's design, this also means that the basic
frame cache in the vault layer is working. And it means that a media asset and frame cache in the vault layer is working. And it means that a media asset and
a clip can be added to the internal session representation, which is then handed a clip can be added to the internal session representation, which is then handed
over to the builder. Probably it's a good idea to include basic over to the builder. Probably it's a good idea to include basic
playback/display of the rendered frames within the GUI while they are created. playback/display of the rendered frames within the GUI while they are created.
Notable features ''not'' included Notable features _not_ included
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* no saving and loading of sessions * no saving and loading of sessions
* no manipulation of objects though the GUI (just display of the session) * no manipulation of objects though the GUI (just display of the session)
* no adding of arbitrary media or inclusion of arbitrary plugins * no adding of arbitrary media or inclusion of arbitrary plugins
@ -50,18 +52,18 @@ Notable features ''not'' included
Milestone alpha: operations accessible for users Milestone alpha: operations accessible for users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For this milestone to be reached, the fundamental operations you'd expect from For this milestone to be reached, the fundamental operations you'd expect from
a video editing software can be '''accessed by a user''' (not a developer!). a video editing software can be *accessed by a user* (not a developer!).
This means that the basic distribution/release model is set up, a ''user'' is This means that the basic distribution/release model is set up, a _user_ is
able to compile Lumiera or install an existing package. Moreover a user should able to compile Lumiera or install an existing package. Moreover a user should
be able to create/open a session file (without any quirks), add some media be able to create/open a session file (without any quirks), add some media
(probably only a limited number of media types will be supported), and then (probably only a limited number of media types will be supported), and then
perform the most basic operations like positioning, trimming, copying, playing perform the most basic operations like positioning, trimming, copying, playing
and finally rendering the timeline integration phase is closed and Lumiera has and finally rendering the timeline. Once this level of functionality is
reached alpha level. achieved, the _integration phase_ is closed and Lumiera has reached alpha level.
Notable features ''not'' included Notable features _not_ included
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* advanced configuration * advanced configuration
* complex/compound projects * complex/compound projects
* meta-clips, multi-cam, advanced multi channel sound handling * meta-clips, multi-cam, advanced multi channel sound handling
@ -75,23 +77,23 @@ Notable features ''not'' included
Milestone beta: usable for real work Milestone beta: usable for real work
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For this milestone to be reached, users should be able to '''get real work done For this milestone to be reached, users should be able to *get real work done*
with Lumiera'''. Especially, a basic asset management should be in place, with Lumiera. Especially, a basic asset management should be in place,
Lumiera should be able to handle the most common media types, the user should Lumiera should be able to handle the most common media types, the user should
be able to do common editing tasks (adding, trimming, rolling, splicing be able to perform common editing tasks (add, move, copy, splice, trim, roll,
copying, moving) both by direct manipulation within the timeline, as by using slide, slip) both by direct manipulation within the timeline, as by using
the conventional two-viewer setup with in/out points. Moreover, it should be the conventional two-viewer setup with in/out points. Moreover, it should be
possible to attach effects (probably still just some limited kinds of effects), possible to attach effects (probably still just some limited kinds of effects),
apply simple transitions and control the layering and overlay mode on output. apply simple transitions and control the layering and overlay mode on output.
Similarily, the elementary routing capabilities and the handling of multiple Similarily, the elementary routing capabilities and the handling of multiple
sequences should be suported (probably still with limitations). The framework sequences should be suported (probably still with limitations). The framework
for automation handling should be in place, while there may be still for automation handling should be in place, while there may be still
limitations on automation/keyframe editing. Having about this feature set limitations on automation/keyframe editing. Having implemented roughly
indicates, that Lumiera entered the beta phase. this feature set indicates that Lumiera can enter the beta phase.
Notable features ''not'' included Notable features _not_ included
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* configuration editing through the GUI * configuration editing through the GUI
* advanced routing, full support of virtual clips * advanced routing, full support of virtual clips
* arbitrary wiring, macro effects or similar * arbitrary wiring, macro effects or similar
@ -99,25 +101,25 @@ Notable features ''not'' included
* arbitrary nesting and navigation within projects * arbitrary nesting and navigation within projects
* full multi-cam support, support for non-standard image/sound types * full multi-cam support, support for non-standard image/sound types
* plugin libraries and packaging * plugin libraries and packaging
* interfaces for plugin authors are not frozen! * interfaces for plugin authors are _not yet_ frozen!
* fully configurable GUI * fully configurable GUI
* full support for proxy editing everywhere * full support for proxy editing everywhere
* extended workflow features (like "export to DVD") * extended workflow features (like ``export to DVD'')
Milestone release-1.0: usable for productions Milestone release-1.0: usable for productions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For this milestone to be reached, Lumiera should be a '''reliable tool for For this milestone to be reached, Lumiera should be a *reliable tool for
productions with a deadline'''. Lumiera 1.0 is not the ''dream machine,'' but productions with a deadline*. Lumiera 1.0 is not the ``dream machine'', but
users should be able to do simple productions. We should be able to promote users should be able to complete simple productions. We should be able to
Lumiera to professionals without remorse. The GUI should be mature, promote Lumiera to professionals without remorse. The GUI should be mature,
undo/recovery should work airtight, performance should be ok-ish and output undo/recovery should work airtight, performance should be ok-ish and output
quality without any glitches. Plugin authors can rely on stable interfaces and quality without any glitches. Plugin authors can rely on stable interfaces and
backwards compatibility from now on, up to release 2.0 backwards compatibility from now on, up to release 2.0
Notable features ''not'' included Notable features _not_ included
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* bangs and whistles * bangs and whistles
* render farm, distributed execution, hardware acceleration * render farm, distributed execution, hardware acceleration
* MIDI and adding of non-standard media kinds yet-to-appear * MIDI and adding of non-standard media kinds yet-to-appear
@ -126,17 +128,11 @@ Notable features ''not'' included
* foreign session import/export * foreign session import/export
* collaboration features * collaboration features
* artificial intelligence * artificial intelligence
* saving the world
Tasks
+++++
Please review and discuss this proposal, consider if it's of any use setting it
up this way...
Discussion Discussion
~~~~~~~~~~ ~~~~~~~~~~
@ -151,7 +147,7 @@ Pros
Cons Cons
^^^^ ^^^^
The contents of the roadmap aren't very specific and thus aren't of much help The contents of the roadmap aren't very specific and thus aren't of much help
for determining ''what has to be done next.'' for determining _what has to be done next._
@ -165,18 +161,17 @@ Alternatives
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
We deliberately don't set any date schedule. Releases happen ''when they are We deliberately don't set any date schedule. Releases happen ``when they are
ready.'' We may decide to do sprints on a short-term timeframe, but it doesn't ready''. We may decide to do sprints on a short-term timeframe, but it doesn't
help promising things we can't calculate for sure. In an commercial setup, you help promising things we can't plan and calculate reliably. In an commercial setup,
have to commit to features and dates, but you also control a certain budget, you have to commit to features and dates, but you also control a certain budget,
which gives you the means to ''make things happen.'' In Open Source which gives you the means to _make things happen._ In Free Software development,
development, we've to be patient and wait for the things to happen ;-) we have to be patient and wait for great things to happen 😇
Thus the proposal is to set up just a very coarse and almost self-evident Thus the proposal aims to set up just a very coarse and almost self-evident
roadmap skeleton, but to discuss and define criteria up-front, which allow us roadmap skeleton, but also to discuss and define criteria up-front, which allow us
to determine when we've actually reached a given level. Moreover, the proposal to determine when we've actually reached a given level. Furthermore, the proposal
is to add a list of features which can be savely ''excluded'' from the given provides a list of features which can be savely _excluded_ from a given milestone.
milestone
@ -186,21 +181,34 @@ milestone
Comments Comments
-------- --------
Looks ok to me, the dust is settling ad we can now think about such a roadmap. Looks ok to me, the dust is settling and we can now think about such a roadmap.
Some goals might be shifted between Milestones on collaborative decision, but Some goals might be shifted between Milestones on collaborative decision, but
so far I agree. Otherwise I'd like to keep the issue tracker focus on work to so far I agree. Otherwise I'd like to keep the issue tracker focus on work to
be done, it shall not become a wishlist tool for non developers, any such be done, it shall not become a wishlist tool for non developers, any such
things are deliberately left out. things are deliberately left out.
-- link:ct[] 2009-01-31
In ticket #4 (debian packaging) i explained that packaging might be optional ct:: '2009-01-31'
for 'alpha' and should be moved to 'beta'.
-- link:ct[] 2009-02-01 In https://issues.lumiera.org/ticket/4[#4 (debian packaging)] i explained that
packaging might be optional for ``alpha'' and should be moved to ``beta''.
ct:: '2009-02-01'
OK, we should make the packaging optional. I think, for alpha the criterion is OK, we should make the packaging optional. I think, for alpha the criterion is
"accessability for users". If compiling remains so easy as it is now (compared ``accessability for users''. If compiling remains so easy as it is now (compared
with other media related projects), than this shouldn't be a barrier. with other media related projects), than this shouldn't be a barrier.
-- link:Ichthyostega[] 2009-02-01
Ichthyostega:: '2009-02-01'
[underline]#Many years later# I can confirm that this approach towards a roadmap
and release planning stood well the test of time and looks reasonable still.
The joke with ``artificial intelligence'' got a nice ring meanwhile,
as many people seem to believe that we're close to the AI miracle.
And since Lumiera might indeed integrate some _tools_ based on
``machine learning'' eventually, it seems adequate to point out
that we can not _save the world_ already in Release 1.0
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

16
doc/devel/rfc/SchedulerRequirements.txt
View file

@ -3,12 +3,12 @@ SchedulerRequirements
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _Mi 09 Jan 2013 12:04:03 CET_ |*Date* | _Mi 09 Jan 2013 12:04:03 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -170,7 +170,7 @@ scheduler and vault layer implementation.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -193,4 +193,4 @@ Ichthyostega:: 'Do 19 Sep 2013 21:31:07 CEST' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

34
doc/devel/rfc/ScriptingLanguage.txt
View file

@ -1,13 +1,16 @@
[grid="all"] Design Process : Scripting Language
`------------`----------------------- ===================================
*State* _Pending_
*Date* _2008-07-26_ [options="autowidth"]
*Proposed by* link:ct[] |====================================
------------------------------------- |*State* | _Pending_
|*Date* | _2008-07-26_
|*Proposed by* | ct
|====================================
Scripting Language Required Scripting Language
------------------ ---------------------------
Add support for the *Lua* scripting language in Lumiera. Add support for the *Lua* scripting language in Lumiera.
@ -21,7 +24,7 @@ as »official« scripting language.
Tasks Tasks
^^^^^ ^^^^^
* Investigate Lua's C bindings and integrate it * Investigate Lua's C bindings and integrate it
* It will attach to the link:Plugin/Interface[] System cehteh is working on * It will attach to the Plugin/Interface System cehteh is working on
Pros Pros
@ -50,7 +53,7 @@ Rationale
Wee need scripting yet alone for driving the testsuite soon. Later on scripting Wee need scripting yet alone for driving the testsuite soon. Later on scripting
might be used to customize workflows and other application internals. Further might be used to customize workflows and other application internals. Further
one might implement a high level / batch interface to lumiera to give it a one might implement a high level / batch interface to lumiera to give it a
scripting interface similar to link:AviSynth[]. scripting interface similar to the https://en.wikipedia.org/wiki/AviSynth[Frameserver »AviSynth«].
@ -105,7 +108,7 @@ ct:: '2008-07-30T16:22:32Z'
I have no problems using Lua. It is proven in the industry, well supported, I have no problems using Lua. It is proven in the industry, well supported,
fast, efficient, high level and designed for this purpose. My only "complaint" fast, efficient, high level and designed for this purpose. My only ``complaint''
is that Lua isn't my pet language (Scheme). And that really isn't a complaint is that Lua isn't my pet language (Scheme). And that really isn't a complaint
at all. at all.
@ -115,7 +118,7 @@ PercivalTiglao:: '2008-07-28T19:56:25Z'
I think Python should be reconsidered: it's given that all languages in this I think Python should be reconsidered: it's given that all languages in this
class are powerful at what they do, however python has particularly well class are powerful at what they do, however python has particularly well
developed libraries and is used as the scripting language in the main raster developed libraries and is used as the scripting language in the main raster
(GIMP), vector (Inkscape) and 3D (Blender, link:PythonOgre[], PyCrystal) Apps. (GIMP), vector (Inkscape) and 3D (Blender, PythonOgre, PyCrystal) Apps.
Combinations of these Apps are all going to be working in a stack in Combinations of these Apps are all going to be working in a stack in
professional production, so the fact that all the others use python makes a professional production, so the fact that all the others use python makes a
more persuasive case for adoption than any micro-benefit in performance or more persuasive case for adoption than any micro-benefit in performance or
@ -126,8 +129,9 @@ get this into professional production houses, then I think having a single
language from OS admin the whole way through the stack is a massive gain for language from OS admin the whole way through the stack is a massive gain for
the types of users who will be using it. I personally prefer Ruby. Naturally the types of users who will be using it. I personally prefer Ruby. Naturally
it's your decision to make, all the best, we are looking forward to alphas and it's your decision to make, all the best, we are looking forward to alphas and
betas in the future + betas in the future
-- *mytwocents*
mytwocents:: 'Aug.2008'
This proposal is about the _required_ scripting language, i.e. when This proposal is about the _required_ scripting language, i.e. when
@ -201,5 +205,5 @@ Lua was _accepted_ as the required scripting language by October.2008 dev
meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023 meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023
and moves this proposal back into the inception stage. and moves this proposal back into the inception stage.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

30
doc/devel/rfc/SemanticTags.txt
View file

@ -3,12 +3,12 @@ Semantic tags
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Do 30 Aug 2012 21:06:54 CEST_ |*Date* | _Do 30 Aug 2012 21:06:54 CEST_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -39,13 +39,13 @@ To give tags some sematics we introduce a simple ontology:
- Tags can have namespaces, delimited by a dot 'foo.bar.baz'. - Tags can have namespaces, delimited by a dot 'foo.bar.baz'.
Tags are looked up from right to left 'baz' would suffice as long it is unique. Tags are looked up from right to left 'baz' would suffice as long it is unique.
Non unique cases will be handled in context (sometimes non uniqunes is desired) Non unique cases will be handled in context (sometimes non uniqunes is desired)
- We introduce simple "Is a" and "Has a" relationships. These are defined by the - We introduce simple ``is-a'' and ``has-a'' relationships. These are defined by the
casing of the tag: 'ALL_UPPERCASE' means "Is a" and anything else (including casing of the tag: `ALL_UPPERCASE' means ``is-a'' and anything else (including
mixed case) means "Has a". Note that for most cases the "Is a" relation will be mixed case) means ``has-a''. Note that for most cases the ``is-a'' relation will
defined implicitly, ín normal cases one doesnt need to care. be defined implicitly, in normal cases one does not need to care.
- define some tag algebra for lookups (group tags by comma and semicolons, where - define some tag algebra for lookups (group tags by comma and semicolons, where
comma means 'and' and semicolon means 'or'). Used to query the tag database. comma means 'and' and semicolon means 'or'). Used to query the tag database.
regex/globbing might become handy too. regex / globbing might become handy too.
.Implicit Tags .Implicit Tags
@ -66,7 +66,7 @@ Tags are collected/discovered by some script which creates a tag-database
(possibly plaintext asciidoc files) as big project index linking back to the content, (possibly plaintext asciidoc files) as big project index linking back to the content,
details need to be worked out. details need to be worked out.
We create special asciidoc macros for crossreferencing tags for example: 'RFC:foobar' We create special Asciidoc macros for cross-referencing tags for example: 'RFC:foobar'
'SOURCE:builder', details need to be worked out later. 'SOURCE:builder', details need to be worked out later.
Note: this Proposal is about including tags in the first place, processing them is only Note: this Proposal is about including tags in the first place, processing them is only
@ -108,7 +108,7 @@ Cons
^^^^ ^^^^
// fact list of the known/considered bad implications: // fact list of the known/considered bad implications:
* adding tags and developing the tools manging them will take some time * adding tags and developing the tools to manage them will take some time
Alternatives Alternatives
@ -129,7 +129,7 @@ It is very urgent and important that we make our content much easier accessible.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -196,4 +196,4 @@ Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~<prg@ichthyostega.de>~
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

44
doc/devel/rfc/SkillsCollection.txt
View file

@ -1,9 +1,13 @@
[grid="all"] Offering Skills for Help
`------------`----------------------- ========================
*State* _Parked_
*Date* _2007-06-13_
*Proposed by* link:ct[] [options="autowidth"]
--------------------------------- |====================================
|*State* | _Parked_
|*Date* | _2007-06-13_
|*Proposed by* | ct
|====================================
Skills Collection Skills Collection
@ -18,7 +22,7 @@ Some Page should list different things needed for working on the project and
users should attach themself when they offer support for it. This is meant that users should attach themself when they offer support for it. This is meant that
people who run into problems know who to ask. In contrast this is not meant people who run into problems know who to ask. In contrast this is not meant
like these Skill pages on Sourceforge or such. I don't like this rating and like these Skill pages on Sourceforge or such. I don't like this rating and
posing system. We let people assing themself to skill and not skills to people posing system. We let people assign themself to skill and not skills to people
and there is no rating. and there is no rating.
Skills shall be anything which is needed like the tools we use, the code we Skills shall be anything which is needed like the tools we use, the code we
@ -39,12 +43,14 @@ Example
.lumiera/renderpipe .lumiera/renderpipe
* ichthyo * ichthyo
... shall this contain emails?
Question: __shall this contain emails?__
Tasks Tasks
^^^^^ ^^^^^
* just set this page up .. either on this wiki or in a tiddlywiki which * just set this page up ... +
either on this wiki or in a TiddlyWiki which
becomes checked into the repo becomes checked into the repo
@ -55,13 +61,13 @@ Pros
Cons Cons
^^^^ ^^^^
* privacy concerns, people might not publish what they know or better what * privacy concerns, people might not publish what they know or, even more,
they ''not'' know what they _do not_ know
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
...urgs ...urgs 😶
Rationale Rationale
@ -76,5 +82,17 @@ community and is absolutely voluntary.
Comments Comments
-------- --------
[underline]#Historical remark#: This RfC stems from the very first days of the »Cinelerra-3 movment«,
which turned into the Lumiera project over the course of the following months. The RfC was already
marked as __parked__ when first imported into the Lumiera Documentation in 2010. Early in 2008 however,
at the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_draft_skills_collection[March developer meeting],
it was discussed shortly and deemed ``...only useful if there are more developers working on the project''.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Reading this RfC today gives me some kind of peculiar melancholic feeling -- it has the vibes of »zero hour«,
when all hands on deck are needed and everyone wants to help; people write their names on a blackboard
at the wayside, to get into contact, organise themselves or just to find their beloved ones...
Ichthyostega:: '2025-09-11'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

99
doc/devel/rfc/StreamTypeSystem.txt
View file

@ -3,12 +3,12 @@ Stream Type System
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _2008-10-05_ |*Date* | _2008-10-05_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
@ -75,9 +75,9 @@ Levels of classification
Image, Audio, MIDI, Text,..._ This is a simple Enum. Image, Audio, MIDI, Text,..._ This is a simple Enum.
* Below the level of distinct kinds of media streams, within every kind we * Below the level of distinct kinds of media streams, within every kind we
have an open ended collection of *Prototypes*, which, within the high-level have an open ended collection of *Prototypes*, which, within the high-level
model and for the purpose of wiring, act like the "overall type" of the model and for the purpose of wiring, act like the ``overall conceptual type''
media stream. Everything belonging to a given Prototype is considered to be of the media stream. Everything belonging to a given Prototype is considered
roughly equivalent and can be linked together by automatic, lossless to be roughly equivalent and can be linked together by automatic, lossless
conversions. Examples for Prototypes are: stereoscopic (3D) video versus the conversions. Examples for Prototypes are: stereoscopic (3D) video versus the
common flat video lacking depth information, spatial audio systems common flat video lacking depth information, spatial audio systems
(Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1, (Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1,
@ -96,7 +96,7 @@ Working with media stream implementations
For dealing with media streams of various implementation type, we need For dealing with media streams of various implementation type, we need
_library_ routines, which also yield a _type classification system_ suitable _library_ routines, which also yield a _type classification system_ suitable
for their intended use. Most notably, for raw sound and video data we use the for their intended use. Most notably, for raw sound and video data we use the
http://gmerlin.sourceforge.net/[GAVL] library, which defines a fairly complete https://github.com/bplaum/gavl[GAVL] library, which defines a fairly complete
classification system for buffers and streams. For the relevant operations in classification system for buffers and streams. For the relevant operations in
the Steam-Layer, we access each such library by means of a Façade; it may sound the Steam-Layer, we access each such library by means of a Façade; it may sound
surprising, but actually we just need to access a very limited set of surprising, but actually we just need to access a very limited set of
@ -107,13 +107,13 @@ two streams and get an conversion plugin.
Thus, to integrate an external library into Lumiera, we need explicitly to Thus, to integrate an external library into Lumiera, we need explicitly to
implement such a Lib Façade for this specific case, but the intention is to be implement such a Lib Façade for this specific case, but the intention is to be
able to add this Lib Façade implementation as a plugin (more precisely as a able to add this Lib Façade implementation as a plugin (more precisely as a
"Feature Bundle", because it probably includes several plugins and some link:{rfc}/FeatureBundle_PluggableModules.html[»Feature Bundle«],
additional rules) because it probably includes several plugins and some additional rules)
Link between implementation type and prototype Link between implementation type and prototype
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
At this point the rules based configuration comes into play. Mostly, to start At this point the _rules based configuration_ comes into play. Mostly, to start
with, determining a suitable prototype for a given implementation type is sort with, determining a suitable prototype for a given implementation type is sort
of a tagging operation. But it can be supported by heuristic rules and an of a tagging operation. But it can be supported by heuristic rules and an
flexible configuration of defaults. For example, if confronted with a media flexible configuration of defaults. For example, if confronted with a media
@ -155,10 +155,10 @@ Tasks
// List what needs to be done to implement this Proposal: // List what needs to be done to implement this Proposal:
* draft the interfaces ([green]#✔ done#) * draft the interfaces ([green]#✔ done#)
* define a fall-back and some basic behaviour for the relation between * define a fall-back and some basic behaviour for the relation between
implementation type and prototypes [,yellow]#WIP# implementation type and prototypes [orange]#(some draft)#
* find out if it is necessary to refer to types in a symbolic manner, or if it * find out if it is necessary to refer to types in a symbolic manner, or if it
is sufficient to have a ref to a descriptor record or Façade object. is sufficient to have a ref to a descriptor record or Façade object.
* provide a Lib Façade for GAVL [,yellow]#WIP# * provide a Lib Façade for GAVL
* evaluate if it's a good idea to handle (still) images as a separate distinct * evaluate if it's a good idea to handle (still) images as a separate distinct
kind of media kind of media
@ -210,7 +210,7 @@ Rationale
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -220,49 +220,74 @@ Comments
-------- --------
//comments: append below //comments: append below
As usual, see the As usual, see the
http://www.lumiera.org/wiki/renderengine.html#StreamType[Development internal doc] link:/wiki/renderengine.html#StreamType[Development internal doc]
for more information and implementation details. for more information and implementation details.
Practical implementation related note: I found I was blocked by this one in Practical implementation related note: I found I was blocked by this one in
further working out the details of the processing nodes wiring, and thus make further working out the details of the processing nodes wiring, and thus make
any advance on the builder and thus to know more precisely how to organize the any advance on the builder and thus to know more precisely how to organize the
objects in the link:EDL/Session[]. Because I need a way to define a viable objects in the EDL rsp. Session. Because I need a way to define a viable
abstraction for getting a buffer and working on frames. The reason is not abstraction for getting a buffer and working on frames. The reason is not
immediately obvious (because initially you could just use an opaque type). The immediately obvious (because initially you could just use an opaque type). The
problem is related to the question what kind of structures I can assume for the problem is related to the question what kind of structures I can assume for the
builder to work on for deciding on connections. Because at this point, the builder to work on for deciding on routing and connectivity? Because at this point,
high-level view (pipes) and the low level view (processing functions with a the high-level view (pipes) and the low level view (processing functions with a
number of inputs and outputs) need in some way to be connected. number of inputs and outputs) need in some way to be connected.
The fact that we don't have a rule based system for deciding queries currently The fact that we don't have a rule based system for deciding queries currently
is not much of a problem. A table with some pre configured default answers for is not much of a problem. A table with some pre configured default answers for
a small number of common query cases is enough to get the first clip rendered. a small number of common query cases is enough to get the first clip rendered.
(Such a solution is already in place and working.) + (Such a solution is already in place and working).
-- link:Ichthyostega[] 2008-10-05
Woops fast note, I didn't read this proposal completely yet. Stream types could Ichthyostega:: '2008-10-05'
or maybe should be coopertatively handled together with the backend. Basically
the backend offers one to access regions of a file in a continous block, this Woops fast note, I didn't read this proposal completely yet.... +
regions are addressed as "frames" (this are not necessary video frames). The Stream types could or maybe should be cooperatively handled together with the backend.
Basically the backend offers one to access regions of a file in a continuous block, this
regions are addressed as ``frames'' (this are not necessary video frames). The
backend will keep indices which associate this memory management with the frame backend will keep indices which associate this memory management with the frame
number, plus adding the capabilitiy of per frame metadata. This indices get number, plus adding the capability of per frame metadata. This indices get
abstracted by "indexing engines" it will be possible to have different kinds of abstracted by ``indexing engines'' -- it will be possible to have different kinds
indices over one file (for example, one enumerating single frames, one of indices over one file (for example, one enumerating single frames, one
enumerating keyframes or gops). Such a indexing engine would be also the place enumerating keyframes or GOPs). Such a indexing engine would be also the place
to attach per media metadata. From the steam layer it can then look like `struct to attach per media metadata. From the steam layer it can then look like
frameinfo* get_frame(unsigned num)` where `struct frameinfo` (not yet defined)
is something like `{ void* data; size_t size; struct metadata* meta; ...}` + struct frameinfo* get_frame(unsigned num)
-- link:ct[] 2008-10-06
...where `struct frameinfo` (not yet defined) is something like
[source, C]
----
{
void* data;
size_t size;
struct metadata* meta;
...
}
----
ct:: '2008-10-06'
Needs Work Needs Work
~~~~~~~~~~ ~~~~~~~~~~
Discussed in the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_stream_type_system[Apr.2011 developer meeting].
There are a lot details to be worked out for an actual implementation but we There are a lot details to be worked out for an actual implementation but we
agreed that we want this concept as proposed here. agreed that we basically want some concept as proposed here.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
I requested to keep it in `pending' state, in hope for more in-depth discussion
Ichthyostega:: 'Apr 2011'
[underline]#Many years later#, I still consider such a _type system_ for stream meta data
to be highly relevant and necessary as prerequisite for implementing the Builder.
Ichthyostega:: '2025-09-18'
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

43
doc/devel/rfc/SystematicMetadata.txt
View file

@ -3,16 +3,16 @@ SystematicMetadata
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Idea_
*Date* _Mo 08 Okt 2012 04:39:16 CEST_ |*Date* | _Mo 08 Okt 2012 04:39:16 CEST_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
_give a short summary of this proposal_ [red]#TODO# _give a short summary of this proposal_
******************************************************************************** ********************************************************************************
Lumiera is a metadata processing application: _Data_ is _media data_, and everything Lumiera is a metadata processing application: _Data_ is _media data_, and everything
@ -85,7 +85,8 @@ Tasks
* define the interaction API [yellow-background]#WIP# * define the interaction API [yellow-background]#WIP#
* scrutinise this concept to find the pitfalls [yellow-background]#WIP# * scrutinise this concept to find the pitfalls [yellow-background]#WIP#
* build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD# * build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD#
** the unit tests related to the _Diff System_ could be counted as such a demonstration +
Ichthyostega:: '2029-09-13'
Discussion Discussion
~~~~~~~~~~ ~~~~~~~~~~
@ -140,7 +141,7 @@ of defining a contract -- is turned into a local problem.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -150,8 +151,30 @@ Comments
-------- --------
//comments: append below //comments: append below
This RfC seems to be more like a vision statement; it contains some interesting
ideas, but not much of an actual proposal. At that time, presumably I had hoped
to spur further discussion or provoke some objection, in order to clarify what
we should be aiming at.
_During the following years,_ many of the ideas spelled out first in this text
found their way into the *Diff System*, now used as a foundation for connecting the
GUI to the Session core in Steam Layer. Especially the discussion of ``Alternatives''
seem to indicate that an essential motivation for this RfC was to find a viable
alternative to building the whole Application around a _central data model_ --
which is in essence what I later transformed into a practical concept with the
aforementioned ``Diff System''.
-> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«]
[underline]#Bottom line#: not sure what to do with this RfC; concepts explained therein
seem still highly relevant and central to what Lumiera is intended to become;
but this text does not fit into the format of an RfC, nor is there a community
of developers to discuss such a design vision appropriately.
Ichthyostega:: '2025-09-13'
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

78
doc/devel/rfc/TagCloudsOnResources.txt
View file

@ -1,81 +1,61 @@
Design Process : Tag Clouds for Resources Design Process : Tag Clouds
========================================= ===========================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2008-07-15_ |*Date* | _2008-07-15_
*Proposed by* link:PercivalTiglao[] |*Proposed by* | PercivalTiglao
------------------------------------- |====================================
Tag Clouds for Resources Tag Clouds for Resources
------------------------ ------------------------
Perhaps a Cloud of tags is unnecessary, but tagging resources similar to Perhaps a Cloud of Tags is unnecessary, but tagging resources similar to
Youtube or like Tag Clouds allows for efficient searching and filtering. Anyone Youtube or like Tag Clouds allows for efficient searching and filtering. Anyone
who uses the web would know how to use them. If a "Cloud of Tags" approach is who uses the web would know how to use them. If a ``Cloud of Tags'' approach is
used, then organizing the tags by some sort of frequency would be useful. IE: used, then organizing the tags by some sort of frequency would be useful:
the more a specific tag is used, the larger it gets, or perhaps the more often the more often a given tag is used, the larger it gets (or perhaps the more often
that tag is searched on. that tag is searched and referred).
Description
~~~~~~~~~~~
Tasks .Pros
~~~~~
Pros
~~~~
* Simple GUI Concept * Simple GUI Concept
* Eases management of resources with Search * Eases management of resources with Search
* Orthogonal to other resource management schemes like Folders * Orthogonal to other resource management schemes like Folders
Cons
~~~~
Alternatives
~~~~~~~~~~~~
Rationale
~~~~~~~~~
Comments Comments
-------- --------
* Note: I was inspired with this idea during an email conversation with Note: I was inspired with this idea during an email conversation with _Rick777_.
Rick777. -- link:PercivalTiglao[] [[DateTime(2008-07-17T14:29:57Z)]]
* Agreed, this is usefull. Also, more advanced config rules can make use of PercivalTiglao:: '2008-07-17T14:29:57Z'
such tags and wiring can depend on them, for example to route your dialogue
audio to another global bus than the music or ambiance.
-- link:Ichthyostega[] [[DateTime(2008-07-27T22:23:38Z)]]
Agreed, this is useful. Furthermore, advanced config rules can make use of
such tags and wiring can depend on them, for example to route your dialogue
audio to another global bus than the music or ambiance.
Ichthyostega:: '2008-07-27T22:23:38Z'
To confirm this point: tagged assets are considered important and kept on the main agenda
Ichthyostega:: '2025-09-15'
Conclusion Conclusion
---------- ----------
This Design Proposal is 'superseded' by a much more advanced proposal: This Design Proposal is _superseded_ by a much more advanced proposal:
link:/rfc/DelectusShotEvaluator.html[Delectus] link:/x/Delectus.html[Delectus]
(Dropping it doesn't mean disapproval) ^(Dropping it doesn't mean disapproval)^
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

54
doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt
View file

@ -1,14 +1,17 @@
Threads, Signals and important management tasks Design Process: Signal Handlers
=============================================== ===============================
//MENU: label Threads, Signals and important management tasks
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _Sat Jul 24 21:59:02 2010_ |*Date* | _Sat Jul 24 21:59:02 2010_
*Proposed by* Christian Thaeter <ct@pipapo.org> |*Proposed by* | Christian Thaeter <ct@pipapo.org>
------------------------------------- |====================================
[abstract] [abstract]
****************************************************************************** ******************************************************************************
@ -110,30 +113,9 @@ Tasks
// * item ... // * item ...
We have appstate::maybeWait() which already does such a loop. It needs to be We have appstate::maybeWait() which already does such a loop. It needs to be
extended by the proposed things above. extended to install signal handlers and perform the actions proposed above.
[red]#TODO# Do we have a ticket for this essential feature already?
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
Cons
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not
@ -144,10 +126,11 @@ Rationale
This is rather common practice. I describe this here for Documentation purposes This is rather common practice. I describe this here for Documentation purposes
and to point out which details are not yet covered. and to point out which details are not yet covered.
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final) write some
Conclusion
----------
//conclusion: When approved (this proposal becomes a Final) write some
Without much ado: we need to care for this...
@ -158,7 +141,8 @@ Comments
.State -> Final .State -> Final
ichthyo wants this to be a dedicated thread (own subsystem) instead running in ichthyo wants this to be a dedicated thread (own subsystem) instead running in
the initial thread. Fixed this in the proposal above, this makes this accepted. the initial thread. Fixed this in the proposal above, this makes this accepted.
Do 14 Apr 2011 03:40:41 CEST Christian Thaeter <ct@pipapo.org>
Christian Thaeter:: 'Thu 14 Apr 2011 03:40:41 CEST' ~<ct@pipapo.org>~
//endof_comments: //endof_comments:

102
doc/devel/rfc/TimeHandling.txt
View file

@ -1,17 +1,17 @@
Design Process : Time Handling Design Process : Time Handling
============================== ==============================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _2007-06-21_ |*Date* | _2007-06-21_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
Time handling Handling of Time and Time Quantisation
------------- --------------------------------------
How to handle time values in the code and which policy to aply to the "current" How to handle time values in the code and which policy to apply
position to the ``current'' position
Description Description
@ -24,23 +24,26 @@ Description
* We use a set of library routines and convenience-methods to * We use a set of library routines and convenience-methods to
- Get time in different formats (fractional seconds, frame counts) - Get time in different formats (fractional seconds, frame counts)
- Calculate with time values (overloaded operators) - Calculate with time values (overloaded operators)
* Time measurement is zero based (of course :-? ) * Time measurement is zero based (of course 😁 )
. *Quantizing to a frame index or similar* . *Quantizing to a frame index or similar*
* Quantizing/rounding shall happen only once at a defined point in the * Quantizing/rounding shall happen only once at a defined point in the
calculation chain and, if in doubt, be done always as late as possible. calculation chain and, if in doubt, be done always as late as possible.
* Values needing to be quantized to time (grid) positions are calculated by * Values needing to be quantized to time (grid) positions are calculated by
half-way rounding, but the result should not depend on the actual applying a suitable rounding scheme uniformly, e.g. half-way rounding, but
zero-point of the scale (i.e. `floor(0.5+val)`, thus quant(0.5) yields 1, the result should not depend on the actual zero-point of the scale
quant(0.49) yields 0, quant(-0.5) yields 0 ) ** `floor(0.5+val)`
** `quant(0.5)` ⟼ 1
** `quant(0.49)` ⟼ 0
** `quant(-0.5)` ⟼ 0
. *Position of frames* . *Position of frames*
* Frame numbers are zero based and Frame 0 starts at time=0 (or whatever the * Frame numbers are zero based and Frame 0 starts at time≡0 (or whatever the
nominal start time is) nominal start time is)
* Each frame starts when the locator hits its lower border (inclusively) and * Each frame starts when the locator hits its lower border (inclusively) and
ends when the locator is on its upper border (exclusively) ends when the locator is on its upper border (exclusively)
image:{imgd}/Lumi.FramePositions1.png[] image:{imgd}/Lumi.FramePositions1.png[]
* When the locator snaps to frames this means it can be placed on the start * When the locator snaps to frames this means it can be placed on the start
positions of the frames solely positions of the frames solely
* When the locator is placed on such a start position, this means 'always' * When the locator is placed on such a start position, this means _always_
displaying the frame starting at this position, irrespective of playback displaying the frame starting at this position, irrespective of playback
direction. direction.
. *Current position for keyframe nodes and automation* . *Current position for keyframe nodes and automation*
@ -48,7 +51,7 @@ Description
frame base (which normally is the case), for each frame there is a well frame base (which normally is the case), for each frame there is a well
defined 'point of evaluation' time position, irrespective of the playback defined 'point of evaluation' time position, irrespective of the playback
direction direction
* There is no single best choice where to put this "POE", thus we provide a * There is no single best choice where to put this ``POE'', thus we provide a
switch switch
image:{imgd}/Lumi.FramePositions2.png[] image:{imgd}/Lumi.FramePositions2.png[]
- 'Point of evaluation' of the automation is in the middle of the timespan - 'Point of evaluation' of the automation is in the middle of the timespan
@ -62,17 +65,17 @@ image:{imgd}/Lumi.FramePositions2.png[]
Tasks Tasks
~~~~~ ^^^^^
* Figure out what has to be done when switching the "current position" policy * Figure out what has to be done when switching the ``current position''
on a existing project. policy for an existing project.
Alternatives Alternatives
~~~~~~~~~~~~ ^^^^^^^^^^^^
Leave everything as in Cinelerra2, i.e. show frames after the locator has Leave everything as in Cinelerra-2, i.e. show frames after the locator has
passed over them, behave different when playing backwards and set the keyframes passed over them, behave different when playing backwards and set the keyframes
on the position of the locator but use them on the frame actually to be shown on the position of the locator but use them on the frame actually to be shown
(which differs according to the playback direction but is always "one off"). (which differs according to the playback direction but is always ``one off'').
Why not? because it makes frame-precise working with keyframes a real pain and Why not? because it makes frame-precise working with keyframes a real pain and
even creates contradictory situations when you switch back and forward while even creates contradictory situations when you switch back and forward while
@ -87,55 +90,64 @@ long as possible and only quantize for rendering a given frame.
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
The intention is to make time handling and calculations as uniform and The intention is to make time handling and calculations as uniform and
"rational" as possible. We try to stick to the precise mathematical values and _deterministic_ as possible. We try to stick to the precise mathematical values
let the calculations just yield an result in an uniform manner, instead of and let the calculations just yield an result in an uniform manner, instead of
sticking to "simple" values like frame counts or even a session-wide frame rate relying on ``simple'' values like frame counts or even a session-wide frame rate
. Time and interval calculations are tricky. Solve this question once and be . Time and interval calculations are tricky. Solve this question once and be done.
done. . Rounding is always dangerous, rounded values are by no means the ``cleaner'' values.
. Rounding is always dangerous, rounded values are not the more "clean" values.
The floor-rounding rule is chosen, because the length of an interval after The floor-rounding rule is chosen, because the length of an interval after
quantisation should not depend on the position in relation to the zero point. quantisation should not depend on the position in relation to the zero point.
The usual mathematical rounding behaves "symmetrical" to the zero point, The usual mathematical rounding behaves _symmetrical_ to the zero point,
which could yield a different length after quantisation if an interval which could yield a different length after quantisation if an interval
contains the zero point contains the zero point
. This is based on the analogy with real film running through a film projector . This is based on the analogy with real film running through a film projector
(or the usual fencepost problem) (or the usual »fence post problem«)
. While using the actual position of the locator as the "current" position for . While using the actual position of the locator as ``the current'' position for
keyframes seems more natural at first, it crates problems when mixing footage keyframes seems more natural at first, it crates problems when mixing footage
with different framerate or when using a low-framerate proxy footage. with different framerate or when using a low-framerate proxy footage.
Comments Comments
~~~~~~~~ ~~~~~~~~
* This is the summary of a discussion cehteh, Plouj and ichthyo just had on * This is the summary of a discussion _cehteh_, _Plouj_ and _ichthyo_ just had on IRC.
irc.
-- link:Ichthyostega[] [[DateTime(2007-06-21T05:12:03Z)]]
* We use GAVL now (needs to be included in the build system) Ichthyostega:: '2007-06-21T05:12:03Z'
-- link:ct[] [[DateTime(2008-03-05T16:19:22Z)]]
* I've tidied up this old design proposal, we could make it final now. I've * We use lib GAVL now (needs to be included in the build system)
ct:: '2008-03-05T16:19:22Z'
* I have tidied up this old design proposal, we could make it final now. I've
changed the rounding rule, please check if it's OK. In the original proposal, changed the rounding rule, please check if it's OK. In the original proposal,
we wanted to use the common mathematical rounding rule, i.e. round(-x) = - we wanted to use the common mathematical rounding rule, i.e. round(-x) = -
round(x) . I changed this, because of the danger of interval lengths or round(x) . I changed this, because of the danger of interval lengths or
alignment to "jump" dependant on the position in relation to the time zero alignment to ``jump'' depending on the position in relation to the time zero
point. point.
-- link:Ichthyostega[] [[DateTime(2008-10-04T22:47:54Z)]]
* Looks ok to me, maybe we should wrap up the gavl time handling in a very thin Ichthyostega:: '2008-10-04T22:47:54Z'
* Looks ok to me, maybe we should wrap up the Gavl time handling in a very thin
layer to unify our time functions and then cast this again into a layer to unify our time functions and then cast this again into a
authoritative testsuite/specification. Anyways I think this can be finalized. authoritative testsuite/specification. Anyways I think this can be finalized.
-- link:ct[] [[DateTime(2008-10-06T06:44:21Z)]]
ct:: '2008-10-06T06:44:21Z'
Conclusion Conclusion
~~~~~~~~~~ ~~~~~~~~~~
* The adapted form of this proposal was *accepted* by October.2008 developer * The adapted form of this proposal was __`accepted'__ by the
meeting. link:{ldoc}/devel/meeting_summary/2008-10-10.html#_time_handling[October.2008 developer meeting].
* The proposed thin library layer to centralize time calculations shall be * The proposed thin library layer to centralize time calculations shall be
added on demand. When doing so, we need to add thorough test coverage for added on demand. When doing so, we need to add thorough test coverage for
time calculations too. time calculations too.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] TIP: this library layer was first implemented as a collection of functions,
but has been transformed into a system of adaptor types meanwhile,
so that any conversion into a _Time Code_ also has to go through
a suitable _quantisation_ into a predefined _time grid_.
-> link:{ldoc}/design/architecture/time/index.html[read more here...]
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

122
doc/devel/rfc/TimelineSequenceOutput.txt
View file

@ -1,9 +1,14 @@
[grid="all"] Design Process : Timelines
`------------`----------------------- ==========================
*State* _Final_
*Date* _2008-11-03_ //MENU: label Timelines and Sequences in the high-level-Model
*Proposed by* link:Ichthyostega[]
------------------------------------- [options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _2008-11-03_
|*Proposed by* | Ichthyostega
|====================================
.Summary .Summary
@ -18,8 +23,9 @@ Relation of Project, Timeline(s), Sequence(s) and Output generation
------------------------------------------------------------------- -------------------------------------------------------------------
In the course of our discussions it meanwhile became clear, that Lumiera will In the course of our discussions it meanwhile became clear, that Lumiera will
show multiple _timeline-like_ views within one project. Similarly it's clear show multiple _timeline-like_ views within one project. Furthermore, support
now that we will support link:EDLsAreMetaClips.html[nested Sequences as meta-clips]. for link:{rfc}/EDLsAreMetaClips.html[nested Sequences as meta-clips] is
considered an essential goal.
The purpose of this entry is to try to settle on some definitions The purpose of this entry is to try to settle on some definitions
and clarify the relationships between these concepts. and clarify the relationships between these concepts.
@ -33,7 +39,7 @@ Project:: the top-level context in which all edit work is done over an
Session:: the current in-memory representation of the Project when opened Session:: the current in-memory representation of the Project when opened
within an instance of Lumiera. This is an implementation-internal term. For within an instance of Lumiera. This is an implementation-internal term. For
the GUI and the users POV we should always prefer the term "Project" for the the GUI and the users POV we should always prefer the term »Project« for the
general concept. general concept.
Timeline:: the top level element within the Project. It is visible within a Timeline:: the top level element within the Project. It is visible within a
@ -41,8 +47,9 @@ Timeline:: the top level element within the Project. It is visible within a
arrangement of media objects, resolved to a finite time axis, to be rendered arrangement of media objects, resolved to a finite time axis, to be rendered
for output or viewed in a Monitor (viewer window). Timeline(s) are top-level for output or viewed in a Monitor (viewer window). Timeline(s) are top-level
and may not be further combined. A timeline is comprised of: and may not be further combined. A timeline is comprised of:
* a time axis in abolute time (WIP: not clear if this is an entity or just a * a time axis in absolute time +
conceptual definition) ^([purple]#WIP#: not clear if this is an entity or just a
conceptual definition)^
* a _PlayController_ * a _PlayController_
* a list of global _Pipes_ representing the possible outputs (master * a list of global _Pipes_ representing the possible outputs (master
busses) busses)
@ -50,8 +57,8 @@ Timeline:: the top level element within the Project. It is visible within a
nested Sequences nested Sequences
Timeline View:: a view in the GUI featuring a given timeline. There might be Timeline View:: a view in the GUI featuring a given timeline. There might be
multiple views of the same timeline, all sharing the same !PlayController. A multiple views of the same timeline, all sharing the same `PlayController`.
proposed extension is the ability to _focus_ a timeline view to a A proposed extension is the ability to _focus_ a timeline view to a
sub-Sequence contained within the top-level sequence of the underlying sub-Sequence contained within the top-level sequence of the underlying
Timeline. (Intended for editing meta-clips) Timeline. (Intended for editing meta-clips)
@ -81,13 +88,13 @@ PlayController:: coordinating playback, cueing and rewinding of a
media data needed for playback. Actually, the implementation of the media data needed for playback. Actually, the implementation of the
PlayController(s) is assumed to live in the application core. PlayController(s) is assumed to live in the application core.
RenderTask:: basically a !PlayController, but collecting output RenderTask:: basically a `PlayController`, but collecting output
directly, without moving a !PlayheadCursor (maybe a progress indicator) and directly, without moving a `PlayheadCursor` (maybe a progress indicator) and
not operating in a timed fashion, but freewheeling or in background mode not operating in a timed fashion, but freewheeling or in background mode
Monitor/Viewer:: a viewer window to be attached to a timeline. When attached, a Monitor/Viewer:: a viewer window to be attached to a timeline. When attached, a
monitor reflects the state of the timeline's PlayController, and it attaches monitor reflects the state of the timeline's `PlayController`, and it attaches
to the timeline's global pipes by stream-type match, showing video as monitor to the Timeline's global pipes by stream-type match, showing video as monitor
image and sending audio to the system audio port (Alsa or Jack). Possible image and sending audio to the system audio port (Alsa or Jack). Possible
extensions are for a monitor to be able to attach to probe points within the extensions are for a monitor to be able to attach to probe points within the
render network, to show a second stream as (partial) overlay for comparison, render network, to show a second stream as (partial) overlay for comparison,
@ -108,36 +115,37 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline,
same time we may have multiple views of the same timeline. same time we may have multiple views of the same timeline.
* all playhead displays within different views linked to the _same_ * all playhead displays within different views linked to the _same_
underlying timeline are effectively linked together, as are all GUI widgets underlying timeline are effectively linked together, as are all GUI widgets
representing the same !PlayController owned by a single timeline. representing the same `PlayController` owned by a single timeline.
* I am proposing to do it this way per default, because it seems to be a best * I am proposing to do it this way per default, because it seems to be a best
match to the users expectation (it is well known that multiple playback match to the users expectation (it is well known that multiple playback
cursors tend to confuse the user) cursors tend to confuse the user)
* the timeline view is modeled to be a sub-concept of "timeline" and thus can * the timeline view is modelled to be a sub-concept of ``Timeline'' and thus can
stand-in. Thus, to start with, for the GUI it doesn't make any difference if stand-in. Thus, to start with, for the GUI it doesn't make any difference if
it talks to a timeline view or a timeline. it talks to a timeline view or a timeline.
* each timeline _refers_ to a (top-level) sequence. I.e. the sequences * each timeline _refers_ to a (top-level) sequence. I.e. the sequences
themselves are owned by the project, and theoretically it's possible to refer themselves are owned by the Project, and theoretically it's possible to refer
to the same sequence from multiple timelines directly and indirectly. to the same sequence from multiple timelines directly and indirectly.
* besides, it's also possible to create multiple independent timelines -— in * besides, it's also possible to create multiple independent timelines -- in
an extreme case even so when referring to the same top-level sequence. This an extreme case even so when referring to the same top-level sequence. This
configuration gives the ability to play the same arrangement in parallel with configuration gives the ability to play the same arrangement in parallel with
multiple independent play controllers (and thus independent playhead multiple independent play controllers (and thus independent playhead
positions) positions)
* to complement this possibilities, I'd propose to give the _timeline view_ * to complement this possibilities, I'd propose to give the _Timeline View_
the possibility to be focussed (re-linked) to a sub-sequence. This way, it the possibility to be focused (re-linked) to a sub-sequence. This way, it
would stay connected to the main play control, but at the same time show a would stay connected to the main play control, but at the same time show a
sub-sequence _in the way it will be treated as embedded within the top-level sub-sequence _in the way it will be treated as embedded within the top-level
sequence._ This would be the default operation mode when a meta-clip is sequence._ This would be the default operation mode when a meta-clip is
opened (and showed in a separate tab with such a linked timeline view). The opened (and showed in a separate tab with such a linked timeline view). The
reason for this proposed handling is again to give the user the least reason for this proposed handling is again to give the user the least
surprising behaviour. Because, when -— on the contrary -— the surprising behaviour. Because, when -- on the contrary -- the
sub-sequence would be opened as separate timeline, a different absolute time sub-sequence would be opened as separate timeline, a different absolute time
position and a different signal routing may result; doing such should be position and a different signal routing may result; doing such should be
reserved for advanced use, e.g. when multiple editors cooperate on a single reserved for advanced use, e.g. when multiple editors cooperate on a single
project and a sequence has to be prepared in isolation prior to being project and a sequence has to be prepared in isolation prior to being
integrated in the global sequence (featuring the whole movie). integrated in the global sequence (featuring the whole movie).
* one rather unconventional feature to be noted is that the _tracks_ (forks) are * one rather unconventional feature to be noted is that the _Tracks_
within the _sequences_ and not on the level of the global busses as in most (actually a _»Fork«_ ≙ a tree of Tracks) are
within the _Sequences_ and not on the level of the global busses as in most
other video and audio editors. The rationale is that this allows for fully other video and audio editors. The rationale is that this allows for fully
exploiting the tree-structure, even when working with large and compound exploiting the tree-structure, even when working with large and compound
projects, it allows for sequences being local clusters of objects including projects, it allows for sequences being local clusters of objects including
@ -149,12 +157,12 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline,
Tasks Tasks
^^^^^ ^^^^^
* Interfaces on the Stage and Steam level need to be fully specified. * Interfaces on the Stage and Steam level need to be fully specified.
Especially, "Timeline" is now promoted to be a new top-level entity within Especially, »Timeline« is now promoted to be a new top-level entity within
the Session the Session
* communication between the PlayController(s) and the GUI need to be worked * communication between the PlayController(s) and the GUI need to be worked
out out
* the stream type system, which is needed to make this default connection * the stream type system, which is needed to make this default connection
scheme work, currently is just planned and drafted. Doing a exemplaric scheme work, currently is just planned and drafted. Doing a exemplarily
implementation for GAVL based streams is on my immediate agenda and should implementation for GAVL based streams is on my immediate agenda and should
help to unveil any lurking detail problems in this design. help to unveil any lurking detail problems in this design.
* with the proposed focusing of the timeline view to a sub-sequence, there are * with the proposed focusing of the timeline view to a sub-sequence, there are
@ -171,8 +179,7 @@ Pros
^^^^ ^^^^
* this design naturally scales down to behave like the expected simple default * this design naturally scales down to behave like the expected simple default
case: one timeline, one track, simple video/audio out. case: one timeline, one track, simple video/audio out.
* but at the same time it allows for bewildering complex setups for advanced * but at the same time it allows for bewildering complex setups for advanced use
use
* separating signal flow and making the fork (``track tree'') local to the sequence * separating signal flow and making the fork (``track tree'') local to the sequence
solves the problem how to combine independent sub-sequences into a compound solves the problem how to combine independent sub-sequences into a compound
session session
@ -181,9 +188,8 @@ Pros
Cons Cons
^^^^ ^^^^
* it is complicated * it is complicated
* it is partially uncommon, but not fully revolutionary, and thus may be * it is partially uncommon, but not fully revolutionary, and thus might be misleading.
misleading. * the control handling in the GUI can become difficult (focus? key shortcuts?)
* the control handling in GUI can become difficult (focus? key shortcuts?)
* the ability to have both separate timelines and timeline views can be very * the ability to have both separate timelines and timeline views can be very
confusing. We really need to think about suitable UI design confusing. We really need to think about suitable UI design
* because the signal flow is separated from the tracks, we need to re-design * because the signal flow is separated from the tracks, we need to re-design
@ -194,13 +200,13 @@ Cons
Alternatives Alternatives
^^^^^^^^^^^^ ^^^^^^^^^^^^
* just one session, a list of tracks and don't cover the organisation of * just one Session, a list of Tracks and do not attempt to cover the organisation
larger projects at all. of larger projects at all.
* allow only linear sequences with one track, not cluster-like sequences * allow only linear Sequences with one Track, not cluster-like sequences
* make the tracks synonymous with the global busses as usual. Use an * make the Tracks synonymous with the global busses as usual. Use an
allocation mechanism when "importing" separate sub-projects allocation mechanism when ``importing'' separate sub-projects
* rather make compound projects a loosely coupled collection of stand-alone * rather make compound projects a loosely coupled collection of stand-alone
projects, which are just "played" in sequence. Avoid nested referrals. projects, which are just ``played'' in sequence. Avoid nested referrals.
* don't build nested structures, rather build one large timeline and provide * don't build nested structures, rather build one large timeline and provide
flexible means for hiding and collapsing parts of it. flexible means for hiding and collapsing parts of it.
@ -210,7 +216,7 @@ Rationale
Obviously, the usual solution was found to be limiting and difficult to work Obviously, the usual solution was found to be limiting and difficult to work
with in larger projects. On the other hand, the goal is not to rely on external with in larger projects. On the other hand, the goal is not to rely on external
project organisation, rather to make Lumiera support more complicated project organisation, rather to make Lumiera support more complicated
structures without complicated "import/export" rules or the need to create a structures without complicated ``import/export'' rules or the need to create a
specific master-document which is different from the standard timeline. The specific master-document which is different from the standard timeline. The
solution presented here seems to be more generic and to require fewer treating solution presented here seems to be more generic and to require fewer treating
of special cases than the conventional approach would be. of special cases than the conventional approach would be.
@ -224,17 +230,17 @@ Comments
GUI handling could make use of expanded view features like ; GUI handling could make use of expanded view features like...
* drop down view of track, that just covers over what was shown below. This may * drop down view of track, that just covers over what was shown below. This may
be used for quick precise looks, or simple editions, or clicking on a subtrack be used for quick precise looks, or simple editions, or clicking on a subtrack
to burrow further down. to burrow further down.
* show expanded trackview in new tab. This creates another tabbed view which * show expanded trackview in new tab. This creates another tabbed view which
makes the full window are available for a "magnified" view. It is very easy makes the full window are available for a ``magnified'' view. It is very easy
to jump back to the main track view, or to other view tabs (edit points). to jump back to the main track view, or to other view tabs (edit points).
* The main track view could show highlights for "currently created" views/edit * The main track view could show highlights for ``currently created'' views/edit
points, and whether they are currently being used or not (active/inactive). points, and whether they are currently being used or not (active/inactive).
* Each tab view could show a miniature view of the main track view (similar * Each tab view could show a miniature view of the main track view (similar
@ -246,36 +252,38 @@ GUI handling could make use of expanded view features like ;
positioned very close to the point on the track that was clicked on to positioned very close to the point on the track that was clicked on to
trigger the drop down. This close proximity means that the mouse motion trigger the drop down. This close proximity means that the mouse motion
distance to commonly used (next) options, is very minimal. Icons for common distance to commonly used (next) options, is very minimal. Icons for common
options might include ; remove drop down view, create new tab view (active options might include; remove drop down view, create new tab view (active
edit point), create edit point (but don't open a new tab - just create the edit point), create edit point (but don't open a new tab -- just create the
highlight zone on the track), temporarily "maximise" the drop down view to highlight zone on the track), temporarily ``maximise'' the drop down view to
the full window size (ie show the equivalent tab view in the current window). the full window size (ie show the equivalent tab view in the current window).
* some of the "matrix" type view methods commonly used in spreadsheets, like * some of the ``matrix type'' view methods commonly used in spreadsheets, like
lock horizontal and vertical positions (above OR Below, left OR Right of lock horizontal and vertical positions (above _or_ below, left _or_ right of
marker) for scrolling - this can also be used for determining limits of marker) for scrolling -- this can also be used for determining limits of
scroll. scroll.
* monitor view could include a toggle between show raw original track , show * monitor view could include a toggle between show raw original track , show
zoomed and other camera/projector render, or show full rendering including zoomed and other camera/projector render, or show full rendering including
effects - this ties in with the idea of being able to link a monitor with effects -- this ties in with the idea of being able to link a monitor with
viewing anywhere in the node system - but is able to be swiftly changed viewing anywhere in the node system -- but is able to be swiftly changed
within the monitor view by icons mounted somewhere on each of the respective within the monitor view by icons mounted somewhere on each of the respective
monitors' perimeter. monitors' perimeter.
* the trackview itself, could be considered as a subview of a * the trackview itself, could be considered as a subview of a
total-timeline-trackview, or some other method of "mapping out" the full total-timeline-trackview, or some other method of ``mapping out'' the full
project (more than one way of mapping it out may be made as optional/default project (more than one way of mapping it out may be made as optional/default
views). views).
* this set of features are going to be very exciting and convenient to work This set of features is going to be very exciting and convenient to work
with - a sort of google earth feature for global sized projects. with -- a sort of google earth feature for global sized projects.
Tree:: '2008-12-19 22:58:30'
Tree 2008-12-19 22:58:30
Final Final
~~~~~ ~~~~~
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

17
doc/devel/rfc/TodoLists.txt
View file

@ -1,9 +1,9 @@
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Parked_ |*State* | _Parked_
*Date* _2008-03-05_ |*Date* | _2008-03-05_
*Proposed by* link:ct[] |*Proposed by* | ct
------------------------------------- |====================================
Todo Lists Todo Lists
---------- ----------
@ -44,6 +44,7 @@ Rationale
Comments Comments
-------- --------
We decided to use a Tiddlywiki for now until this is further worked out We decided to use a Tiddlywiki for now until this is further worked out
-- link:ct[] [[DateTime(2008-03-08T03:38:50Z)]]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] ct:: '2008-03-08T03:38:50Z'
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

50
doc/devel/rfc/UnitTests_Python.txt
View file

@ -2,12 +2,12 @@ Design Process : Unit Tests Python
================================== ==================================
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Dropped_ |*State* | _Dropped_
*Date* _2007-06-17_ |*Date* | _2007-06-17_
*Proposed by* link:Ichthyostega[] |*Proposed by* | Ichthyostega
------------------------------------- |====================================
UnitTests in Python UnitTests in Python
@ -20,7 +20,7 @@ Cinelerra Code via SWIG
Description Description
~~~~~~~~~~~ ~~~~~~~~~~~
Define Test classes in Python, using e.g. the link:PyUnit[] framework of the Define Test classes in Python, using e.g. the PyUnit framework of the
Python Standard lib. The SWIG compiler can generate wrapper code automatically, Python Standard lib. The SWIG compiler can generate wrapper code automatically,
so we can access the C++ Classes and Facilities of Cinelerra as Python Modules so we can access the C++ Classes and Facilities of Cinelerra as Python Modules
and Classes. The Classes to be tested in Cinelerra need to provide some and Classes. The Classes to be tested in Cinelerra need to provide some
@ -29,8 +29,7 @@ the whole Test driven aproach).
Tasks Tasks
~~~~~ ^^^^^
* Find out how the SWIG generated wrappers play together with Python's List * Find out how the SWIG generated wrappers play together with Python's List
and Map types. Without the ability to use the latter in the tests, this and Map types. Without the ability to use the latter in the tests, this
whole proposal is rather pointless. whole proposal is rather pointless.
@ -39,9 +38,8 @@ Tasks
Pros Pros
~~~~ ^^^^
Programming Unit and Self tests in a Scripting language facilitates this task.
Programming Unit and Self tests in a Scripting language facillates this task.
The X-Language bindings are quite usable today. As a side effect, it helps to The X-Language bindings are quite usable today. As a side effect, it helps to
get a clean program structure, because the tests need some Interface and/or get a clean program structure, because the tests need some Interface and/or
some object factories to create the test candidates. Python is proposed, some object factories to create the test candidates. Python is proposed,
@ -49,14 +47,11 @@ because it is fairly mainstream, has a flat learning curve and but is
moderately modern and functional-style at the same time. moderately modern and functional-style at the same time.
Cons Cons
~~~~ ^^^^
* Adds to the complexity * Adds to the complexity
* Some old-style hackers have a quite distinct aversion against Python * Some old-style hackers have a quite distinct aversion against Python
Alternatives
~~~~~~~~~~~~
Rationale Rationale
~~~~~~~~~ ~~~~~~~~~
@ -64,19 +59,26 @@ Rationale
Why am I proposing this? Out of lazyness. Python is there, many devs (on linux) Why am I proposing this? Out of lazyness. Python is there, many devs (on linux)
have some Python skills, SWIG is not overly complicated to use. have some Python skills, SWIG is not overly complicated to use.
And last but not least: just to get the discussion going... ;-) And last but not least: just to get the discussion going... 😉
Comments Comments
-------- --------
* I'd rather consider to use some embedded language in cinelerra which we can I'd rather consider to use some embedded language in cinelerra which we can
use to drive tests, should be something smaller and more sane than python. use to drive tests, should be something smaller and more sane than python.
Needs certainly more discussion. For simple unit tests some C/C++ harness and needs certainly more discussion. For simple unit tests some C/C++ harness and
bit shell scripting would suffice, I really want to integrate this with bit shell scripting would suffice, I really want to integrate this with
https://nobug.pipapo.org/[NoBug]. https://nobug.pipapo.org/[NoBug].
-- link:ct[] [[DateTime(2007-06-17T17:32:27Z)]]
ct:: '2007-06-17T17:32:27Z'
Since Lumiera is a separate project now, we do no longer need to ``hook''
into existing code ``from the outside''. Rather, we have created our own
lightweight unit testing framework in C++.
This RfC was link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_unit_tests_in_python[dropped 3/08]
ichthyo:: '2008-03-06'
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

41
doc/devel/rfc/UseCases.txt
View file

@ -1,15 +1,18 @@
[grid="all"] Design Process: Use Cases
`------------`----------------------- =========================
*State* _Parked_
*Date* _2008-10-31_ [options="autowidth"]
*Proposed by* link:Ichthyostega[] |====================================
------------------------------------- |*State* | _Parked_
|*Date* | _2008-10-31_
|*Proposed by* | Ichthyostega
|====================================
Use Case analysis Use Case analysis
----------------- -----------------
The only way to defeat "featuritis" is to build upon a coherent design -- The only way to defeat ``featuritis'' is to build upon a coherent design --
+ +
which in turn relies upon a more or less explicit understanding what the which in turn relies upon a more or less explicit understanding what the
application should be like, and the way the prospective user is thought to work application should be like, and the way the prospective user is thought to work
@ -287,24 +290,24 @@ Comments
.Template e.g. for regular TV series .Template e.g. for regular TV series
Constraints to fit all contents within fixed timeline, cover topic, select Constraints to fit all contents within fixed timeline, cover topic, select
collage of iconic scenes from archived and collected footage. Update intro and collage of iconic scenes from archived and collected footage. Update intro and
credit roll for each episode. Add in stopmotion, and 3D model animations with credit roll for each episode. Add in stop motion, and 3D model animations with
vocal commentaries. Gather together separate items from "outworkers". vocal commentaries. Gather together separate items from ``outworkers''.
Tree:: '2008-12-27 08:36:36' Tree:: '2008-12-27 08:36:36'
.State -> Parked
Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_use_cases[April.2011 developer meeting].
We have to revisit this, possibly someone (or a group) who wants to work on the workflow. +
For now it is __parked__ until revisited.
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
//endof_comments: //endof_comments:
Parked
~~~~~~
We have to revisit this, possibly someone (or a group) who wants to work on
the workflow. For now its parked until revisited.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter ''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

34
doc/devel/rfc/VersionNumberScheme.txt
View file

@ -3,12 +3,12 @@ VersionNumberScheme
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Final_ |*State* | _Final_
*Date* _Mi 09 Mär 2011 02:00:41 CET_ |*Date* | _Mi 09 Mär 2011 02:00:41 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
[abstract] [abstract]
******************************************************************************** ********************************************************************************
@ -142,7 +142,7 @@ when to use what version number.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -155,11 +155,27 @@ Comments
.State -> Final .State -> Final
considered common practice considered common practice
Do 14 Apr 2011 03:46:07 CEST Christian Thaeter <ct@pipapo.org> Christian Thaeter:: 'Thu 14 Apr 2011 03:46:07 CEST' ~<ct@pipapo.org>~
💡 +
[underline]#Please Note#: our Git branching model has been switched to
link:{ldoc}/technical/code/GitBranching.html[Git-flow] recently. On occasion
of that change, I wrote two helper scripts
- 'admin/buildVersion.py' extracts version info from the latest preceding
Git tag, and additionally allows to _bump some component_ of the version-ID
- 'admin/setVersion' edits a hard-wired small selection of known documents
in the tree with `sed` to update a version-ID
These are both related to version numbers, and also our conventions
for Git-flow refer directly to this RfC.
Ichthyostega:: '2025-09-15'
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

27
doc/devel/rfc/WebsiteNavigation.txt
View file

@ -3,12 +3,12 @@ WebsiteNavigation
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Draft_ |*State* | _Draft_
*Date* _Mi 08 Dez 2010 11:32:32 CET_ |*Date* | _Mi 08 Dez 2010 11:32:32 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
[abstract] [abstract]
******************************************************************************** ********************************************************************************
@ -131,7 +131,7 @@ these issues.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -150,4 +150,17 @@ This is covered by another RfC.
Ichthyostega:: 'So 07 Okt 2012 07:30:17 CEST' ~<prg@ichthyostega.de>~ Ichthyostega:: 'So 07 Okt 2012 07:30:17 CEST' ~<prg@ichthyostega.de>~
This RfC is in the same state as _many years ago_ -- and frankly, I do not know
what to do with it. One part (the Menu generator script) was implemented.
The other parts, which are tagging and cross-link resolution were proposed
and found general agreement at that time, but no-one did care for expanding
them into an implementation concept.
Meanwhile, I am working alone and can thus afford to keep the infrastructure
at the bare minimum, just enough for me to cope. Similar as with the
link:{rfc}/WebsiteSupportMarkup.html#_comments[cross-links and support markup].
However, I consider those topics still something for a group of people to decide.
Ichthyostega:: '2025-09-18'
//endof_comments: //endof_comments:

26
doc/devel/rfc/WebsiteSupportMarkup.txt
View file

@ -3,12 +3,12 @@ WebsiteSupportMarkup
// please don't remove the //word: comments // please don't remove the //word: comments
[grid="all"] [options="autowidth"]
`------------`----------------------- |====================================
*State* _Idea_ |*State* | _Draft_
*Date* _Sa 06 Okt 2012 16:47:44 CEST_ |*Date* | _Sa 06 Okt 2012 16:47:44 CEST_
*Proposed by* Ichthyostega <prg@ichthyostega.de> |*Proposed by* | Ichthyostega <prg@ichthyostega.de>
------------------------------------- |====================================
******************************************************************************** ********************************************************************************
.Abstract .Abstract
@ -221,7 +221,7 @@ can be considered a one-time investment.
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:
@ -246,7 +246,17 @@ those stuff which matters in practice.
Ichthyostega:: 'So 07 Okt 2012 07:31:25 CEST' ~<prg@ichthyostega.de>~ Ichthyostega:: 'So 07 Okt 2012 07:31:25 CEST' ~<prg@ichthyostega.de>~
.State -> Draft
Unfortunately, nothing has happened with this RfC ever since; the reason is
lack of developer capacity. Since this RfC is already fairly detailed, and
no significant objections were pointed out, I am promoting this RfC to
a __"Draft"__ now, yet leave it pending. Same as with the
link:WebsiteNavigation.html#_comments[RfC: Website Navigation].
Ichthyostega:: '2025-09-18'
//endof_comments: //endof_comments:
'''' ''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

4
doc/devel/template/YYYY-MM-DD-developerMeetingSummary.txt
View file

@ -17,12 +17,14 @@ _Summary written by XXXXX_
Recurring Topics Recurring Topics
---------------- ----------------
Discussion of open link:{ldoc}/devel/rfc.html[design process] drafts. Discussion of open link:/x/DesignProcess.html[design process] drafts.
Prop1 Prop1
~~~~~ ~~~~~
////
link:{rfc}/SomeProposal[descriptive name] link:{rfc}/SomeProposal[descriptive name]
////
Summary what issues are discussed Summary what issues are discussed
..Details.. ..Details..

2
doc/devel/template/new_rfc.sh
View file

@ -62,7 +62,7 @@ Rationale
//Conclusion //Conclusion
//---------- //----------
//conclusion: When approbate (this proposal becomes a Final) //conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process: // write some conclusions about its process:

2
doc/technical/code/index.txt
View file

@ -46,7 +46,7 @@ Guidelines
//// ////
'''' ''''
* also see the link:{ldoc}/devel/rfc/index.html[Design Process] for ongoing discussions * also see the link:/x/DesignProcess.html[Design Process] for ongoing discussions
* see the link:/devs-vault/[Developers Vault] for frequently used developer's resources * see the link:/devs-vault/[Developers Vault] for frequently used developer's resources

42
doc/technical/infra/MenuGen.txt
View file

@ -178,27 +178,27 @@ supported placement directives
[options="header", width="70%",cols="^m,<m,s<",frame="topbot",grid="all"] [options="header",cols="^m,2<m,3<",frame="topbot",grid="all"]
`------------------------`------------------------------------`--------------------------------------------------- |==============================================================
internal DSL Asciidoc source | internal DSL |Asciidoc source |
Node(<id>) -- discover `id.txt` -- create new node or retrieve existing node | Node(<id>) |-- discover `id.txt` -- | create new node or retrieve existing node
linkChild(id) basic function for attaching child node | linkChild(id) | | basic function for attaching child node
linkParent(id) basic function to attach below parent | linkParent(id) | | basic function to attach below parent
putChildLast(id) [attach] child <id> move child to current end of list | putChildLast(id) |[attach] child <id> | move child to current end of list
appendChild(id) [append] child <id> | appendChild(id) |[append] child <id> |
putChildFirst(id) move child to current list start | putChildFirst(id) | | move child to current list start
prependChild(id) prepend [child] <id> | prependChild(id) |prepend [child] <id> |
putChildAfter(id,ref) [attach|put] child <id> after <ref> move child after the given ref entry | putChildAfter(id,ref) |[attach\|put] child <id> after <ref>| move child after the given ref entry
link(url[,id][,label]) [child <id>] link ::<url>[<label>] attach an entry, holding an external link | link(url[,id][,label]) |[child <id>] link ::<url>[<label>] | attach an entry, holding an external link
Node(<id>,label=<lbl>) label|title <lbl> define the visible text in the menu entry | Node(<id>,label=<lbl>) |label\|title <lbl> | define the visible text in the menu entry
sortChildren() sort [children] sort all children currently in list | sortChildren() |sort [children] | sort all children currently in list
enable(False) off|disable|deactivate make node passive; any children/parents added later are ignored | enable(False) |off\|disable\|deactivate | make node passive; any children/parents added later are ignored
enable([True]) on|active|activate make node active again (this is the default) | enable([True]) |on\|active\|activate | make node active again (this is the default)
detach() detach cut away any parents and children, disable the node | detach() |detach | cut away any parents and children, disable the node
discover(srcdirs=...) include dir <token>[,<token>] instead of current dir, retrieve children from other dirs (relative) | discover(srcdirs=...) |include dir <token>[,<token>] | instead of current dir, retrieve children from other dirs (relative)
discover(includes=...) include <token>[,<token>] explicitly use the listed elements as children | discover(includes=...) |include <token>[,<token>] | explicitly use the listed elements as children
discover(excludes=...) exclude <token>[,<token>] after discovering, filter names matching the <token> (without extension) | discover(excludes=...) |exclude <token>[,<token>] | after discovering, filter names matching the <token> (without extension)
-------------------------------------------------------------------------------------------------------------------- |==============================================================
commandline options commandline options

2
doc/technical/overview.txt
View file

@ -480,7 +480,7 @@ and disjunction.
Locking Locking
~~~~~~~ ~~~~~~~
General purpose Locking is based on object monitors. Performance critical code General purpose Locking is based on object monitors. Performance critical code
in the Render Engine relies on ''Atomics'', or may use futures and further in the Render Engine relies on __»Atomics«__, or may use futures and further
synchronisation primitives through the wrappers of the C++ standard library. synchronisation primitives through the wrappers of the C++ standard library.
NOTE: At the time when Lumiera project started, the standard library provided NOTE: At the time when Lumiera project started, the standard library provided

2
doc/technical/vault/scheduler.txt
View file

@ -7,7 +7,7 @@ ordered by priority and observing specific timing constraints.
NOTE: Subject to [yellow-background]#active design and implementation# work as of 10/2023 NOTE: Subject to [yellow-background]#active design and implementation# work as of 10/2023
Work-in-progress documentation can be found in the Work-in-progress documentation can be found in the
link:imp/PlaybackVerticalSlice.html[DevWiki: PlaybackVerticalSlice] link:/x/imp/PlaybackVerticalSlice.html[DevWiki: PlaybackVerticalSlice]
About Jobs About Jobs

99
wiki/thinkPad.ichthyo.mm
View file

@ -163213,20 +163213,42 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
<icon BUILTIN="button_ok"/> <icon BUILTIN="button_ok"/>
</node> </node>
</node> </node>
<node COLOR="#338800" CREATED="1757113762879" ID="ID_1196939838" MODIFIED="1757113800674" TEXT="x/rfc">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1757113768640" ID="ID_1915414109" MODIFIED="1757113785504" TEXT="auch RfC-Links sollte man besser abstrahieren">
<icon BUILTIN="yes"/>
</node>
<node CREATED="1757113803372" ID="ID_1964730812" MODIFIED="1757113917367" TEXT="es gibt ein massives Namensraum-Problem">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...da hatte anfangs niemand von uns dran gedacht; inzwischen haben wir <i>dutzende</i>&#160; RfCs, und so manche gute griffige Namen sind bereis weg; generell sollte man
</p>
<ul>
<li>
RfCs mit einem Nummern-Schema versehen
</li>
<li>
im RfC-Subindex auch gewisse qualifizierte Schlagworte mit speichern
</li>
</ul>
</body>
</html></richcontent>
</node>
<node CREATED="1757113786929" ID="ID_1055142518" MODIFIED="1757113798665" TEXT="fange mal schrittweise damit an"/>
</node>
<node COLOR="#338800" CREATED="1757097252163" ID="ID_118274991" MODIFIED="1757097372127" TEXT="vorl&#xe4;ufig in Git einchecken"> <node COLOR="#338800" CREATED="1757097252163" ID="ID_118274991" MODIFIED="1757097372127" TEXT="vorl&#xe4;ufig in Git einchecken">
<icon BUILTIN="button_ok"/> <icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1757097261352" ID="ID_1779486987" MODIFIED="1757097378075" TEXT=".gitignore-Trick"> <node COLOR="#435e98" CREATED="1757097261352" ID="ID_1779486987" MODIFIED="1757097378075" TEXT=".gitignore-Trick">
<richcontent TYPE="NOTE"><html> <richcontent TYPE="NOTE"><html>
<head> <head/>
</head>
<body> <body>
<p> <p>
man kann Exclusions von Exclusions definieren; das klappt aber nur, wenn diese doppel-Exclusions <i>spezieller sind</i>&#160;als die allgemeine ignore-Regel. Insofern wird empfohlen, solche Regeln paarweise zu definieren man kann Exclusions von Exclusions definieren; das klappt aber nur, wenn diese doppel-Exclusions <i>spezieller sind</i>&#160;als die allgemeine ignore-Regel. Insofern wird empfohlen, solche Regeln paarweise zu definieren
</p> </p>
</body> </body>
</html> </html></richcontent>
</richcontent>
<icon BUILTIN="idea"/> <icon BUILTIN="idea"/>
</node> </node>
</node> </node>
@ -163234,7 +163256,7 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</node> </node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1756773353095" ID="ID_397054568" MODIFIED="1756773366565" TEXT="weitere Fixes"> <node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1756773353095" ID="ID_397054568" MODIFIED="1756773366565" TEXT="weitere Fixes">
<icon BUILTIN="bell"/> <icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1756773369043" ID="ID_252956083" MODIFIED="1756773406409" TEXT="Verlinkung Git-Flow (Codebase)"> <node COLOR="#435e98" CREATED="1756773369043" ID="ID_252956083" MODIFIED="1757375452980" TEXT="Verlinkung Git-Flow (Codebase)">
<richcontent TYPE="NOTE"><html> <richcontent TYPE="NOTE"><html>
<head/> <head/>
<body> <body>
@ -163244,6 +163266,16 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</body> </body>
</html></richcontent> </html></richcontent>
<icon BUILTIN="broken-line"/> <icon BUILTIN="broken-line"/>
<node CREATED="1757375530629" ID="ID_353096145" MODIFIED="1757375578668" TEXT="war Kollateralschaden vom Merge von Christians Umbau 2018..."/>
<node CREATED="1757375552149" ID="ID_1100078557" MODIFIED="1757375565206" TEXT="Christian hatte nicht nach {l} im Documentation-Tree gesucht"/>
</node>
<node CREATED="1757467120936" ID="ID_1396646253" MODIFIED="1757467126724" TEXT="Footer">
<node CREATED="1757467128881" ID="ID_536613684" MODIFIED="1757467140201" TEXT="search-Feld?"/>
<node CREATED="1757467140824" ID="ID_389709958" MODIFIED="1757467150994" TEXT="welche Repos sind sinnvoll?"/>
<node CREATED="1757467151657" ID="ID_566958065" MODIFIED="1757467158398" TEXT="genauerer Timestamp">
<node CREATED="1757467159266" ID="ID_599618635" MODIFIED="1757467172806" TEXT="derzeit verwenden wir {localdate} {localtime}"/>
<node CREATED="1757467173466" ID="ID_726876662" MODIFIED="1757467186928" TEXT="denkbar: {docdate} {doctime}"/>
</node>
</node> </node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756834117054" ID="ID_718437760" MODIFIED="1756834125609" TEXT="Lizenz-Seiten erneuern"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756834117054" ID="ID_718437760" MODIFIED="1756834125609" TEXT="Lizenz-Seiten erneuern">
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="flag-yellow"/>
@ -163266,16 +163298,13 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
<node CREATED="1757083926206" ID="ID_1901635357" MODIFIED="1757083934094" TEXT="Einstiegsseite klarer machen"/> <node CREATED="1757083926206" ID="ID_1901635357" MODIFIED="1757083934094" TEXT="Einstiegsseite klarer machen"/>
<node CREATED="1757097219557" ID="ID_1643388033" MODIFIED="1757097235212"> <node CREATED="1757097219557" ID="ID_1643388033" MODIFIED="1757097235212">
<richcontent TYPE="NODE"><html> <richcontent TYPE="NODE"><html>
<head> <head/>
</head>
<body> <body>
<p> <p>
klar machen: Diskusssion ist <b>abgeschlossen</b> klar machen: Diskusssion ist <b>abgeschlossen</b>
</p> </p>
</body> </body>
</html> </html></richcontent>
</richcontent>
</node> </node>
<node CREATED="1757083913652" ID="ID_400973085" MODIFIED="1757083920330" TEXT="Ordnung im Men&#xfc;"/> <node CREATED="1757083913652" ID="ID_400973085" MODIFIED="1757083920330" TEXT="Ordnung im Men&#xfc;"/>
<node CREATED="1757097206857" ID="ID_640799169" MODIFIED="1757097214542" TEXT="x-Llinks nutzen"> <node CREATED="1757097206857" ID="ID_640799169" MODIFIED="1757097214542" TEXT="x-Llinks nutzen">
@ -163293,32 +163322,34 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
<icon BUILTIN="idea"/> <icon BUILTIN="idea"/>
<node CREATED="1757109809510" ID="ID_1949523296" MODIFIED="1757109850212"> <node CREATED="1757109809510" ID="ID_1949523296" MODIFIED="1757109850212">
<richcontent TYPE="NODE"><html> <richcontent TYPE="NODE"><html>
<head> <head/>
</head>
<body> <body>
<p> <p>
Name + Datum als Asciidoc-<b>Delimited-Block</b> Name + Datum als Asciidoc-<b>Delimited-Block</b>
</p> </p>
</body> </body>
</html> </html></richcontent>
</richcontent>
<richcontent TYPE="NOTE"><html> <richcontent TYPE="NOTE"><html>
<head> <head/>
</head>
<body> <body>
<p> <p>
also mit + einleiten und dann mit -- umschlie&#223;en also mit + einleiten und dann mit -- umschlie&#223;en
</p> </p>
</body> </body>
</html> </html></richcontent>
</richcontent>
</node> </node>
<node CREATED="1757109851861" ID="ID_1446312028" MODIFIED="1757109870578" TEXT="den Namen als Definitionslisten-Element darstellen"/> <node CREATED="1757109851861" ID="ID_1446312028" MODIFIED="1757109870578" TEXT="den Namen als Definitionslisten-Element darstellen"/>
<node CREATED="1757109872849" ID="ID_1888615594" MODIFIED="1757109891572" TEXT="Antworten dann als tiefere Schachtelungsebene markieren (Handarbeit!)"/> <node CREATED="1757109872849" ID="ID_1888615594" MODIFIED="1757109891572" TEXT="Antworten dann als tiefere Schachtelungsebene markieren (Handarbeit!)"/>
</node> </node>
</node> </node>
<node CREATED="1757297636473" ID="ID_873518682" MODIFIED="1757297640340" TEXT="RfC">
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1757297650576" ID="ID_404195629" MODIFIED="1757297655336" TEXT="markup broken">
<icon BUILTIN="messagebox_warning"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1757297641266" ID="ID_66055677" MODIFIED="1757297645010" TEXT="CStyleGuide">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
</node> </node>
<node CREATED="1756773417519" ID="ID_1432896045" MODIFIED="1756773420272" TEXT="Men&#xfc;"> <node CREATED="1756773417519" ID="ID_1432896045" MODIFIED="1756773420272" TEXT="Men&#xfc;">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756773421004" ID="ID_1536518392" MODIFIED="1756773452193" TEXT="Reihenfolge Technical"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1756773421004" ID="ID_1536518392" MODIFIED="1756773452193" TEXT="Reihenfolge Technical">
@ -163328,6 +163359,32 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
<icon BUILTIN="flag-yellow"/> <icon BUILTIN="flag-yellow"/>
</node> </node>
</node> </node>
<node CREATED="1757122577486" ID="ID_1246513731" MODIFIED="1757122587846" TEXT="Doxygen">
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1757122589092" ID="ID_723885529" MODIFIED="1757122594029" TEXT="Modules-Page fehlt">
<icon BUILTIN="broken-line"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1757122595259" ID="ID_1861042641" MODIFIED="1757122720646" TEXT="vmtl. &#xc4;nderung in Doxygen">
<icon BUILTIN="info"/>
<node CREATED="1757122621984" ID="ID_12344637" LINK="https://github.com/doxygen/doxygen/issues/10562" MODIFIED="1757122633503" TEXT="siehe #10562"/>
<node CREATED="1757122636775" ID="ID_621368638" MODIFIED="1757122652224" TEXT="demnach w&#xe4;ren das nun &quot;topics&quot;"/>
</node>
<node CREATED="1757122654348" ID="ID_1433417097" MODIFIED="1757122671181" TEXT="anpassen">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1757122671938" ID="ID_1127643223" MODIFIED="1757122695607" TEXT="DoxygenLayout: Tab &quot;topics&quot;">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1757122684965" ID="ID_1398251523" MODIFIED="1757122695608" TEXT="pr&#xfc;fen ob Generierung funktioniert">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1757122698309" ID="ID_433552005" MODIFIED="1757122707016" TEXT="Einstiegsseite anpassen">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1757122866610" ID="ID_110243952" MODIFIED="1757122901163" TEXT="URL auf doxygen.org &#x27fc; https://www.doxygen.nl/index.html">
<icon BUILTIN="help"/>
<node CREATED="1757122902204" ID="ID_313076251" MODIFIED="1757122905207" TEXT="woot??"/>
<node CREATED="1757122905904" ID="ID_187223135" MODIFIED="1757122914193" TEXT="das ist doch von Doxygen selber generiert..."/>
</node>
</node>
</node> </node>
</node> </node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1751808931491" ID="ID_1572764059" MODIFIED="1752070235664" TEXT="Build/Dependencies"> <node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1751808931491" ID="ID_1572764059" MODIFIED="1752070235664" TEXT="Build/Dependencies">