Cinelerra woes

The fact of Cinelerra’s code base showing these symptoms is of uttermost importance and needs our undivided attention. Metaphorically speaking, these are symptoms of serious illness.

Regular segfaulting can be due to tow quite different reasons, and I fear Cinelerra is affected by both. First, it can be caused by missing the detection of error situations, and secondly it can be a derivative of forced-to cast problems without the ability to detect object’s runtime type. Both problems are not immediately obvious and notorious difficult to spot in a dynamic and concurrent environment. You need to attack the root of the problem, fixing symptoms won’t help.

_{TODO explain in greater detail}

…needs an indirection layer. … needs instances transforming and gathering properties … needs the policy “rigorously strict output, tolerant at input”.
the need to look at matters from a global perspective, not just going ahead and changing some property somewhere else. design by contract and design patterns help. No general, "one fits all" solution available for this problem.

_WIP

two aproaches to QA

the new style is a gigantic advance, as it enables small entities and even single individuals to get at a corporate style and industrial strength quality level. It helps fostering transparency and deescalating conflicts, because shortcomings are documented, improvements are visible and measurable. But the biggest improve, in terms of development culture is: you can open up much more for external contributions, because you build up a neutral security mesh. Far less need for the "sceptical, suspicious" type of lead developer, or the "quality devil" (any better English term for this?).

_WIP

This sort of problems is not overly problematic, if only the system is large, flexible and widespread enough to accommodate. In the discussion above we came across this topic with the heart shaped masks and the wipe transitions without soft border. Partially, the basic design of the transition calculation falls into this category as well: adding transitions at the source end is almost obvious and strikingly simple, i.e. it is elegant at the code level. The same holds true for the mentioned transitions. Just a conditional copy in a loop running over the pixel array. Looking at this stunning code is aesthetically pleasing: just a few lines of code, and the visual impact is quite impressive.

As said, such features don’t impose much problems. You could well have 30 plugins of this “cheap spin-off” type, if the asset management is designed to the necessary complexity, i.e. you can have a tree of effects, you have keywords on effects for searching, you can create personal collections or plugin palettes. They could be made clear to be “goodies”, and the basic craftsman’s tools are here at hand, in the main folder.

To return to the example, implementing these basic craftsman’s tools involves quite some consideration: you’d need a buffer to do a dissolve following a path at least, or in the advanced version, you’d need two buffers to mask and to blur and you’d overlay them together on top of the combined frames. So the lesson learned is: some important tools are still missing and we’d need quite some infrastructure which isn’t there at the moment. And it’s highly advisable not to add this infrastructure on a case-by-case base, because this can get dangerous. We’d need a buffer memory manager for plugins, as doing memory allocation in inner loops is a mayor problem for modern machines, and getting a buffer memory manager working correct in a highly parallelized environment can be tricky and should be done with the "big picture" in mind.

_{elaborate on the details}

Solving any of this needs a some localized cooperation above the single-object level. This quickly gets difficult and complex to a level of being almost unmanageable with all the possible side effects it can cause, if it isn’t supported by encapsulation and data hiding. To use the bezier control points as an example: automatic smoothing includes the adjustment of neighbouring control points. If you have already a separation of container (list of nodes) and functionality, and if you express the operations on bezier curves in an intentional, semantic-like style, i.e. as functional services (find_node, get_value, intersperse_interpolated_node_at, get_tanget_at) provided by an object encapsulating the node collection and implementing a generic interface, then adding all of this features is rather a breeze. But Cinelerra has none of this. Instead, individual node values and properties are done from quite unrelated code locations, and all of the searching, testing and manipulation code is implemented in a low-level-style without functional abstraction.

Common to all those problems is that you have to step back in order to see the problem at all. If you just look at the individual technical feature, everything looks fine, correct and solved. You need to take the architectural viewpoint or the usage perspective or the code sanity approach in order to see the duplication of efforts, discrepancies and inconsistencies — and to see why they matter.

