Good afternoon. My name is David Black. I am an architect in the crafts division. And we are going to talk about integrating applications with Final Cut Pro in today's session. And really what this talk is going to focus on is the various tools and technologies you can use to integrate your applications with Final Cut Pro and also leverage a number of applications together to build very powerful workflows for both you and your customers.

We are going to start off today with a little bit of background and talk about some data interchange formats and give you an idea of where some of our technologies came from. We are also going to talk about metadata support for media files. Some very new powerful tools we started to add in the last year. And then finally we are going to go into a number of technologies, specific to Final Cut Pro and sort of some tips and tricks about the best methods to go about using, tie your applications together.

So Project Data Interchange Formats. And really we'll start with the question of what is Project Data? It's seemingly an obvious question but at times when everyone really seems to understand, really Project Data is the structure that ties elements together. If you think about the production for a television commercial or a film, sort of understand that maybe the crews will be out in the field a long time shooting footage, pulling graphics together.

And certainly when there's a lot of time spent acquiring those assets there's even more time spent organizing those assets, sequencing them together and combining them to create that compelling content. So really in a way this is the data that your users spend the most time of all creating. Of course the challenge with this is there's much powerful complexity here. So this tends to be difficult to exchange beyond the normal, beyond the very most basic details.

Legacy formats came about 20, 30 years ago. 0 Really these formats if you think of it were built to tie hardware systems together, so hardware switchers. Now, effectively banks of tape decks and switching hardware all running in sequence to assemble a show. The two most common examples you'll see and still in very common use today will be batch list and EDLs.

And at their core both of these formats are essentially a list of time codes and clip segments. Whereas a batch list is really sort a list of data to define an individual clip and EDL is really a sequence of those elements and time to put together a program.

Contemporary formats came about really in the late '80s and early '90s as a number of companies came to market with more flexible computer-based solutions for editing media. And really they were built to address the shortcomings of the legacy formats, add more richness in the entire model. But of course then the challenge at that point being with systems what they were is as opposed to sort of plain ASCII text, human readable data. These were based around the binary container formats, you know, pick your favorite hierarchical packaging system from the time and someone was using it for media.

Of course the down fall from this is that you needed libraries and tools to parse these things. And, you know, you needed to keep computers running to parse these things. The two most common examples you'll find out in the market today are really OMF and AAF. Both of these originated from Abbot back in the '90s. OMF today really survives in the audio post-production community around ProTools whereas AAF came about as a consortium of companies number of years ago tried to at least bring some standards into the interchange space.

Open data formats came about in the last few years as sort of everyone took the lessons into mind from both the legacy formats and contemporary formats. And really strove to maintain a lot of that richness but actually solved some of the problems that played implementations. You really as you can sort of tell from the name here the key point here is for open and transparent access. You know trying to keep things simple. Trying to keep things open. Allowing everybody to play allowing everybody to get to the data. also really trying to make these easy as possible to parse and generate.

Go ahead and talk about where we came to with Final Cut Pro in this. Because we came into this problem a number of years ago and we took a look at the lessons from the various formats and really took a look at this as an opportunity to solve an operability problem. And of course we started with feedback.

From customers we heard a lot of common things, you know, common data formats, want to get projects, as well as media, and also building processing pipelines. A lot of very sophisticated customers want to build their own sort of workflows between applications. Honestly we heard a lot of the same things from developers along with wanting to talk to Final Cut Pro, write tools and go ahead and integrate their own processing pipelines or at least be friendly to customer- built processing pipelines.

We came back from this exercise with what we felt especially at the time was a very different take on this problem in that really this wasn't a problem simply in interchanging complex data sets between large systems. But really it was data manipulation tools and data manipulation on a large scale as well as a small scale.

Also making these tools and these formats successful not only to developers who can deal with, you know, writing a lots of codes and potentially processing libraries but also to power users who might be out there using command line tools or web servers or other tools to basically just parse large data sets. And of course trying to minimize our library requirements as much as possible. Making these formats accessible on multiple platforms not just our own. And also taking a shot on a problem we heard from Hollywood interestingly enough in terms of handling long term archival projects.

