My name is David Black. I'm a senior architect in the Pro Apps team. And we're here this morning to talk to you about integrating your applications with Final Cut Pro, various technologies to basically enable you to build tools that complement Final Cut and combine a number of tools together to build interesting workflows for your customers.

We're going to talk about a number of technologies this morning. Of course, data interchange to push data between applications, some automation tools for Final Cut Pro, leveraging metadata to basically leave interesting breadcrumbs in your media file, and also a few hints for creating and managing media that's compatible with Final Cut and Final Cut Studio.

Start talking briefly about project data interchange and really the formats that you'll want to use here. Now just to sort of set some context for everyone, sort of start with the question of what project data is. And really it's the glue that ties everything together. Especially in post-production, you know, there's a lot of effort that goes into shooting content, getting video and audio and images, but there's almost more work that goes into sequencing those elements together and combining the raw pieces into a compelling product to deliver to customers in the end. So really, at the end of the day, this is the data that your users spend the most time creating. Of course, with all that richness, it makes that data traditionally very difficult to exchange beyond the most basic representations.

Sort of a little bit of background and history here. All this began probably 20, 30 years ago when you really had hardware-based systems. You think of a rack of tape decks and a switcher controlling them, timing together to lay down a show to tape. And there was interchange between these systems, and it really was basic. You're basically looking at a list of time codes, clip IDs, all put in ASCII text files. Really easy to move around, really easy to read, but again, not a whole lot of richness there.

Contemporary formats came about in the 90s as nonlinear systems made the jump to computers. And while they were great and they were rich, owing partly to the complexity and partly to the limitations of the systems at the time, they tended to be built around binary container formats, things that were efficient in size, but rather difficult to parse, especially if you didn't own the format.

Now we came at this back in the late 90s, and we really wanted to take a fresh look at the problem. So we started by requesting feedback. We talked to our customers, and they gave us some really logical points. They wanted, you know, really have common formats for data.

They wanted to get at the contents of those projects. They already had access to the media files owing to the way we use QuickTime, but they wanted to get at that project data. And they wanted to leverage it to integrate Final Cut into existing and new pipelines that we're building.

When we went to talk to developers, we got much the same feedback, really. You know, they wanted to interchange data, you know, both with our tools and other tools. They even wanted to bridge tools with their code. They wanted to write new tools and extensions, and they also wanted to build those pipelines their customers were asking for.

We came away from this with what we felt at the time was a very different take on the problem. Traditionally, this had been viewed as pushing large amounts of data between two very complex systems. But it was really more than that, especially as we talked to developers. Because it came down to this not only being a conduit for pushing between large systems, but as a data manipulation tool.

You know, it's almost more interesting in some ways to take data, you know, pull it out, make some small changes to it, and push it back in. That was really powerful. And also making things simple enough so that not only could developers use it, but also power users.

From this, we came up with the Final Cut XML Interchange Format, and we introduced it with Final Cut Pro 4. Obviously, from the name, it's XML, which is nice because it's somewhat readable. It's pretty well self-documenting. And, you know, at the end of the day, it's text, really easy to parse, and there are a lot of libraries out there, pretty much on every platform for using this.

And when we designed this, we took care to put the complete contents of our project in this file. Some previous data format efforts sort of restricted things or black things out, and we felt that was really important not to do. Because ultimately, this is a conduit for interchange with everyone. And also, again, sort of opening up not only to developers but power users, making it really easy to look for things.

Here's a small snippet of XML. And, you know, especially seeing XML, it's pretty logical. You've got the header information up there. We've got a clip element and really the critical things here, the name of it, the duration and the frame rate, even a timecode reference tying this piece of media back to a piece of videotape in this case. Now I'd actually like to ask a colleague of mine, Helena, to come up here to talk to you about some details of using the Interchange Format with Final Cut Pro.

Good morning. So you want to use Final Cut Pro Interchange Format when you want to push data to Final Cut, you want to pull some data that's in Final Cut from it, or if you want a round trip, so you want to modify an existing project. And I'm going to talk about handy tools to do each of these workflows.

So to make it easier for you guys to use the XML format, we've added some-- we've put in some handy features. Only one of these is new. So the first one I want to talk about is the sparseness of the format. So if you look at the XML that's exported from Final Cut Pro, it is really long. This is one I exported that has a sequence with an item in it on the video track.

So it's got things like the UUID for that object and updating behavior, like if you were to import that XML again, what should we do with this sequence? It's got, as Dave mentioned, written timecode, but it's also got all sorts of default values for like scene shot and take or comments.

