Good morning. My name is David Black. I'm a senior architect in the professional applications division. And this morning we'll be talking about using XML along with Final Cut and the tools in Tiger to create complex workflow applications as well as import and export data from the professional application suite. Before we begin, I actually want to just give you a picture of what we've been up to for the last year. We just came back from NAB 2005, a month or two ago, and just want to roll our demo reel that we ran during the show.

♪ It's alright this mystical time you've got ♪ ♪ That's a lot it is plentiful ♪ ♪ If you stay in this moment so critical ♪ ♪ Let the music change your brain stems chemicals ♪ ♪ Make you feel like your spirit's invincible ♪ ♪ Falsentrifical reaching up to your pinnacle mouth ♪

♪ The question won't disrespect them but our styles ♪ ♪ Cuff skin touch like Dave Beckham, come on ♪ So something to note about everything you saw in that video, including the video itself, is that it wasn't-- none of that content was built with any one tool, but a combination of tools. In many cases, those tools were linked together using different workflow technologies-- media-to-data interchange, data interchange. In the case of Final Cut, many of those tools used XML to communicate to Final Cut.

What we're going to talk about today is we're going to actually start with a quick introduction to common data formats you'll see in post-production. Talk about interchanging data with Final Cut Pro using XML. And then also get into examples of actually some applications you can build and some ideas for where you can take these tools in your products.

Starting off with project data interchange formats, the first question, for those of you maybe not familiar with the video production space, is what is project data? We can think of it as really the structure that ties everything together. Certainly, there's a lot of time and effort put into acquiring media, shooting video, recording audio, making stills in Photoshop, for example. But really, the tenor and cadence of everything as it comes together is really a function of how those elements are timed and tied together.

Really, when it comes down to it, certainly in post-production, this is the data that users spend the most time creating. It's really getting all of those relations together that makes the product come together right in the end. And traditionally, this has been difficult to exchange. In many ways, many application vendors think of this as their secret sauce, the things that make their applications better than other people. And there's a lot of mismatch in features which has made this problem not necessarily easy to solve.

Legacy formats, you can think of things that came together maybe one to two decades ago. And really they were tied around hardware formats, basically hardware tools. So you could think of a bank of tape decks going through a switcher. Think of a telecine machine. Think of early film-to-video technologies. And if you look at examples, probably the simplest is just something called a batch list.

A batch list is really just a list of relevant segments of media on a source tape or a linear source medium indexed by timecode with some basic logging information. Name, author, tape identifier, et cetera. And EDL is really an expansion on that where those individual segments are laid out in relation to each other to form a completed production. So you can think of the ordering, the timing, transitions, audio effects, et cetera.

Contemporary formats came about in the last decade with the rise of digital nonlinear editorial systems. As computing power came up in the early 90s, all of a sudden, tape-based bays were no longer the most cost-effective solution. And as software solutions came online, they added vast amounts of capability to the whole picture.

So, created to replace legacy formats, really to address those unique capabilities, these formats had the disadvantage of unfortunately being based around binary container formats. Many of the legacy formats were actually nothing more than plain text, something that could be stored easily on a floppy disk or even a printout.

But with computing power somewhat limited, binary formats were used for efficiency. The problem with binary formats is they can be very complex to parse. You're looking at potentially having specific library and tool requirements. This may actually make it harder to find a way to store a particular format. It may even make it harder to take data from one platform to another. Two examples of this, probably the one everyone in the post-production space is most familiar with, is OMF.

This was created by Avid in the early 90s as an interchange form between their individual tool sets. And while an SDK was made available, it never quite caught on, really. And because it was controlled by one company, no one really trusted it, quite frankly. In order to address the shortcomings of OMF, AAF came about in the mid-90s. And this was a format with the same goals in mind, except that it was a little bit more complex. In other words, it was a concept. Instead of being driven by one company, it was driven by an industry consortium.

Really, the goal of this project was interchange between large, complex editorial tools. And being such, binary container formats were used, again, under the auspices of a foundation. The problem with AAF is it really hasn't seen the adoption that everyone had hoped it would. Part of this is just due to the complexity of the format. Part of it just being due to, again, the focus on large vendors, not necessarily small vendors.

Open data formats have actually finally started to come around the last few years. As computing power has gone forward, more and more better tools have come out. Everyone started to realize that all of a sudden, there wasn't necessarily a large performance or storage penalty toward storing data in relatively easy to access formats. Think of things like XML enabling these things to come to pass. Really the key aspect here is open access to everything and really to make them easy to parse and generate.