And still worse: after having seen them, really solving this sort of problems includes quite a bit of augmenting architecture, considering performance and getting different domains subsumed under common patters. With such problems, commonly there seems to be sort of a natural slope in favour of just overlooking the problem and being content with the pragmatic solution. To fight this, users have to point out the discrepancy, users have to demand the real solution, otherwise nothing will happen. Otherwise we won’t get unified treatment of all interpolation, we won’t get full-fledged manipulation of the interpolation and keying of plugin parameters, we won’t get a really useful background rendering and we won’t get smooth reversed playback and consistent treatment of keyframes and playback position at the same time.

To detail more on the “play backwards” problem just as an example, at first sight the current solution “feels good”: it is local (in the sense that for handling playback I only have to set a flag related to playback direction and doesn’t need to build up global scale infrastructure), it is simple and easy to understand: you always display the frame the playback has just passed and you communicate a flag with the playback direction, which is passed on as parameter over all calls forming the rendering engine. The problems start to arise in conjunction with keyframes (where is a keyframe supposed to be located? and where does the changed value show off?). Putting on the code quality angle, I would even call the footprint of this solution disastrous: It fosters the widespread use of copy-n-paste style programming, causing code bloat, tearing apart features related functionality-wise, opening the possibility for subtle bugs to creep in. For example, just while tracing the usage of bezier interpolation (which btw forced me to look up quite a lot of scattered locations due to missing encapsulation and abstraction), I came across several almost classical bugs of conditions being treated differently in code blocks specialized by copy-n-paste programming. All of this bugs turned out to be fixed already, and all the fixes were not done to the point, but by curing symptoms several levels separated from the source of the problem. In one case, it cost me several hours to find out and prove the problem to be solved. I don’t tell this to complain (because that’s normal programmer’s work), but to make clear: the solution initially appealing to be pragmatic and simple puts quite a maintenance burden on the future. Because of this, today there is wide consensus that copy-n-paste-programming should be avoided at any rate (commonly known as the DRY-Principle : Don’t Repeat Yourself!)

Getting the play-backward problem solved in a clean manner is far less straight forward and requires architectural considerations: We would need to advice the Render Engine to compute small chunks of frames in forward direction, maybe (to be further investigated) we would need to provide additional infrastructure to plugins touching more then single frames, e.g. selective temporal average, time front, sound reverberator or compressor etc, and finally, we need to assemble those chunks and send them to output in reversed order. Integrating this with the current design which is a highly parallelized one, using a thread for every frame (for calculation and display) — could become a challenging task. That’s what is meant with “level of Design”

But as a user doing much work with the Application, I stress the fact Cinelerra can’t be a Pro application if it isn’t able to support keyframe tweaking with frame precision, and as a quality oriented software developer, I’d like to propose that we drop the whole PLAY_BACKWARD thing and go for the clean solution.

Just for completeness I want to point out that the current solution for supporting color models creates similar code-quality problems: widespread use of macros and case-tests within the next-to-inner rendering code-path (several superfluous color model and alpha channel tests per frame and plugin). The situation is similar with the current approach to OpenGL support: Scattered code, duplicated algorithms, difficult to trace execution path. Both problems could be used much more satisfactory by fully applying the Builder Design Pattern — again a solution on the architecture level, not the feature level. For this discussion here it’s enough to mention it; this is one of the central concerns of my design/project plan proposal I detail on another page.

Problems of this category are different to the ones discussed in the previous section, as there is no acceptable simple solution on the feature level. If you try to fix it there, you are running against walls. To solve them, you need an architectural approach from the very start, and you need to make several parts of the system cooperate in order to get them solved.

Motion tracker simply can’t output camera automation without a general facility to pass automation between plugins and other components of the render engine, without an abstraction layer unifying different automation types (remember, the motion tracker can generate adjustment values with sub-pixel precision), without the camera being treated like a general plugin (you need to be able to layer several instances) and without a facility to manage and build control connections between cooperating plugins. The same holds true for the other shortcomings regarding the components of the Render Engine. Partially and limited intermediary solution to ameliorate the most serious problems on a short term base are thinkable though.