So--and you notice that all of these are actually empty XML nodes. And these are all because we want to give you all of the keys when we export. We want to make sure you know all of the data. But when you send us XML, you don't have to specify all these things. So this is actually almost a full XML file.

There's just closing out all these scopes, the file, the clip item, the track, et cetera. So it didn't quite fit on the page, but that's all there is to it. So we have the name of the sequence. This is actually the XML I sent to Final Cut to create the same project that I had turned around and exported that I just showed you.

It's got the name. It's got the rate of the item. And then it specifies where that item is. The track and the location on the timeline. And then it specifies the source file. And that's it. So you can really send us very directed information and then get back all of the data that you need from us. Both are available to you.

The second thing I want to talk about is the auto sequence settings. So if you look at the XML export, sorry, import dialog, there's this default sequence setting. And a lot of people have complained to us that this is non-intuitive or it's confusing, people don't know what to do with it. So we added the ability to leverage the open timeline. So in Final Cut Pro 6, you can edit an item onto the timeline, and the timeline's sequence settings can be changed to match that first item.

That's exactly what's happening here with this feature. If you select Auto, the first item in the timeline modifies all the sequence settings of that sequence. So then you don't have to specify them. And so the ability to do that at XML import time is new in Final Cut Pro 6.0.3.

Another thing I wanted to talk about is inheritance. So in the XML, you have things like rate and duration that are required all over the place. You need to specify it on files. You need to specify it in clips. Here in this snippet of XML, we have it on clips.

And it's also required on files, but you'll notice it's not here. And the reason is because we can just inherit those. As long as they're the same, an enclosing scope can tell the nesting scope what those values are. And that's available on most nodes. and it's in the documentation which keys do and don't support it.

Another one that's similar but different is the ID attributes. So you'll often in the XML reference a media file multiple times. So the first time you reference it, you want to specify the name, the path URL, maybe track information. You want to fully specify that file to your best ability, right? So then you would specify on it as well an ID.

Like you could say foo here. And then the next time you refer to it, you say, hey, I'm using foo again. And then you don't have to specify any of the contents of that node because we already know that that's the same item. In the XML that we export, we will use this feature. And so when inspecting, you also want to look for that. It's available on clips, clip items, files, and sequences.

Another thing I wanted to talk about was the update behaviors and UUIDs. And those came in the XML version 3. So when you look at the XML, I mentioned this briefly before, there's a UUID on each item. And this is visible on all project-level items. So clips, sequences, and bins. And the UUID lets us specify this item is the same item. So if you take this sequence in the user interface, copy it, and you paste it in another project, it will have the same UUID. It's the same object.

If you export it and import it, it's the same object. And so then if you wanted to modify it in some way, you export this project, and you just want to change that one thing, you can just specify an update behavior. And the default one is add, which just adds a new object.

And then I just want to change that one thing. You can just specify an update behavior. And the default one is add, which just adds a new object. And then I just want to change that one thing. You can just specify an update behavior. And the default one is add, which just adds a new object. and then actually disregards the UID if there's already something with that same UID. But you can also then replace an item. So you can have a sequence, modify it in some way, and then send it back, and it will be the same item.

Other options available are add if not found, remove, replace. And it's important to note that this update behavior key is also available in the metadata scopes, but it works a little bit differently. And I think Dave is going to talk about that later. And you want to make sure not to mix this up with the ID attributes I just talked about.

So the UUIDs here are a child node of the sequence in this case. But again, clips and bins also have them. But it is not the ID attribute. That ID attribute is unique for the XML file, but not globally unique, where those UUIDs are unique identifiers for that object at all times.

The last one I wanted to talk about was import options. And this gives you the ability to skip the import dialogs. So in the XML, the top level, you could be saying import options, and you could skip this dialog here. And it includes all the data that's in the dialog. So the first option on the dialog is the destination project.

It tells you whether you want a new project and whether or not, if you have an existing project, what that project is. And so here there's two different XML keys to represent that. There's also one for the default sequence settings, and you can specify that auto by saying use first clip settings.

There's also this checkbox here, and this checkbox is disabled if you are using the auto because you're obviously not using any data specified in the XML. You're using that first clip item's data. So in this case, it's true, but if you wanted to use auto, you would put false. And there's also import options for the following three. Then there's also one more, and this one is my favorite one, actually.

So this one's display non-fatal errors. And when you are shipping your products, you don't want anyone to see those errors. So you would want to say display non-fatal errors, false. But then if you're debugging, you want to see exactly what's going on. You want to make sure you catch every last thing. And I'm sure that you never have to say display non-fatal errors, false, when you ship. But hypothetically, were there any errors, you'd want to hide them.