From this we came up with our XML interchange format. We shipped it initially Final Cut Pro 4. And as you can tell we chose XML as encoding for the data. It's actually nice, you know, if you ever looked at XML it's effectively plain text. There are a lot of libraries out on multiple platforms for parsing XML so you don't necessarily have to do all the grunt work yourself. But you can also pull it open in text edit and see the contents.

And really we built it to encapsulate the complete contents of a Final Cut Pro Project. So everything in that project is relevant to the construction of that project is encoded in the XML. Really doing our best to not have any sort of black or private data anywhere in there because that just frustrates developers and users trying to create projects from scratch.

And of course being XML it's really structured ourselves documenting that way. We have plenty of documentation out but if you are taking an XML file out of Final Cut and open it up text edit, you'd be able to figure out pretty quickly what the essential structures in those files were.

Here's a really brief snippet of XML just for those of you who may not have played with it before. Now, it's basically we have a definition for a clip or a media segment. And, you know, we just have sort of these essential pieces here. You know we have the name, the duration, some timing information and also some time code reference information to help indicate where this came from an original piece of source media like a videotape.

Really when we came to this problem, you know, trying to address the needs of developers and users, we got a lot of feedback about having access to Common Industry Data Formats. And really we felt the most achievable way toward that solution was to make our XML format such that it could be a super set of other formats.

Again, going back to exposing the complete content developers this allows other format translaters prebuilt using XML as an intermediate. Mentioned archival a little bit earlier. Now, we talked to a number of people in Hollywood who had the concern of well, you know, if I take a film from the '40s or the '50s assuming I still have the actually celluloid, you know. I have, you know, a list of those edits and I have that film I could go ahead and recombine that and remaster that film 30 or 40 years later.

If I have videotapes or film and an edit list and a binary format, unless I took a machine and wrapped it in plastic and put it in the closet, chances are it's going to be very difficult to decode that 30 years from now. Putting this data in XML means it's effectively ASCII text and anyone even if the software hasn't survived should be able to pick out what the data is and make use of it.

Now, it's been 3 or 4 years since we put this out. And who's using it? Well, an awful lot of people are using it. I wager a large number of people in this room are actually using it. Automatic Duck has built a line of successful format translaters using it. Gallery Systems has done an amazing job with integration with ProTools and audio applications with File Cut Pro. Building4Media and a number of other companies are building full work station automation play out systems and asset manager systems using XML as that essential interchange glue.

And this last year Sony actually brought out some transfer software to basically take the footage from their latest high definition Blu-ray-based cam recorders and bring that directly into Final Cut Pro with a very customized compelling interface that's familiar to the camera operator and having that just feed directly into the Final Cut Pro using XML. And really there are a lot of people out there and just way too many to name in the slide. These are just a few examples.

A brief note on versioning. You know as we built the file format up and over time we've seen the need to make small additions to it. We introduced v4 with File Pro 6 which actually was announced at the NAB show a month or two ago. The important take home point from this particular side is that the XML is forward-compatible but not backward-compatible.

Such that you can export a version one XML file from Final Cut Pro 4.1 and you can import it all the way up to Final Cut Pro 6 no problem. But if you export a v4 file from Final Cut Pro 6, you are not going to be able to read that back into 4.1.

However, you can export a v1, v2, v3 files that are found in Final Cut Pro 6. So you can feed get it back if you need to. Just be aware of the consequences for what version you are actually using. And we have a plethora of documentation up on the developer's site. It's been there for a while. There's a lot of really good tidbits in that documentation, tips, examples, and also information on smaller technologies we'll touch on in a little while.

Moving away from Project Data for a minute I want to talk about Metadata. And really this is a big thing and this is something we began experimenting with last year. And we've been putting more support in place for you, the developers, over this last year. But before we get into some of the details sort of step back a little bit and ask the question of, what is metadata? This is one of these questions where potentially asked 12 developers and you'll get 8 different answers. So just to make sure we are on the same stage with the terms really what do we consider it? We consider it an arbitrary collection of ancillary elements, right, attached to a primary data set.

So you may have a document file for project and you've got a primary chunk of data that really defines that document. But metadata is sort of the optional little things that you can attach to it but don't necessarily require modifications to applications using that course set. And really this collection of elements is extensible without, you know, modifying the core data set or modifying the application.

