Good morning. My name is David Black. I'm a senior architect in the product applications division. And today we're going to talk about creating workflow solutions with Final Cut and XML. Really what we're talking about today are tools and technologies that you as developers can use to integrate with Final Cut Pro and build dramatically interesting video and media processing pipelines.

We're going to start with a brief introduction to some industry standard data formats. Since this is Interchange, this maybe gives some information to people that you may not know. Also talk about interchanging data with Final Cut Pro and how you can actually integrate applications very tightly with it. We also have some new tools for tracking media files to talk about. And finally, we're going to try and wrap it all together with a custom workflow application that uses all of these capabilities.

But before we begin, talk about a little bit what's gone in the last year. NAB this year released Final Cut Pro Studio, the first universal binary version of the suite, including Final Cut Pro. And as of today, there are more than half a million registered Final Cut Pro users. This is an incredibly huge audience for your applications and your tools.

Of course, this is only the registered users of Final Cut Pro, not probably the double that number is actually using it. And also in the past year, Final Cut Pro has been involved in a lot of key world events. Both the Torino Winter Olympics and 2006 World Cup had dramatic broadcast presences, really driven by Final Cut Pro combined with other compelling tools for complete workflow solutions.

We're also going to talk about some new features in Final Cut Pro today. The engineering team, a lot of time over the last year, responding to requests from developers and looking at new ways to open up the software. We have an upgraded XML Interchange Format. We have some new tools for having external applications talk with Final Cut Pro. And for the first time, we're introducing support for metadata in media files in combination with the QuickTime team.

But there's a catch with all of this, as some of you might be able to guess. What we're going to be talking about today in terms of new features are in an upcoming version of Final Cut Pro. So sadly, they're not in the version of Final Cut Pro you can go and buy off the shelf today. WWDC is a unique opportunity to talk to you all, and so we felt it very important to give you this information despite the fact that it's not shipping today. But it will be shipping soon. I just can't talk about when today.

Temporary formats came about in probably the last 10 years, and really they came about through complex things, multiple layers, more transitions, more effects. But unfortunately again, this is sort of owing to the time in which they were created, they were built around binary container formats, so essentially big blocks of arbitrary bytes, which unfortunately means they're very complex to parse and generate, you know you're not gonna pull up text edit and open one up or use VI, so you're gonna need rather complex libraries and tools to open these things up and do things with them. The two most common examples you'll find out in the industry today will really be OMF and AAF, and both of these formats really originated in efforts from Avid back in the 90s.

OMF was sort of their initial stab at it, today it's really commonly used in the audio industry, just because it's there and it works. AAF came about a couple years ago as a successor to OMF to try and address some of the issues. Instead of being owned by one company, it's run by the Advanced Authoring Foundation, or Forum, excuse me, and really the attempt was for an industry consortium to exchange data. Um... Now today we sort of have a movement toward open data formats, and this is really where our hearts lie.

In that, legacy formats didn't do what we needed, and contemporary formats did more, but they were really hard to parse and generate. And really that's just not cool, because you really want everyone to have open access to all the data, and really not need complex tools to parse and generate this stuff. And, you know, there are definitely tools available to do that today.

So when we looked at doing data interchange with Final Cut Pro a number of years ago, we started by talking to people. We started talking to customers and developers. And really everyone said they wanted common processing pipelines. Everyone wanted access to the data. Everyone wanted to talk to Final Cut Pro, and everyone wanted to integrate or essentially exchange data between Final Cut Pro and other applications.

And we came away from all these conversations with what we believe at the time was a very different take on the problem, in that it's not simply interchange between systems we're talking about, but it's also allowing power users and developers to get at the data. So, you know, you could think of building round-trip tools that do interesting modifications, not simply shipping a project wholesale between one large system and another. And we really wanted to minimize library and tool requirements with both OMF and AAF.

We just saw so many people who were bitten by the complexity of getting those formats parsed on multiple systems. And also, we came back with another interesting problem of long-term project archival, talking with people in the film industry, where, you know, certainly EDL from 20 years ago you could parse, but if you're going to take an Avid project and an OMF file from the early 90s, you better have a machine wrapped in shrink wrap in a closet if you hope to open it up in 20 years.