I should have explained that you get a dialogue at the end of XML import and it says, "There were errors found. Would you like to see them, true or false?" And that's what that Boolean hides that dialogue. When you round trip Final Cut XML, you would do something like you would export the XML, you'd modify it in some way, and then you would send it back into Final Cut with an import. So let's look at kind of how you would do that. Let's take a snippet of XML. It's very simple. It's got a sequence of the UID and update behavior. And so you would specify the same UID, and then you would change the update behavior to replace.

And if you want to switch up media files, it's very similar. If we look at another snippet of XML, we see, in this case, it's a file that we want to change the path URL on. So you would change out that path URL to the new path URL. And then you also want to modify the track details. So here, this is a-- I actually put a dot, dot, dot. This is like a six track audio, one track of video file.

And you would want to take that out if you're modifying it in some way. So let's say maybe you're changing it to a stereo file. Because we've specified those tracks there, we're going to go looking for those tracks. But if you take that out, we'll only look for the tracks that you specify. If you don't specify any, we'll just look at the file. So let's remove those.

And then so you would send us a snippet that looked a little bit like this. And make sure you watch out for the ID. Remember I mentioned that the reference is there and it's an empty node. So if you were to go through searching through the file without looking carefully to see if you were actually getting some child back, like let's say, go get file/path URL. And you get it and you get nothing and you'll then have a null node.

So watch out for that one. I've mentioned a little bit, there's different versions of Final Cut Pro's XML file. And it's important to note that those are not the same as different versions of Final Cut Pro because the XML format, as Dave mentioned, came out in Final Cut Pro 4.1.

And the versioning of the XML files has to do with the features of the XML format. So, for example, in version one, you know, you have a basic project. But in version two, we changed the track layout of audio files to match Final Cut Pro 5.0. And then you also get multi-clips and you also have the ability to update and things like that in the future and later versions, sorry, in the later versions of the Final Cut Pro XML format. But you don't have those, say, in version one. So if you want to use version one for maximum compatibility, that's great. But then you obviously don't have the features. So you have to have the features of the latest version of the XML format.

They all are, all versions of Final Cut can take in all the older versions of the XML, but not future versions from when they were created. So I just wanted to make a point about user experience. We give you the ability to use import options, and I'll talk a little bit about AppleEvents in a second.

And you want to use these to give your users a rich experience. You don't want to have them use the XML import and export dialogs, if at all possible. I think you want to skip those, because it's a little bit confusing for users. Full documentation of the XML format can be found on our website.

Now let's talk about some of the ways you can automate Final Cut Pro. So you can send Final Cut Pro Apple events. And you can send events to read and write the XML, to manage projects, to perform a find operation. And it's important to note this is a find operation in the user interface, not find operation that gives you back data. And those are all documented on our website.

And I wanted to call out that the Apple Events is not Apple script. So you can tell us, give me XML, and we'll run an XML export and give you back the data. But it doesn't give you the ability to do everything in Final Cut because that's a lot more complicated.

So if you want to import XML into Final Cut, you could either do a finder launch to send that XML into Final Cut, and we would open it. And you would use the four-character code KG, and you would also use XML. There's a space there. And you could also do this by sending us an Apple event.

And you would use the I XML four-character code to specify that. And then you would also send us a buffer of the XML you wanted to import. Potentially, you could also choose to send it to a specific project, in which case you'd need to send us also that project file's FSRF, I think.

And in the XML, you could use import options to avoid dialogs. So let's look at how you do that. You have basic initialization for all AppleEvents. These are very similar. You have all your parameters and then you init everything. And then at the bottom here, you have specifying Final Cut by saying key G. And you would just say the four-character code signature of any application that you were sending the event to.

And then to do an import XML, you would specify that I XML, which I just mentioned, for import XML. Then you would pass in the buffer for the XML data. Here it's called XMLD. And the Final Cut Pro project is optional, which is why it's highlighted. And that would be FCP for project. And then you do the send. It's very straightforward. To do an export XML, you would do EXML for export XML. And you can pass in the project again that you want to specify.

If you don't specify one, you get the topmost projects XML. And that will return that XML buffer in the same parameter name XMLD for XML data. So to do that, you would send the same thing, only you'd modify the I XML to EXML. And then you would not specify an XML buffer because you're going to actually get one back.

So let's remove and change this thing. So this would be your send. And then you need to go get that XML data in the reply event. So let's look at where that is. So you have initialization of the buffers, essentially, that you're going to pull that data into. You need to get the size of the thing from the reply event. And then you just pull it in.