Quick little example here. Another thing to think about is a particular piece of data may or may not be considered metadata depending on the application context in which it's used. You know really briefly here. If I have a QuickTime file, there are essential attributes of that file in terms of the codec and the image size and format which are critical to QuickTime player's use of that file. But to finder they are just interesting attributes displayed at the user.

Another example everyone here is familiar with I'm sure is MP3 and AAC files. And little ID3 tags that put the album information in those files. And sort of going back to our model, the central content of that file is the compressed audio data. And while the ID3 tags don't have to be there, they certainly enhance your experience using that file by allowing to you find and search music. The standard has also grown from its initial incarnation from just a collection of fields to a repository for all sorts information including album art work.

Now, that we've sort of defined some generalized terms for metadata, let's talk about the QuickTime side of this equation. When the QuickTime team released v7, they introduced support for QuickTime metadata containers. And you can think of these containers as the repository for keys and values tied together. These containers currently are supported on a movie, on a track, or a piece of media. And each container uses a particular key space to identify the keys. The point to note here is that the QuickTime architecture is built up such that you can define different key spaces. And, you know, use different identifying values depending on your particular application.

Another key point here though is this is not necessarily a one-to-one key value paring. This is really a key contains end values associated with it. There's some interesting sort of usage semantics. This we will touch on in a few minutes. But it just bears noticing keeping in mind.

The containers themselves are stored in the movie resource. Those of who used to work in QuickTime files understand the concept given in the movie resource which defines movie structure and then you have the sample data. All the metadata you put in a movie will be stored in the movie resource.

This is the advantage that it goes everywhere that movie is. It has the potential disadvantage if that data gets loaded into memory everytime that movie file is opened. We really haven't seen problems with this yet. We are look at alternatives for this. But the nice thing is there's no real penalty for querying that metadata once you've opened that movie file. And of course this data gets carried in reference movies independent of the media.

Another point of confusion we heard after rolling this out last year is the difference between user data and metadata. Certainly a number of developers have made use of QuickTime user data atoms to store their own private data over the years. But the difference between the two is that as where user data atoms are essentially blocks of binary bits identified by FourCC code, the metadata containers are really a key value key space with accessory APIs. Of course the advantage is since you type each one of the metadata volumes, you know what data is in there. So you don't sort of have the black container problem with user data atoms. That we touched on earlier with the project data.

Another point to note talked about key spaces for a minute. Really the primary key space that we make use of is the QuickTime reverse-DNS key space. An example of, you know, annoyingly long or short depending on your view point key there. And it's actually very handy because it helps differentiate your company's data from your user's data from other organization's data. And even in similar to XMLs plain text advantages provides by some documentation of what your values are. And it gets us out of the namespace collision problem, which is not a lot of fun.

Some procedural things here. I'm not going to go into complete depth on the APIs. But getting a container is a simple matter of calling the CopyMovie or TrackMetaData API. Even though it says copy it's giving you a reference to that current container. If you want to get values, you know, you get a container and then get iterate using the GetNextItem API.

You can basically walk through all the values in a container or give it a key to restrict your search. And once you have that item that query will give you back a QT metadata item handle. You can use that with property APIs to get the data or type or any other interesting information.

If you want to add a value, again it's simple. Get a container and call Add. No real surprises here. If you want to remove a value, you can call RemoveItemsWithKey to remove everything associated with the key, you know, mentioned a few moments ago that it's one key to n items. If you want to remove a single item thought that means you'll need to iterate and find that item then call and remove the API on that particular item.

And we'll do a quick demo here. Can we have the demo station, please? Thank you. So I've got a little command line application I wrote a little while ago to play with QuickTime metadata. And my folder here, I have a couple of movie files. And this little -- sorry about that. If I run my MetaMovieScraper tool on one of these movie files here, excuse me one second I'm just going to turn that off.

It just goes ahead and does a dump of the containers on a particular movie. If you look here it is basically enumerating the movie and the track and the media and there's one key in this file. Basically a string named OfficeExit. Now, this is just a very simple file that we'll come back to using later. But to give you an example of something more interesting.