So where all this came back to is the Final Cut Pro XML format. Introduced it back with Final Cut Pro 4. And we chose XML because, you know, XML is clean. It's easy. There are a lot of tools out there to use it. And if you need to, you can go into TextEdit and play with it. And really, we put the complete contents of a Final Cut Pro project in XML. Being XML, it's self-documenting. So certainly while we have documentation developer side, if you pick it apart, you're likely going to understand generally what all the constructs are.

And really importantly is we aren't putting any black data or essentially hidden data in the format. One of the challenges with both OMF and AAF is it was open such that manufacturers could put hidden or just basically arbitrary blocks of bytes in. So you take a project and you put a really cool effect in it and you pull the AAF file out and you discover that, oh, wow, I don't have the documentation to pick apart that effect information. And that really frustrated a lot of our users.

Here's an example snippet of Final Cut Pro XML. Again, it should be relatively easy. I have a clip, structure, name, duration, time code. And this is something that really a power user or developer wouldn't really have much of a problem grokking or editing in a text editor and bringing back into the software.

And really when it comes down to it, we designed Final Cut Pro XML to be a superset because one of the core uses of it was interchanging data with other systems. And we wanted to make sure that everything that was Final Cut was available regardless of what other system might be using. And in fact, today, if you use one of those industry standard tools for doing AAF interchange or other format interchange using Final Cut, there's a really good chance it's going through XML. We found it actually to accelerate a lot of our internal development greatly.

And coming back to another need we saw from the film industry and broadcast, it actually is archivable. Again, it's text. It's self-documenting. You know, if you can read that CD in 20 years, there's a really high likelihood there'll either be an XML tool there or you can write one up to pull it apart.

Now, who's using this today? Well, a lot of people are using it today. Both Automatic Duck and Gallery Systems have really compelling data interchange tools. Building for Media, a European company, has a complete broadcast server built using Max and Final Cut Pro, all tied together using XML. Silicon Color, who's actually down in our Apple in the Studio booth downstairs, they have a full color correction solution, which actually does full diffing round trip with Final Cut, such that you can make changes in Final Cut and Silicon Color will notice those changes and update accordingly.

And finally, just in the last few months, Sony has enabled support for their new XD Cam HD cameras with Final Cut using Final Cut Pro XML. They built a really interesting media transfer application for the Mac, the Sony building software for the Mac, which communicates with Final Cut using XML and has been incredibly well received by our users.

Now version 1 was supported in Final Cut Pro 4.1. Version 5 came along in, excuse me, version 2 of XML came along in Final Cut Pro 5.0 and it's support for constructs like multi-clips, etc. And we have version 3. And with that, I will invite Helena Ju on the stage to tell you about the new features. David Black, Helena Ju Thanks, Dave.

Good morning, everyone. I'm Helena Ju. I'm a senior engineer on the Final Cut Pro engineering team. So basically, when we do development in the XML format, we work in three areas. We track new features and technology, like Dave was talking about the multi-clip stuff. We address known bugs, and we improve integration based on developer feedback. I'm hearing from a lot of people that they want to have better integration, that certain things are not in the XML, things like that.

So this last piece is the part that we're focusing on today at developer conference, it's not surprising. And the ones we've added are the ability to update existing projects. So previously you had additive abilities, and now you can actually modify existing data, and this is project level and the media file level for a metadata support. Also, we've now added support for communicating with Final Cut using Apple Events.

The ability to modify and update existing projects is good because it enables better integrated workflows. So tools can take an existing version of a project. You can send out things, say, to your color department, whatever, and have it come back and change rather than having to add another version of the sequence or even whole bins and versions of the project. In addition, it allows for more widespread use of XML fragments, so you can just replace the items you want to replace and not have to redefine your whole project.

