Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
115 lines
4.6 KiB
Text
115 lines
4.6 KiB
Text
2008-07-06 Lumiera Developers Meeting
|
|
=====================================
|
|
:Author: Teld
|
|
:Date: 2008-08-10
|
|
|
|
Participants
|
|
------------
|
|
* ichthyo
|
|
* cehteh
|
|
* jilt
|
|
* dmj726
|
|
* Teld
|
|
* \_nasa_
|
|
* alcarinque_
|
|
* MNO
|
|
* Wescotte
|
|
* weatherhead
|
|
|
|
|
|
Boilerplate
|
|
-----------
|
|
|
|
Organization of this meeting
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
* dmj726 intends to write the protocol
|
|
* _Ichthyo_ is chairman
|
|
* there is no agenda, so this is a freeform meeting
|
|
|
|
Leftovers from last meeting
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
There are no leftovers
|
|
|
|
|
|
Introduction of Lumiera
|
|
-----------------------
|
|
Because there are quite some new participants, an introduction of the project Lumiera is given
|
|
|
|
There are 3 core devs:
|
|
|
|
* _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
|
|
* _JoelHoldsworth_: GUI in C++/Gtkmm
|
|
|
|
Other people involved:
|
|
|
|
* _rcbarnes_: ui designer and coder
|
|
* _raffa_: web content
|
|
* _Simav_: gives a hand when and where he can
|
|
* _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_:
|
|
|
|
* improvement of the testsuite (simple Bash)
|
|
* start of a worker thread manager (Posix knowledge required)
|
|
* start of the scheduler (some Posix, good C coding)
|
|
* runtime profiler (little but advanced Posix realtime programming job)
|
|
* review of code and documentation
|
|
* system administration
|
|
* setup of a build/test environment on the server
|
|
* setup and maintain postfix/dovecot by a mail administrator
|
|
|
|
_Ichthyo_:
|
|
|
|
* asset management (keeping track of all media files, captures, clips, scenes)
|
|
* 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
|
|
* 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).
|
|
* 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.
|
|
_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
|
|
---------------------------------
|
|
* 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.
|
|
|
|
* scripting language.
|
|
+
|
|
--
|
|
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.
|
|
--
|
|
|
|
* 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.
|
|
|
|
* 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.
|
|
|
|
* ``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: link:{rfc}/ProcPlacementMetaphor.html[RfC Placement Metaphor]
|
|
|
|
|
|
Next meeting
|
|
------------
|
|
The next meeting will be held Thursday, 7 August 19:00 UCT.
|