I have another file here. That, this is actually a file that I ingested using the current version of File Cut Pro from Panasonic P2 memory card. And if I dump out the Final Cut of this file, you'll see there's an awful lot more stuff here. The interesting thing about this case is with especially the solid state-based cameras, manufacturers are putting in a great deal of very interesting metadata.

Everything from MFX-centric media IDs to information on who shot the footage, etcetera. And we're putting all this as metadata in the movie file. The nice thing about this is whereas traditionally this data might have been put into a project file and the media file was just the media this data will now ride wherever that media file goes. Can we have the slides again, please?

Stepping up a level we talked about metadata support and QuickTime. Now, I want to talk about some of the specific capabilities we put into Final Cut Pro.

We introduced support last year with Final Cut Pro 5.1.2 and really our support builds on top of QuickTime metadata support. So everything we discussed is what this is built on. Now we support arbitrary metadata files. It's important to note that for now we are only dealing with metadata at the movie and track levels. And we're really only supporting the QuickTime primary key space. So those reverse-DNS strings we talked about. And we'll define any of the data we'll support any of the data types that QuickTime has defined in their header files: the strings, numbers, binary, etcetera.

The other important point to note about Final Cut support for metadata is because of a couple of advantages we will get into that in just a moment. The support is really something of a cache. And the concept goes something like this. If I launch Final Cut Pro, make a new project and import a metadata-bearing QuickTime file, when Final Cut Pro conducts its internal database reference to that file, it will look for metadata present in the file. It finds any, it will read it and it will cache it in the project file.

Now, the nice thing about this is you may have a project where your media file is on disk, you quit and save. Next time you come back in that media file has all of a sudden disappeared. Well, if that file is gone, the cache is still there so the metadata is still there. So you still have your metadata in case the file has gone away this may help and make it easier for you to find the file at a point in the future.

But the another key point of this though is that the authoritative copy of the data is your media file. So if you make a project, import a file, save, quit and then change the metadata in that file. The next time you open that project and it reattaches and resyncs that file, the cached copy will be taken out in favor of the data in that file at that time.

Now, of course one of the revisions we made to the XML format was to support metadata. What you'll notice is if you have metadata- bearing files and you export XML from Final Cut, you'll see metadata elements in the file definitions. This export is based on the cached metadata repository we talked about a moment ago. So even if you're exporting a project file with off-line media, you will see the metadata there as Final Cut's last notice of that media file.

The import process will pay attention to those elements but it's a little interesting if you think about it because on import Final Cut Pro will parse the XML, it will create temporarily sort of off-line file representations assuming the media file is not there. And of course it will read in all the metadata elements you define in your XML. Of course the minute Final Cut Pro goes attached to a file on disk, it will kill that metadata cache in favor of the file on disk.

Now, there are some commands we actually put in the XML importer so that you could effectively say, no I don't want this key to be blown away I want this key to be actually written in the file. These are fully covered in the documentation. They make use of the commands to find for the update behavior key. This key is also used for some incremental project update facilities we introduced last year as well.

Here is an XML snippet with some metadata. And you'll see it right there. And it's pretty simple. We'll define that it came from QuickTime. We've got their reverse-DNS key we've defined as well as the data type and the actual content. Depending on what the content of that key is, you are either going to see that they are there in terms of the case of strings and numbers. Or you're going to see, you know, effectively U encoded byte string there for binary data. And we'll switch back to demo station for just a minute.

All right. So we had those files we were playing with just a minute ago. And what I'm going to do now is go over to Final Cut Pro and I've got an empty project here. And I'm just going to go ahead and drop one of those into Final Cut.

And we have a clip here. Now, this is the clip here in Final Cut even though this piece of metadata here at the moment the user would never know it. All these fields are really all the same. The interesting part comes when I do an export.

And if I come back out here to the finder and open this up, you will see the metadata definition that we talked about before.

Now of course this is really a simple file in the case of the P2 file we saw a few moments ago There'll be an awful lot of stuff here. But the interesting point here is all this data is there. So from an application perspective if all you're doing is something relatively simple, you know, basically parsing through XML data, you are going to see any metadata that anyone else put into those media files.

If we can have the slides back, please.