Here is an example of how it can be useful. This is a very simple project. You have one clip, one sequence. If you want to replace that clip, previously you would do an XML snippet that brings in that one clip, and you get one more clip. I've highlighted that clip in red just to show you, but typically it would just be exactly the same because you wouldn't typically change the label color.

If you were to do it, say, 10 times, you just get a whole bunch of different versions of that clip, and which one is which, or which one's the original and which one's the one that's the new one, you wouldn't know. Here, I've highlighted in red again, but you wouldn't know which one was the newest version unless you took the extra steps to go back and delete them. Also, it's not updating the existing item. It's instead just adding new ones.

So the new way, the new way we're going to show you how to do today is you have your existing project and you import the XML, and now you can replace it. And this is an optional thing. So you can still have the old way, but in addition now, you can eat your cake too. So how are we doing this? We've added two new XML keys, and these are available on Clips, Sequences, and Bins, UUID and Update Behavior.

Here's a sample snippet so you can see kind of what it looks like within the context of the XML. In XML version 3, we're now outputting the UUID as well as the update behavior. And the rest of it is exactly the same as the sample Dave showed you before, except that this is a sequence. So we've got a sequence with name, duration, rate, time code, all the usual things.

And we've added a UUID and update behavior. So UUID uniquely identifies the object across projects or across XML import and export. This means that you can have two projects with the same object in them, so therefore the same UUID. Like if you copy a clip from one project into another project and you paste it there, obviously you want that UUID to persist. So that UUID will be in both projects.

If you then reconnect that media, say, in the first project to a different piece of media, then now you have the same object but two different versions. So that's important to note that users can get themselves out of sync, and you need to be aware of that when you're working with these items.

The same is true, of course, with XML import and export. You can export your project. Everything has its UUIDs, like one, two, three, four, five. And then you modify things and you re-import. You can replace those things. Or you can put it into another project, for example, and they will have exactly the same UUIDs, because you want to be able to track those things across projects. Of course, they persist over time. So if you save out your project and you open it up on another machine or something, the UUID is the same.

UUIDs live, as I said before, on Clip Sequence and MINS. They are generated using the CFUUID API in Final Cut, and we strongly recommend that people use that, but you can use any method that generates a WC3 standard compliant UUID. There's an example right there. And... This is different than the pre-existing key we have in the XML, which is actually an attribute, sorry. So like on a clip, you can have the attribute for an ID.

So the ID in this case, an example is foo, and this is actually only unique per XML file. If you were to export the same clip in a project that's been modified, potentially, it will now be called foo1 or foo16 or whatever, because it's only unique per the XML file, and it's a reference per that XML file and not persistent across long, anything like that.

whereas the UID is persistent and unique. So now we have a way of targeting specific things with the UUID. Then we want to be able to say what we want to do with this item that we've targeted. We can do this with a new key called Update Behavior. And let's see.

It allows you to modify and open project items. That's the end of that sentence. So the different processes that we allow you to do with the update behavior are replace if found, replace or add, add if not found, add or remove. And you'll notice there's different flavors of replace and add. And the reason is because we take context into account of the existing project.

So it is important to note, since we're taking the context into account, that the XML importer will do its best job to maintain the existing master clip relationships. But we can only do so much. So you should specify exactly what you want if you know. That's the way to ensure that those are persistent the way you want them to be. So here is a table which indicates what the different cases are. But rather than reading this to you, which you can do in your own time, I'm going to show you some examples.

So replace if found. If you have the original present, we replace it if it's found. If you don't have the original present, we don't replace it because it's not found. Replace or add replaces it if it's found, and if it's not present, we add the item, which is handy if you want to always make sure it's there in the current state. Then add if not found adds it. If it's not found, here it was already there. So if you only want to make sure there's one copy of the item, you would do this version. And then if it's not present, then we add it.

An add just adds. So if there's already an existing item with the same UID-- in this case, there is-- then we're going to change the UID of that new one, the red one here, so that we can add it. So that's what you're saying. You're overriding the UID if necessary to add this thing.

