CUISINE

download
screenshots
home


Quick Intro
User Guide
System Design
File Formats
Terminology
Object Layout
Debugging Guide
Stability
Timeline View
Frame Server

Why I like separate tools

A suite of small tools is not the opposite of an "integrated system".

Take the example of a one-frame dust fix. You're in your editor, notice a bit of dust on a frame, and (since you're working alone and don't have an artist to do this for you), you decide to paint out the dust. So you tell your editor to save that frame to disk, you pick a place to save the frame, start your paint program, open a file, find the file you made, paint out the dust, save, return to the editor, load the file, and somehow edit it into your show in place of the bad frame.

You do this process all the time, and we all agree that you shouldn't have to repeat all those steps each time. The popular solution in the WIMP world seems to be to put paint features in the editor. Now the editor is a better, more powerful program, and your workflow is streamlined since you don't have to "go" anywhere to paint, right?

Well . . . :

  • You have to use the same vendor's paint and edit code to enjoy the new workflow? That's a big constraint.
  • In the case of commercial software, everyone pays more for functionality that they don't all need. Vendors love that, but studios don't. Even the compositor Shake (sold for $10K) was considered too big for all projects; in a large studio, many Shake users didn't need the bulk of the product.
  • This approach doesn't get you "integration" with, say, a tracker tool until your vendor decides to write or hopefully acquire someone else's tracker.
  • Suppose you do have an artist to do your paint work. You should run the edit+paint program and your artist should too, and you should try to coordinate who's touching what? That sounds tricky. What you really wanted to do when you noticed the dust frame was to designate it for painting. Then you or your artist, at that time or at a later time (or at multiple later times), paints the frame, and the new frame appears in the show.

The specific burden from the original story was that you had to stop your editing work to play with filenames and paths and to launch other programs. You didn't care that the painting happened in the same window or not, although you might appreciate a quick update from the paint/track/colorcorrect program.

What belongs in an editor

Here's an example separation of some of the tasks involved in filmmaking. I tried to order the list from high-level to low-level, but the details and order aren't important:

Asset management, input, output

Editing

Compositing

Painting, modeling, animation

Operators and effects

My point is that "can your editor do titling?" is a funny question. I don't think it's the editor software's role to provide an implementation of a compositing operation (such as a titling style) or a simple effect (such as a dissolve). As I prefer separate tools for separate tasks, I'd like to see an editor that is adept at controlling a titling composite or dissolve effect. Overlaying a single text line on an image may be a common task, but in my shop, performing a film look and sharpen effect might be even more common. Or maybe I always write the first word of each title in a different color. I should be able to add my particular needs in the same as-high-level-as-possible way that the standard operations are implemented.

A text overlay with a drop shadow is almost like a text overlay with a blurred drop shadow, and it's almost like one with a blurred and perspective-skewed drop shadow. Should a built-in titler support all those tricks? Where should it stop? One answer is "the built-in titler should support common title operations". The other answer is "the editor should not support any title operations, but be able to control any operation". The "control" in that last sentence is certainly a limited interface-- I don't want to see all the editors that belong in a compositor hanging around my editor.

Plugins and modules

Some host apps treat plugins as addons, when I'd like to consider them to be equally important operators on the data. I'm impressed with Maya's system (MEL and the C++ API) whereby Alias wrote chunks of their off-the-shelf system in the exact same way you'd write your shop-specific extensions. The plugin API is the same as the API that the rest of Maya uses to access its data and routines.

But I have two issues with my editor: I want to be able to add plugins/modules to the editor system and I want to let the editor talk easily to other filmmaking tasks (audio and video effects, capture, output, etc). The editor is near the top of the moviemaking chain (possibly below the asset manager), and the editor user may want to fuss with some parameters-- especially the timing-- of the lower-down tasks.

For example, making new frames that form a dissolve cut between two video clips is not an editor software's job, although an editor user is going to be the one to specify where such a dissolve should happen.

While my effects have a limited view of the system (limited like "do something to some media and return some other media") and they have a

On to the other issue: actual editorial add-on pieces. Some examples of things I might supply with the editor or you might add on later:

  • sync two bricks based on their audio track (assuming they were two cameras that heard similar audio)
  • setup tiny dissolves (or another effect) between many cuts
  • "switcher" editing, where you can make (and store) cuts between several tracks in real time

Guidelines

  • Listen to anything the users want to say and remember it. If the user writes anything about the edit on a notepad, there's a chance the editor software isn't doing its job.
  • The data is far more precious than the programs, and it has a much longer lifetime.
  • Don't count on any data being in any sort of good shape. The software needs to do the best it can in a rough environment.

drewp@cuisine.bigasterisk.com.