It was pretty interesting, but maybe simpler than you think. The hundred thousand dollar Da Vinci unit they use to color correct doesn’t really do much more than what a high-speced PC workstation could do, as far as I could see, and the interface was the typical early nineties “pro visual software” interface, a la Shake, a large screen with lots of buttons and widgets, no windows you can move, and things in tabs. And lots and lots of sliders. The big console the Da Vinci uses is certainly cool, and I’m told you can get those for normal PCs too, but they’re still overpriced (in the 10k dollar range, which is ridiculous for 4 large trackballs and a bunch of buttons and knobs). Brings me back to my rants about why good free software could blow this whole thing wide open.

The telecine itself is a pretty cool piece of gear, though, even though it’s also relatively simple, and overpriced, like much else in movie production. But the results look good (and this was a transfer to SD, even).

All in all, an interesting experience. I hung around the Da Vinci operator and picked up a bit about how the interface worked, and prodded him on how to get the curves right (years of still image correction experience pay off). The best part was the included free food and drinks, though. They make really good sandwiches.

Federico says that I talk about “obsolete tools”. That’s not strictly correct, Final Draft, for instance, isn’t so much obsolete as it is finished. In its current design, without substantial rewrites and rethinking of the philosophy, there’s not much more it can do, except for perhaps fixes for some annoying and random limitations (screenplays can be saved as PDF, but treatments can’t, for instance).

From what I’ve seen, when software is finished in that sense, there’s an opening for new software to come in and take its place. It usually takes all the good things from the old program’s user interface, and improves the underlying architecture and philosophy to the point where wholly new things are possible. I’ve used Final Draft 6 for several years, ever since I started dabbling in writing screenplays, and it’s actually quite slick for the basic writing process. Screenplays are written in a very strict format, and Final Draft is basically a text editor that does all that formatting for you, so all you have to think about is the text itself. For that, it’s great, and it’s by far the most used screenplay editor. The other main contender being a macro package for Microsoft Word, which does basically the same thing, but is somewhat more cumbersome, and obviously required MS Word.

What should a new, free screenplay editor do, ideally? A lot of work should probably go into the file format. The basic format is easy to define, since the screenplay format has changed almost nothing in the last 20-30 years (and little before that, too). XML is an obvious choice, the DTD wouldn’t even be particularly complicated or large. Then you would need to replicate Final Draft’s rough editing interface, which is that of a text editor with a monospaced font and some special formatting, and a few special hotkeys. That’s all you need for a basic editor, I could write a screenplay just fine with that.

From there, there are two directions you could go. One is to make it better for screenwriters, which on one hand would include things like advanced (optionally server-based) revision control and collaboration features. Final Draft has some rudimentary revision control, along the lines of the revision control in MS Word, and it’s had over the internet collaboration for a few years, where two people can work on the same screenplay, and do text-based chat. Free software could probably do both of these better, by offering a range of revision control and backup options, integrated with Subversion and Arch, and the collaboration stuff is perfect for GOCollab.

Additional features for screenwriters would be to improve the things that are not about writing the screenplay itself. Final Draft is very screenplay-oriented, and does little to provide tools for story development. You can write treatments, but they’re basically just text documents, and you can work with “index cards”, but that’s just another view of the scenes in a screenplay. A real index-card mode with color coding and various other features, some way to look at events and subplots, there are many things that can be done here.

On the other hand, there are a lot of non-screenwriter things that involve the script. The final version of the script (called the shooting script, the one with numbered scenes) is used as a backbone and reference for everyone involved in the production, from preproduction through shooting to postproduction. Production assistants, sound engineers, art department, location scouts, editors, CGI artists, everyone uses an annotated version of the shooting script as a reference for their work.

Final Draft uses a separate program, called the Final Draft Tagger, to do some of this breakdown. It allows you to tag bits of the script with various codes to signify cast member, prop, costume, sound effect, set dressing, etc., for use in budgeting and scheduling, but it’s fairly basic. Using XML namespaces and server-based revision control, everyone could add their own data to the script, maintaining a centralized copy where everyone could sign off on the information. Daily call sheets could be almost automatically generated from this, as could a wealth of other information.

There’s much more that could be done, especially extending into the production and post-production, but as a starting point, something with this feature set would absolutely kill all the competition, and it’d be a great place to start for extending into production and budgeting, shooting, and post-production, and at some point becoming a complete system for movie production work, unlike anything that exists today.

Even in small, low-budget, and not terribly organized productions like Bolas Chinas, there’s a strong sense of common purpose within the cast and crew. Everyone’s trying to get the damn thing done. It’s on the level of the best software development teams I’ve been on, and that’s part of what makes it so fun, I think. There’s also that smooth feeling of people doing their thing, efficiently and without fuss (of course, that’s not always, or even often, true, but it very often feels that way). And you develop a certain camraderie with everyone in the cast and crew. No matter what you think of their work as such (which can certainly vary), you have the same purpose, and you sympathize with each other. You eat, chat, sleep, and wait for hours together, and it’s pretty much impossible not to feel a little bit like a family.

Now that I think about it, that feeling of family has always been something I’ve looked for in the jobs I’ve had. I loved working at Helix Code/Ximian in the beginning, for instance, since we were just 30 people, and everyone talked and knew each other. Later, when the company got bigger and more corporate, it wasn’t that much fun any more.

I think management consultants and their ilk could learn a lot from looking at movie productions. But on the other hand, I think movie productions could also be modernized quite a bit. There’s a bunch of stuff that’s basically hold-overs from the old days, and is particularly obsolete on small, guerrilla productions.

Øyvind and I spent a lot of our waiting time talking about uses for computers in movie production. There could be a huge amount of stuff done there, for screenwriters, directors, DPs, production people, continuity/script assistants, and whatnot. What’s available today is pretty pathetic in terms of integration and user interface, and I say that as a registered Final Draft user. If free software wanted to completely take over a relatively small, but high profile niche market, that would be it. Open formats, free software, and heavy integration would be perfect for this stuff.

A good place to start would be a screenplay editor. It’s basically just a glorified text editor with some formatting macros, and could be written in a short time by a couple of decent programmers. It also has the advantage of beign very well-defined. Current screenwriting software is developing so little that there was no useful new features in Final Draft 7 as opposed to 6. So duplicate FD’s functionality, with a slightly better UI, an open XML-based file format, and a Final Draft import/export filter, and you’d be on your way. Add stuff like integration with a revision control server, version diffing, collaborative editing, and a few other things, and you’d own that market.

Update: I’ve written more detailed about screenwriting software requirements in a new post.