Getting on to talk about Final Cut Pro, we took a look at the interchange problem starting a couple of years ago. And we started off with customer feedback. Having put out an editorial tool that we've seen it market for, we started to ask our customers and developers what they wanted.

From customer, we got feedback of certainly they wanted access to common data formats used in the industry. There were some that we had managed to support. There were others that we hadn't at that time. But customers wanted access to it all. Customers also wanted access to the contents of their projects.

The sophistication of the general editorial customer has gone up in the last few years. Whereas customers may have used sort of handwritten notes and logbooks in the past to keep track of their projects, now they're really getting into using things like databases and other tools on their computer to keep track of what's going on with their media.

That really only works if they can actually have some level of access to their projects. And finally, a lot of customers wanted to integrate Final Cut Pro into their custom processing pipelines. These may have been systems that they purchased from other vendors. These may have been internally developed workflow systems.

Developer feedback in some ways was the same, but slightly different. Certainly, a lot of developers wanted to interchange data with Final Cut Pro. Simple import/export, being able to leverage their tools with ours, and also to be able to write tools and extensions for Final Cut Pro. When you get beyond the large developers, there are a great number of developers who actually want to write very interesting focused tools that work with Final Cut Pro to extend it in new areas of workflow. And finally, developers had their own custom processing pipelines from turnkey systems to contract work.

When we considered all the feedback, we ended up taking what we feel is a different look at the problem than most people, in that really it's not just interchange between systems, but really it's about enabling both developers and users to do unique things with their data. We felt it very important to minimize library and tool requirements. On the one hand, we didn't quite see the need anymore with where systems are today, but at the same time, we felt it very important to enable everyone to work with us.

Something else we also sort of see as a creeping problem that not necessarily everyone has considered is really long-term archival of projects. I'll come back to that in a minute, but it's sort of a problem that not everyone has realized yet, but just starting to rear its head.

To solve this, we came up with a Final Cut Pro XML interchange format. We initially introduced it with Final Cut Pro 4. And of course, it's coded in XML. Found this very important. Standard tools, standard libraries. Tiger has wonderful support for XML. And even when it comes down to it, you can parse it and use it as plain text if you want.

And we put it together, we felt it very important to make sure that it covered the complete spectrum of a Final Cut Pro project. The data structures within our self-documenting, if you had the XML and nothing else, you could make sense of it. And we also felt very important that with the data we had control over, we did not want any black or dark data. This is actually, this is quite a serious problem in some formats where there'll be data encoded in such a way where a particular vendor can access it, but an average user, power user, or a third-party developer cannot, and that dramatically limits the flexibility of those tools.

Here's a brief snippet of XML. We'll get into a little bit more details later. But if you look at this, this is really on the order of just defining a simple clip. You see a name, a duration, a frame rate, and even a source time code to track back to a source media tape.

In designing our XML format, we considered it very much a superset of formats. Again, with the feedback from our customers, they wanted access to common industry formats. We threw everything into our format so that we could actually use it as a translation mechanism. In fact, internally, we already have several translation tools that use our XML as an intermediary format to simplify the process. For example, we have an AAF plugin up on our website for users to download. That AAF basically translates to and from XML. We talked about an archivable format and this being an issue.

Think of maybe 30, 40 years ago if someone were to go and cut a film. Once that film was completed, they could store the original negative and the cut list indicating the segments of tape being used. And 30, 40 years back, assuming that film stock had survived, you could come back and reconstruct that project.

Similar capabilities with EDLs, again, need to preserve your source tapes. Of course, the problem is with binary container formats, if it's dependent on a particular library or platform, 20 years from now, they're going to be able to use it. Now, that platform and that library may not exist or may not exist in a usable fashion. Having this data as plain text makes it relatively simple for someone to write a parser. Again, no library or platform requirements and XML is great for this, as is making it self-documenting.

Who's using this today? A lot of people are in the last few years. Automatic Duck and Gallery systems have a wide range of interchange tools, primarily oriented toward interchanging between Final Cut and Avid systems. Building for Media, a small shop in the Netherlands, actually has an entire broadcast automation system built using QuickTime and Final Cut and XML, which is being deployed in several broadcast stations around the world at this point. Grass Valley makes a very well-thought-of line of broadcast servers.

