The basic idea is to locate Media Objects of various kinds within a configuration space. Any object can have a lot of different qualities, which may partially depend on one another, and partially may be chosen freely. All these various choices are considered as degrees of freedom — and defining a property can be seen as placing the object to a specific parameter value on one of these dimensions. While this view may be bewildering at first sight, the important observation is that in many cases we don’t want to lock down any of those parameters completely to one fixed value. Rather, we just want to limit some parameters.

To give an example, most editing applications let the user place a video clip at a fixed time and track. They do so by just assigning fixed values, where the track number determines the output and the layering order. While this may seem simple, sound and pragmatic, indeed this puts down way to much information in a much to rigid manner for many common use cases of editing media. More often than not it’s not necessary to “nail down” a video clip — rather, the user wants it to start immediately after the end of another clip, it should be sent to some generic output and it should stay in the layering order above some other clip. But, as the editing system fails to provide the means for expressing such relationships, we are forced to work with hard values, resort to a bunch of macro features or even compensate for this lack by investing additional resources in production organisation (the latter is especially true for building up a movie sound track).

On the contrary, using the Placement metaphor has the implication of switching to a query-driven approach.

When interpreting the high-level model and creating the low-level model, Placements need to be resolved, resulting in a simplified and completely nailed-down copy of the session contents, which this design calls »the _Fixture_«

Media Objects can be placed

There is a conventional way of dealing with those properties, which stems of the use of analogue hardware, especially multitrack tape machines. This conventional approach constantly creates practical problems, which could be avoided by using the placement concept. This is due to the fact, that the placement concept follows the natural relations of the involved concepts, while the conventional approach was dictated by technological limitations.

The high-level model is close to the problem domain, it should provide means to express the (naturally complex) relationships between media objects. Using an abstract and unified concept is always better then having a bunch of seemingly unrelated features, even if they may be more easy to grasp for beginners. Moreover, the Placement concept deliberately brings in an rule based approach, which well fits into the problem domain. Finally, there is sort-of a visionary aspect involved here: Ichthyo thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for new workflows to be discovered, and the Placement concept could be an extension point for such undertakings.

Re: “Finally, there is sort-of a visionary aspect involved here: Ichthyo thinks that nowadays, after image and sound are no longer bound to physical media, there is potential for new workflows to be discovered, and the Placement concept could be an extension point for such undertakings.”

New workflows will not just be discovered, but they will be able to be recorded, analysed, templated, automated, and integrated into the full workflow process. This will free up a greater proportion of time for the »finishing« processes of projects.

“The Placement concept could be an extension for such undertakings” is very likely to be an understatement as it is this which will be what makes these undertakings possible, because it enables the gathering, use, and decision rules based on these parameters.

This feature/capability is likely to stamp the Lumiera project as a flagship benchmark in more ways than one, for some time.

Back to Lumiera Design Process overview