Okay. So some take-home thoughts for you about metadata support. Really what you want to think about is how you can leverage metadata to make your customer's lives easier. If you have an application that creates media for use in Final Cut or elsewhere, think about embedding interesting bread crumbs into your media files. You know you can tell later on if your application created a file, you can embed telemetry or other interesting ancillary data. And really just think about attaching a relevant data to those files.

For example, if you are building a backup or an asset tracking application, you can embed your private IDs as metadata in those media files and they'll go wherever the media file goes they'll go in the project. And you can build really simple tools that finds those links and rebuilds them later on.

Also think about caching interesting data for post-production. We looked at that P2 source media file earlier. There's an awful lot of data there that was interesting. There's an awful lot more data that I've certainly heard from camera operators and basic production crews in the field that would like to be able to drop in their media to use as a reference later on.

Another interesting point is to properly label your metadata elements, you know. Talked about the nice things about reverse-DNS strings, you know. Not having namespace conflicts. If I never have to resolve another namespace conflict with special case code, I will be a happy man. You know put your company name in there. Do some interesting description data, it's just a string, you know. Spend the bytes to actually define what your data is so you'll know what it is and your customers and even other developers will know what your data is.

So we focused on sort of two big areas of technology, data interchange and metadata. And want to go ahead and talk about some more sort of lessons that we've learned over the years for working with various developers about how to do good clean interaction with Final Cut Pro.

Now, of course, where I encourage you to start if you're beginning this process for the first time is really to take a moment and think about for your application or your workflow how do you really want to operate with Final Cut or really what are you doing? Are you doing an exchange tool? Are you doing an importer or an exporter? Are you doing more of an automation tool? Sort of build sequences and bins and clips in Final Cut Pro in an automatic fashion? Or are you simply scraping them for interesting data? How is your application in Final Cut going to make use of different media files? And also what development tools and what languages are you going to use? That choice can really indicate not only what XML parsing technologies you use, but potentially what interoperability technologies with Final Cut Pro you make use of as well.

Start off again with XML and, you know, just to sort of drive a couple of these points home. Think about using XML to really link and drive different stages in your workflow. Right. We talked earlier about, you know, not just moving data between big complex systems but using it as sort of a repository for data throughout a production pipeline.

You can also think about round-tripping XML. This is something we've seen a couple of developers do really exciting things with. But not a whole lot of people yet. You think of a workflow where you have a sequence in Final Cut, you take a piece of XML describing it, you run it through your tool and do interesting modifications to it and then just turn right around and send it back into Final Cut Pro. You can make use of UUIDs and the update behavior keys.

So when that XML comes back in, it just goes ahead and replaces the original element in your project and your user will never know. And also think about you can do very interesting and simple things just scraping the XML for data, you konw. If you are looking to just tracking what media your projects are using.

Another point which I'd hope more people would have picked up more intuitively but -- is the XML importer was designed from the beginning to support what we call "sparse" XML files. If you were to fill out every field on every clip on every sequence and every bin on a Final Cut Pro project, and write that out as XML, you have a lot of data. In fact, if you do nothing more than import a movie file into Final Cut and export an XML file, you will see a lot of fields there in that XML.

You don't need all those keys to be present when you are coming back into Final Cut Pro. Really you only need to define the fields with the data that are relevant to you. Final Cut Pro is, you know, just going to basically use defaults for data that you don't put there. Anything that it needs to know that like for example the frame rate for a codec potentially it will actually infer those settings either from parent elements in terms of, you know, a clipitem in a sequence or even from the default sequence preset that gets used on import.

And don't be too worried about sort of going too far with this because if you fail to define a key of something that is really needed the XML import is going to throw an error and you're going to see a log in the console letting you know what data is missing. And really the hope behind all this was to simplify your code, you know, just be able to keep you focused on defining the data you need to play with.

Another workflow that we've seen some companies make good use of is the concept of swapping media out from underneath a project file. Now, you can think of this as doing it on a sort of online off-line workflow moving from low res media to high res media. Also think of this if you have a media processing application that's going to take an existing media file, do some effects on it and write a new one out.

You can build a tool that will effectively take an XML definition of a sequence, walk through all the file definitions and update the definitions to point to brand new files on the disk. And also, you know, you'll see a file definition for Final Cut and it will have a lot of information in it just like the point of clips and sequences. A file definition really only at its heart needs to have a name and a URL. Most everything else assuming a file's there can be inferred from the media file itself. So you don't need to go too insane by putting all the little details in there.