They actually added support in the last year for Final Cut systems to not only retrieve media from their playback servers, but push media up for broadcast as well. Siemens, formerly BBC Technology, has a rather interesting workflow workgroup system called Kaledia. So you can think of this sort of as a multi-user collaborative editorial workspace, essentially indexing media and projects, et cetera. And this is linked directly with Final Cut Pro using XML. It's actually a separate application which uses XML and Finder Launch to enable data interchange.

Finally, Silicon Color is a small company which has a very well-thought-of color grading system. Think of color grading as sort of the industrial strength version of color correction, used in the film world, et cetera. And this system actually does full round-tripping with Final Cut Pro, tracking changes to the media not only within itself, but within Final Cut. So essentially, you could grade a show and then have someone go back and tweak it in Final Cut, and Silicon Color would notice and reprocess only the footage that changed.

Version 1 we released back Final Cut Pro 4.1. It's supported in 4.5 and 5.0. When we released Final Cut Pro 5.0 earlier this year, we actually bumped the version to version 2. And primarily this is about supporting new features in Final Cut Pro, including multi-camera editing, much improved support for multi-channel audio, and even film data courtesy of Cinema Tools.

And really when it comes down to it, it's all about the workflow these tools put together. And start off by talking about some lightweight workflow tools, things that are relatively simple to put together. Think if you could use Perl scripts, Apple script, Automator to build these. These are things oriented around you have a task, might be repetitive, might be something you do once a month, and you want to automate it both for accuracy and efficiency. And really these are the kind of things that not only developers can build, but power users as well.

Some examples of this, you might talk about interstitials, essentially sort of the little now playing numbers you'll see in a TV station. Text overlays, you might have footage shot in a language with subtitles. You want to automate the insertion of those subtitles on that media as you edit it. And even just doing data mining or extracting information from projects, you might want to know what songs, what media is used for rights purposes. And with that, I'd actually like to invite Eric Version on stage to show you some examples of tools he put together.

Good morning, everyone. As David mentioned, I'm going to show you some of the things you can do with Final Cut Pro XML interchange format. I always have a little trouble with that phrase. I'm going to go ahead and open up one of the samples that comes with Final Cut Pro. It's a little set of -- excuse me.

Am I not -- What's going on here? Here we go. OK. This is a sample. Some footage of the Bay Area in high definition. Looks very nice. And what I'd like to do is I'd like to subtitle this. So I want to have some text that matches what's going on with the images. And since I anticipate I'm going to be wanting to do this more than once, I might as well write a tool. So let's pause this. We want to select it. And let's save it out using the XML export. You'll be seeing this a lot.

All right. There we go. Need to give it a name. Let's just change that name so it's a-- A little bit simpler. And let's hide this away. And then that highlighted file on the desktop is the resulting XML export. Now, I've got two scripts up here at the top. These are both AppleScript droplets.

I'm going to go ahead and take my XML export. I'm going to show you the action of the scripts, and then we'll go back and take a look at how we actually did it. So I just drop that on the first one. wants to ask me where to put it. I'm just going to use the default. Let's take a look at this.

Let's see. Can I zoom it up? There we go. What we have there is just a really simple output format. We've got three columns. First column is the start time. The second column is the duration. Last column is the text that I'm going to add. Start times and durations are expressed in frames.

You'll notice that this first one doesn't have a very interesting title. Let's just get rid of that one. And if I was doing this for real, I'd-- so let's just go save and put that away. Now we want to go and insert that text into the project. So we'll drop the XML back on there. We want to go down and pick the file that tells us what we're going to add. And we'll just take the default here. Now let's go drop that on Final Cut.

Now, you'll notice in the import, I can either create a new project or I can add this to my existing project. I'm going to go ahead and add it to the existing project and fix the fault because you've got a whole variety of frame rates. may have to switch that and Helena is going to show you how you can even cause that dialogue to go away. And we can see we've got the new thing. Let's go ahead and play that. And now you'll see that we have subtitles.

And I hardly had to do any work at all. Now this, at this point I could actually go in and change these some if I wanted. But let's pause this and I'm going to go ahead and close the project because we're not going to be coming back to that.

And let's take a look at the scripts that we're running. Here's the first one. I'll start out with just Apple's friendly disclaimer. You'll see that an awful lot this week. The first portion of this is simply some standard AppleScript that I pulled off of Apple's website. It's not even on the developer site. If you go -- it's called the AppleScript guidebook, essential subroutines. This is just a script to process it as a droplet.

