Design Process : Mistakes to avoid

I am not sure yet about separating things into processes, generally it is clear that this would be more robust but there are some performance impacts and programming problems (massive amounts of data in shared memory). But most importantly, when a subprocess gets a job and crashes on it, it won’t complete the job, we don’t have a choice except gracefully abort it. From a user perspective “It doesn’t work!” there is no much difference to a complete crash. Well and yes we aim to make it crash proof rather, crashes a bugs and have to be fixed, period.

Lumiera will never ever loose work, we don’t plan to make a project file, auto-save way. Lumiera will keep projects in an internal database like format which consists of a Dumpfile and a continuous written logfile. After a crash/power-down whatever, this log just gets replayed. The advantages are countless, imagine persistent, selective undo and so on. Any other format (Cinelerra2 XML, MXF, …) will be realized by importer/exporter plugins.

Hereby I confirm that this comment still represents the stance of the Lumiera project regarding this crucial issue. We should not tolerate crashes, rather report them and contribute to improvements or alternatives.

And all user actions in Lumiera are captured as an Event Log, which can be replayed any time (and in altered form) to recreate any state of the edit.

Please look at our design drafts, things will be separated (little different than you describe here). We reuse things which are beneficial (gavl, ffmpeg, ..) but we are also aware that we reinvent the wheel for some things by intention. Lumiera’s goal is not just to glue some existing libraries together under a new Gui, there are already a lot projects trying this way. We rather aim for a 'Professional' high performance Video editing solution which does some things in a different (maybe more complex) way. We do not use existing frameworks like MLT or GStreamer because we believe that these do not fit our goals (GStreamer will be supported through plugins). We do not intend to produce yet another multimedia framework library to be used by others.

This entry captures in a succinct way the reason why we build Lumiera.

However, this also touches on a deeper theme:
Whenever we solve a substantial problem, we are tied and bound to our solution, and we have to stick to it. Thus, by solving such a problem for real, we loose the ability to do “anything we want, anytime”. Since we are human, we have to pick one path and forgo all the other, possible ones. Doing so is not a “mistake”.

Now one might try to escape from this dilemma, by defining flexibility or sovereignty as the actual problem. It seems even feasible to address this by turning it into a schematism — and then you are bound to that one.

Joel started working on a GUI recently and makes good progress. The UI should finally be quite flexible as it mostly provides a skeleton where plugins render to. We have quite a lot ideas about the UI and user input is welcome. The UI is currently the most separate tier in the design, i’d like to make it a plugin itself which is loaded when Lumiera is started in a Gui mode, but it is to early to say how exactly it will be integrated, except that we all agree that GUI is optional and Lumiera can also run headless, script driven.

It is many years later now; we indeed do load our GUI as a plug-in, yet have not gained much by this move. The reason is, what we actually need for editing video is hard to implement in any toolkit. Once you start solving that problem, you are bound in very intricate ways to the specific toolkit you just happened to choose (in our case, this is GTK).

In a nutshell, being “user-friendly and extensible” is not something to be solved at an abstract, generic level — we’ll have to face the fact that a beginner will have quite different demands than a experienced professional. And Lumiera is a tool for professionals. Being beginner friendly is certainly desirable, yet it remains a secondary goal, and we have not even made so much inroads regarding the primary goal.

Lumiera is a video editor we don’t care (*cough*, not really true) about video formats. Everything which comes In and goes Out is defined in plugins which handle video formats.

So this point is not hard to solve (use plugins), yet this obvious solution creates a lot of much more tricky problems. In Lumiera, we attempt to actually solve those secondary problems, instead of just stating “this can be solved by plug-ins” (as most other existing software does). Unfortunately, this makes the project very complex. The chosen path seems feasible, yet honestly, I do not know if we’ll ever make it.

Quote from Openhub.net (formerly »Ohloh«):

“Nuff said”…
Oh well, about user docs we like to get that impressive ratings there too, any helpers?

Here I’d like to add that writing is hard — any writing, not only writing code — and writing text that other people can understand and which is accurate at the same time is even harder. It requires a lot of resources, and typically developers are not good at writing in a way that is understandable by “average joe”, while people good at writing nice text seem to have quite some problems with understanding the thinking style pertinent to software engineering. So, let’s say: “we keep trying”

We refuse to make it cross platform intentionally. Most things are written in a portable style, and POSIX compatible; some might need platform specific fixes. But our target is primary Linux (because that’s what we use) secondary any other Free OS (hopefully we find some testers/maintainers for that). Lumiera might run on OSX and patches will be accepted, but it is not a free platform so we don’t care by ourselves. Windows due its different system interfaces will be hard to port, if someone wants to do that, have fun, we will accept patches to, but we do not support it in any way by ourselves.

For a typical “business” application, this is largely a problem of the UI; we tend to solve that problem by using web technology nowadays, of relying on similar frameowork solutions. Doing so however incurs significant cost; the following point — scripting languages — is one of the symptoms.

However, video processing is still a technology pushing the limits. We can address this either by aiming at an industrial setup, where the actual processing is done in a server farm. Or you can limit yourself to what can be achieved on a personal computer — which requires to keep priorities straight and deliberately abandon unnecessary secondary goals and “nice to haves”

The Lumiera project follows the second path.
What is essential thus becomes a question of philosophy, or politics.

At some point a scripting language will be required, be it to drive the testsuite, make headless rendering work and so on. This will likely become a small embedded language like Lua… details need to be worked out.

This decision was revised and changed. Lumiera is written in C++ and will certainly require some special media processing plug-ins, but it will not require any scripting language for core tasks.

Yet a script runner and script driven use is on the main agenda, since that is an essential feature for large scale media editing projects, where at least some kind of quality render happens on a cloud platform. Our goal is to stick to widely used and commonly packaged software and libraries whenever possible.