Something to watch our for about this though is another optimization we put it in the XML export was the concept of using sort of "id" attributes to share file definitions. You'll want to watch out for what clips you use what file definitions, you know, making sure to replace the fully filled out file definition if you are just touching one file. But if you are changing the relationships between different clips in different files, you may need to fill out definitions that are sparsely defined during the export from Final Cut Pro.

Another interesting point touched on a little bit is the use of UUIDs. We added UUIDs last year to allow you to uniquely identify elements in a project. These IDs basically get created when a clip or sequence get made for the first time. And unless, you know, duplicate that item where you have two of the same one in a project, that ID is going to stay the same throughout the life of that project and the elements moved to the new projects. Combining the UUID tag with the updatebehavior key allow you to do the in-place updates we talked about a few minutes ago. And you can use these commands to do basically any browser level items, so clips and sequences.

We'll go ahead and do another demo quick because I sat down to prepare for this talk this year. Can we have the demo computer, please? Thank you. I sat down to do this talk this year and having some feedback from a number of developers at NAB about, you know, some sample code they wanted to see. And, oh, excuse me one second.

No, I don't want auto save, thank you. Where effectively they were trying to do some very simple XML transformations, you know. They had workflows, they had different tools and they couldn't quite take everything in a Final Cut Pro XML document and put it into an older tool. So they need to migrate between the two.

So what I put together is this application called Time Line to Time Code. And this is actually up on the ADC developer site as sample code. And really all this application does is take File Cut Pro XML. It does some minorly intelligent parsing using XQuery and the NS XML classes and effectively takes all the edit times in a sequence to build an edit list. Now, ironically this is somewhat similar to an ADL but a lot sort simpler and actually is sort of oriented toward exactly what someone might need to do with an interchange application.

So I drug the XML file to my document or my application and it went ahead and parseed it and just found all the sequences in here. It's displaying a little bit of interesting information about that sequence. And it's got a number of attributes here that it can go ahead and emit. So I'm just going to pick a couple. I'm just going to write an edit list.

And if I drive -- what I'll do just as a comparison is, I'll take the project I opened and I'll take this edit list and I'll drag them both off to BBEdit. And this is the edit list, you know. It's a very simple something you can pull into XML, just a tabbed limited list. You know, a number of start end duration times. And of course this is the XML that it all originated with.

And it's just a lot of data when you may have an application which literally just needs this. Another piece of code in this sample that you'll probably want to look at is actually some frame count time code conversion code. It's actually what gets used to generate all these numbers you see here. Again something that a number of developers asked to help accelerate their XML development.

Slides back, please.

Moving on. Let's talk about AppleEvents. This is something we haven't mentioned before in this presentation. We introduced this last year. Again based on developer requests. Developers had certain workflows where they wanted to automate a couple commands in Final Cut Pro just to make things smoother.

In looking through the problem we basically came back with building a couple of strategic AppleEvent commands in place. So that you automate interesting things like opening and closing projects, getting XML managing selection. An important point here another point of confusion I had to content with the last year is that this is AppleEvent support.

This is not AppleScript support. AppleScript is a lot more complex than what we've done here. It's certainly interesting but it's not something we have today. Full documentation for all of the commands really for this are available actually in the XML in the same document that's the XML documentation. There's also a number of sample applications on the Apple developer site illustrating this.

For importing XML there's an import XML document command. Another interesting point and something that we really didn't document very well in past years. Is that we've actually had this wired up pretty much since the beginning, such that you could take an XML document with the right extension and right type and creater code and drop it onto the Final Cut Pro application icon and it would go ahead and motivate an XML import operation. This is really just putting an explicit AppleEvent in front of that existing functionality.

Another point here to note is this will just do the equivalent of the user just going to file, import XML. So unless you put an import option scope in your XML to hide the import UI you will see it. Again, the import option scope is also covered in full detail in the documentation.

