Activity › Forums › Creative Community Conversations › Events: Good or Bad?
-
Jeremy Garchow
December 24, 2012 at 3:12 pm[Aindreas Gallagher] “the only thing that is required is proper media management. the collaborative review finder space available in a well ordered FCP project file encompassing all assets is an intrinsic asset of the FCP system itself. Its highly egalitarian. Finder level review of these assets by multiple partners is pretty key in a lot of shops I get to go into.
The idea that we return to a blackbox one way transcode silo strikes me as strange – at least coming from apple. I can’t tell who they are selling it to. “
Put another way, what is unique to FCPX is that you can see what is in each Event just by looking at the Finder.
Since FCPX stores media, be it linked or copies/transcodes of the original, you can simply browse all of the movs in the Finder without even opening FCPX, or having a copy of FCPX installed on the machine.
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.
Jeremy
-
John Heagy
December 24, 2012 at 4:16 pm[Bill Davis] “QUOTE:
For us it simply gets in the way and adds a layer of complexity when in a large shared environment. The need to virtualize the media via aliases when linking to media is of no benefit.
(Bullet Point: It’s NOT perfect for my large facility)”Wow Bill, thanks for quoting and properly summing up what I really meant so concisely.
Clearly these are divisive statements that warranted you’re condescending and insulting response. My request for ideas that would help FCPX find a home in collaborative workflows aka: “niche workflows” has clearly upset you. Sorry about that!
I’ll also try and communicate the entirely of my thought in the posting subject from now on.
Happy Holidays
John -
John Heagy
December 24, 2012 at 6:08 pmBill, 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
-
Oliver Peters
December 24, 2012 at 6:34 pm[John Heagy] “The considerations for doing that:
How does FCPX function with 6000 .movs in an Event?”I haven’t had events quite that large. Usually the largest have been around 1,000 files and up to 1TB of ProRes/LT/HQ/4444 media. My concern is that each time this Event is initially accessed, it will take a while for the files to be buffered into RAM. Might not be a show-stopper, but definitely an annoyance compared with other NLEs.
[John Heagy] “22 weeks x 6000 clips equals 132000 clips and all need to be accessible!”
Then if all of this has to be accessible at once, that’s a LOT of buffering. I use a volume-level SAN, so FCP X works differently than with XSAN. 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?
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. Their Projects are different, so to move from one room to the next, we simple copy over the Project file from room A to room B and continue. In this scenario, two editors can be working simultaneously with the same media pool.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
John Heagy
December 24, 2012 at 6:50 pm[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
-
Oliver Peters
December 24, 2012 at 7:37 pm[John Heagy] “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?”
In this configuration, all volumes are mounted as if they were external drives. In fact, the icon looks like any other drive and not the network icon like “add SAN locations”. In fact “add SAN locations” is greyed out on these systems. The SAN software (FibreJet) controls read/write permissions. Without it, you would accidentally write to the same volume from two different locations causing collisions and corruption. FibreJet prevents that.
We initially tried running Events/Projects on the SAN volume, but that caused too many beach balls in X. Presumably it’s a network traffic issue and not a bandwidth issue, since the connections are all 4Gbps FC.
Each user can make their own metadata changes to Events, since that info resides locally. So far our use has been to have editor A cut the main job and have editor B go in and simultaneously create cutdowns of interviews to be used by editor A. Then the cutdown project file is copied into the other editor’s Projects folder. Any Event metadata changes, like keywords, etc. done by one editor do not show up in the other editor’s version, unless that Event is also copied over. Since editor A only cares about the edited selects, he generally would not need the keywords that editor B created in his editing process. I haven’t tested this with compound clips, so I’m not sure what would happen there. I guess you’d have to make sure to also copy the Events with the compounds.
It’s essentially the same process as if I were editing a project at work and at home, with each location having a mirrored set of media. In the SAN case, there’s no need for a mirrored set of media drives, since each of the two room links to the same media files.
If you modify the media externally to FCP X, then the same caveats apply as if you were working locally. For instance, my biggest bottleneck is sending files to an out-of-house colorist. I get back rendered files, that are trimmed and have had the file names altered in some fashion. FCP X will not relink these without a corresponding FCP X XML. So far, I don’t think Baselight (the colorist’s system) generates that. So, I have to use a workflow that involves an FCP 7 roundtrip and 7toX to get these files back into X.
If you were working back and forth with two editors making changes to a common “master sequence”, this would have to be done by working on local copies and then moving the sequence (Project file) between them. It’s essentially the same way FCP 7 would work now. To my knowledge there are only three systems that support active, dynamic changes within the same open job/project/production and that’s Avid, Avid/FCP7 with EditShare and Lightworks.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
John Heagy
December 24, 2012 at 8:41 pmAh 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
-
Oliver Peters
December 24, 2012 at 10:47 pm[John Heagy] “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.”
Yes.
[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.
[John Heagy] ” Do you see any added value that merits the added complexity of having your media only be accessed thru events?”
Well, as I said before – and Jeremy disagrees with – the design intent (as I understand it directly from Apple) is to use the “copy imported files into the Event” function. This keeps the media safely managed. In any case, the organizing/metadata process still has to occur, whether the Event files are separate files at the finder level or whether they are embedded into an overall project file (FCP 7, PPro). I am used to dealing with this in Avid-land. There, bins in the app correspond to specific files in the finder that exist within a project folder. These are linked to media files inside a controlled MediaFiles folder. Alternately, you can use AMA which makes things even more complex, by linking to media not within controlled folders.
What I still don’t really understand is why Event files and folders should be different from Project files and folders. At their core, there doesn’t seem to be much difference. They aren’t in Avid-land, since sequences live in bins and a bin file with master clips at the finder level is in the same place as the bin file with sequences. Not sure why this is any different with X. For me this gets confusing with X, because I manually move Event and Project folders in and out of the active folders. Ultimately I have to be careful about naming, so I remember what folder is an Event and what’s a Project so that I move them back into the right place.
[John Heagy] “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?”
No real answer to that. In the SAN shop I’m referring to, I’m the main editor moving forward with X to test the waters. The other editor who has assisted with X is only doing so with my encouragement. Mainly so that he’s up to speed. So customizing Events with collections is fine. All the media stays in the same Event for a single production. I’m completely against changing clip names inside the NLE (other than Avid). Yes X tracks and takes care of this, but it can cause other issues later, especially when you need to roundtrip with other applications. There are plenty of other fields to use.
[John Heagy] “I forgot volume level SANs can’t mount read/write on more than one user”
A volume-based SAN can give only one user write access to a given volume. A single user can have read access to any or all and can have write access to any volumes not already accessed by another user. In this set-up, each room usually has write access to its designated working volume and read access to all the others. Volume-based SAN structures usually are organized by rooms or by productions depending on the facility preference.
[John Heagy] “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.”
While that’s generally true, you have to remember that FCP “legacy” users screamed for better media management and that’s precisely what Apple did in X. As far as Avid, I find it easier to deal with moving this media around, with the exception of AMA. That’s still a work-in-progress.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
John Davidson
December 24, 2012 at 10:47 pmThis forum is a lot like this:
https://www.hulu.com/watch/3526John Davidson | President / Creative Director | Magic Feather Inc.
-
Bill Davis
December 25, 2012 at 12:20 am[Jeremy Garchow] “FCPX doesn’t have a traditional project structure and the way Events are sometimes organized causes more work than we are used to. Since Render files and transcodes are stored with Events, it makes moving or duplicating Events a lot of work or take a lot of disk space, not to mention, when duplicating a referenced Event, FCPX will automatically add any external media in to the Event on the duplicate. This creates unnecessary duplicates of media. Is this the best way that this can be done, Apple? What is the benefit here?”
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?
Admittedly, you have vastly more experience than I do trying to make X work in a SAN environment. And I’ll bow to your experience when it comes to managing the I/O issues that are involved with that.
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.
I can easily understand that in a facility construction, where the database must be both fixed and centralized that what works for me will NOT work for the facility manager. However, I’m still thinking that there may be something about the newly “disconnected” capability that suits my workflow so well that portends a new way of working for larger systems as well.
If, as Philip Hodgets has schooled me, virtually EVERYTHING about X is metadata based and simply a system of managed references to pools of sequestered data. It’s seems reasonable to believe that as that structure (FCP-X) evolves, I’ll have to more farther and farther away from my original ideas that SOURCE footage is what I used to think it had to be.
Again, I admit, my Firewire Drive workflow is NOT the solutions for everyone. But that’s not the point. It’s that it BROKE my prior thinking.
I’m absolutely unqualified to tell anyone in a SAN environment what the new “agile yet automatically re-linkable” data referencing construction in FCP-X will mean to them. But I DO know it’s something very different from what was built in to Legacy.
And so I’ll likely keep asking openly what there is about the NEW plumbing that you and I both have come to better understand that Apple has built into X that might be relevant to those who have little or no experience in anything but systems that treated pools of stored video as simple Capture Scratch buckets.
Because I think that’s a huge difference in how X works, compared to Legacy.
I’m also mindful of your phrase “the way Events are sometimes organized causes more work than we are used to.”
I think that’s well written. And it askes if the problem is the structure of how Events (ARE) or more based on the fact that X is young, and there aren’t that many of us who have that many hours poking around under the hood.
[Jeremy Garchow] “Why all the duplicates? What happens when we need to archive or restore, or simply track multiple sets of the same data set? Is this the best way this can be done, Apple? Anyone?
“I don’t understand this, because I NEVER face duplicates unless I purposely create them for backups.
That’s the core of my workflow. One source file. Expressed many ways via X. I don’t COPY Events much – I reference them by either loading them or not. It seems natural and simple to me. But I acknowledge that if I was surrounded by 10 other editors who had to work simultaneously on the SAME event in real time and can see how it would be a serious concern. Again, however, this is the realm of folks who see X as a “REPLACEMENT” for Legacy and need it to do the same jobs that Legacy did.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.
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?
[Jeremy Garchow] “Even if you take a SAN out f it and try and work between two machines (one local, one mobile) and multiple drives, it gets a little weird and you can end up with a lot of duplicates of things (media/Events/Projects, etc).”
Now this is something I do a LOT and I’m just not seeing this. The program on two machines. The EVENT AND PROJECT material on anything you can move between them – and BINGO – you never have to duplicate anything. It’s simply seeing the Event and Project libraries for what they are. Data pools that any machine running X will look for – and if detected, that project instantly becomes part of the connected machines workspace. So the issue is only if you need TWO editors working on the same files. And I totally agree – X is currently NOT built to do this. It’s NOT a collaborative editing tool right now any more than Legacy was in V1. It’s at best got baby steps in that direction with the increasing ability to handle XML, OMF, etc. But that’s NOT it’s wheelhouse right now. So asking it to form the hub of a large collaboration system is as silly as asking a bunch of guys with sports cars to be responsible for getting all the kids to a large, local school.
Now we’ve heard that they’re maybe working with some larger shops on a nice trailer rig that the powerplant in X might hook up with someday for heavier loads – but right now, it’s just NOT a truck.
It would be excellent if they can build a real load hauler into this design, because I think you, as much as any of us have come to appreciate the things that X does well. But it’s NOT a truck. Not yet. Not at all.
And it’s NOT Legacy 2.0 yet either.
It’s going to be something different. We’ll see what in time.
[Jeremy Garchow] “FCPX is billed as the Final Cut Studio replacement, and in many ways it is. One last remaining hurdle is workflow, and in a shared environment large or small, that is a major consideration.”
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.
In fact, knowing how differently they work, it would have been totally insane if Apple had ever knowingly said that. After all, they were the ONLY people who really knew what it actually was. And I’m sure they had no illusions about anyone in the middle of a job, switching and just moving right along.
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.
Sorry for the novel – but the gifts are wrapped and everyone in the house is out on errands, so I”ve got quiet time to write.
Hope your coming year goes well and I truly appreciate your participation in the forum. You’ve been tremendously fair and useful to the discussion and I appreciate all the efffort you’ve put into helping so many here understand the reality rather than just the popular perception of X.
Merry Christmas and all the attendent best wishes.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
Reply to this Discussion! Login or Sign Up