[John Heagy]

[Tim Jones] “LTFS is for standalone drives”

How do you explain Storage DNA which writes LTFS directly to LTO-5 library drives with no virtualization.

https://storagedna.com/products/dna_evolution/overview/#traditional

Now what I have run into is that Quantum will not support LTFS across fiber from third party middle ware. It will actually work in the case of Storage DNA but Quantum would prefer you buy this instead:

https://www.quantum.com/Products/TapeDrives/LTOUltrium/LTO-5/LTFS/Index.aspx

Oddly they have no problem with LTFS and third parties if it’s SAS drives in the library.

John

[John Heagy]

[Walter Soyka] “Portable metadata.”

Curious what you mean by portable?

Side car files or embedded into the media?

Apple seems to be embracing embedded with the Quicktime extended metadata model. Take the standard “Reel” field in FCPX. That is populated if there’s a com.apple.proapps.reel entry in a movie. Most of the metadata fields in FCPX can be populated similarly with embedded metadata. One can even add custom fields in FCPX, and with Digital Rebellions’s QT Edit embed matching data.

This would allow external MAMs to send metadata to FCPX via xml or embed the data in the movie so merely importing brings in all the data.

I like that you mentioned AvidDS. That did so many things right!

John

[John Heagy]

[Marcus Moore] “FCPX is built on the same database structure as FinalCutServer”

I was never a fan of FCS and prefer it never come back. Any Asset Manager that starts life dealing with only images and later adds video never works very well. FSC was born from Art Box… nuff said.

[Marcus Moore] “Perhaps it could be possible to assign logging info to a specific user.”

Managing write access to metadata will require user permissions (Open Directory) and a centralized server/database. Saving projects directly to this database, much like Adobe’s Anywhere, would make sense.

Deciding how to manage global/institutional metadata vs user/project metadata is the real trick. User permissions could easily lock certain users from changing certain fields. Locking everything up would limit much of FCPX’s abilities. There could be a user set of metadata that would follow the user login but never be part of the global. This could be viewed by other users but not changed or eventually added to the global.

John

[John Heagy]

[Marcus Moore] “• audio mixing either within FCPX or with tight Logic integration”

This is at the top of many’s list and I believe will be part of a free update.

[Marcus Moore] “• collaborative workflow”

Less popular but key to FCPX being adopted by larger shops with shared storage. I think this will be part of a paid, hopefully 10.1, version.

The question is: What can Apple do specifically to improve collaborative workflows?

What kind of collaboration are we talking about?
Moving FCPX projects to other apps for grading and audio.
Offline/Online
Multi-user editing with shared storage.

The first two are in pretty good shape. That leaves multi-user editing with shared storage.

Not to rehash Events Good or Bad but how Events work is key to truly sharing projects and more importantly Events. With local storage and a single user, Events organize and present a single view of all media to present and future projects, it’s really a nice built in MAM. Any metadata additions are applied to a single presentation and there are no duplicates to worry about.

Once an Event is placed on shared storage and shared (really duplicated) it’s shared singularity vanishes. Each Event on a San Location is only available to one user. This forces one to duplicate Events into new San Locations in order to work concurrently. Every duplicate made to allow another editor to work with the same media invites additions/changes to the original event. This is entirely counter to a proper MAM which presents the same view of all asset to all users.

Restoring the singularity of Events to shared storage is key to multi-user editing. In my opinion.

So how does Apple do that?

John

[John Heagy]

Thanks for the detail response. I wasn’t questioning all the tagging, keywording, and search – couldn’t all that theoretically work without media being squirreled away in an event?

We’ve come to the conclusion that San Location(SL) = project and essentially are using events to support only projects in this SL. This is not Apple’s intent where Events become a long term library for any and all projects. In Apple’s world of single users with local storage, all events are shared with all projects. I understand one can export xmls of events but then they generate new events and unless merged at some point go “out of sync” quickly.

In order to work in a shared media environment we must create isolated events.

I understand my argument against events in a shared environment is somewhat moot as events are required.

I think we’re all in agreement Apple needs to improve shared media workflows. I’m just pointing out what I see as fundamental obstacles.

Not being able to share events is a fundamental obstacle considering events were built to be shared across projects.

So I think Apple needs to figure out a way to share events in a shared environment.
If not they will continue to be something we will have to work around.

John

[John Heagy]

[Keith Koby] “mportant concept: fcp7 project file = fcpx san location
or a san location is just a folder on the san, so, folder = 7 project”

Hi Keith,

Yes, we have come to that conclusion as well. It’s basically a way of combining events into a “project folder” so it’s much like Avid in the end. For concurrent workflows we would add two additional SLs, one for the second edit and another “share SL” that could be added in order to copy a project into and then released to the other edit to copy to their SL.

We have a project volume that is smaller and less powerful than our many media volumes. Using San Location (SL) = Projects approach means putting the SL on the small project volume. Now I have to worry about Render files, which need media volume performance, not to mention render files filling the small volume. Heaven forbid a user has the media link preference set wrong and terabytes of media start coping behind the scenes into the volume. The render files are a big issue. We maintain a live backup of our entire project volume. Including render files will increase it’s size 10 fold. Deleting them is the obvious answer but unlike FCP7 they are buried inside each project folder requiring one to delete from FCPX or have admins go cherry picking in the finder.

I’m not arguing that using events in a shared environment is impossible. I am arguing it’s value.

[Keith Koby] “Yes – we too want real project and event sharing inside of X. We also want a good way to get information back out of fcpx back into the mam. It opens many doors when that feature set is available. “