Working with project files, plans to open save and close. Note that this command will take a URL to indicate what project you're working on. Go ahead and basically ask for an XML representation project again using the URL. Couple of tips that we found. I've written a couple of sample applications using AppleEvents in working with some developers who have been using it. Keep track of, depending on which AppleEvent command you are using, the particular identifying data you need, to use. You know, in some case it could be UUID, in some case it could be a URL.

Another point sort of for application performance and interactivity is to think about putting your AppleEvent code on a separate thread from your main application loop. There are times it might take Final Cut Pro a little bit of time to do something and you might not want your applications sort of blocked there or at least sort of hard locked there waiting for Final Cut Pro to do its processing.

Move on to metadata. Mentioned erlier that we had support for metadata with Final Cut Pro 5.12, you know, the cache model that we talked about, XML accessibility. And a point here to think about is that we went through some trouble to put the metadata editing commands in the XML importer but we really would prefer that especially on a production level that you use the QuickTime APIs directly. Really those commands were there for prototyping and help power users out. And, you know, while they are there, they function they are not necessarily the highest performance and they are not always going to give you the granularity of control that you will want in editing your metadata.

And another point which I forgot to mention earlier with XML we found it's really been powerful to have human readable data there. You know so that if something is going wrong and someone opens a file, you know, search for some text and find and fix a problem and this lesson also really applies to metadata.

You know, it may be that you have, you know, a chunk of interesting data you want to store in a movie file, and you can squeeze that down into, you know, 32 bytes, 64 byt2es, if just put it in a binary block of data. It's really a lot better to break those things out into individual keys, use strings, use numbers. It's going to save your users and other developers trouble if they need to parse your data. And it's also going to save you from sort of platform issues in terms of struct alignment or byte swapping.

And with that actually I'd like to ask a colleague of mine to come up on stage for the moment. J.R. Hass came to us a little while ago working on new application we announced this year called "Color" and I'd like to have him give you some of his thoughts.

Thanks, David. (applause) Hello, good afternoon. My name is J.R. Hass. As David mentioned I'm one of the engineers whose worked on the new Color application.

So what is Color? First and foremost Color is a standalone application. It's now part of the new Final Cut Studio and it's a GPU-based color correction tool. So what I mean by color correction is simply just adjusting the color of a digital movie. So a quick example would be say you have a clip that was shot in the daytime and you wanted to give it a night time look and feel. Well, you can use Color to achieve that look. And being from Apple it of course supports QuickTime. And for those in the film space it also supports DPX sequences.

With that what is the Color grading workflow or where does Color fit in the picture? Well, this is the digital age. We would first expect our users to acquire some sort of high quality digital media. And then using that media they would complete and edit with a tool such as Final Cut. At this point they could then send that edit with their digital media to Color to have a colorist color correct it, make it look good, render it out and then send that graded project back to the editor for a final output save.

What were some of the goals we had when implementing this workflow? Well, our primary goal was to streamline this interaction between Final Cut and Color. We really wanted the round trip experience to be as seamless and as accurate as possible. In other words we wanted the editor to worry about editing. The Colorist having to worry about coloring but neither would have to worry about managing media files or misplacing files or transferring information.

A solution that satisfied this goal was Final Cut's XML. Using Final Cut's XML in Color we are able to recreate the Final Cut timeline. So this makes it really easy for a colorist to start color correcting cut and grade the project and make it look good. And then we are also able to read in some other information as well such as the geometry data from Final Cut. After the colorist is done, he can then spit out a new XML file but using the original as a reference and send that color graded good looking project back to the editor for a final output.

What are some lessons we learned from implementing this workflow? Well, as David's been talking about XML contains an abundant amount of information compared this to other older formats to which just might contain the cuts. XML is going to contain the geometry as I mentioned but also the transition information and your plug-ins that you might be using.

Now, it turns out that Color doesn't support all of the things that is in the XML but that's okay because XML is very scalable. So the things that we don't support we just ignore but that plays an important role and we complete that round trip experience. Because when we generate a new XML file, that stuff is still there and it's just applied to the color corrected content. So the editor doesn't lose any of his work either.

And also there are several tools available to parse XML. So you'd be really hard pressed to find a programing language or a platform that doesn't already have tools available for you to parse that XML. So you don't need to reinvent the wheel, you can just worry about processing that data. And also as David mentioned XML is just text. So as developers it makes it very easy to debug.

