Looking Ahead to 10.1

[Andrew Richards]

I was hoping against hope for live Event sharing pretty much since FCPX launched. Shared timelines are probably much more difficult to pull off, but if done well could be pretty interesting. I was a big proponent of Final Cut Server while it existed, and even tried to build a business around it right around the time it was canned. Shared Events with hooks for developers would bring all that full circle, even if I’m not really part of the scene anymore.

Best,
Andy

[Geert Van den berg]

I thought from the start that the new FCP base was ideal for projectsharing or multiuser editting, but I don’t think this is going to happen because the application is built around SQlite databases, these are not meant for multi-user editting, it locks out other users during writes. It seems Apple is fond of using SQlite though, it’s used in almost all the apple apps.

[Oliver Peters]

[Geert van den Berg] “I thought from the start that the new FCP base was ideal for projectsharing or multiuser editting, but I don’t think this is going to happen “

Actual simultaneous project sharing (not just media sharing) is a smaller niche within an already-small niche. Not even most Avid systems are set up this way. It ain’t gonna happen. The part they could do better is to improve multi-user access in SAN environments or the general transportability and relinking of files.

– Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com

[Andrew Richards]

They aren’t using SQLite directly, but rather via Core Data. Core Data has a method for hooking up to other RDBMSes, so it is technically feasible.

Oliver is right though, it isn’t going to happen. Too small a niche and not worthy of the very considerable effort it would take. Sure would be cool though.

Best,
Andy

[Geert Van den berg]

Yes but a project and an event are stored as an SQlite database which is open to only one writing user.

Doesn’t mean it’s impossible to create an application and a workflow around this limitation, databases are nearly always interchangeable. Had they build it using a server based database then real multiuser access would have been possible and it would open up other workflows that are currently not possible.

Adobe Anywhere allows working on the same timeline, but it’s not really end user friendly to install and it’s not realtime, you need to commit your edits to the server and then some sort of collission detection is done and it requires some heavy server hardware, however I would think that it is possible to create a workspace comparable to Google doc’s where you can see who is logged in and see the tweaks that are made by someone else nearly live. (for example a red box on clips which are selected by another user)

Maybe Apple will come with a final cut server product again, they have a server product for OS X too. But the main thing is that the databases need to be stored on a server which all clients can access for this to work.

Mounting and unmounting SAN locations can’t be the end of this. It’s old fashioned.

[Andrew Richards]

[Geert van den Berg] “Yes but a project and an event are stored as an SQlite database which is open to only one writing user.”

Allow me to elaborate on my previous post:

[Me] “They aren’t using SQLite directly, but rather via Core Data. Core Data has a method for hooking up to other RDBMSes, so it is technically feasible. “

Final Cut Pro X does not directly call SQLite C APIs, it calls Core Data which uses SQLite as one of its available persistent store types. There is an obscure class in Core Data called NSIncrementalStore that allows the developer to hook their Core Data app up to whatever kind of persistent data store back-end they so chose. This could be a PostgreSQL database, a NoSQL store of some kind, whatever. They just need a little glue code to get it going.

This is not to say building such a thing is trivial, only that the way FCPX was developed to store project and event databases already has a built-in method for hooking it up to a RDBMS. So from the client-side perspective, the hooks are already there. Building the server-side would be a major feat and probably far more expensive than the market would bear.

[Geert van den Berg] “Maybe Apple will come with a final cut server product again, they have a server product for OS X too. But the main thing is that the databases need to be stored on a server which all clients can access for this to work.”

I doubt it, but I’d be very pleased if they did. Probably the biggest hurdle to building the server side of such a system is it is not at all practical in the tidy, shrink-wrapped package which Apple wants to achieve for its products. A complex server with highly specific hardware requirements that is necessarily very expensive, not a Mac, and requires a lot of enterprisey support is not a product Apple is ever going to consider building. The best I think we can hope for is some kind of API for FCPX that would let some enterprising third party do the heavy lifting. Throw a switch in FCPX’s preferences and it stops pointing to SQLite files on disk and instead queries a compliant MAM? Could be very cool, but still far too niche to believe it would ever happen.

[Geert van den Berg] “Mounting and unmounting SAN locations can’t be the end of this. It’s old fashioned.”

It’s a kludge, I agree.

Best,
Andy

[Geert Van den berg]

I think we’re saying the same thing. It’s possible but unlikely. Name one Apple Pro App which allows collaboration. But I have to admit I did not read about the capabilities of Core Data yet.

I did read some interesting things in the Apple developer Core Data technology overview:

Merge policies.
Core Data provides built in version tracking and optimistic locking to support automatic multi-writer conflict resolution.

What Core Data Is Not
Core Data is not a relational database or a relational database management system (RDBMS).
Core Data provides an infrastructure for change management and for saving objects to and retrieving them from storage. It can use SQLite as one of its persistent store types. It is not, though, in and of itself a database. (To emphasize this point: you could for example use just an in-memory store in your application. You could use Core Data for change tracking and management, but never actually save any data in a file.)

FAQ.
How do I use my existing SQLite database with Core Data?

You don’t. Although Core Data supports SQLite as one of its persistent store types, the database format is private. You cannot create a SQLite database using native SQLite API and use it directly with Core Data (nor should you manipulate an existing Core Data SQLite store using native SQLite API). If you have an existing SQLite database, you need to import it into a Core Data store (see “Efficiently Importing Data”).

What I think we’ll get though is Eventsharing comparable to sharing an iTunes library. Read-Only.

But of course there are no boundaries for Apple to implement another hook in the app or change databases. If Apple creates something which works for Final Cut Pro X they’ll be able to use the same technology or app for Aperture and Logic as well, maybe it is in the pipeline… I have gotten a bit more optimistic again.

[Chris Kenny]

[Andrew Richards] “They aren’t using SQLite directly, but rather via Core Data. Core Data has a method for hooking up to other RDBMSes, so it is technically feasible. “

There’s no need to hook Core Data up to a multiuser RDBMS to enable collaborative features. Core Data itself has live syncing features, mediated through iCloud. In this scenario, each client system would retain a local, single user SQLite store, but Core Data would update those stores as other clients pushed incremental project updates to iCloud. This technology is designed to implement precisely the sort of real-time collaboration being discussed here — User A and User B both have the same sequence open, user A moves a clip, and User B sees that clip move almost immediately.

Shared access to media (which is actually an easier problem) would be handled through a separate mechanism.

Mind you, Core Data syncing is presently considered by many developers to be too buggy to actually, well, use for anything. But it’s hard to imagine Apple hasn’t been putting in a lot of work to fix it, since it’s a key enabling technology for the multi-device vision Apple has for computing. iOS 7 will probably be our first chance to see if they’ve fixed it.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Richard Herd]

I just read there will be a check box to automate client dispositions to happiness.

[Marcus Moore]

Could we find out sooner rather than later? A couple of tweets from Michel Horton over the last day regarding the Amsterdam Supermeet on the 15th suggests that FCPX will be on the agenda, even though it’s not currently listed in any presentations…