The -- all the OpenHandler does is handed the list of files that were dropped on, the application bundle, it's checking to make sure that the particular things are actually files. If it is a file, it's going to go ahead and call the process item routine. Otherwise, it'll post an alert telling me it's a little upset.

Here's the process item stuff. Again, this is fairly straightforward. The main thing we're doing here is the do shell script at the end. That's really the meat. The rest of this is just setting things up. You'll notice the beginning of the routine, we're going and getting the path to the application bundle that we've run. The reason that I'm doing that is do shell script.

When it invokes the shell script, your current working directory is going to be the root of the volume. In many cases, that's not what you want. What I actually do is I grab the path to the application bundle, pop up one level. That's what local Dura is. I also set another reference, which is pointing to where the scripts are inside the bundle so that I can easily call the pro script.

Next line. Down, return R, display dialog. Just telling AppleScript to run the display dialog for me. And then in the... Yeah, if you look down here, all we're doing is-- Changing the paths into quoted form because on the Mac you can have path names that have spaces in them or other characters and these can be a problem for the Unix command line parsing. We just go ahead and quote everything and then down here when we have the shell script, we actually pass a single command line which does the CD as the beginning and then does the Perl script.

Now let's show the actual Perl script. So the first thing we do is we have to create a new Perl script. So we have to create a new Perl script. And then we have to create a new Perl script. And then we have to create a new Perl script.

Let's go over here. OK. And notice I'm using a Pro module called XML LiveXML. XML LiveXML is not included in the standard Mac OS X distribution. Nor is it included in the developer tools distribution. So if you're going to use that, you need to go and get it either from CPAN or from Think or from Darwin Ports. In preparation for this talk, I did actually get it from Think and I got it from Darwin Ports and both worked.

First thing I do is just create a parser. This is just-- the standard Perl is just making sure that I was only called with one argument because I don't know what to do if I have more than one. And here's the main routine that's actually doing things. We start out, we're past the name of the file that we want to operate on.

We go ahead and Go ahead and ask the parser to parse the file for us and pick up the root element of the document. Then once I've picked up the root element of the document, I'm going to go ahead and make sure it has the format that I'd like. Now you'll notice that this stuff here, that's just an XPath expression.

If you haven't used XPath before, don't be afraid. I hadn't used XPath before I did this. And it's basically-- it'll take you about half an hour to an hour to figure out how to use XPath and feel comfortable with it. This particular sample, I only wanted to have one sequence, so I'm making sure that the format looks the way I want. Then I'm going ahead and finding where the video tracks will be.

Then all I'm doing is zipping along the track and for each clip item I'm pulling out the duration, start and end times. And the reason I'm doing this extra nonsense down there is because I'm only picking up clip items. When I initially did this, I did this with the sample file that you saw.

I later tried to apply it to some other things and got a little more broke because I was attempting to compensate for the fact that I wasn't actually picking up all the items. And that's basically "Let's go ahead and look at the second one, which looks very similar. Again, disclaimer at the front. This top part here, this is exactly the same as the other script.

And in fact, down here, it's again very similar to the previous script. This part is exactly identical. Here's where we picked up the name of the list file that we wanted to-- that contained the text we wanted to insert. Here's where we picked up the rest of it.

And you'll notice that the do shell script is a little more complicated because in this case, I'm actually calling it with an argument, which is the generator that describes the-- describes to Final Cut the form of the text that the text should take. Let's go ahead and get out of there.

Go over. Here's my Perl script. Again, same sort of thing. There's our disclaimer. The opening, this is almost exactly the same except that I'm using get ops. To pick up my options, the process and routine in this part is identical to the previous one. And let's get down to the part that actually does something.

This line, I go ahead and I create a track that I'm going to put the text generators into. This is initially a node that's not connected to anything else. It's not part of my document. It's just off on the side. I go in and pick up my input, come back in typical Perl fashion, it's just a reference to an array of arrays. I go through that whole array.

For each item in the array, I create a generator that's going to give me back an XML node. I append that to the track, so I'm building up the track as we go along. Once I've gone through the list, I just take the track, attach it into the video, and now tell the document to serialize itself back out, and that does the write out. Here's the generator. Here's the generator.

