History: Resources and Background

Attic

This page is very long and intended as a place to stash away additional peripheral information, notes, extended explanations and a collection of pointers into further content of historical relevance.

2011: Start telling the Story of Lumiera by recalling the circumstances where the movement to improve Cinelerra started in 2007. Some HTML snapshots from 2008 and an undated copy of the polemic »Cinelerra Woes« in Moin-Moin markup had been preserved in some folder on Ichthyo's private PC.
2025: While researching the roots of some very old RfCs,
and as part of a general clean-up of the Lumiera website together with the preview release 0.pre.04, the HTML captures were rediscovered and transcribed into Asciidoc.

Revisiting these documents, together with further resources from Mailing List archives and the TidlyWikis preserved → <1> → <2> in the project Git history leads to a more reflected and coherent understanding of the initial movements leading to the Lumiera project.

Inception

Most of the activities connected to the formation of the »Cinelerra-3« project happened through informal cooperation via the #cinelerra IRC channel and by private mail exchanges. Unless something was captured and stored by some of the participants at that time, most records are gone.

The Archive of the Cinelerra mailinglist however is still available online.
[ And this implies that the mailinglist activity was also captured partially (but not completely) in the Internet Archive. Furthermore, Ichthyo has retained a local mbox folder with all posts since he joined this mailing list in October 2005. ]
Which allows to reconstruct some stepping stones of the interactions at that time.

the first proposal to modernise Cinelerra
the first public announcement of the »Cinelerra-3« effort
the official announcement of the new project.
the new project is named »Lumiera«

Timetable