So it's very straightforward. We have this also for opening projects, which is OFCP, closing projects, CFCP, find. The find is a little bit more complicated because it has more parameters, some of which are enums, but those are all in the headers, which are in all the sample code, and it's also documented on that. There's an appendix for the Apple events in the XML documentation. It's all in there.

So when you're using the AppleEvents, you want to be aware that you're using-- I mentioned before the UUIDs are not the same as the IDs. And when specifying a specific object in the AppleEvents, because you can get the XML of a specific object, you want to specify it with UUIDs. Just don't mix those up with IDs. And it'd be great if you don't block your application's event loop waiting for a response from us. Because we actually do exactly the same thing we do in the user interface.

So if you export the XML for a whole project that's huge, it's going to take us some time to get you that XML. And in the meantime, you're just sitting there churning and waiting. And we're like busily spitting out XML. So that could take a while. So it's best if you don't block waiting for us. and full documentation can be found on the same site. You can notice it's Chapter 9 of the XML documentation. So, Dave will tell you more about metadata. Thanks. Thank you, Helena.

Since Helena has gone through Project Data and AppleEvents, I want to spend some time on metadata. This is something that we've been spending some time on recently, and it really enables some powerful workflows. Again, just to set some context, so we're all coming from the same spot, here's a very basic definition of what it is.

Basically, we think of it as just a collection of arbitrary data attached to a file or a dataset. It's something on the side. It's useful with the data in the dataset, but not required for it. And you can actually modify that data, ideally without touching your sort of central core.

Probably the best example that everyone's familiar with would be ID3 tags in your MP3 or AAC files. The central content of that file is that compressed music. That's the thing you play back and you enjoy. But really, your enjoyment of it is enhanced by being able to figure out what that file is with more than just the file name, things like the artist and the album and even the year it came out. And going back to our definition, it's editable. So if you get a file with a bad tag, you can fix it. And it's actually grown over time with new fields. Album artwork came in later than the initial version, for example.

Now, in the post-production space, you might, if you haven't thought about it before, you might sort of ask yourself, well, what could you use metadata for? Well, there are a lot of things. You know, at the most basic level, you might take media files that your software creates and put a tag on there indicating you created it.

Maybe cache some information that links back to some of your other files. If you're, you know, working with or building an asset management system, you know, store your database IDs in that media file. You know, so if that file itself comes back in later, you can track it back to your database if other links went stale.

If you have a tool that does interesting media analysis, maybe it's very computationally intensive, you know, cache that on the file as metadata, right? It's there. It rides with the file. You know, you do your analysis once. Then you can use it for rendering or other process later.

And another thing we've seen a lot of growth in recently is actually leveraging data from the production process into post-production. You know, making use of new file-based cameras that put all sorts of useful things in the media they record to storage. If we persist that as metadata in the media files all the way through, even until the very end, we can pull that. and sort of figure out where things came from.

Now, QuickTime added support for metadata back in version 7, and the concept is basically of metadata containers, with containers available on the movie, track, and media levels. Each container is pretty much, you know, sort of a key value list. It's not really a one-to-one key value mapping. It's more sort of a one-to-end mapping. So for a key, you'll have one or more values.

It makes some interesting semantics if you're trying to add or replace items in there. And of course, each value has a definition of the data type stored within it along with the length and the actual value payload. And the keys are actually covered by a key space, and that key space is something you specify when you work with that container.

The primary key space that QuickTime uses, uses reverse DNS strings. And it's actually quite nice because one of the challenges with metadata has been sort of preventing this collision problem. You know, if we both have a value named, if we both have a value for studio and we just label it as studio, then if I put a value in that file, you put a value in that file and we don't know where it came from, it can be complicated if we have tools dependent on that value.

So by using reverse DNS, we can put things like our organization name and our product name in that labeling. And it really helps, especially if you think of media files you've created or modified sort of further down the production pipe being analyzed by another tool or a user that didn't necessarily know where they came from. You know, and here's a very basic example, very generic of just, you know, an organization, a product, and a key.

Now the metadata containers themselves are interesting because unlike the sample data, unlike your audio and video data, it's actually stored in the movie resource. So of course it's going to go wherever that resource goes. So if I open a QuickTime file with metadata in it and I save a reference movie, a copy of that metadata is going to go along with that movie resource in the reference movie.

Again, sort of a couple attributes of this. This data ends up being loaded into memory, which is nice because if you're going to query it, you don't have any additional overhead like you would if you were querying audio and video data. But you want to be mindful of how much data you're putting in here. You don't want to bloat the movie resource to, you know, 200 megabytes just for data set. If you have a set that large, you might want to look at another option for storing it.