And of course, if it's not present, we keep the same UID and we just add it. Removes the existing item from the project. I thought this was the last piece you need to be able to do all the operations you'd want to integrate fully with Final Cut. So if it's present, it removes it. If it's not present, it doesn't do anything.

Ah, so now I'm going to show you a demo replacing-- this is just an XML demo with Final Cut Pro. Can we switch to the demo machine, please? So here I've got a simple project with a monkey in the sequence, and we'll just export the sequence as XML.

And then let's go look at that XML in BBEdit. So I have a different version of the exact same clip over here in this other XML file, Scratch.xml. And so I'll take the UUID from my uncle is a monkey, copy it. And paste it here. So I'm going to use Scratch, and I want to do a replace. So we'll just change this to replace if found.

And this would be an example of something maybe if you gave it to a different department to make some changes to the artwork, and then you brought it, you got an XML back, then you would just do a replace if found. And it's literally just an export of the XML.

So we'll just import XML. Oh, the version I exported, I didn't color the sequence, so you'll see the sequence color change from red to not red. So, put this XML. Okay, let me, sorry, we have multiple demos on this machine, so let me just revert and do that again.

So it's important to set the sequence settings you're importing the XML as to the same as your target sequence or project. And one can override these settings in the XML itself using the import options. But here, since I just did a straight XML export, we don't output those so that the user can specify the settings they want. So here's the latest version, and you see that the monkey's now scratching his head.

Okay, back to the slides. So the reason he's scratching his head is because he's a little confused about how the XML works, but of course you all know. Can we go back to the slides, please? You all know that it's very simple. There's just the UUID and the update behavior, which allows us to do this.

There's still further work to be done. The specification, for example, as it is today, does not deal well with containers. So if you have a bin and then subsequent items within the bin, since you only have add, remove, replace, you don't have any way of, say, merging the existing contents. So further details can be found in the documentation, which will come out at the same time as the future release of Final Cut.

In addition, we're talking about Apple Event Support today in Final Cut. And this is exciting because Not only are we doing the basic Apple events of open, close, and all those common to the Finder community, but in addition now we're also supporting inner application communication. So you can open your existing projects, you can close existing projects, which is good, but then you can also retrieve and send XML data.

You can select or open items because you can specify them by UUID, and you can also invoke Final Cut Pro's built-in find mechanism. I think that last one is-- Very exciting, and people can do some very interesting things with that. Please note, however, this is Apple event support, not Apple script. We're not talking about a language that we're defining today.

So here's just a really quick look how easy it is kind of thing. All this code is basically set up. And the important thing here is that the OS type for Final Cut is key G. And then you send the event, which in this case is get XML, KGAE, get document XML. And then you send that command.

And then that's it. And that also had the return value in it. So then to retrieve the XML from it, you would just pull out the buffer and all these things. And then with the sample code, you would do the interesting thing with your XML right there. I'm looking forward to seeing what people are going to do there. So the different events that we're supporting are open, close, get XML, import XML. And you can use these in combination. So you can, for example, open a project, get the XML from that project, and close it, things like that.

You can also select a specific item and open that item up in the viewer or-- Canvas, and also find items. And this doesn't return you the values of those keys. Instead, it does the-- The Find Operation in Final Cut, which will go find all the items with, say, the name foo or the comment one, which is the director likes this shot or something like that.

So these changes that I've talked about today-- the UUID, the update behavior, and the ability to make these interactive changes with them. And the Apple Events allows you to do a lot of powerful things. You can modify existing projects. You can do so seamlessly to the user, because now you have the Apple Event support to back you up.

And so I think that you can do very interesting things. The sample code and documentation, of course, will be provided with the next version of Final Cut, and it will be on developer.apple.com/appleapplications. And Dave will be demoing some more of this integration later on in the presentation. I can't wait to see the cool stuff you guys are going to do with this. Thank you.

Thank you, Helena. So, next thing I want to talk about today is metadata support. And this is something brand new we're introducing soon. And it's something that really we found to be interesting and really powerful and hope you will too. But just to make sure we're all speaking the same vocabulary, we'll just start off and talk about for a minute what really metadata is. And sort of the most generic definition I could come up with is that it's an arbitrary collection of ancillary data attached to a primary data set.