You'll see that the generators go straight forward. For those of you who aren't that familiar with Perl, this is a little bit of Perl magic, which allows me, when I read in the file, to do it in a single line. So of course I'm passing the start time, the length, and the title that I want to put up there. You'll notice that I'm actually not even doing any XML down here. I'm just doing string substitutions.

I'll show you what I'm pulling in as the generator file in a moment. Do the same string substitutions, then I tell the parser to parse that result, pass back the document element so it can be stitched back into the-- Overall XML. Let's go ahead and take a look at the generator.

Now you might be saying this looks a little complicated. Gee, that's a whole bunch of XML, isn't it? But I actually didn't have to write that XML. I got Final Cut to give that to me. You'll notice I only changed a couple of things in here. There's the duration, there's the in and the out, start and end, and in fact down here is where the string is.

So let's... Take a look and see how we could go ahead and get something like that generator. In fact, what I'm going to be showing you here is exactly the way that I got that generator in the first place. What we're going to do is create a new project.

This is an empty project. Let's go ahead and use the XML export and save that. We'll call this one before. Then I'm going to go over to my effects, get a video generator. There we go, text. And throw one of these on the timeline. Okay, straightforward. And let's go ahead and export that one.

"Following after, let's hide this away. Now I'm going to go to, because I'm a Unix guy, I'm going to go over to the command line. These files happen to have been created with Macintosh line endings. I'm just going to fix those with a little tool of my own. And then I'm going to use OpenDiff.

The only reason I'm fixing the line endings, OpenDIF could actually handle it with the Mac line endings, but it doesn't look quite as nice. And here you see what changed between the two copies of the XML. Well, the duration obviously changed because we went from having nothing to having something. And here's the generator.

And if I were to cut this out and paste it in and do a diff with the generator file I'm using, you'd see that it's virtually identical. Now, one of the other things that David mentioned as something we might want to do is you might be working with what's called a bumper or an interstitial. And here's one that we had one of our editors make for us.

Surfing is serious business for these middle schoolers. When the school day is over, instead of heading to the playing fields, they head to the beach. Join us at 5:00 when we meet these amazing kids. Only on KROC Channel 8. OK. Typical spot you might see on TV. You'll notice the only places where we actually mention the time are here. There's a piece of text that says 5 o'clock. And back here.

There's-- what was that? I changed keyboards on me. Back here. Join us at 5:00. Where we say join us at 5:00. So what we want to do-- is it would be really nice to be able to generate multiple copies of this bumper, one that says five o'clock, one that says seven, one that says 11, and be able to do that in an automated way. So let's go ahead and once again export the XML. Let's just give it a nice simple name. Okay. And I'm going to go ahead and close these projects so you can see that there's nothing going on. There we go. And hide that away.

Now, surf is very complicated. I'm not going to show you that XML, but I'm going to show you what we want to do with it. Here's the beginning of my script. Okay, so we have a bumper, and that bumper has two things that we want to modify in there. It's got the audio that we want to swap out, and it's got the text that we want to change.

So in order to do that, I need to have in my files coming in, I need to know what's the name of the original audio, what's the original text, and then what do I want to replace that with in terms of audio and text, and what name would I like to give the resulting output. So here's in fact the input I'm going to give it. Very straightforward.

Nothing very exciting there. And you'll see that this script is very simple. The top again, all I'm doing is making sure I have a single argument. And here's the-- Routine, I get past the file name, I grab the content of the file. I'm not even doing any XML parsing in this. I grab my input and then for each one I'm going to go ahead and make a copy.

If we go down and Look at Make Copy here. We're going to go, as I said, we're getting a file name, we're getting the content of the file, we're getting what we're looking for and what we're going to replace it with. I use standard Perl stuff that's in the distribution to parse the name, generate a new name. I go and find all occurrences of the audio file name and replace them. The audio file name also shows up in URI form with escapes, so I want to catch that as well and then substitute the text. And then when I'm done, I just write it out.

"Go ahead and if we're going to run this, let's go over here. Just go ahead and run bumper with surf and take input from bumper. How many times can I do that? There we go. And that didn't take any time at all. And there we have. Let's go ahead and bring one of these up in Final Cut. I'm going to go ahead and create a new project this time. Save it away. And if I click over here, you can see that it now says 7 o'clock. And if I click over here, there we go.