Going into some API stuff really quick, I've certainly heard from people that the APIs seem a little opaque, so we'll go through some basic usages. It all starts with getting a container. And you have the QtCopyMovieMetadata or TrackMetadata or even MediaMetadata APIs that give you back a metadata ref.

And this is actually a ref count instance. You have to release it when you're done with metadata release. The interesting point here is even though all these APIs have copy in the name, they're giving you a pointer or an instance to the live container in data. So it's not so much that here's a complete standalone copy of my container, it's here's an instance I can operate on, just something confusing from the API name. Now once you have that container, if you want to start getting at things, you basically use the QtMediaGetNextItem API. When you get an item, that item's going to have a reference to the value and the key in it.

And the simplest thing is really just to enumerate over them. So in this snippet of code here, we initialize an item ref with the uninit constant, and we're just basically iterating. We've got the container, the storage format, the key format, and pretty much as long as that comes back without an error, we're getting all of the items in that container.

Now, let's say I actually wanted to find all the values associated with a particular key. We'd modify that call slightly. You know, we have a string here with a key we want to look for, and you notice that we've modified the call we made before with that key value in the link. So now we're going to iterate over all the values attached to that key.

Now once we have that item ref, if we want to get the value payload, we turn to another API. The Get Item Value API will basically take the value payload and copy it into a buffer. Of course, most of the time you're going to want to dynamically allocate that buffer. So you can actually make that call with null in the out value pointer parameter just to get the size back in that final size argument.

Oh, one other thing I'll pop back to really quick. Once you have these items, you can use the QuickTime Properties API to get all sorts of interesting information about it. This includes not only another way to get the size, but also a way to get the data type of that value as well.

Now let's say you want to add something to a container. Well, you use the logically named Add Item API. It's kind of long here, but it's basically got all the essentials. It's got the container, the format, the key, the key format, the key data, the item and the type, and everything.

You're going to specify both the key and value when you're using this API. And of course, what it's going to do with that key is it's going to look it up, and if there's already a key and a value list existing, it's just going to append that value to the list.

And of course, we've iterated over, we've added something. What if you want to remove something? Pretty much the simplest way to do it is take that key and basically call this API here, which will remove everything associated with that key. Now, what if I have a list of items attached to a key and I only want to remove one? You can actually use the iteration code we saw before to figure out which value you want to remove, and then you can call the remove item call to remove the item from that container.

So now we'll do a little demo really quickly. And we've got an example application we put together, again, because we wanted to help you use the APIs. And it's kind of neat. We use all the APIs we've talked about to basically open up a file to read all the metadata out of it.

We actually made a little core data model to hold all this in memory to help us bind to our Cocoa UI. So you can actually see it and step through it all. Now, all the source code for this is on the WWDC site. It's on the Apple Applications page. It's also linked to this particular session. So if we can switch the demo machine, please.

Excellent. So I'll go ahead and run this metadata editor application. And I'll open up just a file over here. We'll see this file later. And it's pretty simple. This is actually a QtKit view over here for just viewing the contents of my clip, if I can click right here. And as I twiddle down through this, I'm basically walking through all the containers in the file.

This particular file only has one key associated with it. Here are all the normal primitive data types that QuickTime supports, and of course, the value payload over here. Now, I actually want to open up a slightly more complicated file for you. I mentioned earlier one of the uses for metadata being to link production and post-production. So I'm going to take a funky chicken movie over here, which we actually captured using a Panasonic camera.

I'm actually going to make this big because there's so much data in here. Now, this actually originated as an MXF file on a flash card. And there's all sorts of MXF metadata here persisted as metadata to support workflows where MXF might be part of it using the UMIDs. But there's all sorts of interesting tidbits here, including some of these fields that could have potentially been set on the camera by the person recording it. And of course, you see on the other tracks, there's a slightly different set of metadata as well.

Can we get back to slides, please? All right, so we've talked about metadata in the generic QuickTime context. Now I want to focus on how Final Cut Pro uses QuickTime metadata in particular. In 5.12, we added support for QuickTime metadata, building on all the support we just talked about. You know, basically arbitrary metadata in QuickTime movies. Currently, you want to note that we're only handling containers at the movie and track levels. And we're also supporting that primary QuickTime namespace that we talked about. And of course, all the standard data types.

Now Final Cut makes use of metadata in a very specific way. From the outside it might seem a little strange, but there's actually a method to this. And it's really all about maintaining a metadata cache. Now the internal architecture of Final Cut is such that when you bring in a file, any file, we actually create a little file record for it. And we cache all sorts of interesting information on that, which gets saved in the project. Things like the number of tracks and the format. In fact, a lot of the things you actually see in the XML are in that cache.

