move all existing IRC meeting summaries from the website into the core tree
Note: the documentation subtree is included in the website, so the meeting summaries are still visible online
This commit is contained in:
parent
eb087b98b1
commit
a3dd83c0f0
13 changed files with 2091 additions and 0 deletions
82
doc/devel/meeting_summary/2008-02-01.txt
Normal file
82
doc/devel/meeting_summary/2008-02-01.txt
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
Initial Lumiera Developers Meeting
|
||||
==================================
|
||||
:Date: 2008-02-01
|
||||
|
||||
//Menu: label 2008-02-01 the first Lumiera Developers Meeting
|
||||
|
||||
__Participants__
|
||||
|
||||
* hermanr
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* Dasypus
|
||||
* gmerlin
|
||||
* SimAV
|
||||
* pippin
|
||||
* Plough
|
||||
* Plouj
|
||||
* Velmont
|
||||
|
||||
|
||||
Discuss the open points in [Lumiera/DesignProcess] --- do we need this formalism?
|
||||
---------------------------------------------------------------------------------
|
||||
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.
|
||||
* 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
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
Monthly meetings
|
||||
----------------
|
||||
|
||||
* 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?)
|
||||
* 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
|
||||
* publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the link:TiddlyWiki[] and on pipapo.org
|
||||
* News, Protocols and the agenda of the next meeting can be found at link:MonthlyMeetings[this page here]
|
||||
* next meeting on first Thursday in March (6.3.2008)
|
||||
|
||||
|
||||
Who works on what, what are the short term goals, what tasks are open?
|
||||
----------------------------------------------------------------------
|
||||
*Ichthyo* works on the processing layer. Current goal is to get the core of the builder fleshed out. Next goal is to create a clip object (dummy), add it to the EDL, hand the EDL over to the builder and let the builder make the first (preliminary) render nodes. (note: left many details for later).
|
||||
Ichthyo started coding his design draft and things seem to work out as intended. Some Keywords: Have a high-level model and a low level model. The former is comprised of the objects in the Session edited by the user, the latter is a network of completely configured render nodes, employing the same pull model as in Cinelerra-2. In between sits the Builder, translating high-level into low-level. This translation is done on demand (not for every frame).
|
||||
Current state in this part is: basic asset manager is done, asset objects (forming a hierarchy) can be created and will be registered automatically, it is possible to create a clip-"MediaObject" from a media asset (without caring for any details regarding multichannel clips). Some support lib components are written, Session and data holders start up on demand and shutdown cleanly. The test suite is the only interesting executable, and this will remain so for quite some time. Currently writing the first parts of the Builder.
|
||||
Further plans/ideas: Ichthyo is rather determined to embed a Prolog interpreter (YAP Prolog) to handle all sorts of configuration queries in a rule-driven fashion. Things Ichthyo can't do in the near future: caring for session loading/saving serialisation plus storage backends, caring for a DB based implementation of the asset manager and integration with production support software, target the scheduler which will receive any edit operations initiated from the GUI.
|
||||
|
||||
*Cehteh* is currently working on webgit, which is somewhat related inasmuch it will make small contributions to the mob repository much simpler. Previously he started with some foundation and support facilities. He plans to come back to the Backend implementation in about two weeks. The Backend is intended to handle all media (and even meta-)data as generalized frames. The render nodes network created by the Proc-Layer is completely stateless and all data is served from below. While it will be possible to address and access individual data within a frame (e.g. audio samples), frames are the smallest unit for memory and cache management. No plans to use a tiled memory model or to support frames larger than aprox. 20-40% of the available RAM.
|
||||
Cehteh's design plan includes a scheduler to organize the access to the raw data, monitor the timings and prefetch data as needed. This scheduler will be configurable via quality preferences ("need realtime", "need perfect quality"). Further, there will be an elaborate caching scheme trying hard to avoid re-rendering any frames already calculated previously. Temporary data will be backed by files and thus swapped out — this swapout and size of temporary data is to be monitored and adjusted according to the current load — and all temporary data is kept as most-recent-used cache discipline. Incoming and outgoing footage shall mostly be handled by using mmaped buffers. The rationale is to avoid unnecessary copy from kernel to user space and wasting memory for an additional in-kernel buffer. Writing via a mmapped buffer is little more tricky; there will be a in-place writing which is used for indices and other precalculated data which needs updates, and the processing layer can query write buffers which are actually a small cache/ring and then comited to the file. Basically, mmapping is a clean solution if you can design for it, and it's portable (posix)
|
||||
Things to do: object serialisation backend is sometime on Cehteh's schedule, but that's ahead and if someone else helps or takes over it would be OK. Even more true for a DB based backend for the asset manager.
|
||||
|
||||
*Gmerlin* plans to implement grayscale support for GAVL, so the upper layers can store arbitrary data in it.
|
||||
|
||||
About multithreading
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
Since the render nodes are stateless they can be driven in multiple threads (but inter frame dependencies need to be resolved/serialized). Mostly the backend manages threads and does that quite conservatively (compared to Cinelerra-2 which massively creates separate threads for small tasks). Any edit operations initiated from GUI go to a scheduler in the middle layer, which enqueues and effectively serializes operations done to the "media objects" in the high-level model. The editing operations themselves are *not threadsafe* by design, they rely on being scheduled correctly. The builder is triggered from this Proc-Layer scheduler and starts in one separate thread, and when done, we swap whole parts of the render nodes network and then the backend can re(start) rendering as needed.
|
||||
|
||||
|
||||
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" ;-)
|
||||
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 be "googleable"
|
||||
* should not be offensive
|
||||
* should have one of the free top level domains (.net, .org)
|
||||
* should be compatible with educational institutions (sorry, no pr0nedit :)
|
||||
* should not obviously collide with trade marks
|
||||
189
doc/devel/meeting_summary/2008-03-06.txt
Normal file
189
doc/devel/meeting_summary/2008-03-06.txt
Normal file
|
|
@ -0,0 +1,189 @@
|
|||
2008-03-06 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: cehteh
|
||||
:Date: 2008-03-07
|
||||
|
||||
__Participants__
|
||||
|
||||
* hermanr
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* Plouj
|
||||
* SimAV
|
||||
* akirad
|
||||
* _MMA_
|
||||
* rgareus
|
||||
* ddennedy
|
||||
* edrz
|
||||
* anewcomb
|
||||
* gmerlin
|
||||
* oracle2025
|
||||
* gisle
|
||||
|
||||
|
||||
Boilerplate
|
||||
-----------
|
||||
|
||||
Organization of this meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
* cehteh writes the protocol
|
||||
* hermanr does chairman
|
||||
|
||||
|
||||
Leftovers from last meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
We concluded there are no leftovers
|
||||
|
||||
|
||||
Go through Ideas and Drafts in design process
|
||||
---------------------------------------------
|
||||
|
||||
|
||||
Idea: time_handling
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[]
|
||||
|
||||
Point 1 is superseded by using gavl.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python[]
|
||||
|
||||
We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal.
|
||||
|
||||
Conclusion:
|
||||
Drop it.
|
||||
|
||||
|
||||
Idea: Todo Lists
|
||||
~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists[]
|
||||
|
||||
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.
|
||||
|
||||
Conclusion:
|
||||
We use the Tiddlywiki task macro thing for now.
|
||||
|
||||
|
||||
Draft: CCodingStyleGuide
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide[]
|
||||
|
||||
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.
|
||||
|
||||
Conclusion:
|
||||
Make it final.
|
||||
|
||||
|
||||
Draft: DevelopmentFramework
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework[]
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection[]
|
||||
|
||||
This might be only useful if there are more developers working on the project.
|
||||
|
||||
Conclusion:
|
||||
Leave in draft state for now.
|
||||
|
||||
|
||||
Draft: Architecture Overview
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[]
|
||||
|
||||
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.
|
||||
|
||||
Conclusion:
|
||||
Good idea, needs some refinements, work in progress.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Conclusion:
|
||||
Things need to be worked out in link:DesignProcess[], take a look and review it.
|
||||
|
||||
|
||||
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[]
|
||||
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.
|
||||
|
||||
Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co.
|
||||
|
||||
Conclusion:
|
||||
Projectname is Lumiera, we have a lot things to rename.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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!
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
|
||||
The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see below).
|
||||
|
||||
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:
|
||||
Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed!
|
||||
290
doc/devel/meeting_summary/2008-04-03.txt
Normal file
290
doc/devel/meeting_summary/2008-04-03.txt
Normal file
|
|
@ -0,0 +1,290 @@
|
|||
2008-04-03 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Sami Kallinen
|
||||
:Date: 2008-04-09
|
||||
|
||||
__Participants__
|
||||
|
||||
* cehteh
|
||||
* gmerlin
|
||||
* hermanr
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* johncoswell
|
||||
* rgareus
|
||||
* sakalli
|
||||
|
||||
|
||||
Boilerplate
|
||||
-----------
|
||||
|
||||
Organization of this meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
* sakalli writes the protocol, ichthyo will help reviewing it
|
||||
|
||||
|
||||
Recurring Topics
|
||||
~~~~~~~~~~~~~~~~
|
||||
We concluded there are no leftovers and currently no Drafts from the design process to discuss
|
||||
|
||||
|
||||
Call for volunteers
|
||||
-------------------
|
||||
(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:
|
||||
|
||||
* Protocol writing
|
||||
* maintaining to do lists and isolating tasks
|
||||
* constant code and documentation review
|
||||
* unit/functional testing
|
||||
* 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
|
||||
|
||||
See http://www.lumiera.org/wiki/todo.html#Tasks[]
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Project announcements/registration
|
||||
----------------------------------
|
||||
(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.
|
||||
|
||||
Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful)
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
* 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 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:
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
* 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.
|
||||
* 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 / 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
* 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
|
||||
* 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
|
||||
* 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 in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer
|
||||
|
||||
Some brainstorming points about usability:
|
||||
|
||||
* We need a realy good bezier widget for all sorts of curves.
|
||||
* Faders that can be grabbed everywhere are nice like like ardours and Blender faders. Or others which have no big knob
|
||||
* The controls in blender's node view would be a good modal to copy (not advocating GL UI, just using widgets and concepts).
|
||||
|
||||
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.
|
||||
|
||||
|
||||
GUI CONCLUSION
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
* 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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
We made no decision about official presence but most likely there will be a developer meeting if nothing else.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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_
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
|
||||
The next meeting will be at thuesday 8th may 21:00GMT
|
||||
|
||||
|
||||
''''
|
||||
|
||||
.Timecode discussion
|
||||
----
|
||||
12:51 cehteh gmerlin: did you read my last mail about generalization of metadata?
|
||||
12:51 cehteh key/value pairs
|
||||
12:51 gmerlin not sure about that
|
||||
12:51 cehteh i am pretty sure that i want that in lumiera
|
||||
12:52 cehteh if gavl does that for us it would be even better
|
||||
12:52 gmerlin first of all 2 different things:
|
||||
12:52 gmerlin 1. arithmetic <-> struct
|
||||
12:53 gmerlin 2. Generic <-> format specific
|
||||
12:53 cehteh arithmetic for sure
|
||||
12:53 gmerlin On the decoder API side, I want to export ideally only one type
|
||||
12:54 gmerlin No no SMPTEXXX and ISO999908098
|
||||
12:54 cehteh will that be attached to the frames in a intrusive way?
|
||||
12:54 cehteh i rather leave the attaching up to the application
|
||||
12:54 gmerlin intrusive?
|
||||
12:55 cehteh struct frame { uint64_t timecode; } vs...
|
||||
12:55 cehteh struct frame { struct metadata* something; }
|
||||
12:55 cehteh or even vs something done at a api level
|
||||
12:56 gmerlin struct lumiera_video_frame { gavl_video_frame_t * f; uint64_t timecode};
|
||||
12:56 gmerlin Or add timecodes to gavl_video_frame_t
|
||||
12:57 cehteh struct lumiera_video_frame { gavl_video_frame_t * f; struct metadata* timecode_n_stuff; }
|
||||
12:57 ichthyo so I support a struct metadata*
|
||||
12:58 cehteh ichthyo: timecodes might not be regular .. they should be optional, but anyways they dont cost when using an arithmetic type
|
||||
12:58 cehteh i mean thats the purpose of timecodes .. to tag every frame and dont make assumptions that your footage is perfect
|
||||
12:58 ichthyo but a struct metadata* would rather mean to keep it out of basic GAVL and have a libmetadata -- which may be integrated with GAVL -- right?
|
||||
12:59 cehteh someome may have stolen a frame :P
|
||||
12:59 cehteh thats gmerlins decision ...
|
||||
12:59 gmerlin I'm against gavl integration of metadata
|
||||
12:59 gmerlin gavl has a clear scope: Number crunching
|
||||
01:00 cehteh gmerlin: you somehow have to pass it from the decoder to the application
|
||||
01:01 cehteh i would prefer to introduce some sidechannel
|
||||
01:01 gmerlin Yes, gmerlin_avdecoder will provide a separate function for getting the next timecode
|
||||
01:01 gmerlin bgav_get_next_timecode()
|
||||
01:01 cehteh gavl_get_frame (gavl_frame* place the frame here, metadata* place metadata there)
|
||||
01:01 gmerlin or: bgav_timecode_from_pts()
|
||||
01:03 gmerlin Some higher MXF profiles allow changing timecode parameneters in one stream
|
||||
01:06 gmerlin It's sometimes impossible to separate demuxers and codecs
|
||||
01:06 gmerlin better have them together in one lib
|
||||
01:06 cehteh actually i would like to cache gavls internal states into the backend
|
||||
01:08 gmerlin Ok, so timecodes are YYYYMMDDHHMMSSFF as int64_t
|
||||
01:08 cehteh the indexing is something i prolly have some words about
|
||||
01:09 cehteh timecodes are uint64_t as microseconds
|
||||
01:09 cehteh well for lumiera :-P
|
||||
01:10 cehteh YYYYMMDDHHMMSSFF as int64_t isnt that much better than a struct :P
|
||||
01:11 ichthyo now, IMHO its mostly up to gmerlin to decide how it fits into GAVL
|
||||
01:11 cehteh ack
|
||||
01:11 gmerlin Not gavl
|
||||
01:11 ichthyo gmerlin?
|
||||
01:11 gmerlin gmerlin avdecoder yes.
|
||||
01:11 cehteh in lumiera we will use usecs
|
||||
01:11 ichthyo yes
|
||||
01:12 ichthyo we will have a conversion function somewhere
|
||||
01:12 gmerlin And will it include a calendar date?
|
||||
01:12 cehteh doing it only once (avdecoder->usec) makes some sense
|
||||
01:12 gmerlin usecs since when?
|
||||
01:12 ichthyo either, we get directly usecs from avdecoder, if this fits in for gmerlin,
|
||||
01:12 ichthyo or we'll get the format which works best for him and we do the conversion ourselves
|
||||
01:12 cehteh defined elsewhere
|
||||
01:12 cehteh reel-start or absolute time or whatever
|
||||
01:13 ichthyo also, what sort of timecode this was based on (drop frame or not)
|
||||
01:13 cehteh gmerlin: thats a important point .. just uint64_t does not suffice
|
||||
01:13 cehteh it needs a tag describing what kind of timecode was used
|
||||
01:14 cehteh no matter how you encode it
|
||||
01:14 cehteh and iirc there are quite some timecodes
|
||||
01:14 ichthyo because in this respect richard was right: we need to be able to reprocuce any value 1:1
|
||||
01:14 cehteh yep
|
||||
01:15 cehteh further i want to be able to convert between any kind of timecode in a fingersnip
|
||||
01:15 gmerlin ichthyo: and that's impossible with usecs
|
||||
01:15 cehteh gmerlin: its not
|
||||
01:15 ichthyo with usecs alone: agreed
|
||||
01:16 ichthyo with usecs + metadata it should be possible
|
||||
01:16 ichthyo modulo some extreme cases (high speed cams, weeks of footage....)
|
||||
01:16 cehteh yes .. you need framerate and other infos depending on the metadata
|
||||
01:17 cehteh you need to be careful to do the math right so that inverse functions dont drift
|
||||
01:17 gmerlin I'll export something lossless, which repduces MXF, DV and Quicktime timecodes losslessly
|
||||
01:17 gmerlin You can then do what you want with them :)
|
||||
01:17 cehteh thats why i would like to do it at only *one* place/library .. because its delicate and bugs are easier to spot/fix there
|
||||
01:18 ichthyo and then there is some api to get at the additional metadata
|
||||
01:18 cehteh yeah
|
||||
01:18 ichthyo and beyond that: lets devise a libmetadata
|
||||
01:18 cehteh just shove the data over .. YYYYMMDDHHMMSSFF as int64_t would be ok
|
||||
01:18 gmerlin Ok.
|
||||
01:18 cehteh we make a libmetadata (as part of our support lib)
|
||||
01:19 cehteh somewhat independent so that it can be spun out
|
||||
----
|
||||
|
||||
|
||||
.about Metadata
|
||||
----
|
||||
01:19 cehteh gmerlin: well .. how bout other metadata
|
||||
01:19 cehteh your decoder needs to pass that too
|
||||
01:20 gmerlin like?
|
||||
01:20 gmerlin Author, Artist title...
|
||||
01:20 cehteh some cameras encode shutter speed, focus, gain control, colour balance
|
||||
01:20 cehteh and other things
|
||||
01:20 gmerlin Hmmm
|
||||
01:20 gmerlin I think MXF exports some of these
|
||||
01:21 ichthyo wav files can have additional chunks; whats with flac?
|
||||
01:21 gmerlin flac has vorbis metadata
|
||||
01:21 ichthyo important for the more modern sound formats
|
||||
01:21 cehteh dunno .. just thinkin about pro codecs and raw film metadata
|
||||
01:21 ichthyo just wanting to point out: things to come here,
|
||||
01:22 ichthyo e.g for sound: what stream is what channel
|
||||
01:22 gmerlin Channel locations are handles by gavl
|
||||
01:22 gmerlin If you have a multichannel stream
|
||||
01:22 cehteh well .. note that there is per-asset metadata you want to pass .. and per frame metadata
|
||||
01:22 cehteh maybe even some more undiscovered cases :)
|
||||
01:23 cehteh did someone say this is easy??
|
||||
01:23 sakalli did any of you watch the video regarding red workflow that i sent to the mailing list? redcode raw holds everyting, asa, wb, etc... hope lumiera will be able to facilitate that as well.
|
||||
01:23 ichthyo at some point I want to be able to support ambisonics
|
||||
01:24 ichthyo and maybe some day there will be wave field sysnthesis in more broad use
|
||||
01:24 cehteh the codec in the back needs to pass us these things else we cantb handle it
|
||||
01:24 gmerlin well, the easiest would be to extend bgav_metadata_t
|
||||
01:24 ichthyo rationale is: just be open
|
||||
01:24 cehteh gmerlin: maybe we need to investigate this things more, nothing needs to be decided now
|
||||
01:24 ichthyo ack
|
||||
01:25 cehteh see my key/value metadata proposal .. at some point maybe you make a complete sidechannel just for metadata
|
||||
01:25 cehteh decoder stuffs that in on demand and it is passed along with its own api like the bgav_timecode_from_pts()
|
||||
01:26 cehteh that way you dont need to touch it more than necessary
|
||||
01:26 gmerlin shouldn't that key/value stuff be unified with plugin parameters?
|
||||
01:27 cehteh for lumiera, maybe, maybe not
|
||||
01:27 ichthyo you mean: you have a common api for describing "values" ?
|
||||
01:27 cehteh some plugin parameters are determined by math functions
|
||||
01:27 gmerlin You have a key, a type and a value
|
||||
01:27 cehteh maybe for caching them
|
||||
01:27 cehteh the api might be unified .. but the storage not
|
||||
01:28 gmerlin why?
|
||||
01:28 ichthyo because any block of data could be in the metadata
|
||||
01:28 cehteh metadata which belongs to the frame coming from the decoder is const
|
||||
01:28 cehteh plugin parameters are volatile
|
||||
|
||||
01:33 gmerlin One other point (but too late for it now) are audio timecodes. I'll adress that on libopenvideo
|
||||
01:33 cehteh we will write a little more sophisticated timecode library
|
||||
01:34 cehteh gmerlin: that should be unified :)
|
||||
----
|
||||
244
doc/devel/meeting_summary/2008-05-08.txt
Normal file
244
doc/devel/meeting_summary/2008-05-08.txt
Normal file
|
|
@ -0,0 +1,244 @@
|
|||
2008-05-08 Lumiera Developers Meeting
|
||||
======================================
|
||||
:Author: cehteh
|
||||
:Date: 2008-05-15
|
||||
|
||||
__Participants__
|
||||
|
||||
* cehteh
|
||||
* joelholdsworth
|
||||
* ichthyo
|
||||
* raffa
|
||||
* Wes``Lappy
|
||||
* gmerlin
|
||||
|
||||
|
||||
Boilerplate
|
||||
-----------
|
||||
|
||||
Organization of this meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
* cehteh writes the protocol
|
||||
|
||||
|
||||
Webpage-Infrastructure, Maintenance
|
||||
-----------------------------------
|
||||
|
||||
Cehteh put this on topic because it's really urgent to bring up some
|
||||
infrastructure to manage the information we produce.
|
||||
|
||||
The Lumiera pages on pipapo.org were always meant as intermediary
|
||||
solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh
|
||||
expresses that he wants to move pipapo.org to a new infrastructure
|
||||
based on asciidoc and git he created
|
||||
(see http://git.pipapo.org/uWiki.html[]). This system is barely useable
|
||||
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
|
||||
(scripting) needs someone who knows shell scripting and doesn't need
|
||||
to be done by the core devs freeing their resources to work on
|
||||
Lumiera. Cehteh expresses that none of the people who proposed to
|
||||
help before showed up yet. WesLappy tells he might help (addendum not
|
||||
this week, because he is busy).
|
||||
|
||||
Next there was a suggestion by cehteh to convert the tiddlywikis to
|
||||
asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel
|
||||
mentions that they feel a little odd. Generally we all agree that
|
||||
they have some problems in sense of workflow and merging.
|
||||
|
||||
Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and
|
||||
build up \'official' documentation based on their content in
|
||||
whatever-we-use-then (asciidoc) documentation system. All agree on
|
||||
this approach.
|
||||
|
||||
Back to the new wiki, cehteh suggests to make stricter access rules to
|
||||
prevent spam: "There will be a group of \'Validated' people which
|
||||
following rules: only Validated people can edit general content and
|
||||
\'Validated' people can add new people to \'Validated' themselves". That
|
||||
means that we can have a lightweight self-administrating
|
||||
authentication where new people have to be introduced by someone who
|
||||
is already there.
|
||||
|
||||
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.
|
||||
|
||||
Raffa will take care of content/design as much her time/knowledge permits.
|
||||
|
||||
|
||||
Conclusion
|
||||
~~~~~~~~~~
|
||||
|
||||
* We really need someone to help with the webpage scripting.
|
||||
* Documentation needs to be well organized and 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
|
||||
* All other documentation should be below that
|
||||
|
||||
|
||||
|
||||
Whats pending in link:DesignProcess[]
|
||||
-------------------------------------
|
||||
|
||||
|
||||
MistakestoAvoid
|
||||
~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[]
|
||||
|
||||
rick_777 wrote a "MistakestoAvoid" page which explains some possible
|
||||
gotchas. We basically agree with most points there while we already
|
||||
decided to address some things differently than he suggested. One
|
||||
noteable difference is that we do not intent to provide a windows
|
||||
version of Lumiera, which was explained in serveral places. Cehteh
|
||||
added some comments to the page explaining some things.
|
||||
|
||||
|
||||
nothing more to discuss in \'Ideas', we go over to \'Drafts'
|
||||
|
||||
|
||||
ArchitectureOverview
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[]
|
||||
|
||||
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
|
||||
.fig.
|
||||
|
||||
Conclusion: We agree to keep it as .SVG, add it to the repository and
|
||||
improve/complete it.
|
||||
|
||||
|
||||
GitSubmoduleTransistion
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion[]
|
||||
|
||||
Another suggestion made by cehteh is to make managing of subprojects
|
||||
within the sourcetree easier. Joel and ichthyo oppose that it is not
|
||||
really needed now and needs more understanding of git. Ichthyo
|
||||
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
|
||||
know if we will some rearrangements and movements of files between
|
||||
modules.
|
||||
|
||||
Conclusion: We transform the documentation to a submodule and see how
|
||||
it works. Other things will be decided much later.
|
||||
|
||||
|
||||
|
||||
|
||||
GlobalInitialization
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization[]
|
||||
|
||||
This topic is discussed and agreed on the link:DesignProcess[] page already.
|
||||
|
||||
Conclusion: finalize it
|
||||
|
||||
|
||||
MasterRepositorySetup
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup[]
|
||||
|
||||
Setting up an master repository was decided on the last meeting.
|
||||
cehteh now set one up which also does some automatic, but intended
|
||||
fragile merging from subsystem maintainer branches.
|
||||
1. it updates automatically for the maintainers repo for conflict
|
||||
free fast-forwards
|
||||
2. it can always be overridden with explicit pushes
|
||||
|
||||
The others agree on the setup.
|
||||
|
||||
Ichthyo stresses that maintainers shall watch that their \'master'
|
||||
branch should compile cleanly and pass the testsuite always, test
|
||||
which are not operational should be tagged as PLANNED. We all
|
||||
agree, while cehteh's master is currently in a broken state (note:
|
||||
fixed now).
|
||||
|
||||
Then a short discussion about building and synchronizing the docs
|
||||
follows. Problem is that docs build in maintainer branches are
|
||||
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
|
||||
build from the LUMIERA/master repository, preferably on the \'devel'
|
||||
vserver which has to be set up.
|
||||
|
||||
Conclusions: Make this final, setup build environment in the devel
|
||||
server and build docs there.
|
||||
|
||||
|
||||
|
||||
NoBugFlags
|
||||
~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags[]
|
||||
|
||||
Defining a debugging control hierarchy. This is work in progress and
|
||||
cehteh explains that he works it out and deploys it, this depends on
|
||||
the link:GlobalInitialization[] decided earlier.
|
||||
|
||||
Conclusion: accepted, finish and finalize it.
|
||||
|
||||
|
||||
|
||||
Further Technical Discussion
|
||||
----------------------------
|
||||
|
||||
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
|
||||
explain him that we already made some discussions. Integrate the GUI
|
||||
into the build system probably linked as library, nothing finally
|
||||
decided yet. Communication will go over the plugin/interface facility
|
||||
(Plain C API). This things should be worked out and documented in
|
||||
link:DesignProcess[].
|
||||
|
||||
Cehteh made a small tool `./admin/headercheck` which will gradually
|
||||
extended to proof that headers are sufficiently selfstanding.
|
||||
|
||||
|
||||
|
||||
Progress
|
||||
--------
|
||||
|
||||
Cehteh finished low level file handling and working in mmaping and
|
||||
frameprovider next. When thats finished, the finalization of the
|
||||
Plugin loader and interface definition things is the most urgent thing.
|
||||
|
||||
Ichthyo works on the builder internals and next on some sort of
|
||||
"connection manager".
|
||||
|
||||
Joel goes on with GUI programming and integrating it into the source
|
||||
tree next.
|
||||
|
||||
Gmerlin and cehteh discuss about how to handle the index files which
|
||||
avdecoder uses internally. cehteh would like to manage them in the
|
||||
Lumiera backend to, because filehandles are a precious resource.
|
||||
Gmerlin explains that this index files are just loaded and kept in
|
||||
memory. So this poses no problem for filehandle exhaustion. We will
|
||||
discuss this further via email.
|
||||
|
||||
Cehteh suggests that we should think about some kind of
|
||||
preferences/registry sometime next to store default configs.
|
||||
|
||||
Following a discussion about how messages are passed between GUI and
|
||||
core. Generally we will use the interfaces defined by the plugin
|
||||
system. Gmerlin says that he uses message queues in \'gmerlin', Joel
|
||||
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
|
||||
GUI things too. For the parts where the GUI interacts with the high
|
||||
level proc model ichthyo and joel agree on working something
|
||||
(synchronous) out. Ichthyo stresses that the edit core is not
|
||||
threadsafe by design and relies on the backends scheduler.
|
||||
The underlying builder might sometimes to expensive for synchronous
|
||||
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
|
||||
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
|
||||
are not \'doable' should be flagged as erroneous but not dropped since
|
||||
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
|
||||
possible that the GUI gets immediate synchronous feedback for such
|
||||
things.
|
||||
|
||||
|
||||
|
||||
Next Meeting
|
||||
------------
|
||||
|
||||
Next meeting is on 5th June 21:00 UTC
|
||||
81
doc/devel/meeting_summary/2008-06-06.txt
Normal file
81
doc/devel/meeting_summary/2008-06-06.txt
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
2008-06-06 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: ichthyo
|
||||
:Date: 2008-06-07
|
||||
|
||||
21:00 -23:15 UTC on #lumiera
|
||||
|
||||
Participants:
|
||||
-------------
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* rcbarnes
|
||||
* raffa
|
||||
|
||||
|
||||
Left over from the last meeting
|
||||
-------------------------------
|
||||
Nothing left over and no urgent topics. Seemingly, work is proceeding in all parts of the application.
|
||||
|
||||
|
||||
Discuss Ideas and Drafts in design process
|
||||
------------------------------------------
|
||||
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.
|
||||
|
||||
|
||||
Idea: Design the Render Nodes interface
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface[]
|
||||
|
||||
*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.
|
||||
|
||||
*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.
|
||||
|
||||
|
||||
|
||||
Idea: Placement Metaphor used within the high-level view of Proc-Layer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[]
|
||||
|
||||
In the course of the discussion, *Ichthyo* explains the rationale
|
||||
|
||||
* 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)
|
||||
* 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
|
||||
|
||||
*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.
|
||||
|
||||
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.
|
||||
|
||||
* 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.
|
||||
* 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)
|
||||
. 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
|
||||
. GUI pulls the necessary properties by calling Proc on a per object base.
|
||||
* as a rule of thumb, GUI <--> Proc is mostly synchronous, while Backend <--> GUI is often asynchronous, but there are exceptions from the rule
|
||||
* we have general _parameters_, which are automatible. These are represented as _control data connections between the nodes_. We certainly don't want to represent some things in this way, though. For example, the in/out points of clips are fixed values.
|
||||
* in Ichthyo's concept, the Placement doesn't itself provide such parameter values/sources, rather it can be used to _find_ or _derive_ parameter sources.
|
||||
* the node graph is built bottom up, starting at the source, then via the effects attached locally to a clip, further on upwards (directed by the tree of tracks) to be finally connected via global busses to the output ports. Rendering pulls from these output ports.
|
||||
* Joelholdsworth, Cehteh, Ichthyo and Rcbarnes agree that the plain _node-editor_ approach is problematic in the context of a NLE. It shows too much details and fails to capture the temporal aspect. We strive at having node-like features and flexibility, but rather within the timeline.
|
||||
* especially, the topology of the node graph isn't constant over the whole timeline. But it's the job of the builder in the Proc layer to deal with these complexities, the user shouldn't be overwhelmed with all those details.
|
||||
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
* some people in europe complained that 21:00 UTC is too late, esp. with daylight saving
|
||||
* there was the proposal to alternate between the current schedule, and sunday 16:00 UTC
|
||||
* but Joel can't attend on sunday afternoon for now
|
||||
* so we settle down on thursday, 16:30
|
||||
|
||||
Next meeting: *Thursday 3. July 2008 16:30 UTC*
|
||||
94
doc/devel/meeting_summary/2008-07-06.txt
Normal file
94
doc/devel/meeting_summary/2008-07-06.txt
Normal file
|
|
@ -0,0 +1,94 @@
|
|||
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
|
||||
* ichtyo 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++/Gtkm
|
||||
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
|
||||
ichtyo:
|
||||
|
||||
* 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. 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.
|
||||
|
||||
|
||||
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. 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.
|
||||
|
||||
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: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[]
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
The next meeting will be held Thursday, 7 August 19:00 UCT.
|
||||
74
doc/devel/meeting_summary/2008-09-04.txt
Normal file
74
doc/devel/meeting_summary/2008-09-04.txt
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
2008-09-03 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Joel Holdsworth
|
||||
:Date: 2008-09-05
|
||||
|
||||
Participants
|
||||
------------
|
||||
* ichthyo
|
||||
* cehteh
|
||||
* joelholdsworth
|
||||
* Plouj
|
||||
* thorwil
|
||||
* wildhostile
|
||||
|
||||
|
||||
Boilerplate
|
||||
-----------
|
||||
|
||||
Organization of this meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
* joel
|
||||
* ichtyo is chairman
|
||||
* there is no agenda, so this is a freeform meeting
|
||||
|
||||
Leftovers from last meeting
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
There are no leftovers
|
||||
|
||||
|
||||
Mailing Lists
|
||||
-------------
|
||||
* any improvements should be reported to cehteh
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
Plugin Interfaces
|
||||
-----------------
|
||||
* all plugin interaction, including manifest queries will happen through the system of 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.
|
||||
* 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
|
||||
-----------------------
|
||||
* 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.
|
||||
|
||||
Builds and Buildbot
|
||||
-------------------
|
||||
* ichthyo asks for help setting up a test/build server
|
||||
* We now have build scripts based on scons and autotools.
|
||||
* All current build systems have different problems.
|
||||
* ichthyo will take care of the Debian packages for Lumiera and NoBug
|
||||
|
||||
Website Transition Plan
|
||||
-----------------------
|
||||
* There's lots of work to do on the website - transitioning etc. that the core developers don't want to get bogged down with. We need a web developer to volunteer.
|
||||
* All the website stuff is stored in git, and works through Asciidoc, which is not difficult to learn.
|
||||
|
||||
Logo Design
|
||||
-----------
|
||||
* Postponed for the next meeting when joelholdsworth is around.
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
The next meeting will be held Thursday, 2 oct 21:00 utc.
|
||||
|
||||
|
||||
Comment
|
||||
~~~~~~~
|
||||
re "ichthyo asks for help setting up a test/build server" for "Debian"
|
||||
|
||||
see "Build Server" at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming?action=edit&editor=gui[]
|
||||
232
doc/devel/meeting_summary/2008-10-10.txt
Normal file
232
doc/devel/meeting_summary/2008-10-10.txt
Normal file
|
|
@ -0,0 +1,232 @@
|
|||
2008-10-10 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Ichthyo
|
||||
:Date: 2008-10-15
|
||||
|
||||
Oct 10, 2008 on #lumiera 19:00 - 23:15 UTC +
|
||||
|
||||
__Participants__
|
||||
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* alcarinque
|
||||
* !KenSentMe
|
||||
* Plouj
|
||||
* raffa
|
||||
* thorwil
|
||||
* Victor_Sigma
|
||||
* wildhostile
|
||||
|
||||
|
||||
organisational
|
||||
--------------
|
||||
Not much of a fixed agenda this time.
|
||||
+
|
||||
Agreement to start with the Logo discussion, as this is of general interest, followed by the design drafts and similar dev topics.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
* it would allow for a lot of people to really participate
|
||||
* it could help to shape a general (graphic) style for Lumiera
|
||||
* it could underpin the fact Lumiera indeed is a collaborative effort
|
||||
* it doesn't mean additional work for the core devs on the whole
|
||||
* it helps spreading the word
|
||||
|
||||
Then, there is some discussion about the requirements. The core devs are concerned to keep up some quality level, because there is the possibility for the community to embrace a design, but when Lumiera enters the area it is intended to do, the standards of comparison will be different. The GIMP logo can be quoted as a negative example here.
|
||||
|
||||
|
||||
Conclusion
|
||||
~~~~~~~~~~
|
||||
There will be a Lumiera Logo contest.
|
||||
|
||||
* 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)
|
||||
* then, after a pre-selection phase, the vote shall be conducted prior to the December meeting.
|
||||
|
||||
Some minimal technical requirements will be enforced:
|
||||
|
||||
* the basic sign fits a compact rather quadratic bounding box (like 4:3)
|
||||
* easy to print on various media (on posters, t-shirts, ..)
|
||||
* basically a shape, using only a small number of solid colours (web safe)
|
||||
* should work on different backgrounds, esp. not requiring white background
|
||||
* the design should scale from microscopic size (favicon) up to big posters
|
||||
* vector graphic source is mandatory
|
||||
|
||||
Besides, we give some artistic guidelines
|
||||
|
||||
* it should be recognisable
|
||||
* 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 be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented
|
||||
|
||||
Raffa volunteers to help organizing the contest and the voting.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Recurring Topics: design proposals
|
||||
----------------------------------
|
||||
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts.
|
||||
|
||||
|
||||
Mistakes to avoid
|
||||
~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[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 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.
|
||||
|
||||
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.
|
||||
|
||||
__Conclusion__: drop it
|
||||
|
||||
|
||||
on the question of separate processes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The only practical solution would be to separate the GUI. Separating backend and proc-layer doesn't make much sense, technically speaking. We re-considered this question. Joelholdsworth (GUI) and Ichthyo (Proc-layer)prefer running the GUI in-process and to avoid the additional hassle with shared memory. Cehteh (backend) doesn't care for know and would like to re-discuss it as an option later on. This is somewhat similar to the possibility of running Lumiera distributed over the network, which is a goal, but not an immediate one.
|
||||
|
||||
|
||||
|
||||
Tag Clouds
|
||||
~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources[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"]
|
||||
|
||||
__Conclusion__: drop it
|
||||
|
||||
|
||||
|
||||
|
||||
Overview of Lumiera Architecture
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[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.
|
||||
|
||||
__Conclusion__: accept it, change the image to a link
|
||||
|
||||
|
||||
|
||||
|
||||
EDLs as Meta-Clips
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips[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.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
|
||||
The Builder
|
||||
~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder[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)
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
|
||||
High-level Model
|
||||
~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel[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.
|
||||
|
||||
__Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation?
|
||||
|
||||
|
||||
|
||||
|
||||
Lua scripting language
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage[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)
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
|
||||
|
||||
|
||||
Time Handling
|
||||
~~~~~~~~~~~~~
|
||||
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[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.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
Note: the proposed rigid testsuite for time handling is necessary only when we introduce a wrapper...
|
||||
|
||||
|
||||
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.
|
||||
|
||||
__Conclusion__: accepted
|
||||
|
||||
general Topics
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
No conclusion yet, to be discussed further.
|
||||
|
||||
|
||||
|
||||
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]
|
||||
|
||||
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
|
||||
|
||||
* 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)
|
||||
* implementing such an interface can be done in 3 major ways
|
||||
* 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_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
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Conclusion
|
||||
~~~~~~~~~~
|
||||
|
||||
looks good, agreement by all core devs.
|
||||
+
|
||||
Should be reviewed and investigated in detail to find any hidden problems.
|
||||
|
||||
|
||||
|
||||
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...
|
||||
|
||||
The next meeting is scheduled for '''Wednesday Nov 12 2008 19:30 UTC''' at #lumiera
|
||||
72
doc/devel/meeting_summary/2008-12-10.txt
Normal file
72
doc/devel/meeting_summary/2008-12-10.txt
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
2008-12-10 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Teld
|
||||
:Date: 2009-01-12
|
||||
|
||||
Dec 10, 2008 on #lumiera 20:15 - 00:45 UTC +
|
||||
|
||||
__Participants__
|
||||
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* Teld
|
||||
* tchy
|
||||
* Divinespectrum
|
||||
* raffa
|
||||
* kirk
|
||||
* Victorsigma
|
||||
* pedro
|
||||
* thorwil
|
||||
|
||||
|
||||
The Lumiera Logo
|
||||
----------------
|
||||
|
||||
The logo contest is a great success: http://www.pipapo.org/pipawiki/Lumiera/Logos[105 entries]. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection[presented] so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight.
|
||||
|
||||
|
||||
Recurring Topics
|
||||
----------------
|
||||
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
__Conclusion__: the name Sequence will be used instead of EDL
|
||||
|
||||
|
||||
Interfaces between layers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Ichtyo explains that the idea is that between layers only the C Language interfaces of the interface system are used. Wrappers have been made so that a convenient C++ interface is available.
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
General Topics
|
||||
--------------
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
|
||||
The next meeting will be at Wednesday 14 jan 21:00 UTC
|
||||
|
||||
|
||||
122
doc/devel/meeting_summary/2009-01-14.txt
Normal file
122
doc/devel/meeting_summary/2009-01-14.txt
Normal file
|
|
@ -0,0 +1,122 @@
|
|||
2009-01-14 Lumiera Developers Meeting
|
||||
=====================================
|
||||
:Author: Raffaella_Traniello_and_Goibhniu
|
||||
:Date: 2009-02-25
|
||||
|
||||
Jan 14, 2009 on #lumiera starting 20:00 UTC
|
||||
|
||||
|
||||
__Participants__
|
||||
|
||||
* cehteh
|
||||
* ichthyo
|
||||
* joelholdsworth
|
||||
* raffa
|
||||
* goibhniu
|
||||
* Teld
|
||||
* nikola_
|
||||
* thorwil
|
||||
* SimAV
|
||||
* raevol
|
||||
|
||||
|
||||
The Lumiera Logo - Workflow and GUI
|
||||
-----------------------------------
|
||||
Everyone is pretty happy with the results of the logo contest. The logo still needs some refinements, especially:
|
||||
|
||||
* the font
|
||||
* angle of view
|
||||
* single logo or multiple logos based on a theme (dynamic logo)
|
||||
Logo work discussion has started on Mailing list but it is dying out.
|
||||
|
||||
Workflow and GUI discussion has already started on Mailing list. Keeping it effective and useful demands core devs time and energy.
|
||||
|
||||
|
||||
Conclusion
|
||||
~~~~~~~~~~
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Group 1 [WORKFLOW]
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
. 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. +
|
||||
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. +
|
||||
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. [[BR]] It thinks about ergonomics.
|
||||
|
||||
|
||||
Group 2 [ARTWORK]
|
||||
^^^^^^^^^^^^^^^^^
|
||||
. director/supervisor: raffa (Raffaella Traniello)
|
||||
The group discuss about logo, themes, the look and feel...
|
||||
|
||||
|
||||
Getting the 'non-coders' community to help
|
||||
------------------------------------------
|
||||
goibhniu proposes an issue tracker.
|
||||
|
||||
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)
|
||||
|
||||
|
||||
Conclusion
|
||||
~~~~~~~~~~
|
||||
* goibhniu volunteers to set up Trac.
|
||||
* raevol volunteers to maintain it.
|
||||
* The link:AsciiDoc[] Day idea will be discussed at the next meeting.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[]
|
||||
(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?
|
||||
|
||||
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.
|
||||
|
||||
|
||||
# Errors, Assertions, Checks, Dev- and Release-Builds
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A new Nobug is nearly ready with new documentation (cehteh). The error handler has been improved, as announced on the ML. Cehteh emphasised the importance of using nobug everywhere and not `#if DEBUG`:
|
||||
|
||||
DEBUG is not a standard C/C++/buildsystem defined macro when it works its just coincidence but NDEBUG is standard. Neither does such code use nobug facilities nor respect nobug build levels.
|
||||
|
||||
in new nobug you can do:
|
||||
NOBUG_IF_ALPHA(
|
||||
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.
|
||||
(http://www.lumiera.org/nobug.html)[]
|
||||
|
||||
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
|
||||
and running the testsuite under valgrind works properly now
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
Usually meetings are the second Wednesday each month on #lumiera at Freenode. The next meeting will be on Feb 11 - 20:00 UTC
|
||||
|
||||
|
||||
Core dev's IRC meetings
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
cehteh proposes a recurrent core dev meeting, more frequent than the monthly meeting since there is the a lot of stuff ahead that needs communication.
|
||||
|
||||
118
doc/devel/meeting_summary/2009-09-09.txt
Normal file
118
doc/devel/meeting_summary/2009-09-09.txt
Normal file
|
|
@ -0,0 +1,118 @@
|
|||
2009-09-09 Lumiera Developers Meeting
|
||||
=====================================
|
||||
Raffaella_Traniello_and_Hermann_Voßeler <prg@ichthyostega.de>
|
||||
|
||||
Sep 9, 2009 on +#lumiera+ +
|
||||
^20:00 - 22:30 UTC^
|
||||
|
||||
.Participants
|
||||
- cehteh
|
||||
- ichthyo
|
||||
- joelholdsworth
|
||||
- andrewjames
|
||||
- daniieel
|
||||
- hermanr
|
||||
- liveD
|
||||
- raffa
|
||||
- SimAV
|
||||
|
||||
|
||||
|
||||
Point 1: FrOSCon
|
||||
----------------
|
||||
|
||||
Our participation to the conference was a success. We met other video
|
||||
developers and people interested in Lumiera.
|
||||
It has been a meeting opportunity for the community, it produced good and
|
||||
reusable propaganda material (about 100 flyers distributed).
|
||||
This success wouldn't be possible without a lot of people helping. +
|
||||
So lets say: *Thank you all*!
|
||||
|
||||
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
|
||||
(in German).
|
||||
|
||||
Participation as a group to other possible events has been considered for +
|
||||
(in order of interest):
|
||||
LAC, Piksel, OVC, Piksel Summer camp, Linuxtag, FSCONS.
|
||||
|
||||
To improve visibility _liveD_ proposes to extend the project also on the
|
||||
new social network like facebook. +
|
||||
The proposal is discussed but doesn't find supporters.
|
||||
|
||||
|
||||
Point 2: Funding
|
||||
----------------
|
||||
|
||||
Preparing for FrOSCon had some costs, paid by the people working in
|
||||
Lumiera. Ideally, _cehteh_ says, people working on Lumiera should not have
|
||||
to pay for working on it, no matter who pays.
|
||||
He proposes to make a project partnership with FFIS (a German non-profit
|
||||
organisation for founding free software).
|
||||
That means we could officially collect donations through FFIS (people
|
||||
donate to FFIS, to free software in general or specifically to Lumiera).
|
||||
That could work out well for specific scopes, like covering travel,
|
||||
lodging and diet for developer gatherings or for exhibition material and
|
||||
server.
|
||||
|
||||
The proposal is accepted. _Cehteh_ will contact FFIS to propose them a partnership.
|
||||
If later on there will be funding for development (not just covering expenses)
|
||||
that would require a different approach and special communication with the
|
||||
community.
|
||||
|
||||
_daniieel_ proposes to put a price to each request in "buglist". +
|
||||
The proposal is discussed and dismissed.
|
||||
|
||||
|
||||
Point 3: Website
|
||||
----------------
|
||||
|
||||
The news in the homepage makes the project look alive. But this is not
|
||||
enough to communicate the state of the Lumiera development. Two
|
||||
solutions are proposed:
|
||||
|
||||
* The website needs to be reorganized and made accessible. andrewjames
|
||||
volunteers to work on it.
|
||||
* 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
|
||||
other devs to add their informations. Then someone shall aggregate this
|
||||
and make a news webpage. That creates a new task: help collecting the
|
||||
news and write them together.
|
||||
|
||||
The devs will communicate their achievements more often in small steps
|
||||
to the mailing list
|
||||
|
||||
_raffa_ proposes monthly news on the homepage with more broad topics
|
||||
(development, community, openvideo). +
|
||||
The proposal gets no interest.
|
||||
|
||||
|
||||
Point 4: Ticket Query clean-up
|
||||
------------------------------
|
||||
|
||||
Trac allows for creation of custom ticket queries. We've accumulated quite some
|
||||
custom reports, and _cehteh_ asks if some of them can be dropped (Ticket #225).
|
||||
_Ichthyo_ points out that he uses some reports frequently, and considers some
|
||||
others nice-to-have. Finally it turns out that only Report #5 isn't used by
|
||||
anyone and can be dropped.
|
||||
|
||||
_Cehteh_ points out that the http://issues.lumiera.org/tags[TracTags] macro
|
||||
is a convenient feature -- for example it allows to tag tickets by required skill.
|
||||
|
||||
|
||||
Point 5: Coding
|
||||
---------------
|
||||
|
||||
_Cehteh_ finished a first stable NoBug release and intends to give uWiki a boost
|
||||
in the next weeks. _Ichthyo_ worked on a command frontend usable at the GUI/Proc
|
||||
interface; in the next time, there will be some integration work to be done
|
||||
together with _Joelholdsworth_ to get the GUI and high-level model connected.
|
||||
|
||||
A short discussion about the relevance of uWiki for Lumiera follows. Indeed,
|
||||
it takes away some developer power, and _Joelholdsworth_ is concerned about that,
|
||||
as the project is a bit underpowered generally. _Cehteh_ on the contrary considers
|
||||
building a suitable (distributed) infrastructure as an important part of the
|
||||
project.
|
||||
|
||||
|
||||
|
||||
208
doc/devel/meeting_summary/2011-03-09.txt
Normal file
208
doc/devel/meeting_summary/2011-03-09.txt
Normal file
|
|
@ -0,0 +1,208 @@
|
|||
Lumiera Developers Meeting
|
||||
==========================
|
||||
:Author: Stefan Kangas
|
||||
:Date: 2011-03-09
|
||||
|
||||
March 9, 2011 on +#lumiera+ +
|
||||
^20:00 GMT - 23:30 GMT^
|
||||
|
||||
//Menu: label 2011-03-09
|
||||
|
||||
__Participants__
|
||||
|
||||
* Christian Thaeter (cehteh)
|
||||
* Francesco Siddi (fsiddi)
|
||||
* Hermann Voßeler (ichthyo)
|
||||
* Odin Hørthe Omdal (Velmont)
|
||||
* Raffaella Traniello (raffa)
|
||||
* Stefan Kangas (skangas)
|
||||
|
||||
The New Website
|
||||
---------------
|
||||
|
||||
The new website is finally online.
|
||||
|
||||
How do we proceed with the graphical layout?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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> so i will go on coding a static html layout
|
||||
21:38 <fsiddi> then will submit it to your critique and then we can make a template out of it
|
||||
...
|
||||
21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area
|
||||
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_2.jpg["Website Proposal Mockup number 2", width=128, link="{img}/meetings/2011-03-09-mockup_dev_2.jpg"]
|
||||
|
||||
Discussion about the IFrame
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The only serious alternative to IFrames seems to be SSI, since we want to keep
|
||||
generating pages with asciidoc, and not have to regenerate the entire website
|
||||
just because one page changed.
|
||||
|
||||
Conclusion was that we will stick with IFrames for now and change later when/if
|
||||
that becomes a problem.
|
||||
|
||||
Old stuff in the repository
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There is a folder /attic on the website.
|
||||
|
||||
This information is supposed to be merged with the rest of the website, and then
|
||||
deleted from its current location. This work is on-going and considered a
|
||||
"background task".
|
||||
|
||||
IRC Logs
|
||||
--------
|
||||
|
||||
A discussion was brought up about how to handle IRC logs.
|
||||
|
||||
For privacy reasons we do not want to save them routinely in public
|
||||
locations. If we put them on the web they will most probably be kept by Google
|
||||
until the sun burns out.
|
||||
|
||||
*robots.txt* might be respected by Google or not. Surely some other search
|
||||
engines will not respect it. Private logs or other logs not publically available
|
||||
are fine though.
|
||||
|
||||
22:40 <cehteh> well ... IRC should *not* be for persistent documentation .. we shall
|
||||
force/educate ourself to document things (and decisions) properly, irc
|
||||
should be volatile
|
||||
...
|
||||
22:41 <ichthyo> in the past, sometimes we had very "contentful" dicussions
|
||||
22:41 <ichthyo> in that cases we just saved a transcript
|
||||
...
|
||||
22:44 <ichthyo> so personally I prefer to make transcripts of the *really* contentful
|
||||
discussions and put them in the public documentation
|
||||
22:44 <ichthyo> "transcript" means cleaned up irc log
|
||||
22:44 <cehteh> yes
|
||||
22:45 <cehteh> so for meetings we should prolly do that
|
||||
22:47 <cehteh> not further edited but just leave all join/parts/noise and silly
|
||||
comments out
|
||||
22:47 <cehteh> (and also rants and stuff)
|
||||
22:48 <cehteh> only conclusions and most important arguments shall stay
|
||||
22:48 <cehteh> maybe reorder it a bit as it happens that we talk about 2 things at the
|
||||
same time
|
||||
22:48 <cehteh> but also not too much work on it
|
||||
22:49 <cehteh> and more importantly: document decisions and proposals in a more
|
||||
offical way: that is 'rfc'
|
||||
22:49 <skangas_> Agreed. It is more important to preserve information in an accessible
|
||||
way for the future than focusing on mundane details like
|
||||
join/part/order/ranting etc.
|
||||
22:50 <skangas_> This means I personally always prefer shorter summaries of a
|
||||
discussion to IRC logs, given that they do not leave anything
|
||||
important out.
|
||||
|
||||
VoIP discussions over Mumble?
|
||||
-----------------------------
|
||||
|
||||
There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux.
|
||||
|
||||
It was decided that while the idea is nice, it will not be used for developer
|
||||
meetings. We might use it for developer discussions outside meetings if we feel
|
||||
the need though. This will probably be more common as the number of developers
|
||||
increase.
|
||||
|
||||
Also, the point was brought up that GNU Emacs has really nice support for
|
||||
several people sharing the same session. Everyone gets their own point, and with
|
||||
some hacks it is even possible to color them differently. This needs to be done
|
||||
on an untrusted remote server though -- Emacs can do anything and it is thus
|
||||
highly insecure.
|
||||
|
||||
Version numbering
|
||||
-----------------
|
||||
|
||||
Hermann has written an rfc for version numbers.
|
||||
|
||||
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> where develtag is a timestamp
|
||||
23:20 <ichthyo> and we *could* make a stream of development versions
|
||||
23:21 <cehteh> YYYYMMDD should suffice
|
||||
23:21 <cehteh> or maybe just monotonic increading from 1
|
||||
23:21 <ichthyo> well... optional suffix+ number
|
||||
23:21 <ichthyo> for the rare cases that you roll two releases a day
|
||||
|
||||
...
|
||||
|
||||
23:20 <ichthyo> and the third idea of my proposal: *not* use major.minor.patch before 1.0
|
||||
23:24 <ichthyo> i.e. in the whole alpha... beta range
|
||||
23:24 <ichthyo> we just do 0.01 0.02 ... 0.99
|
||||
23:25 <skangas_> Does it go without saying that minor versions can go on above 1.9.0
|
||||
to 1.10.0 etc?
|
||||
23:25 <ichthyo> yes, I didn't mention that, but thats important
|
||||
23:26 <ichthyo> its not nice, and usually you get a major first, but it can happen
|
||||
23:27 <ichthyo> so i'd say, we have discussed it now, we could comment on it and then
|
||||
revisit it next time (and maybe decide on the proposal then)
|
||||
|
||||
23:27 <skangas_> Do we want a stable version and a development version?
|
||||
23:28 <skangas_> e.g. 1.0 is stable and 1.1 is unstable
|
||||
23:28 <skangas_> I am thinking about the scheme that wine and linux is using.
|
||||
23:28 <cehteh> i think linux won a lot with abadon this odd/even practice
|
||||
23:28 <ichthyo> regarding stable versions
|
||||
23:28 <ichthyo> personally, I don't like that idea
|
||||
23:29 <skangas_> cehteh: I did not know they had abandoned it.
|
||||
23:29 <cehteh> skangas: linux dont use that anymore
|
||||
23:29 <cehteh> since 2.6 years ago
|
||||
23:29 <ichthyo> because they tend to rot
|
||||
23:29 <skangas_> ichthyo: The stable versions?
|
||||
23:29 <cehteh> you just make a release and done .. everything after that is for the
|
||||
next version
|
||||
23:29 <ichthyo> yes
|
||||
23:29 <cehteh> the only thing to discuss is how you count there
|
||||
23:30 <ichthyo> also, it is more in line with the "extreme programming" style
|
||||
23:30 <ichthyo> i.e. don't do too disruptive changes
|
||||
23:30 <cehteh> if you want 'pre' or 'rc'
|
||||
23:30 <ichthyo> but rather refactor often
|
||||
23:30 <skangas_> OK.
|
||||
23:31 <ichthyo> there is onre concern though
|
||||
23:31 <ichthyo> there *needs* to be some stability then
|
||||
23:31 <cehteh> releases get only bugfixes and *maybe* you can declare some release as
|
||||
LTS ... but for lumiera i would think really hard about that and likely
|
||||
deny that
|
||||
23:31 <ichthyo> because people are working with the software
|
||||
23:31 <ichthyo> but we want to have that with our compatibility scheme
|
||||
23:31 <cehteh> (our interface system should provide backward compatibility)
|
||||
23:31 <ichthyo> yes
|
||||
23:31 <ichthyo> but anyway, it *might* turn out that we fail with that promise
|
||||
23:32 <ichthyo> and then we'll have to reconsider a "stable" line
|
||||
23:32 <cehteh> so maintaining some LTS while having another development branch will
|
||||
suck developer resources
|
||||
23:32 <ichthyo> yes
|
||||
23:32 <ichthyo> so I'd really try hard to avoid that
|
||||
23:33 <cehteh> well a stable line yes ... that is 'stable' until the next stable
|
||||
release is there .. and then 'maintained' as in adding important
|
||||
bugfixes for some (but not excessive) time
|
||||
23:33 <cehteh> we need to care for a stable for sure
|
||||
23:33 <ichthyo> indeed, but it shouldnt digress too much from the active development
|
||||
23:33 <cehteh> but we dont want some really old release to get permanent updates and
|
||||
care because we declared it as LTS
|
||||
23:33 <skangas_> ichthyo: Is your RFC open to editing/additions?
|
||||
23:34 <ichthyo> yes
|
||||
23:34 <ichthyo> please go ahead, just add comments etc.
|
||||
23:34 <cehteh> use the rfc.sh comment function :)
|
||||
23:34 <skangas_> I was just thiking about writing this down in some way, that we
|
||||
specifically do not want this.
|
||||
|
||||
23:23 <cehteh> also do we want 'rc' releases?
|
||||
23:23 <cehteh> or do we just declare certain devel snapshots as rc (i like the later)
|
||||
23:23 <ichthyo> yes, thats what I'd prefer too
|
||||
23:24 <cehteh> devel snapshots should be automatic buildable by builddrone
|
||||
23:25 <cehteh> I would like to make builddrone an automatic staging system
|
||||
23:25 <cehteh> add some 'rules' there ..
|
||||
23:26 <cehteh> if build and testsuite succeeds and test-install works and latests
|
||||
commit doesnt contain WIP: then stage a devel snapshot
|
||||
23:27 <cehteh> (eventually or maybe we might even put tests/bugs there which prevent
|
||||
certain staging actions, finally all integration and complete releases
|
||||
could be automatized)
|
||||
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
|
||||
|
||||
Next meeting
|
||||
------------
|
||||
|
||||
The next meeting will be at Wednesday April 13 20:00 UTC.
|
||||
285
doc/devel/meeting_summary/index.txt
Normal file
285
doc/devel/meeting_summary/index.txt
Normal file
|
|
@ -0,0 +1,285 @@
|
|||
Past Meetings
|
||||
=============
|
||||
|
||||
//Menu: sort children descending
|
||||
|
||||
Not all meetings gets summarized on this page. For example, there are no meeting
|
||||
summaries at all available for 2010. This only means that there were not enough
|
||||
things that needed deciding/documenting during these meetings to warrant someone
|
||||
spending time on the task of writing a summary.
|
||||
|
||||
Anyone interested in Lumiera development is also encouraged to read mailing list
|
||||
archives and other documentation.
|
||||
|
||||
|
||||
9 Mar 2011
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* The New Website
|
||||
* IRC Logs
|
||||
* VoIP discussions over Mumble?
|
||||
* Version numbering
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2011-03-09.html[Summary (written by Stefan Kangas)]
|
||||
|
||||
|
||||
.informal meetings, no summaries
|
||||
********
|
||||
In 2010, the monthly meetings where rather informal gatherings,
|
||||
without any relevant decisions beyond the organisation of conference activities.
|
||||
During that time, usually the two remaining Lumiera core developers where alternatively
|
||||
either prevented by real-life obligations, or otherwise just in ``deep coding mode''
|
||||
********
|
||||
|
||||
|
||||
9 Sep 2009
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* FrOSCon
|
||||
* Funding
|
||||
* Website
|
||||
* Ticket Query Clean-up
|
||||
* Coding
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2009-09-09.html[Summary (written by raffa and Ichthyo)]
|
||||
|
||||
14 Jan 2009
|
||||
-----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* organisational (protocol, agenda, leftovers?)
|
||||
* Logo Contest results, elaborating the winner concept
|
||||
* Forming a Workflow group
|
||||
* Set up a Trac for issue tracking
|
||||
* Getting the \'non-coders' community to help
|
||||
* Possible GUI-Integration: Display a frame?
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2009-01-14.html[Summary (written by raffa)]
|
||||
|
||||
|
||||
|
||||
|
||||
10 Dec 2008
|
||||
-----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* organisational (protocol, agenda, leftovers?)
|
||||
* Logo Contest progress, discussion about how to do the pre selection
|
||||
* rename "EDL" into "Sequence"
|
||||
* link:DesignProcess/TimelineSequenceOutput[Project, Timeline(s), Sequence(s) and Output]
|
||||
* GUI/Proc Interface and collaboration
|
||||
* Threading questions regarding gtk-main and main()
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-12-10.html[Summary (written by Teld)]
|
||||
|
||||
|
||||
|
||||
|
||||
12 Nov 2008
|
||||
-----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* organisational (protocol, agenda, leftovers?)
|
||||
* Logo Contest progress
|
||||
* uWiki Progress
|
||||
* Builddrone, any helpers?
|
||||
* Platform and lib dependency status
|
||||
* Discussion about foreseeable problems with Gui Plugins
|
||||
* Include dir and namespaces
|
||||
* build system, plugin tree
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
_(missing)_
|
||||
|
||||
|
||||
|
||||
10 Oct 2008
|
||||
-----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* organisational (protocol, agenda...)
|
||||
* Lumiera Logo
|
||||
* Design Process: Go through Ideas and Drafts
|
||||
- Mistakes to avoid
|
||||
- Tag clouds
|
||||
- Lumiera Architecture
|
||||
- EDLs as meta-clips
|
||||
- Builder
|
||||
- Lua scripting language
|
||||
- Time handling
|
||||
- Interface naming
|
||||
* Config System (1st version landed)
|
||||
* Use of Namespaces
|
||||
* Interface Definition Language
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-10-10.html[Summary (written by Ichthyo)]
|
||||
|
||||
|
||||
|
||||
|
||||
4 Sep 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, agenda, ...)
|
||||
* Plugin Descriptors
|
||||
* Mailinglist, setup, administration
|
||||
* Lumiera-work Mailinglist (for TODOs)
|
||||
* About Website transition plan
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
_(missing)_
|
||||
|
||||
|
||||
|
||||
|
||||
7 Aug 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* Go through Ideas and Drafts in design process
|
||||
* Config System (in the works)
|
||||
* Scripting language plans
|
||||
* GUI brainstorming page
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
_(missing)_
|
||||
|
||||
|
||||
|
||||
|
||||
6 Jul 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, what's left from last meeting)
|
||||
* Introduction of Lumiera
|
||||
* handling of config errors.
|
||||
* scripting language.
|
||||
* editing on small devices (eeePC)
|
||||
* uWiki.
|
||||
* 'musical' timeline in bars and beats
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-07-06.html[Summary (written by Teld)]
|
||||
|
||||
|
||||
|
||||
|
||||
6 Jun 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, what's left from last meeting)
|
||||
* Go through Ideas and Drafts in design process
|
||||
- processing node interface
|
||||
- Placement concept
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-06-06.html[Summary (written by ichthyo)]
|
||||
|
||||
|
||||
|
||||
|
||||
8 May 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, what's left from last meeting)
|
||||
* Go through Ideas and Drafts in design process
|
||||
* Website infrastructure
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-05-08.html[Summary (written by cehteh)]
|
||||
|
||||
|
||||
|
||||
|
||||
3 Apr 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, what's left from last meeting)
|
||||
* Go through Ideas and Drafts in design process
|
||||
* Call for volunteers (which tasks are to do, how can we interest people) for wiki/todo.html
|
||||
* Project announcements/registration (freshmeat, gnu, etc...) any takers?
|
||||
* Informal talk about the GUI (We have some people who want to contribute now, what's going on, how can they start)
|
||||
* froscon application (linux multimedia booth?)
|
||||
* timecode-metadata discussion: convert to arithmetic time type early or late?
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-04-03.html[Summary (written by sakalli)]
|
||||
|
||||
|
||||
|
||||
|
||||
6 Mar 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* boilerplate (protocol, whats left from last meeting, next meeting)
|
||||
* Go through Ideas and Drafts in design process
|
||||
* "Call for design" for some features relevant for the whole Application:
|
||||
- parameters and automation
|
||||
- render node interface
|
||||
- handling of compound sessions
|
||||
- session storage interface in general
|
||||
* Project name
|
||||
* Project Server, setup, organization, administration
|
||||
* GPL3 pros cons, license rationale
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-03-06.html[Summary (written by cehteh)]
|
||||
|
||||
|
||||
|
||||
|
||||
1 Feb 2008
|
||||
----------
|
||||
|
||||
Topics
|
||||
~~~~~~
|
||||
* Who will write the protocol below
|
||||
* Discuss the open points in link:Lumiera/DesignProcess[] do we need this formalism?
|
||||
* Who works on what, what are the short term goals, what tasks are open
|
||||
* State of the new-name search for the was-intended-as-cinelerra-3 project (no name discussion, just how we will progress!)
|
||||
* Introduce the development model
|
||||
* How to handle the regular meetings in future (day, time, where to put summaries)
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
* link:2008-02-01.html[Summary (written by Ichthyo)]
|
||||
|
||||
Loading…
Reference in a new issue