Date	Actor(s)	Description
`2006-10-12`	Cehteh, Joh.Sixt	first mention of a Git repository set up by Cehteh to track the Cinelerra-Subversion repo and used by Johannes to help with merging tasks. This message seemingly slipped by accident onto the public Cinelerra Mailing list, and the response in this thread is the earliest record of Cehteh being active in the Cinelerra project.
`2006-12-31 18:39:23 -0800`		The original author of Cinelerra complains about what he considers a “list of authors” stored in the Community-SVN, interpreting this as an attempt to sideline him and not giving appropriate credit. The team is quick to respond and apologise, while Cehteh points out that this file is a technical artefact required by the Subversion-to-Git bridge; some days earlier, the Cinelerra-CV developers and Cehteh had indeed discussed how to populate and maintain this file, and notably the core developers did foresee the hurt reaction by Adam Williams (aka »Jack Crossfire«, »Heroine Virtual«). This banter puts a spotlight onto the situation regarding the community version of Cinelerra.
`2007-03-07`	Cehteh, Ichthyo	The first public proposal by Cehteh to modernise Cinelerra: He suggests to replace several hand-made solutions by facilities from the C++ standard library; Johannes Sixt responds in a slightly reserved way, and proposes he might start with introducing `std::string`; Ichthyo responds in support of this initiative, but raises the question of mergeability and cautions that a full fork would require much more developer manpower… Cehteh's answer is essential, and summarises his mindset at that time. Likewise, the response by Herman Robak should be noted, as he assesses that a technical clean-up would be prerequisite to attract more developers, and he urges to appreciate Cehteh's initiative. Furthermore, another member of the list speaks up and proposes a collaboration. [ The term “lack of developer power”, which was some kind of a formula often used in the Cinelerra community at that time, not only refers to a lack of »man months« to be expended on the project, but also the lack of coherent collaboration as a group. When Nathan Ryan asks in the mentioned proposal “Any thoughts or advice you as the developer community can pass on would be great. In particular I would like to know more about how we could work with you guys to create the best possible software”, then no-one is entitled to answer and speak for the group and no-one is able to commit some capacity for such a kind of collaboration. The status-quo is structured in a way that suffocates any initiative. And while Cehteh indeed answers to the proposal, he can only state his opinion and relate his answer to the kind of initiative he presumably hoped to start at that time. ]
`2007-04-16`	Andraž Tori	The developer most active in the community version during the last years, and the last one to contribute regularly and to respond to critical issues, announces that he has to step down and devote his time and attention to other issues; he points out that the situation of the community version is dire. Cehteh responds and mentions his initiative to rely on “the Git way” for collaborative work on Cinelerra, pointing out that some people have created improvement branches in their Git repos. Furthermore, he intends to focus more on infrastructure and clean-up than on bugfixes, considering this the most helpful approach. He even proposes monthly developer meetings coordinated on the Mailing List. This response and proposal is ignored completely by the community. People continue to discuss feature requests and ask for patches to be included (even while there is no active developer anymore)
`2007-04-28`	Ichthyo, Cehteh	Taking note of the conspicuous non-reaction to a grave if not critical situation, Ichthyo responds off-list. Cehteh invites him to join the “guerilla team” and grants him write access to his »Pipapo wiki«, so that Ichthyo would be able to publish design proposals and make announcements there. Both commence their first extended conversation on IRC and Cehteh shows his “braindump” page. But, unfortunately, Ichthyo is completely overloaded at that time, with his day-job in the finance sector, a CD project recording classical pipe organ music and work on an independent film project.
End of [ The exact date can only be guessed, since the earliest documented captures of these documents had a filesystem timestamp from 2008-03, and the content from the »pipapo wiki« was imported as part of the Lumiera website in 2010. The earliest timestamped comment (2007-06-04) by Cehteh can be found in the project proposal, while the »Design Process« RfC is marked 2007-06-03. Given that this was a Sunday, and handling the avalanche of responses to Ichthoyo's pamphlet took several days, we arrive in the last weak of May 2007. This is confirmed by the note “May 2007” at the start of the project proposal. ] May 2007	Ichthyo	Publication of »Cinelerra woes«, the »Cinelerra-3 Project Proposal and »best practices«. The vision text »Possibilities at hand« was published roughly one week later.
`2007-06-03`	Cehteh	RfC »Design Process« [ all mentions of the word `"cinelerra"` had been mass-replaced by `"lumiera"` early in 2008, after the new name was chosen in a vote by the community. ]
`2007-06-04`	Cehteh	adds comment to Ichthyo's Project Proposal with several arguments on why it might be better to “start from scratch”. [ Ichthyo immediately countered these arguments, and was backed by several other members on IRC; yet comments from Cehteh later this summer (notably in the first public discussions on the Mailinglist in August) indicate that he saw the existing code base of Cinelerra as a “bottomless pit”; he must have then arrived at that conclusion by some time in spring, since no further detailed investigation and work directly related to the old codebase was discussed throughout that Summer in the group. On the other hand, Ichthyo was well acquainted with the Cinelerra-2 code base, and had just succeeded in getting his “Bézier Patch” accepted by the Cinelerra-CV developers, and he published another patch while the new initiative was unfolding. ]
`2007-06-07`	Cehteh	RfC Distributed Development Framework based on Git, to replace all customary project management tooling.
`2007-06-08`	Cehteh	RfC Development Toolchain
`2007-06-09`	Cehteh	RfC Community Manifest
`2007-06-13`	Cehteh	Cinelerra-3 Announcment sent as private mail to the original author of Cinelerra, all developers associated with the Cinnelerra-CV community version and to select people considered to be active in the community. [ Years later, in September 2011, in commit `3a2a65d6d` Ichthyo wrote the section of the »History« page on the the project beginnings and added his copy of this mail, transcribe into Asciidoc. Notably the source of this page contains the full mail headers of this message, hidden as a comment. ]
`2007-06-18`	Cehteh	Initial Git commit. [ In line with Cehteh's vision, this Git repo was meant to serve as “distributed tooling”, initially to exchange updates to TiddlyWiki pages. However, due to the turns and twists of the »Cinelerra-3« initiative, this eventually became the first commit in the Lumiera project history. ]
`2007-06-19`	Ichthyo	elaborated UML diagram added to Git, showing components involved in the render.
`2007-06-26`	Ichthyo	first experiments with code generation from UML. [ These experiments were done on a branch `"prototype"`, which was mentioned in several internal mails, yet discarded later without being merged. The purpose (as can be inferred from those mails, was manifold: it was used as an example to discuss indentation styles, which eventually led to choosing GNU style; furthermore, it was used to experiment with build systems, and — last but not least — Ichthyo intended to use a hierarchy of skeleton classes, closely modelled after Cinelerra’s »EDL«, as a backdrop for prototyping work, intended to be integrated into the Cinelerra code base later. ]
`2007-06-27`	Cehteh, Ichthyo	Decision to use GNU style for newly written code. [ This discussion and the following decision seem plausible at a glance, given that the development team seemingly agreed to produce some prototypical code quickly. They knew that matters of code style had to be decided early, preferably immediately, to avoid “bikeshedding”. However — given the specific circumstances at the on-set of this new initiative — it still seemed strangely mis-aligned to launch into debate on selecting a code style; the code was only intended to serve as a prototype, and meant to be integrated into the then current Cinelerra code base. So this might be seen as yet another indication that Cehteh (who was pushing to pick a code style instead of just using the default from Bouml) had already made up his mind at that point to aim at a new code base, separate from the existing Cinelerra-2. ]
`2007-06-29`	Cehteh	RfC All Plugin Interfaces are C
`2007-07-02`	Ichthyo	recommends the use of a SCons based build system, after investigating alternatives and building a prototype. [ The proposal to investigate SCons and CMake was made by Cehteh, based on “favourable mentions” within the community. Ichthyo investigated several systems, but quickly narrowed them down to SCons, which is written in Python and defines the build in a DSL written in Python. Furthermore, he showed how the build can be extended by “build tools” written in Python. Cehteh had investigated CMake, but was disappointed with both systems: “ich hab jetzt in cin3 bissl mit scons gespielt, ist ok, aber nicht gerade wirklich gut, dann hab ich mal cmake angefangen (siehe nen branch) ist eigentlich das gleiche in grün, kann alles, aber auch nur umständlich” [SCons is OK-ish, yet far from compelling, and CMake is just plain confusing]. He then publishes a page to state his discontent with the existing tooling to build code, and describes what he would consider a “smart” build system. ]
`2007-07-03`	Cehteh	RfC Naming scheme for C Interfaces. [ While the RfC is titled »C Coding Style Guide«, the text, especially the comments, appear confusing; however, it is linked directly to the Plugin RfC and its purpose becomes more evident when viewed from the perspective of the Plugin architecture debate, which unfolded at the same time. ]
`2007-07-03 — 2007-07-10`	Ichthyo, Cehteh, Plouj	Debate on introducing a Plugin-centric architecture, that ended without a clear resolution.
`2007-07-11`	Cehteh	declares the Plugin-RfC as accepted.
`2007-07-15`	Cehteh	first commit to add code: a draft for a plugin loader.
`2007-07-19`	Cehteh	adds an Automake build system and promises to maintain it.
`2007-08-08`	Ichthyo	performs the code generation from the UML model — after configuring Bouml for GNU style — and checks in the resulting hierarchy of skeleton code, to be used as a starting point for the render engine prototype.
`2007-08-13`	Ichthyo, Cehteh	add a minimalist Unit test runner and test suite written in C++, complemented by a shell script to launch collections of test executable invocations
`2007-08-15`	Cehteh	first “public” announcement of the »Cinelerra-3« effort on the Cinelerra Mailinglist. [ This was not really a planned, official announcement, since the developers had previously agreed to avoid public “wishlist” discussions and and evaluate a code prototype first, so that the new proposed initiative could be backed by facts and achievements. However, the mention of the term »Cinelerra-3« started to appear occasionally on the mailinglist, since most of the internal discussions among the developers took place in the `#cinelerra` IRC channel and where thus effectively visible in public (you just needed to know where to look). In one of the numerous threads to analyse the desperate situation and the various issues of the Cinelerra project, this time by Marcos Cabalero, a Cinelerra user working in the media industry in Argentina. As part of the ensuing discussion, Herman Robak hinted at the new effort: “I think Christian Thäter’s protocols for work on Cin3 are clever”, then repeating the distinction between “talkers” and “doers” he frequently made. Cehteh responded soon thereafter with the summary statement, which can be considered the first public representation of the new initiative. ]
`2007-11-15`		Piksel07 Festival in Bergen (Norway). Herman Robak, Oracle2025 (Richard Spindler), Cehteh, Raffa (Raffella Traniello) and Vale (Valentina Messeri) meet there; video editing with Free Software is one of the topics of the festival. Cehteh explains the advantages of contributing through using Git and distributed tooling, while Richard holds an Open Video workshop to demonstrate a complete video workflow with his Open Movie Editor. There is also a discussion round to analyse problems open on video editing on Linux → summary. [ It is remarkable that the discussion among developers almost entirely revolves around issues of video technology — which are certainly notoriously challenging. The discussion thread following the mentioned protocol of “problems for video editing on linux” is a good example. There appears to be widespread consensus that simple building blocks should be provided as free software, that “can be used to combine new functionality”. However, it would appear that users suffer from quite different problems. ]
`Winter 07/08`		Mailinglist and IRC users continue to propose new initiatives to address the problems: → Cinelrra Usability · make Cinelerra smart · I believe in Cinelerra · I believe … continued · Proposal: Open Video Platform
`2007-11-26`		The very first message from the original author in a year: A complaint about misrepresentation. [ Some days before, a member of film maker’s IT staff had contacted the list to express his gratitude for the work done on Cinelerra, asking how it would be possible to get involved and how support to build a render farm could be obtained. This individual indicated that they would like to donate money. Adam Williams, the original author responds that “cvs.cinelerra.org did not write most of the software and they do not contribute to the original tree”. This hurtful response seems to indicate again, that — even after all those years — Adam still does not comprehend what a Free Software community is all about; presumably he perceives the community as a group of impostors who try to damage his reputation and discredit him of his work. To put this into appropriate context it should be noted that numerous individuals had reached out and contacted him throughout the year to request that he join discussion. Some weeks later, it was reported within the community that Adam had responded by private mail to one of the developers involved into the »Cinelerra-3« effort, pointing out that over the years he has seen numerous “students” trying to tell him how to build an application. ]
`2008-01-25`	Adam	The original author of Cinelerra, speaking on behalf of Heroine Virtual Inc, requests to drop the name »Cinelerra-3«, since it would interfere with their planned schedule and feature set. [ Within the »Cinelerra-3« group, this statement is interpreted as insipid if not insulting to the community, which also clarifies that any possibility of re-integrating any improvements into »upstream« code would be rejected. Ichthyo responds with an official statement to clarify how the initiative formed and that it will continue henceforth as a separate project, including the adoption of an entirely new name. As too be be expected, the ensuing thread immediately digresses into a discussion about UI toolkits, leading to the topic of UI plugin interfaces, and closing again with a summary by another user, explaining what is broken both with the software and the organisation of the Cinelerra project. ]
`2008-01-28`	Ichthyo	Official statement: a new separate project begins.
`2008-01-28`	Hermanr	Proposal to form a new »Cinelerra-2« group with the goal to organise the improvement of the software, on the grounds that the »Cinelerra-3« initiative is now officially a separate project. This proposal does not find much resonance.
`2008-01-30`		Start of an extended series of discussion threads on UI toolkits. [ Although developers of the new project immediately stated that there would be no agenda for UI toolkit debate for some time to come, reality revealed itself otherwise as such discussions seem usually unavoidable: The interface is the only part of the software to which a user can relate to. However, during those discussions, some notable statements were made, which clarify the attitude of the developers: → 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 ]
`2008-02-01`		First official Developer Meeting of the new project
`2008-03-07`	Raffa Odin	The new project is now named »Lumiera«. [ A list of names were proposed by the community for the project, the proposals were narrowed down by applying a set of rules, selecting 15 candidates from ~250 proposals. Finally, the name of the project was determined through a naming contest using a Condorcet Voting scheme. All people registered for the Cinelerra Mailing list were allowed to cast a vote, since these are considered to be the active community. ]

History of Cinelerra

Cinelerra was first released in August 2002. According to the Wikipedia article, the author had developed a predecessor »Broadcast 2000« since 1996, which was audio-only at start, aiming at audio for broadcast production. The ability to play-back a video track was added eventually, in 1999 — and various internal limitations related to the UI caused the rewrite into Cinelerra. According to a common narrative, the Author was way ahead of the time to recognise the potential of PC hardware to allow for independent film production outside of the system of the media industry.

For a long time, the identity of the original Author and the relation to the Heroine Virtual Ltd company was steeped in mystery. This setup was chosen intentionally, as the pseudonymous character Jack Crossfire aka »the Heroine Warrior« pointed out in an interview in 2003 with O’Reilly’s Linux devcenter:

“In a shrinking industry like we’re in now, managers aren’t ready to see staff engineers building killer apps outside their day jobs, and they aren’t afraid to get rid of anyone who ignores the system. You can’t release software under an individual name when that happens, so »Heroine Virtual Ltd.« became the entity under which all our content creation tools would appear. We leave it to your imagination how many people are behind it.”

— Jack Crossfire 2003

It is well established meanwhile that “Jack Crossfire” is a pseudonym for Adam Williams, as was confirmed by himself in March 2007 on the Cinelerra Mailinglist:

“Could you use Adam Williams instead of Jack Crossfire for license notices? He is unemployed again and doesn’t have the conflict that he did before.”

— Heroine Virtual Ltd. 2007

The interview mentioned above is a recommended read, as it touches onto various subjects related both to the technological hurdles to overcome, as well as to his attitude towards collaborative development:

JC: (…)
Now, before we get into another war about evil murdering dictators oppressing free software developers by withholding important technical documents, the lack of import and export capability is probably going to solve itself in the long term.

More and more of the compatibility between external devices and Linux boxes is moving from hardware implementation to software implementation. For some new high definition camcorders coming out, the interface change is purely in software. Instead of creating new I/O boards with new registers sets and logic waveforms, they’re using the existing I/O boards while changing the software to decode MPEG-2 instead of DV. It’s virtually impossible to support new I/O boards, while it’s relatively easy to support new software protocols.

That isn’t to say the evil murdering dictators should continue refusing interviews with their driver developers, but free software developers can get their biggest gains by doing more in software instead of hardware.

ORN: What kind of help could Cinelerra use from those willing to volunteer their skills?

JC: The biggest contributions would be detailed explanations of how to crash it. There are a lot of crash situations, but they’re very hard to reproduce.

We’re always interested in new developments in image processing, new directions the content creation industry is headed in, and platform-independent assembly languages.

Finally, it takes a long time to incorporate outside changes. New code has to be verified against the current stability, and it has to be maintainable. So that limits the amount of new code that can be integrated to bug fixes or big, major features people are going to use all the time.

Supposedly, this is why a lot of programs have macro languages and language bindings. The problem is, the guys who use the macro languages to add new features are normally more interested in programming the language than using the program to create content.

A lot of people like the Autoconf system and want to rebuild the Cinelerra tree to use Autoconf. That system has proven to be real hard to cross compile with and it fills the screen with huge amounts of linker wrappers, compiler flags, compiler wrappers, concealing the important messages. Furthermore, these systems of layered build scripts and package configurators have grown so huge that it’s become just as hard to hunt down the right script flags as it is to configure a makefile.

ORN: Any advice for those interested in modifying the Cinelerra code to help improve/stabilize it? Or advice in developing Linux multimedia applications that deal with video?

JC: There are very few features that are going to justify the amount of work required to implement them. Unless you’ve got millions of dollars and a large staff of slaves, features that are big, major, and lasting in impact are the things you’ll be most rewarded for in your private software adventures. (…)

— Jack Crossfire 2003

Was Cinelerra only GPLed to avoid legal problems?

This hypothesis was spread frequently within the Cinelerra-CV community around the time when the Lumiera project started. While being a questionable claim in itself,
[ Only the initial author of a piece of software, who (still) holds the copyright, can place it under the protection of a Free Software license. A pseudonym however is not a person, and can thus easily be challenged. Consequently, this would not be a viable move to shake off an already existing litigation threat.
It might be seen as an attempt however to conceal traces and to prevent other people from establishing a possibly dangerous link to a person — especially if this person might be bound already by legal terms of an employment contract, and thus prohibited to undertake any actions that can be construed as competing with the interests of the employer. ]
it might be seen as a reflection of generally negative sentiment against “upstream”, which was perceived by the community as someone not sharing the “Free Software mindset” — an assessment based on the difficulties to establish any kind of collaboration with the upstream author of Cinerlerra.

The claim regarding litigation problems is based on a sentence, found in the introductory paragraph of the Wikipedia page until January 2007, which was then removed due to doubts regarding plausibility of that claim:

“Cinelerra was first released August 1, 2002, and was based in part on an earlier product known as Broadcast 2000. Broadcast 2000 was withdrawn by Heroine Virtual in September 2001; Heroine Virtual cited legal liability concerns in the wake of litigation from the RIAA and MPAA and the costs involved in high-end video production.”

— Wikipedia in 2006

However, the History of Cinelerra as told by Michael Collins 2014 paints a distinctively different image, and provides much needed background texture, necessary to understand the roots of Cinelerra and the people driving it ahead. This source, as well as the Interview quoted above rather indicate that Adam Williams always identified as a Free Software developer, and as an actor standing on his own feet. He sees Cinelerra as his brainchild, and feels responsible to steer its further development — yet always mixed with some concern of not being recognised properly, and the apprehension that his baby might be taken away.

The Footer at the bottom of the Archive capture from 2017 (of “our story”) might be seen as just another indication to support this impression

Notice: There are many versions of this application called Lumiera and "Cinelerra…." on other websites with various tweeks, random version numbers, & varying documentation, but this [here] is the distribution they’re all derived.

Donations and support to other websites and versions which are called "Cinelerra", "Cinelerra-CV" or "Cinelerra 5.xxxxxxxxxx???" do not fund development of Cinelerra. In fact, support with those versions does nothing but delay the actual development of Cinelerra, as originally envsioned, created, and developed almost 20 years ago.

Debate: Plugin-centric architecture

This section provides background information regarding a controversy, which surfaced after the first weeks of actual planning work had passed in the new »Cinelerra-3« initiative, in Summer 2007.

Both opponents had a strikingly different background of experience. Cehteh (Christian Thäter) had worked in a qualified job related to events and music, and as a freelance software developer, with a focus on system programming and embedded systems. At that time, he had already long-lasting connections with the Linux community in Karlsruhe and south-west Germany, and he had published several small-scale toolchain projects as Free Software. His wife had completed an ambitious video editing project with Cinelerra one year ago, and he had helped her with technical support, which has led to his involvement with the Cinelerra-CV community. His aspirations can be sumarised by the following quote from August 2008, in a response on the Mailinglist

My ideal would be if free software could be done in a evolutionary process, where good ideas are exchanged and reviewed between developers and maybe seasoned/interested users (only a distributed revision control system makes this possible). Good things will persist and be merged while unimportant or bad things just get abandoned (but stay alive somewhere in a public repo to be fixed or reconsidered anytime later).

On the other hand, Ichthyo(stega) (Hermann Voßeler) has a strong academic background. He worked for the past years in the banking sector, developing critical infrastructure in a small team of experienced developers, where code reviews, discussions about code quality and maintenance of legacy code is everyday practice. Since his time at the university, he has a vested interest in the dynamics of failing IT projects. He had succeeded with contributing some localised improvements and features to larger projects, but had no deeper ties with the Free Software community yet. Aside of his work job, he was involved into independent film making, did a lot of editing both on commercial and free software and increasingly used Free Software both for video and audio related to his CD production projects with classical music. His approach can be characterised by the conclusion of the Cinelerra woes text

Design matters; don’t blame the past, start improving it now: It is possible to attack problems even in a quite large and long living code base. We just need to leave the Problem perspective and switch to the Design and Architecture viewpoint. It is not necessary to cure thousands of isolated problems, but it will advance Cinelerra if we step back and introduce some structures, Layer separation, encapsulation and QA facilities and then, in a second step, rework and reorganize a few central facilities to provide a higher level of Integration.

The controversy arose at the point where a team of three developers had formed within a new development framework, and was about to start into actual coding. From the context, it can be seen that tensions were building up in various related topics. The actual dispute was set off by a RfC from Cehteh, to confine all plugin interfaces to plain-C. Together with his stated intention to use plugins as building blocks also within the application, this amounts to turning a C++ code base (Cinelerra) into a new C-style code base, where C++ programming techniques are relegated to a local context.

Subject: CStyleGuide

Date: Tue, 3 Jul 2007 21:30:20 +0200
From: Voßeler Hermann <Hermann.Vosseler@XXX-bank.de>
To: Christian Thaeter <ct@XXXXX.org>
CC: ploujj@XXXX.com

Am Dienstag, den 03.07.2007, 20:51 +0200 schrieb Christian Thaeter:

> Btw: seen my Interface / CStyleGuide proposal in the pipapo wiki? please
> review it carefully if it looks ok, I straight go into make a referene
> implementation, since this is a very low level building block.
>
yes, I have seen it this morning. I have to look at it more carefull
tonight, when at home. Basically, it looks OK for all external
interfaces, i.e. interfaces other external apps or components will use
to call to cinelerra or to embed within cinelerra. Good examples for
this type of things are LADSPA plugins or some video codec interface

For use /within/ the application we should consider the following
questions first:

* how much "plugin architecture" do we want? Does a "micro
  kernel/plugin" approach help? how then do we handle extension points?
* why should we constrain ourselves to just C linkage? For example for
  the effects plugins it's just natural to require each plugin to define
  a GUI object as well and then proxy the communication (Cinelerra2
  basically does the same, just does it create two instances of each
  plugin class, one for the processing and one for the gui). Same for
  exceptions: they wouldn't be used so commonly if they weren't helpfull 😉
  On the other hand: for a data storage plugin/interface
  I don't see much use in using classes at all because this is
  procedural by nature. (Thats the point where people start inventing
  all those silly singleton classes...)
* the internal interfaces shouldn't be fixed this much, because this
  hinders refacturing. Well, at least until we reach beta 0.98 😃

Hermann

Subject: Re: CStyleGuide

Date: Tue, 03 Jul 2007 23:18:49 +0200
From: Christian Thaeter <ct@XXXXX.org>
To: Ichthyo <prg@XXXXX.de>
CC: ploujj@XXXX.com

Voßeler Hermann wrote:
> (...) Basically, it looks OK for all external interfaces,
> i.e. interfaces other external apps or components will use to call
> to cinelerra or to embed within cinelerra. (...)
>
> For use /within/ the application we should consider the following
> questions first:
> * how much "plugin architecture" do we want? Does a "micro
>   kernel/plugin" approach help? how then do we handle extension points?

IMO as much as possible, I stated that the cinelerra main app should be
only a skeleton using plugins. (do we want to start more monolithic and
then factor plugins out, or plugins from start on?)

Extensions shall be considered when designing this interfaces. I also
considered to make the plugin interface extensible without breaking
compatibility (naturally it will turn out whats needed during
development of new features)

consider my favorite example
 (based on cin2, cin3 might be little different):
Cinelerra has tracks on the timeline, these tracks shall be plugins (we
provide plugins for audio and video tracks, but someone might provide
tracks for midi, 3D animation or such)

Tracks have some gui components
 1. patchbay
 2. timline drawing (thumbs for video, waveform for audio, notes for
midi, ...)

some internal components:
 1. list of clips on the track
 2. attached effects container

(and some more)

we now need to define/collect what interfaces are needed to implement
tracks. There will be not a single interface but a group of related
interfaces which in sum define the behaviour and gui rendering of a track.
 * cinelerra_track_gui_patchbay_interface
  defines the patchbay gui
 * cinelerra_track_gui_timeline_interface
  how timeline is rendered
 * cinelerra_track_effects_container_interface
  manage effects on the track
 * cinelerra_track_clips_interface
  manages clips (add/remove, order, ...)

these 'tracks' use in turn other interfaces we define, effects, codecs, ...

for effects plugins this is quite similar, we need at least a interface
for the gui component and one for the internal workings.

> * why should we constrain ourselfs to just C linkage? For example for
>   the effects plugins it's just natural to require each plugin to define
>   a GUI object as well and then proxy the communication (Cinelerra2
>   basically does the same, just does it create two instances of each
>   plugin class, one for the processing and one for the gui). Same for
>   exceptions: they wouldn't be used so commonly if they weren't
>   helpfull ;-). On the other hand: for a data storage plugin/interface
>   I don't see much use in using classes at all because this is
>   procedural by nature. (Thats the point where people start intventing
>   all those silly singleton classes...)

The Idea is here to make it possible to write plugins in any other
language, C bindings are the best thing to make this possible. The
downside is that glueing C++ is not effortless. I think it's still worth it,
but this is just a proposal.

> * the internal interfaces shouldn't be fixed this much, because this
>   hinders refacturing. Well, at least until we reach beta 0.98 😃

yes, my proposal only applies to 'external' interfaces. Unfortunately many
interfaces are considered external by this plugin architecture (whatever
we provide for us, we provide for people extending it too)

Subject: How to proceed?

Date: Wed, 4 Jul 2007 22:01:32 +0200
From: Voßeler Hermann <Hermann.Vosseler@XXX-bank.de>
To: Christian Thaeter <ct@XXXXX.org>
CC: ploujj@XXXX.com

Hi Christian, Hi Michael,

for my part I am now at the point where I could start coding. Yesterday
I looked at your UML and wiki, Christian, and I got the impression you
are at a similar point, as it seems to be a complete sketch and just
"the details" have to be worked out.

In the last discussions about plugins, interfaces and naming conventions
we touched several times this "good old C versus OO" question. I really
don't want to engage in these discussions anymore, basically it were
the arguments and fights of the 80ties and early 90ties and led to the
conclusion that no single paradigm can claim to be absolute superior;
probably this explains the gigantic success of compromise languages
like C++ and Java, which give us choice of paradigm within one environment.

Probably I told you about my background, having to deal everyday with
such object networks and collections (typically with objectrelational
mapping beneath and a distributed environment with parallel queries),
this led me to just "seeing" some striking structural deficiencies of
Cinelerra2 causing quite some of the user visible trouble. Further,
I experienced several times, that a combination of design patterns,
abstraction and separation of concerns can make such problems
manageable to the degree of almost disappearing; thus I come to
trust that this methods will work for the objectoriented part of
cinelerra as well. On the other hand, I don't have much in depth
knowledge about low level I/O and can't even judge the quality of
this aspect of the cinelerra code base.

In my work domain the last 10 years saw quite a hype of plugin/
microkernel and component based approaches, followed by much sobering
and sort of a "back-to-the roots" movement. Today, "Plain Old Java
Objects" and reliance on just the language's abstraction mechanisms
(which notably include some sort of introspection in all modern
languages though) is often found much more viable than all those EJB,
ActiveX, Corba and even SOA frameworks. To quote some observations

- plugin frameworks are either really universal and pay for this
  by being trivial (not allowing much more then be plugged together).
  Or they just pretend to be universal and arbitrary combinable,
  but indeed there is not just a microkernel, rather
  the system relies on very specific plugins being there and
  configured in a very specific way (and this can result sometime
  in a lousy architecture -- interesting question)

- when a plugin system really does what it promises, i.e. giving
  you the ability to combine the components dynamically in a
  rather unlimited way, this can lead to a plethora of different
  systems and maybe the "write once test everywhere", and finally
  the "dependency hell" and "metadata hell"

- microkernel/plugin systems which stand the test of time and don't
  degenerate are rare. One notable example is the ECLIPSE/OSGI.
  The key idea here is, not only to have plugins, but to have a
  generic mechanism, by which the plugins can provide extension
  points. Each plugin can create it's own new plugin framework
  so to say. Together with a good feature/bundle/installation
  management, this works surprisingly well (but is -- not much
  surprise -- quite complex and has a very steep learning curve).

- and last but not least the well known XP mantra. "You aren't
  going to need it": I have seen too many component frameworks
  invented to be open for the world, but really just used and
  extended by their inventors and even avoided by the younger
  team members.

You can hear a good deal of scepticism from this, while I am
d'accord with the basic Idea to stay open, extensible and
adaptable just by configuration. Personally, I tend rather to
making just plugin interfaces for subsystems, because so the
common purpose of all plugins of one sort can be clearly defined.

So, after rethinking, I'd now like to propose:
 * have a plugin interface for codecs (gstreamer?)
 * have application specific plugins for effects (basically
   just extend the capabilities of Cinelerra2 plugins a bit
   to include projector and mask)
 * add a LADSPA host (and ditch all hand written sound processors)
 * design the render engine from start as being self contained,
   so the render engine (together with these interfaces) is a
   embeddeable component)
 * add the glue language and a small objects/scriptable framework
   at the EDL level, to support things like your track patchbay
   or new editing methods and styles. (thats what I am aiming at
   with the "placements")
 * allow GUI components or extension modules (need to be compiled
   in, but easy to write even for beginners)

====================================

Now, personally I would like to think about this possibilities,
but start or proceed now with implementing a (just plain monolithic)
prototype of the core render engine + data backend, just to find
out where the real problems are hidden.

I say I'd like, because I really don't want to rush ahead
or to trap anyone into a specific programming or project style.

So, please, tell me if this would be an option, or if you would
prefer to stay in the planning and designing phase.

cheers,
Hermann
 (which has to wait for some really looong running 🙄 SQL queries
  at the moment...)

After that exchange, an extended and heated debate followed, and both continue to talk past each other…

Ichthyo refutes the benefits claimed by Cehteh, by arguments of architecture
Cehteh ignores Ichthyo's arguments and proposes technical solutions
Michael Ploujnikov proposes that
- Cehteh should actually implement his envisaged plug-in solution…
- Ichthyo should build a functional prototype of the session with an invocation of the Builder component, all in C++ and well structured using C++ interfaces…
- then all developers would investigate together how this can be translated into plug-ins
but Cehteh rejects such an assessment as a waste of time
Cehteh claims that the concerns regarding complexity can be addressed by using only simple function calls in plain-C
Ichthyo urges to complete a functional prototype for the render engine first

After having missed each other several times on IRC (Ichthyo was still very busy with his work job plus a music recording project and a film project), they meet in IRC on 2007-07-10 to settle this dispute

Cehteh starts the discussion by claiming that actually both of them would pursue very similar intentions, with only marginal differences
furthermore, he points out that he does not want to build a system of “Lego bricks” and all he wants is to introduce proper versioning to external plugin interfaces
Ichthyo attempts to voice his various concerns…
but Cehteh constantly talks him over and proposes a plethora of technical solutions to details, and digresses to several other topics
the discussion fades out on a rather benignly note, with
- “I think we can jump into the coding now” (Ichthyo)
- “this talk was a big progress” (Cehteh)

Next day (2007-07-11), Cehteh unilaterally marks the Plugin-RfC as accepted, without any qualifications or limitations, adding just the statement

“after a talk on irc, we decided to do it this way, further work will be documented in the repository”

In Hindsight it is not clear why Ichthyo did not object to this audacity.

As can be expected, this unsettled conflict flared up several times later down into the project’s development. A notable example is documented as part of the discussion regarding application start-up, more than a year later, in November 2008. Cehteh had opened a RfC regarding »Application Structure«, and Ichthyo commented

“(…) I am somewhat unsure if the purpose of this proposal isn’t rather to load just a micro kernel and then pull up components according to configuration. Because I wouldn’t accept such an architecture, and I clearly stated so right at the beginning of our project. I accepted a very flexible and language neutral plugin system on the condition that the core remains in control, stays „reasonable“ monolithic and componentization doesn’t handicap us in creating an architecture based on abstractions and exploiting the proven design patterns.”