And so it's sort of secondary data that while it might not be central to the functioning of an application, it really makes it useful. It's also something that, you know, traditionally you can edit without modifying that core data set or even updating the application that uses that core data set. And another interesting note, really, is that whether or not a particular piece of data is considered metadata or maybe the central or core data of an application may be really dependent on what application is using it.

And sort of an example of here is think about a QuickTime file and think about two applications that use QuickTime files, Finder and QuickTime. When QuickTime looks at a movie file, it's very concerned with things like image size, codec, frame rate, sample rate, et cetera. When Finder's managing a QuickTime file, it cares about things like the size and the label and the name.

But in the context of Finder, Finder may actually be able to sniff the QuickTime file and see the image size and the image codec, but to it, it's really sort of secondary ancillary data. It's things that might be interesting to view in the Finder. It might make it easier to find your file, but it's not central to what Finder does. Similarly, in a way, the actual size or the label of the file could be considered metadata by QuickTime player as well.

The really common example I'm sure everyone here is familiar with would be ID3 tags, essentially album, artwork, author information in your music files. But while they're there, you really don't have to have an ID3 tag in an AAC file or an MP3 file to be able to play that content back.

But simply by having that data, that MP3 or AAC file is a lot more useful to you. You can pull it up on iTunes or on your iPod and actually find out what that file is without having to sit there and listen to it for a few minutes.

And it's editable. You get an MP3 file with a bad tag in it, you can edit that data. And also the standard's grown out of time. I think version 1 of the ID3 tag only had text. I think it was version 1.2 or 2.0 where they actually added support for album artwork.

The metadata support for QuickTime came about a year or two ago in QuickTime 7, and sort of initial stab by the QuickTime team at this. And really, it came down to having containers on movie track and media levels. Each container has a key space. That key space identifies values within.

And then, of course, each container has a number of values indexed by those keys. It's interesting to note that this isn't simply a singular key value pairing. It's sort of more of a key index, right? You have a key and you have a number of values associated with that key.

In a way, it's similar to user data, if any of you have used those constructs in QuickTime before. One interesting note is this means if you're actually going to replace a value in a QuickTime file, you can't simply do an add and expect to write over it, like Helena was demonstrating with the XML, but you actually need to go in and find the old item and remove it.

Now, QuickTime supports a number of key spaces, but they've actually defined one very useful one as standard, which essentially is reverse DNS strings. Now, anyone who's built a plist or built a UTI identifier is very familiar with it. So, if you're using a key space, you can label what your values are by your company and your application. And this is actually a really great key space, because it just means we're all not stepping on each other's toes.

Now, also interesting to note that for QuickTime files, the metadata is stored in the movie resource. QuickTime file itself has a sample data, has a header, a sample table, and then a resource at the end. And the metadata is just stored in that movie resource. Hence, whenever you open that QuickTime file, all that metadata is going to be read into RAM. It's actually good from a performance perspective because doing a query is not going to give you a huge performance penalty. It's not so lovely if you're thinking about putting, you know, six megabytes of metadata in your QuickTime file.

Granted, just about everyone we've talked to, all these cases we've been looking at for the time being aren't using dramatic amounts of metadata, so it's not a huge issue. It's just something to be aware of. Also important to note that reference movies will carry this stuff as well, and you'll actually be carrying a unique copy in your reference movie.

So how do you get at metadata? Well, it's pretty simple. You get a metadata container out of QuickTime. You iterate using the get next item command. You can basically specify a key if you don't want to iterate through everything. And then you use the value or property APIs to get information back. Traditionally, once you have a metadata item, you'll query the type to make sure it's what you want.

You'll get the size. You can allocate a buffer, and then you'll actually get the value. If you want to add a key, it's pretty similar. You get a container, and then you call add item. You want to remove item, again, get a container and use the remove item APIs.