Now, just to... Okay, so as a last thing, what I wanted to show you was once I had this thing that would do subtitles, I got a little crazy and I went, "Oh, wow. I could do, I could like subtitle a song. I could do my own karaoke." So I took a song I liked and I just grabbed the lyrics off the web and listened to the song and adjusted the line breaks so it matched the phrasing. And then I wrote a very, very simple piece of Perl that took that text and distributed it across the timeline of the song, just evenly separated. As you can see-- not in the right place. Here we go.

There's the words and after I fixed it, I'll just play a little piece of that for you. There's sulfur, californium, and fermium, berkelium, and also mendelevium, einsteinium, nobelium, and arcryptan, deandre, danzine, and zircon, rhodium, and chlorine, Carbon, cobalt, copper, tungsten, tin, and sodium. And that's what happens when you give an engineer too much time. And with that, I'd like to turn it back to David.

Slides back, please. Thank you. Thank you, Eric. So I just wanted to give you a good idea of just relatively powerful but simple things you can actually put together very quickly using XML. Simple is not everything, and there are times when you need to do something dramatically more complex. These might be situations in which you need to actually generate XML from scratch. Maybe you're doing an import or export type application. You might be merging very large data sets from another application.

In some ways, these tools might be more mini-applications in some ways. Tools with UI basically targeted to make things very simple for a user, as opposed to sort of maybe a scripting tool or something very tailored to a particular user's workflow. And really, as opposed to using things like Perl and AppleScript, you tend to build these things with much more industrial strength tools, like Xcode, Interface Builder, C++, and of course Core Foundation, Core Data, and even things like LibXML, too. Actually, to talk about some of these, I'd like to invite Helena Ju up on stage to show you some of the things she's been working on.

Good morning. So Dave talked a little bit about how a lot of different people are using Final Cut's XML as an integration tool. So a lot of times, people are bringing in media via some other acquisition, or perhaps they're editing the color, or they're sweetening the audio, all in different applications.

And then you want to bring those things back into Final Cut. So one example, for example, is the documentary filmmakers. A lot of them are bringing in a lot of stills. So they perhaps will use iPhoto to organize various albums, so let's just do that now. Here, these are just some pictures I have in my Ocoto library. So let's see. Let's take a waterfall shot and-- Some of the shots of Chicago and this exciting pink elephant. And cookies I made at my grandma's house.

So then what we're going to do here is use a little tool that I wrote last week. It took me about two days. And we're just going to go ahead and choose-- OK, we're just going to choose that album we just created, WWDC2. And this tool-- so I wrote this entirely with NSXML, CF, various core foundation tools on Tiger.

And so here, we select the album that we want to export from iPhoto. And all I do is I basically mine the iPhoto's album XML file for the data that I want, which is the URLs of the various files that I'm using in an album, and also the names of all the albums, which is then I put in this pop-up.

And then I use the UI to tell myself later which durations, transitions. Here, I just created a random one that chooses between the three that I provided in the pop-up, and the duration of the transitions, and the frame rates, and how we want to output the-- sequence names. So we'll just save that one off. Great. And bring that into Final Cut. I'm giving you an idea of how the tool works and then we'll walk back through and look at the XML generates and how that code works. So, save that.

And voila, here it is. I'm actually using Final Cut Pro HD, which is 4.5, which we released last year at NAB. So this is actually an older version of Final Cut to show you that the XML worked even then. And you can develop powerful tools even with the older Final Cut.

The version of the XML in Final Cut 4.5, as this is playing, is version 1 of the XML, XML being the name of the Final Cut Pro XML interchange format. We're actually on version 2 now, but that mostly the differences are various things for the new features in Final Cut 5. So we're talking multi-clip, multi-channel audio export, things like that, are in XML version 2. But other than that, it's actually identical to version 1.

So let's stop that playback and check out that XML. Like if I import it again, we automatically get the save dialog. We didn't get that import XML dialog that Eric had multiple times. The reason is because I have this block here at the top of the XML. Let's see.

I'm unable to zoom, but here we have import options. And what I do here is I create new project and say true. So that automatically spawned the save dialog with the default project name I put in there. And then goes ahead and does the default sequence presets, et cetera.

and all the different options that are in that import dialog. So we'll go ahead and just basically fill out the dialog and then the user doesn't need to see it when they import the XML. So the other interesting things here, sequence, this part is pretty much boiler for any sequence except the name here is different because we brought this in from the UI, and the frame rate comes in from the UI as well. So there's media track. And then here is the first clip item and here is the transition item. If we were to export this from XML from Final Cut, let's just do that now. You'll see that there's actually a lot more keys. So let's see, export XML after.