I see events as a built in MAM considering Final Cut Server is dead. In a MAM, media is separate from projects and has powerful metadata tagging and search, just like events. The other tenant of all MAMs is presenting a shared consistent view/version of all the media. Events prevent concurrent sharing and allow/encourage users to customize/change the media metadata. In the end one has a SL/project with custom metadata that can’t be concurrently shared but only copied. Sounds like FCP7. Not saying that’s bad but we’re jumping thru hoops here for what gain? I don’t think I like the idea of using FCPX entered metadata to feed a proper MAM. Not enough control of taxonomy… pulldowns etc.

So similar question: What’s the value of events if using a MAM?

[Keith Koby] “Events are incredibly powerful if you use them the right way and they work in a collaborative environment. If used in the wrong way in a shared environment (copying files into the event), they can be cumbersome.”

Can you detail one powerful feature of events? I’m not talking about search and metadata entry as that could all be done without the media being separate from the project in light of SL=project. What’s a powerful feature of requiring media be in an event in order to view or use in a project?

One thing I could see us using an event for is a set of approved media for all shows, like lower thirds, copyrights, etc. Having them become inaccessible once a single user attaches kills that idea. I’d like to see read only events as a start.

As you say, and describe, it’s possible to collaborate with FCPX. I just don’t think it’s an improvement over FCP7. This is why FCPX is struggling in large shared collaborative workflows and Apple’s solutions/recommendations fall very very short in my opinion.

[Keith Koby] “If you want to discuss further, I’m sure we have a mutual friend who can put us in touch.”

Indeed we do! Looking forward to speaking with you soon!

Happy Holidays
John

[John Heagy]

[Oliver Peters] “…you have to remember that FCP “legacy” users screamed for better media management and that’s precisely what Apple did in X”

Yeah I hear that, but I wasn’t one of them. We had that all licked. It takes discipline and off course a reliable shared environment.

John

[John Heagy]

Ah I see. So you have shared read only volume/s with all the “real” media then each room has it’s own read/write volume with events linked to the real media.

So you have three things to worry about: The real media, the project, and now the event. Do you see any added value that merits the added complexity of having your media only be accessed thru events? Do you encourage your users to customize these events i.e. changing clip names or creating keyword collections? Do you attempt to merge the events when finished?

I forgot volume level SANs can’t mount read/write on more than one user. Maybe that’s why FCPX allows this workflow. Got my hopes up there for a minute.

With FCP7 it was easy to trick, or break the “rules”, and do what you wanted. FCPX will be a tougher nut to crack. FCPX is a walled garden… at least it’s not Cheyenne Mountain like Avid. Hmmm, whats a good metaphor for Premiere… maybe “The kitchen sink”

John

[John Heagy]

[Oliver Peters] “It is my understanding that only one user at a time can access the same SAN location on XSAN. Is this right Jeremy? If so, how would it affect collaboration?”

That’s correct. It kinda kills collaboration on the face of it. One would need to copy that event to another Xsan location at which point the media is shared but any additions made in the event, favorites, keywords etc are now isolated.

[Oliver Peters] “In my volume-level SAN workflow, we keep all media files on the SAN. Events and Projects are local on each machine linked to the SAN media. When there is a collaboration, each editor has a copy of the same Events. “

That’s very interesting! You have fooled FCPX into thinking your volume level SAN mount is truly an internal HD. Can multiple users make metadata changes to the media in these shared events? Do both users see each others changes? How does that effect the project? Does externally changed media unlink media in the project?

Sorry for all the questions.

John

[John Heagy]

Bill, you may want to stop reading as I’m about to discuss niche workflows.

[Jeremy Garchow] “Do you need to share project data, event data, or media metadata?”

We do start edits in one shift and finnish in another, and will have up to 3 rooms working on a single show at the same time. So yes to sharing projects.

The use of Event sharing comes down to access and scale. Scale in number or edit rooms and amount of media. Every edit room needs access to all the growing weekly media.

If we were to use the Event strategy 100% (Bill doesn’t like “paradigm”) we could put each week’s media, 6000+ clips per week, in it’s own Event via an Xsan location or multiple locations.

The considerations for doing that:
How does FCPX function with 6000 .movs in an Event?
22 weeks x 6000 clips equals 132000 clips and all need to be accessible!
Once a single user adds this Xsan location/s it prevents everybody else from accessing it.
Sorry, but I not going to copy 132000 aliases into 20 separate Xsan locations for each of our edit rooms to link to.

For all the above reasons we would only use Events to import/link to just the media needed for that sequence. Using Events like Apple intended really only works when there’s a clear association between a small groups of projects to a small group of events. When all projects need all events all the time across all systems… well it simply wasn’t designed for that.

We use an offline/online workflow in most cases. Importing an offline xml determines what media needs to be imported, so using events in an ad hock way would work.

Currently the most likely way I see us sharing is via .fcxml where the media is simply relinked to another Xsan Location/Event totally independent of the original. Due to media being imported fresh each time the metadata in the event is essentially pointless. Initially fcpxml was not designed with 100% fidelity… has that changed?

For us Events are simply a means to an end in our offline/online workflow. I’m not saying it’s not valuable to others, we may use it for isolated jobs.

FCP7 managed to flourish in “one man bands” all the way up to facilities like ours. FCPX is loosing out as the successor to FCP7 in “facilities” and even small shops due to the fact it was not built to facilitate sharing of media, but to really restrict it in a nod to Avid. Apple has underestimated how the anti-Avid approach used in FCP7 benefitted places like us. Designing workflows (sorry, niche workflows) with FCP7 was like using a near unlimited palette, compared to Avid which is like painting a straight jacket.

It’s clear I’m swimming upstream in trying to use FCPX in our facility based on our what our peers are doing. Bunim Murrray is just one example of many.

Wish me luck!

John