And metadata is really the same way. Such that when we open that file and we build that file record, we'll read all the metadata out of it and store it in that file record. Now the useful thing about this is Final Cut has the notion of files going online and offline. So I have a project with a file, I quit and I save.

If that file goes away and I relaunch Final Cut, it's not sort of game over, I can't open the project. The file and whatever clips are there, they're just marked as offline because the media file isn't there. Of course, the user can go point to it or go and pull that file back in their proper location.

But the nice thing is when that offline file record is there, all that metadata is still present and active. So for example, if you're building an asset management system and you had database IDs stored as metadata. If you open up a project and you see the files offline, you can pull that metadata, go off to your server and pull a new copy of that file down and reattach it to that project.

Now, of course, another interesting part of this is that we have that cache in the file record, but you want to note that the movie is the authoritative source. The copy in Final Cut really is a cache. So if we sort of go back to our model before, where we make a project, we bring in a file, we have the metadata there.

If we save our project and quit, and then in another application modify the metadata in that file, the next time Final Cut launches and attaches that file, it's going to see the metadata has changed, it's going to get rid of its copy in the cache, and read everything in from the file. There's some interesting bits of this you'll see in a few minutes, but again, just something to be aware of in terms of how Final Cut uses metadata.

Now, of course, because there's metadata in Final Cut, there's also metadata in the XML format. About the same time we added metadata elements in XML, again, they're basically under the file elements, because that's where they exist in Final Cut. You'll see them under File for movie-level containers and under Audio and Video for the tracks. Here's a snippet of XML again, and a file definition similar to what Helena is showing us earlier. And here's metadata definition. And basically, we're indicating it came from QuickTime. We've got the reverse DNS string. We've got a type. And then we actually have the value payload.

Now, of course, XML import also has some processing that you should be aware of, and this relates to the caching behavior we just talked about. Normally during an XML import, Final Cut will take that XML file you give it, we'll parse it and make sure it's syntactically okay, we'll go through and instantiate all the Final Cut Pro objects within that file. So, you know, build your sequence and put everything together, and then once that build is complete, we'll actually go and reconnect all the file references within.

So in that instantiation phase, we'll create offline file references like we discussed, and at the very end, we'll roll through and attach it to all the media files on disk. Now, during an XML import, you'll want to note that during that instantiate phase, we take all those metadata elements, and we put them effectively in the metadata cache in those offline file elements.

But of course, owing to the file being the authoritative source, when we do that reconnect phase, anything that's defined in the XML by default is going to get deleted in favor of what's in the media file. This means that if you want to use the Final Cut Pro, you'll want to use the Final Cut Pro. But if you want to use XML to actually populate metadata, you have to take some special care.

Basically, and it's actually simple. Helena talked about the update behavior commands earlier, for new clips and sequences. We support a subset of them in the metadata elements. We basically support add and remove. The idea being if I want to add a metadata element, I just put that update behavior in there.

And during the import processing, during that instantiate phase, what we'll do is not only will we put those elements in the cache, but we'll actually pull off a copy of it, so that once the reconnect phase is complete, we'll sort of go through and process those metadata transactions. So after we process this piece, we would actually add a new element under that key to that file. And of course, at that point, it's in the file, it's in the cache, everything's good.

So we'll pop to another demo here just to try and illustrate a little bit of this. We've talked about caching, talked about exposing metadata in XML, and using the commands on import to actually modify metadata. Can we switch to the demo machine, please? All right, so we'll go ahead and close out of our application here. We'll come to Final Cut where I've got an empty project.

And I'll go back to my folder, and I'm going to take one of these puppets files here. And I will drag it into Final Cut. And if I go ahead and take this now, and actually before I do this, I'm going to just open this up in the editor really quick. So currently, the only element in this file is this clip ID key. So I'm going to drag this over to Final Cut and export this to XML.

Okay, so now I've got an XML file. I'll pop this thing open, and if we search for metadata... Here's the definition that we were just looking at. Again, that ID. Now, I want to use the update behavior command that I just mentioned to add another element to this file. So I'll pull a little snippet out here. Actually, what I'm going to do is I'm just going to replace this one. I'm just going to add a new key to this. So I'll save this. And actually, I'm going to do one more thing really quick.

The file will be attached to the old clip as well as the new one, but this will just make it a little bit easier to see. So if I double-click on this, we'll import it. And now if we go back to Finder, we open this up in the editor, we see we added our new ID here. And of course, at this point, if I were to export the XML from that project, I'd see both of those tags defined.