And as a final note I'd just like to mention that even though Color is from Apple the core technologies we use to create the interoperability between Final Cut and Color are the same ones available to you as developers. It's just that XML and AppleEvents APIs. So it really is powerful stuff and it played a crucial role in implementing this workflow that I described in Color. I will now give the stage back to David.

The microphone is malfunctioning here.

Excuse me.

All right. Clicker would be handy. So we'll go ahead and do another demo now. This is another application I built to illustrate a number of concepts we've been talking about today. So can we have the demo station, please.

All right.

We'll try this out. So we talked about AppleEvents, we talked about XML and we talked about metadata. And really these technologies are built to build workflows. So I thought I'd go ahead and show you a workflow that I went ahead and prototyped up using these tools and Final Cut Pro.

So I have a copy of Final Cut Pro running here this is the project we were playing with earlier. And just for clarity I'm going to go ahead and close it. And I've got an application here on the desktop called Movie Assembler. Now, the workflow this is really meant to soft of prototype is that of sort of an assembly station for a news organization. We are just keeping a current cut of the film up to date.

And the concept here is really that I may have a project where media is coming in at various times. Right. And I need to go ahead and constantly keep that new media in sync with my project. So that at any point the client or the producer can come in and see the current state of things.

So I have a project down here, this is just a short film I'm working on, just going to go ahead and drop that onto the Movie Assembler to open it. And you'll notice here it's got a list of the sequence here. It went ahead and parsed the XML to infer sort of what the media paths are.

And it went ahead and opened it up here in Final Cut Pro in the background. Interesting point to note here is that the project file that I dropped onto this application was a Final Cut Pro project file. To get the XML it opened up on Final Cut, then using AppleEvents requested an XML version of it.

Now, if I come and look at my sequence here, you know, I have the clips sort of typical comedic office drama. And the problem I have here is this clip is wrong. I had him sitting down and then he's walking down the hallway. And that's just really not the right media. So someone needs to go out and reshoot this.

So go ahead and come back to Movie Assembler. And I'm going to go ahead and tell it to monitor a watch folder, this incoming folder here. So I'll go ahead and start this up.

Hopefully a little bit better. There we go. So I've gone ahead and got this monitor in this watch folder.

And you'll see these basic fields grayed out indicating it's doing something. So when I come back to finder, and I've got this movie file here. Now, in this case I'm going to assume this media file was the corrected footage. So I'm going to go ahead and just put a copy of it in my incoming folder.

And after it copied you go ahead and save, Final Cut Pro will update it. And you'll see a message here in the log that it went ahead and found the file and did an update. Now, if I open up the sequence, zoom out a little bit. We'll see that it went ahead and replaced the incorrect footage with the right shot of our hero sitting at his desk getting lots of work, or may be it's bugs I'm not quite sure.

So this application is also up on the ADC Developer site. Makes use of NSXML, XQuery to parse XML, AppleEvent communication with Final Cut Pro. And of course Cocoa to do the UI and the watch folder monitoring. Cab we have slides again, please?

Okay. So where to go for more information.

Well, we have a number of example applications up on the web, up on the Apple Developer site. We have the documentation we mentioned up there I know we just recently updated it for a Final Cut Pro 6. Couple of labs and sessions coming up, think about this week. Tomorrow there's a QuickTime session on advanced digital video techniques. Actually we're going to talk about a lot of interesting things in that session, you know, color spaces, pixel formats, sort of gotchas that come up for anyone processing QuickTime media.

On Friday we have two more sessions for the Final Cut studio team, focusing on FXPlug. Both basic and advanced methods. And we also have a Pro Applications lab running in parallel with the second session. And we'll actually have people at that lab including myself to talk about a range of pro apps integration technologies, if you do have questions.

So really what's the summary we want you to take home here. If you are building tools, leverage what Final Cut Pro can do, you know. If you don't need to reinvent the wheel, please don't. Please make use of the things we put together. XML is really powerful. It's not just for imports and exports.

You can use AppleEvents as sort of automate things for you users and simplify things. And really think about the metadata angle. This is something that certainly more and more customers are asking for in terms of them wanting to track the media within their own workflow and own asset management systems. And they are all looking for tools to really make this happen.