Now, going to Final Cut Pro for a second. In Final Cut, we really built off of QuickTime support for metadata. So what we're supporting is metadata, arbitrary metadata, on the movie and track levels. We're only supporting metadata with a reverse DNS namespace. Again, this is what appeared to be most useful to us and everyone we've talked to.

And we're using the defined type primitives that QuickTime supports. They have things like strings and numbers, blocks of binary data, etc. Certainly, we would encourage you to use the more readable types in terms of things like strings and numbers for reasons I'll get into in just a moment.

Now, it's also important to note that when Final Cut Pro notices metadata in a QuickTime file, it's actually going to cache a copy of it. So in Final Cut, whenever you add a movie to a project, we create a file record, and that file record has all sorts of interesting data on it, like the time code, et cetera. And we'll basically snapshot the current metadata state of that file and store it in that file record.

Now, what's nice about this is if your file goes away, your metadata hasn't gone away. It's there safely cached in the project for future use. But it's also important to know that this is a cached copy of the metadata. So essentially, sort of the term we use is file always wins, such that if I bring a file into a project with metadata, it creates a saved copy of it.

Cool. I save and close the project. I then go and modify the metadata in that file. The next time I open up that project and reconnect to that file, whatever new metadata state is in that file is going to be put in the project over the next time. old cash state.

Now, I mentioned a moment ago that it's really good to use nice, clean types like strings and numbers for metadata. And really, that comes down to the fact that we also export metadata through the XML interface. So you bring a file into Final Cut with metadata, and you send out XML, you'll see new metadata tags in that XML listing all of those elements. Certainly, everything we support, we will emit through XML. But if there are things like strings and numbers, then your users and your tools can actually read it via XML, which is very handy.

We also have a couple commands similar in fashion to the update behavior commands that Helena was discussing earlier that actually allow you to do basic metadata editing via an XML import session. So you can essentially add and remove keys. You'll also note that in XML, metadata elements are supported under file, audio, and video. And here is an XML snippet with a metadata element. It's very similar to the clip we were looking at earlier. And you'll see a definition there. We're defining it as part of QuickTime. We have our key, we have our type, and we have our content.

And here are the two commands. Again, you can pull down the slides and look at these in detail. Not that there's much. It's pretty simple. Add adds a new one to the end of the list, and remove will remove everything for that key. Now, this is all well and good, but there are certainly a couple of things missing that we've noticed and we've certainly heard requests for. Temporal metadata is the big one.

There are an awful lot of really interesting types of metadata you can put on media files where essentially you associate a piece of data with a range of time in that file. Really cool stuff, just not there today. Also, one of the big reasons to put metadata in is spotlight, to have spotlight index all of your QuickTime files. Now, both of these things we're actively working on with QuickTime team. Can't really talk about when they'll be available, but hopefully at some point, and we've definitely heard a lot of feedback on wanting these in the software.

So really quickly, just talk about metadata and post production, because in a lot of use cases we've been out there researching, we found very definite usages for it. And really, when we look at what customers are looking for in post production tools, they want to reduce the huge amount of annual labor that seems to be involved in actually finishing a production, and actually have their media managed in an intelligent fashion, and just be able to throw arbitrary interesting bits of data and have them ride throughout the production pipeline.

One interesting request is actually carrying interesting data from production through post production. We have a lot of really nice new cameras these days which record things like lens settings and lighting and the camera operator in the media as they record it. Having this data embedded in the media file and flowing throughout the post production process means you can use it near the end.

If you've taken a beautiful beach shot, sunset, a car driving along, and you know you have to composite Godzilla in the background wreaking havoc and destruction, if you know what lens that was shot with, well, then your 3D guy can render it appropriately so it really looks like he's wreaking havoc and destruction, not like he's a cardboard cutout or a guy in a rubber suit.

Media management, file management, asset management is really the number one area of investment, honestly, we've seen out from customers, and they're actively looking for solutions for this. And, you know, in helping a number of companies build solutions in the past, we found that just metadata is really a key enabler for this, in that now being able to drop arbitrary data in files means you can track them independently of a project, independently of a path on disk.

