-
Events: Good or Bad?
-
[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
-
[Bill Davis] “Over my decade working with Legacy, ALL I could do was read whole files into my Capture Scratch and so I built a mental management process around MOVING that Capture Scratch around if I wanted to work on a different machine. “
I don’t understand this statement. “Legacy” was never tied to the Capture Scratch folder. This was merely where files captured from tape or converted via Log and Transfer ended up. You could easily import from any folder. With file-based workflows, the Capture Scratch location has become a lot less important. For instance, in working with converted ProRes files from HDSLRs or RED, as well as native files from Alexa, I haven’t used the Capture Scratch location for years (except for renders).
In that sense – as Jeremy has stated – “legacy” and X basically work the same way. So even today, if you move to a different machine with X, you still have to move the source files for media as well as event and project folders. If you are talking about having all of this on a single FW800 drive, then that’s exactly the same as “legacy”. Simply have the source clips and the FCP “legacy” project on the same drive. I guess I don’t understand your explanation as to why one is different than the other.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
John,
Sorry, I got to this party really, really late. All the wine is gone and there’s been like 4 or 5 fights… I missed a good one!
We are using fcpx in an xsan environment somewhat similar to yours and it works and we are actually finding it very powerful and useful.
Here are the keys:
1.) Keep your media centrally located on the san. Govern finder access with ACLs just as you would today. Not sure how you do it, but we do not use Final Cut Pro Documents structures any more for media org on the san.
2.) Turn off “copy media to the event on import” (paraphrasing) in the fcpx preference’s pane. It’s a preference that you’ll want to manage and teach your editors about in the event that they trash their preferences (just like we had to with certain preferences in 7 in a san environment like scratch etc)…
3.) The directory where you would keep your fcp 7 project files will need a parallel directory on the san for fcpx “san locations”.
Important concept: fcp7 project file = fcpx san location
or a san location is just a folder on the san, so, folder = 7 projectThe storage pool on your xsan where this project directory is kept (if you are using affinities and the like in your san setup) needs to be big enough to hold your render files.
4.) In the fcpx project directory that we created above, create a folder for each “project” that you are working on. Add that new directory as a “san location” to one station’s fcpx instance.
5.) Inside of x, select the san location in the event browser and create a new fcpx event in that san location. Do the same in the project area and create a project. Import your media (no copy) into your new event and begin tagging/prepping and then editing in the newly created project (timeline).
6.) San locations are one user at a time, kind of like 7 projects were supposed to be one user at a time. Although in 7 you could open the same project at the same time and clobber someone else’s work if you weren’t careful.
7.) To hand a san location over to someone else, “remove” it from one instance of x, add it to another.
8.) a) To copy a project to another user, like you would copy a 7 project file, create another folder on the san in the fcpx projects directory. Export an xml of your events and projects from the first station, import it on the second into the newly created san location.
8.) b) Jeremy Garchow and I have been discussing other workflows. You can take a project (sequence) and make a compound clip out of it (like a 7 nest but better), and then share the compound clip inside of an event as an xml. The second user can then import it.
Yes a mam can help. Check out Cantemo Portal. We are installing it now.
I suggest them because, being in a similar san environment to your’s with lots of media and “collaboration” (using the same media at the same time at the least), things can get changed and moved. Check out the feature they are adding called CP Media Detection that reads Filesystem Events.
https://moosystems.com/products/moofs-media-detection/
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 think, though, that a mam would be recommended over putting tens of thousands of clips or hundreds of thousands of clips into a single project (7, X, PP6, whatever – you’ll have problems). Catalogue and centralize that annotation in a mam. Search the mam. Pull what you need into a project and customize from there. You’ll get better performance from the NLE. Cantemo Portal has a way to export an fcpxml directly into fcpx…
So to answer the question of the original post: Events, good or bad?
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.
Happy Holidays John! If you want to discuss further, I’m sure we have a mutual friend who can put us in touch.
Keith
Keith Koby
Sr. Director Post-Production Engineering
iNDEMAND
Howard TV!/Movies On Demand/iNDEMAND Pay-Per-View/iNDEMAND 3D -
[John Heagy] “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.”
Sharing Projects is much easier as FCPX has devices in place to do so without duplicating media.
You could dupe the Project to a new San Location, dismount that Location, then mount on another machine.
There would be no ID conflicts this way. But, every Project needs an Event.
[John Heagy] “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.”
Yes. From there you would need to dupe the Event. This is where FCPX, currently, doesn’t have the convenient duplication method as it does with Projects without duplicating all media in the Event. Finder dupes result in dulicate IDs. This is fine as long as you never cross the streams and try and add both the original and duped Event at the same time.
[John Heagy] “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.”Not sure how it functions with 6000 .movs I honestly haven’t tried it, let alone 132000.
I find that having less Events, in general, is better than having a bunch of Events open at once. I would try to add everything to as few Events as possible. This is where FCPX’s organization methods really do help as it’s fairly easy to group sets of footage together (which in your case sounds like it’s by ‘week’).
[John Heagy] “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.”
No, but I think this is where there’s a big difference between FCP Projects, the the FCPX method of Projects/Events.
If all of the media starts from the same pol of media (same clip IDs) then “modifying Event References” in FCPX seems to work pretty well, at least in the cases where I have needed to use it.
Also, again, FCPX has methods in place here to move Projects around decently. You’d select the “Duplicate Project + Used Clips” and set a new destination (which in your case, would be a new San Location). Then FCPX Dupes the finished Project and creates a new aliased Event. If all of your media is accessible to everyone on the SAN (which it should be if you are working with aliased media), this works really really well.
This is also dependent on media types. If everything is .mov before you import to FCPX, you’re good.
If you use P2, then it’s best to convert to .mov before editing in FCPX as I don’t think there’s an MXF plugin that will read p2 clips natively quite yet (other Op1A MXF formats do work just fine, though).
AVCHD is also a problem as it needs to rewrap to .mov. You would want to do this outside of FCPX so that the media isn’t imported directly in to your Event/Location, and it gets sequestered from the rest of the network in a read only Location that FCPX won’t mount.
[John Heagy] “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.”
is that with proxy media or do you mean you finished outside of the NLE?
[John Heagy] “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?”
It seems that some if it has changed, yes, at least with Events. When exporting an XML, you now have a choice of metadata presets to export along with it. Of course, these could be FCPX’s premade groupings, or you can make your own. I haven’t done absolute extensive testing, but it seems the Event XMLs are accurate. This is also a good way to store dupes of Events, and be able to import them, still with aliased media, be able to rename them, and giving the Event a separate ID. I use an set that I made called “everything View” in which every single option is checked. I have to remake this view after every new install of FCPX as the amount of metadata fields changes with every release and we raraly work with one type of media in a project anymore, so I feel it’s better to have it all than not have enough.
Projects also have this same metadata export functionality. Projects are tougher, though, as the Motion Templates don’t always come through, and there seems to be generic “There were errors when importing this XML” and no clues as to what those errors were.
I find that using FCPX’s methods are more reliable for now, if staying within FCPX. Of course leaving FCPX will require an FCPXML.
[John Heagy] “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. “
The jury is still out for me. I find that separating Projects and Events is actually kind of helpful. Sometimes the two are very different and should be treated as such. Event XMLs are also helpful.
[John Heagy] “It’s clear I’m swimming upstream in trying to use FCPX in our facility based on our what our peers are doing.”
Yes, but it’s fun. And rewarding. Right?
-
[Oliver Peters] “[John Heagy] “So you have three things to worry about: The real media, the project, and now the event.”
Yes. A true in-app project management function is a glaring omission. Yes, Event Manager X… I know. Still a horrible omission by Apple.”
Agreed.
Although with SAN Locations, it’s better. Our particular SAN has a function called “ProjectStore” that acts as a bit of a front end to project management. It wasn’t created specifically with FCPX in mind, I think it’s more of an Avid function, but it does work really well for an FCPX shared environment. Perhaps XSan has similar functions, I don’t know.
-
[Bill Davis] “Jeremy,
But doesn’t the inherenet difference between “traditional projects structures” and the way X is nearly entirely referential the whole crux of this problem?”
Sure. That’s what we are trying to figure out. It doesn’t work the way it used, so, at least in my case, I need to figure out a way that works. I don’t care if it looks or smells like FCS3, I just need it to work in a way that’s conducive to a multi-user, multi-seat environment. So far, it does and it doesn’t.
[Bill Davis] “But =even my rudimentary workflow has caused me to have to seriously re-consider how I view the “attachment” of files to their home base versions. Over my decade working with Legacy, ALL I could do was read whole files into my Capture Scratch and so I built a mental management process around MOVING that Capture Scratch around if I wanted to work on a different machine.
What X has revealed to me is that this is extremely inefficient in my situation. It’s MUCH easier to make the data pool transportive – rather than seeing the PROJECT as the element I transport. “
But the problem, Bill, is that once you have more than one user, which means more than one Project or Event, things can get odd. The way that FCPX stores the files can cause some issues if you aren’t careful or diligent. FCPX, currently, only has limited tools to deal with all kinds of workflows. It needs mroe work in certain areas to make protability iwthin the same network lighter and faster. Portability between different vollumes is OK in FCPX, but sharing and emrgning data from one larger or smaller set together isn’t wuite refined in FCPX.
In your case, using one Fw800 drive, your Events and Projects are ever changing, but it’s on one device, which of course you can use on whatever machine. Now imagine a subset of that data that three separate people are working on. It gets harder to deal with and is impossible with one fw800 drive.
Now, that’s not to say that the structure is inherently flawed with FCPX. I don’t think it is. I just think it needs a few more tools to help users migrate and merge these data sets in order to keep things together, while being able to work separately.
[Bill Davis] “I don’t see X as that. I see it as itself. Something extremely excellent at what it’s created to do – but NOT something trying to be what it’s not.”
Great. I see it differently. The database approach will win out, I think, in the end for us. I just think there needs to be more in app functionality to deal with all the data, so I see it as not finished trying to be what it is. I don’t know if you’ve ever done this, but if you have a gmail account and know someone else with a gmail account, try editing a document at the same time. It’s next level collaboration, it allows per user tracking and changes, and allows real time access of a “single” document. I could be wrong, but it seems to me with the way FCPX Events are setup, this type of thing may be possible mroe so than it not being possible. I don’t know. This won’t be possible with a fw800 drive, that part is clear.
[Bill Davis] “I think it IS worth asking is if the problem so many have with X is that it’s NOT Legacy writ larger? Which is still the ONLY way they believe they can find any value in it?”
As I said earlier, for me personally I don’t care if it works like FCS3, I just need it to work. Right now, the plans seems to be in place, and there are hints to better collaborative workflows and there’s already a bit of functionality built in to it, but the level of control isn’t there. If none of the current functionality was available, (like SAN Locations, XML, etc) I would leave it alone. But it IS there, so I am going to try and leverage it and discuss what’s possible today. If FCPX isn’t going to work out for us, this will give other companies a chance to shore up their offerings, and perhaps I will take my business to them. Win, win.
[Bill Davis] “Not sure I heard ANYONE say that from the stage at NAB 2011 when Apple introduced it. They said “The NEW Final Cut Pro X.”
Then, absolutely yes, they announced the EOL of FCP-Legacy. But I don’t remember ever reading anything about it from APPLE saying that X was supposed to be a direct REPLACEMENT – as in stop using Legacy today and start working with X to do everything you’re doing today, tomorrow.”
They tried, Bill, as they stopped selling Legacy almost immediately. That was a warning shot across the bow to move on. So I can either use the product of the same name sake as I have been doing for the better part of the last decade, or I can jump ship to another company. I don’t need a stronger hint as to what I need to do.
[Bill Davis] “So I’m going to maintain that that was petty exclusively an audience interpretation, not ever an Apple talking point, and an interpretation that many invested legacy users came to not only believe, but deeply resent.”
I am not mad at Apple, so stop telling me that I am. I am trying to make FCPX work for us, why can’t we question the design when there’s simply no method in place to perform certain capabilities that are needed in a shared environment?
-
[Keith Koby] “Important concept: fcp7 project file = fcpx san location
or a san location is just a folder on the san, so, folder = 7 project”Bingo.
Now if there was a way to dupe only what’s needed, instead of everything that’s in that folder.
Or move a Proxy only Event, or a high quality transcode only Event from the greater Event.
-
[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 -
[Jeremy Garchow] “I guess you can call that a closed blackbox, but I’d tend to say it’s even better than FCP7. With FCP7 you’d need to open a project to see exactly what media was in it, not so with FCPX.
“you know thats not real – apple, as oliver peters has laid out, are heavily weighting the scenario to avid style events where the media is held transcoded in a blackbox not referenced to – yes, they are still readable QTs in the event, but they are undifferentiated and the entire externally readable project folder structure paradigm we understand is gone.
answer me this – tell me you do not have a default project structure folder – or maybe a few variations on that theme.
one of the cardinal strengths of FCP was the realisation that you could create a fully permanent public archive for all assets – a civil service in the finder as it were, using naming and numbering conventions, each project holding a common asset folder substructure, with the lot going periodically off to LTO.
last I checked – this got deployed across massive commercial concerns and quite a bit of broadcasting – at least in the UK.yes it was delicate – it was finder based – but it was immensely powerful. properly ordered, the finder forms an excellent basis of operations.
send a producer an email with a finder file string, and they can interrogate graphics assets, scratch VOs, PSDS, offline renders, recent 5D dumps -simply because these are all held in a common transparent folder project structure hierarchy – in the finder, that they can navigate to.and they they can introduce assets the same way – two way street.
Apple made a really serious mistake here – its new software is aping pro avid scenarios, but bent more to a prosumer auto focus protective scenario –
its just frankenstein software –it’s neither fish nor fowl.
I personally really feel that: the thing that came off the software operating table – with jobs’s feedback hand grenades lobbed in over time –
it has an epic identity crisis, that will never go away – apple have likely locked themselves into a total dichotomy, given how much they have probably sold this to an enthusiast base, as well as their historical blooded pros.I find it impossible to see anything other than this software evaporating in the mid ground.
it’s – you know – a chimera. thats just not a smart thing to create.
https://vimeo.com/user1590967/videos http://www.ogallchoir.net promo producer/editor.grading/motion graphics
-
[Aindreas Gallagher] “you know thats not real – “
Pretty sure it’s real. I can see what’s in an Event. I can’t see what’s in an fcp7 project.
[Aindreas Gallagher] ” but they are undifferentiated and the entire externally readable project folder structure paradigm we understand is gone.”
Not entirely. You can import pre organized finders in to fcpx and the folders translate to keyword collections.
[Aindreas Gallagher] “answer me this – tell me you do not have a default project structure folder – or maybe a few variations on that theme.”
Sure. Depending on the job, there’s a rough outline we use.
[Aindreas Gallagher] “one of the cardinal strengths of FCP was the realisation that you could create a fully permanent public archive for all assets – a civil service in the finder as it were, using naming and numbering conventions, each project holding a common asset folder substructure, with the lot going periodically off to LTO.
last I checked – this got deployed across massive commercial concerns and quite a bit of broadcasting – at least in the UK.”I guess I’m having a hard time understanding why this can’t be done with fcpx.
[Aindreas Gallagher] “yes it was delicate – it was finder based – but it was immensely powerful. properly ordered, the finder forms an excellent basis of operations.
send a producer an email with a finder file string, and they can interrogate graphics assets, scratch VOs, PSDS, offline renders, recent 5D dumps -simply because these are all held in a common transparent folder project structure hierarchy – in the finder, that they can navigate to.”And why can’t you do this with fcpx?
Reply to this Discussion! Login or Sign Up