There's all these other keys in here at the top of the sequence. We've got the duration of the sequence, which actually was at the bottom of this one, but then we have time code in the out and then a whole bunch of different things about the media format. And the thing I'm trying to show you here is that while you can define pretty much everything in the XML, you don't have to.

We're trying to create a lightweight tool so that you can simply and easily define the keys that you need to define. So for example, for the stills, I don't really care, for example, about the duration or the the time code, things like that. So if we look at the clip item, which this is the first clip item, it runs from here to here in the-- after, it doesn't quite fit on the screen. And over here this is the XML that I defined in my app.

And all I defined is the file that it's coming from, the name, the duration. So start and end, I actually just put a negative one for the end, and I'll talk a little bit more about how I do the timing for the individual elements. And then the time base I want you to calculate the frame rate says.

So that's a little bit what the XML looks like. If we go to the application, here. Let me just hide those other things. So I've got two different classes here. I've got the PSController class, and this class is the class that writes out the XML. So I've got functions named save slideshow, write XML out to create XML document.

And the other class is where I'm pulling in things from the UI and also things from the iPhoto XML, which is actually a PList. So I have functions like get slideshow title, should create new project, get clip duration, get media duration, number of files in album. These are the type of functions I have in this class.

So I'm not going to talk so much about this class because you can pretty much bring in data from anywhere, any database, any like from iTunes, iPhoto, your databases or a tab-delimited file. Those can be coming from anywhere. The interesting thing and relevant thing for this talk is how we're creating that XML. So at the top of the file, of course, I have just the boilerplate.

And then here we have saved slideshow. All this does is-- I actually got this code from the developer.apple.com and I did a search for NSSavePanel. So you too can find this code on your local website. And I just default save to the desktop. I write the file out as an XML file and then I get the title from my UI and then just tell myself to write the XML.

Which here is really short because I'm using NSData and all NSData have to do is say I want to take my XML document, which you'll see this function in a second, and then I want to write it pretty print so that you have all the nice tabs and everything's on different lines.

And then I call the NSData call write to file. And I sort of feel like I'm cheating because it's so easy, but that's all there is to it. So here is a block of what I want that XML to be output as, which is here, this is the import options, sorry, this is a helper function called add import options that I added to my create XML file so that I could bypass that dialog. So all it does is output this chunk of XML essentially, slightly different depending on whether or not you actually wanted to output a new project or not.

So we take in a root node, which we're going to make-- so we make a blank note here. All it has is the name of the thing. So it's called import options. It doesn't live anywhere. And then we add it to the root node here. And so that gets put in as a sub node.

And the important thing to note about all this processing is just that it's all about just reorganizing data you already have. You brought in all the data from your UI, from your other database. And here, it's not exciting, because all you're doing is reorganizing data you already have and sticking it in this particular order so that it looks like XML so that Final Click can understand it.

So we're going to create a new project node and say that it's true, because we know we want to create a new project. And then we add child to the import options node. And that's exactly how you append things and add new nodes to the XML tree. And I do the exact same thing here. I go and get the project name, and then I save it off as the value of a node called target project name. And then I add it as a child to the import options.

So then I just collapsed that here for all the rest of the import options, since now you can sort of see how one puts together the nodes. And then for create XML document, the only interesting thing really is that you create a node in the middle of nowhere, just like you did everywhere else.

And then you initiate with root element. And that creates an NSXML document. And then you can add the version of the XML document and the character encoding. But after that, everything is exactly the same. Here I'm adding an attribute. And then below, I'm creating new elements. I'm doing add child over and over again for the rest of the sequence. And then I have a little for loop here.

which creates the clip items and then also the transition items. So this is my loop. And the only reason it's so long is because for each XML node I've got a couple lines where I go and get the string and then I stick the string in the node and add it as a child. And I want to point out that the reason why this is such uninteresting code and it's really boring is because Tiger is really great. I used NSXML everywhere and where I couldn't I pretty much used the core foundation analog.

This demo is really boring because Tiger is so great. I don't know how to explain that very well. It took me two days to write this code and I don't particularly know Cocoa very well. I'm one of the developers on Final Cut. So I just had one screen that was developer.apple.com and I constantly looked things up. And then I had the other screen where I was writing code.