You can do fun things like indexing content to make sure it's stored on your server. And you can play fun games like when you do essentially a check-in and check-out, very similar to CVS. You can look at the dependencies of a project and figure out what's on your server and what's not, or what's not locally, and pull it across.

And one other interesting case that's come up over the last few years when sort of started talking about metadata is really rights and clearances. You know, if you're producing a TV show or a commercial or a movie, it's really important that you have the rights to show everyone who's in that production, rights to all the music, etc. And, you know, especially if you're out there shooting interviews on the street, it's really key that you get sign-offs from everyone involved.

Frequently, when you're doing a, like, doing a production for a client, you'll do an audit at the very end of the production, which will involve a poor PA sitting there scribbling notes, frantically watching the video, and correlating that to a back, back to a big stack of piled notes.

Well, if up front someone can simply enter who's in every individual shot, such that at the, at any point in the process or at the end of the project, you can run a query and just get a list out, and now all someone has to do is correlate that list with a stack of signed releases.

Or if you want to be really slick, have it correlate with a database of signed releases. Then doing an audit becomes trivial, and it just gives the client a lot more confidence. It gives the company lawyers a lot more confidence, and it's something that everyone I've talked to, you know, they think about maybe putting about 10% more effort in up front, and it's just absolutely worth the savings at the end.

Now at this point, I'm going to do a little demo, as Flea mentioned, try and pull together a number of these technologies. Can we switch the demo machine, please? Final Cut Pro Project Manager: I've got a couple things here. If I go in here, I've got a little application I've been working on. I've got a little project where I have some files and I have a project here.

You can think of this as a broadcast workflow, but really this is just some film footage that I have laying around, just a little short film. I have the dopey hero, his annoying coworkers, the hot girl he can't talk to, his boss, and annoying French puppets. So, what I really want to do is I have this cut I'm working on, and you'll notice that I have a couple pieces missing. I've got some black here and a couple clips, and I actually want to go ahead and drop some files in and just update this in the background so I don't have to think about it as I have new content coming in.

So, what I'm going to do is I'm going to just go ahead and close this project for now. I'm going to come here to a little app I've been building. This little app is called Assembler. is essentially to monitor files coming in and update a project for me. So in Assembler, I'm actually going to open up that Final Cut project I just saw.

And as I open it up, you'll see that actually via Apple Events told Final Cut Pro to go ahead and open up that project. At the same time, it came back and asked for an XML copy of the project to populate the sequence list. So in fact, I can do things here.

I can say, I want a new sequence.

Now what I'll do is I'll come back out here to Finder, and I have my folder here. I'm going to go off to another volume, and I've got some media that's just come in from the field, a couple of things here. So what I'll do is I'll take this Enter Office clip here, and I will drop it in my incoming folder. And as it copies it, the app will notice it here in a second. Hopefully. It will hopefully notice the file here in a moment.

Well, the demo gods do not appear to be with me today.

That I wrote a little while ago, which basically just dumps out the metadata in the QuickTime file to the console. And if I run this, it's going to complain because it's actually PowerPC build. And you'll see I have this key here, org refuge file clip ID 2-2. 2-2 essentially correlates to the name of this slug clip here. And again, assuming the demo gods would have been with me today, this actually would have motivated the replacement in the sequence itself.

But sadly, not happening today. Can we switch back to the slides, please? So, just to sort of summarize where we're from today, really what our goal has been, and sort of will cluster the Final Cut team that Helena and I work on, is really to enable more workflow tools around Final Cut and around post production. We very strongly believe in open formats for interchanging between different applications, you know, because when we talk to our customers, they're not buying one product, they're buying six, because no one does it all. And linking those applications is really important.

We've put together a number of new features for you, again, coming in an upcoming release of Final Cut. Version 3 of the XML, with all the powerful, essentially, additive commands to actually edit a project in place. Metadata support, which is just going to become bigger, and especially when you think of large organizations wanting to track just terabytes of media. And Apple event support, allowing you to build applications that are tied directly into Final Cut.