Can we go back to slides, please? So some thoughts to take home from metadata. Reading metadata with XML is great. It's simple. It's quick. Sort of the whole thing-- the whole reason why we did XML in the first place. But normally, you're probably going to want to think about adding metadata using QuickTime, using all the APIs we discussed. Certainly, we put the interface in XML to modify metadata. It was normally intended for power users and development testing.

It works, but if you're doing large volumes of things, it's probably going to be more efficient to do it yourself in your code. And at that point, you're doing it completely separately from Final Cut, so you don't have to have Final Cut running necessarily if you're on a server, for example.

Just sort of like our philosophy behind XML, really your philosophy behind metadata should be not only storing useful data as metadata, but making it readable. Making it readable for you in the future, for your users, and your fellow developers. Think about using strings and numbers, discrete values instead of large blocks of binary data. Of course, if you do that, you don't have to deal with Indian or alignment issues. And ultimately, you make it easier for everyone. If I pull it open in a general metadata tool like the one I just showed you, and you can actually see what it is.

Labeling metadata elements is also part of this. We talked about reverse DNS being there and giving you a large namespace to work with. Use that. Make sure everyone knows where your data comes from and so there really aren't any collisions. Collisions are really bad. Of course, also want to think about scoping.

In one of the files I opened for you, you noticed they had different data on the movie and the track levels. That's because there was data on the track which was specific to that track. Think about that with your data. If you have data that's specific only to the video, probably want to put it on the video track, as opposed to things that apply to the media package as a whole putting it on the file.

So now sort of the last main section we want to talk about is some tips for what you can expect for media files coming from Final Cut Pro and also for you to create media files that Final Cut and the rest of the studio applications can use without any issues.

Now there are a number of ways, you know, at the macro level to get media in and out of Final Cut. You know, sort of the baseband interfaces, you have a PCI card or a FireWire interface, you know, doing sort of linear captures and linear outputs. There's also a lot of file-based devices, you know, cameras that record to hard drive or flash drives, where it's, you know, it might be in a proprietary wrapper or an MXF wrapper, and they'll still be sort of almost a logging process to bring that media in, but it'll get re-wrapped into a QuickTime container, and of course all that metadata persisted.

And then there's also file interchange. This is probably going to be the most interesting to everyone in this room, where, you know, effectively you're importing media files you've created into Final Cut or doing an export operation to get a self-contained QuickTime movie or even a reference movie out.

Now for file interchange, we've been talking a lot about QuickTime today because that's really the primary format for our application. There are other formats like AFF and BroadcastWave, for example, in the audio domain, TIFF and Photoshop files for stills. But really the prime format you're going to want to think about, especially with the richness of metadata support, is QuickTime.

And of course, you know, it's a generic container, basically audio, video, all of that. We support numerous formats in it, you know, everything from, you know, DV or JPEG on up to uncompressed HD. And of course, for you, you've got the whole QuickTime API there to help you create those files, so you don't have to build a whole, you know, file read-write runtime to get that QuickTime. Everything's there on the platform. David Black, Helena Ju

Same thing goes for codecs.

You can do a lot of things with different codecs in Final Cut Pro. It really only supports a particular subset. And that's based on what's relevant to the video industry, what has predictable performance, and really what our customers have been asking for. So you want to make sure that any codecs you're working to put media in are actually supported. Another note here is that we really don't support compressed audio at this point in time. Again, it comes back to squeezing the most real-time playback performance out of the machine and having predictable characteristics in terms of what we can pull and when.

Another interesting bit is timecode tracks. Timecode tracks are actually really powerful. Traditionally, they were used to index video on the computer back to a videotape. But even if your media has never touched videotape, maybe it was recorded to flash, it's still really handy because it gives us a fixed time scale to refer to things.

So maybe if I have an hour-long QuickTime movie, I can put a timecode track in it indicating sort of a start of timecode, maybe at two hours, let's say. If at some point I decide that I need to clip some of that media out, maybe I'm reducing my project down, that timecode track gives Final Cut a reference to figure out how to offset and correlate things when you attach those smaller files to your project.

Now we've talked about a number of technologies today and want to actually do another demo to sort of tie them all together. And this is based on somewhat real workflow example, things not only from the production realm but all the way to broadcast, where maybe I have a project where I have media coming in and I've got my show more or less done, or maybe I just have something built with placeholders. And as those files come in, I really want them to just automatically be added, so I don't have to have someone sitting there watching a folder manually.

This application, again, like the other tool I showed you, the source code is up on the website, linked to this session, and it uses a lot of technology we talked about today. We use Apple Events to basically programmatically drive Final Cut. We use XML to push and pull data in and out of Final Cut. And we actually leverage QuickTime metadata to identify what we're going to do with particular pieces of media. Can we switch this demo machine, please? OK, so we've got Final Cut running in the background here. And I'm going to run my little movie assembler application.