So if I can do it in two days, I'm sure you can do it in much less time. And then down here we have where we do the transition items. Now I said I would talk about a little how I did the ins and the outs and the starts and the ends for the transitions. So let me do that now.

Okay, so for the clip items here, so first I have the clip item block and then I have the transition item block below it so that if I don't have any more clip items coming up, I know not to add a transition. So that last element isn't going to have a transition at the end.

So here to do the start and end, I actually am calculating the start and end for each individual item based on those durations in the dialogue. And you'll notice actually these were in seconds, but all the math in here is in frames. So I'm going ahead and getting the number of frames, which I'm calculating in my other class.

And then I'm putting it in as a start value, but only for the first item. And then same thing with the end. I'm only adding it for the last item. So here's where I add the end element. I'm only adding it for the last one. Everywhere else I'm putting in negative one.

And the reason I'm doing that is because you have these transitions and, okay, so you think about the media. Because for the still, right, the media could be however long you want it to be. It's a still, so it's just going to repeat itself. But if there's a transition, the media for one element is like this long and the media for the next element is this long.

And they're going to overlap where that transition is so that you can do that wipe for the whole duration of the transition or you can cross dissolve. And really the media needs to be there for the whole duration of the transition. But it's hard to say, right, that this thing overlaps that thing by however much you need it to. And Final Cut, you figured that out magically. So what we've done is say, well, you just say Final Cut, figure that thing out magically with a negative one.

And then you put the transition exactly where you want it. And we know to say, okay, well, the transition starts here, so I'm going to start blending. So that's what the negative one is for. It's an undefined value. And then we magically do that for you. So then the same thing with the transitions. We actually put the correct start and end in. You see there's no magic negative ones here. And that's how you get nice transitions.

I mentioned this briefly, but the thing I wanted to leave you with is that you could really make such a tool with any sort of database. Here, I've just used the iPhoto database because it was convenient and I happen to have iPhoto pictures on my laptop. But given enough time, you could do the same thing with any database. I was going to do iTunes as well, but I ran out of time. But one can also do the same thing with iTunes, with file maker pro database. Many people are doing this.

Like Dave listed out all the various companies are doing interesting things. Building for Media is doing exactly this sort of workflow. They're bringing in stuff from the broadcast server. They're saving it off to certain files and they say, "Okay, here are the URLs. Here is how long the files are. I'm going to make you a rough cut." And really, anybody can be doing this, bringing it from any sort of asset system. So good luck.

Thank you, Helena. So really to wrap up, it really is all these tools, all these capabilities are really about the workflow. And really our goal has been to enable a wide range of tools to be built by you, by everyone. Open formats really are key to this. It's in a way, you know, we certainly have ways we think in which our software will be used, but there are really interesting things that we just don't know about that you know about that we want to enable you to do.

I talked earlier about linking multiple applications, basically using data formats to move data between different applications to round trip it, etc. And this is really a powerful thing and really what customers want. As Eric showed you earlier, the simplest tools can really do powerful things. And yet, if you want to go to that next level, you can move up to more traditional tools to again, write many applications, pull workflow systems, etc. relatively easily.

Just some ideas, you know, we've talked about these this morning, but just to reiterate them a little more. Data extraction, really good thing, really important thing. Template-based media generation. Eric showed you not only how he just merely reused a chunk of XML from Final Cut, but how he did substitution in an initial program. Building bumpers and interstitials like Eric showed you used to be a very time-consuming thing. It used to be a very error-prone thing, and a lot of organizations are using tools like this to simplify things.

Putting subtitles, text overlays, again, doing automated, just quicker, more accurate. And when you get into more sophisticated applications, asset and media management tools, that's the number one thing we're hearing from customers. They're out there looking for tools to complement Final Cut and their other media applications. As hard drives go up and machines get more powerful, everyone's getting more and more media, and they need a way to management. Production databases. Talked earlier about power users. Well, pretty much the most insane power users I've found, are in the film community. These are people who used to have little hand logbooks they'd scribble down information from their software with.

They're now building massive database systems off to the side that track all the production information. Not only relatively simple things like rights, but even just who's in what shot, what the lighting was, who was on the camera at the time. And finally, data importers and exporters. Enabling customers to pull data back and forth in applications in the way they want is something that definitely sells. If you're looking for more information on any of this stuff, everything is on the developer site. All the code that Eric and Helena showed you today is up there. Links to the Final Cut Pro XML documentation and DTDs are up there as well.