And what I'm going to do is in Movie Assembler, you want to note, I'm actually going to open up a project. This is a Final Cut Pro project here. And as I open it up, you'll notice that Final Cut went and opened up this project as well. And if I look in the UI here, it's pretty simple. I've got, actually what it did is it told Final Cut to open up the project, it asked for an XML file of the project, and then it parsed it.

It figured out a couple of things from that. It figured out the sequences in there, since the way this tool works, it's going to point at a particular sequence. It inferred a folder where all the media was living. It also inferred a default watch folder, basically a place to watch for new files to show up in. And I've also got a little log here. So now what I'm going to do, since I see that Final Cut is open in the background, is I want to actually process sort of one of these events, right? I want to basically have media come in.

Now, if I pop over to my sequence here, this is just a little, you know, silly little short film. And it's pretty good, but the shot sort of highlighted in red here is wrong. You know, I've got, let's see, I've got my hero. He comes into the office. He's not very happy. He sits at his desk, and then, well, wait, he's walking again. That's kind of not right.

So obviously that shot's wrong. Obviously I got the wrong shot from effects or color correction. So I've already told him I want a new file to come in, but that's basically the fix that I'm going to have happen. So I'll come over here to Movie Assembler, and I'm just going to have it start monitoring my watch folder. You'll see in the log there. And if I come back over here to my folder... The file didn't go back there.

All right, we'll fix that. So here's our watch folder. Here's our media folder. And here's a new file that's actually going to come in and be processed by this tool. Now, we actually opened this file a few minutes ago, and you noticed that there was actually a piece of metadata with an ID in it.

That ID is what we're going to use to figure out where it needs to go. So if I drop this into my incoming folder after just a second here, you'll notice that Final Cut twiddles. And if we come back to our log here, it says it moved puppets into our media folder.

So now if I come back and open up my timeline, And zoom out a little bit. I'll see that I actually have-- The correct shot here, our hero getting lots and lots of work, lots of bugs to fix. Okay. And that's basically it. Let's go back to slides, please.

Again, the sample code for all that is up on the website. There are a number of other tools up there as well, and we really hope that helps you guys out. It's really powerful stuff, and the APIs can be a little interesting, but it's pretty quick to get the hang of it.

Now last year, about this time, well, probably five minutes from now, honestly, in Q&A, we got a number of questions about a product we just announced. This is a product called Final Cut Server. And for those of you who weren't here last year or weren't at NAB this year or last year, you might ask yourself, what is it? Well, it's a tool for workflow management and also asset management for Final Cut Studio users. And basically, it allows people to live as a work group, share media, have things almost like what we talked about in Final Cut here happen when media arrives in the system. And of course, now it's actually shipping as opposed to last year when it had been announced.

Now what's interesting for you is that, just like Final Cut, this is actually a customizable tool. This was intended to help tie workflows together as well as enable them. So it's very configurable. It actually uses XML for pushing and pulling data. It actually makes very extensive use of the metadata technology we've been talking about here.

So you can populate media files, metadata, and as they pull into server, it'll go ahead and set up definitions for them and you can see them. You can also do things with defining custom behaviors for that metadata. Now we're not going to go into much more detail here. I wanted to mention it just because it came up last year. There's actually a session coming up at 10:30. We'll give you more information on that.

Okay, so to wrap up, think about using all the tools we've put together for you to not only tie your applications with Final Cut, but sort of tie all sorts of things into workflow experiences for your customers. XML, you know, it's not just a simple import and export tool. It's a manipulation tool, depending on what you want to do.

And you can really use some nice capabilities of XML along with Apple Events to make things really clean for your users. You know, don't require them to do manual imports and exports. Just have your tool do the right thing. And think about using metadata. Think about putting interesting breadcrumbs there, not only for you, but for everyone else.

So Alan is unfortunately not here today due to a family commitment. But if you have questions, you can certainly ping him as well as one of us. If he's not the right person, he'll vector you the right person as well. We have all the documentation and sample code up on the developer website. Again, a lot of this is linked to this session, but even if you just go to the normal developer website, you'll see all of it there.

Other sessions, actually there are two sessions coming up next which you may find interesting. In this room, we're going to have a team up here talking about the effects plug API for Final Cut Studio. And over in Russian Hill, we're actually going to have a session on all of the integration technologies for Final Cut Server. So again, the XML and the metadata. We also have labs this afternoon. If you have questions that don't get covered during Q&A, come on down. We'll be there from 2:00 to sometime around 4:30, I believe, both for Server and Final Cut Pro.