Activity › Forums › Apple Final Cut Pro › Roles: got ’em to work.
-
Michael Gissing
September 23, 2011 at 1:03 am[Erik Krisch] “STEMS are not delivered to a mix stage. Apple got the term wrong. Nothing is a ‘stem’ until the final mix is completed. Going to audio post, the dialogue or whatever tracks you choose would be SPLIT out in either raw UNITS or, if you’ve done some mixing to the tracks beforehand, PREDUBS.”
Correct Erik – the reason audio post exists is to get raw unprocessed audio as individual files so that they can be properly edited, EQ’d and mixed in an environment with proper monitoring by someone trained and experienced. You are correct in saying that you do not deliver stems to audio post and that they are what is produced in the mix to delivery specs.
However anything can be a stem if it is a ‘partial’ of a finished project. I am less concerned about using that term and more concerned that people might think FCPX is capable of producing proper mix stems.
-
Jeremy Garchow
September 23, 2011 at 1:04 am[Michael Gissing] “This is a sure recipe to ensure that basic things get broken regularly.”
How do you mean?
I’ve had Automatic Duck ProImport AE for years, it’s never broken.
-
Jeremy Garchow
September 23, 2011 at 1:11 am[Michael Gissing] “However anything can be a stem if it is a ‘partial’ of a finished project. I am less concerned about using that term and more concerned that people might think FCPX is capable of producing proper mix stems.”
It is true that people should not think that FCPX’s multichannel QT Export is an OMF replacement. Anyone who delivers OMFs will know that it isn’t.
Roles will help define the clip relationships and will probably hand that info off to a proper clip by clip by channel OMF exporter.
-
Michael Gissing
September 23, 2011 at 1:11 amJeremy, not a specific comment on the Duck. Like all software it needs to be constantly updated to make sure it works when versioning changes things.
At this stage FCPX is developing what seems to be a new variation on XML. I remember the agonies of third party developers in the early days of OMF when AVID would make changes and then interchange would be broken until third party developers caught up. So after such a long period since OMF has been settled, it is worrying to me that Apple are going to be coming up with a two stage approach to getting something as basic as an OMF off the system. Any two stage approach with a developing interchange format is going to break things often.
My argument is that it is so basic a function that not having it integrated from day one is a problem.
-
Jeremy Garchow
September 23, 2011 at 1:23 am[Michael Gissing] “My argument is that it is so basic a function that not having it integrated from day one is a problem.”
Yeah, that’s valid, but I don’t think this process was simply forgotten by Apple, it’s just a slow rollout.
Now that the XML system is out, my guess is that we will see fairly rapid development for interchange, but perhaps optimism makes me naive.
-
Craig Seeman
September 23, 2011 at 1:36 am[Michael Gissing] “I suspect Apple are just going to get XML functionality as the primary form of import/ export and rely on third parties to fill in the gaps. This is a sure recipe to ensure that basic things get broken regularly.”
Apple certainly may rely on third parties. If they’re “reasonably” priced I have no problem with that. You buy what you need.
It also means Apple will focus on core functions.
Actually i think the opposite is true regarding things getting broken regularly. This is why Apple needs to pay careful attention to APIs, things such as XML support, because it’s a foundation that generally shouldn’t be changed. This is likely why it’s been slow in coming. It also means it’s less likely to be broken. Architecture, whether for plugins or import/export is not likely to be messed with.
BTW it’s much the same reasoning why Apple’s SDK for camera compatibility will rely on the camera makers to support. The SDK won’t change. The camera makers will have the ability to do their own work and changes as need be. This is what Apple is doing with XDCAM EX and why the comment about it on the FCPX update page.
-
Michael Gissing
September 23, 2011 at 1:45 am[Craig Seeman] “It also means Apple will focus on core functions.”
That’s the core of my comment. I can’t see OMF export as a non core function. If FCPX couldn’t export a quicktime everyone would have gone ballistic. OMF functionality is at the core of my business and something that all NLEs have had as core functionality for a long time. If Apple are palming it off, I need to know if as I must continue to steer editors away from FCPX.
-
Jeremy Garchow
September 23, 2011 at 1:56 am[Michael Gissing] ” OMF functionality is at the core of my business and something that all NLEs have had as core functionality for a long time. If Apple are palming it off, I need to know if as I must continue to steer editors away from FCPX.”
From the now offline FAQ:
“Does Final Cut Pro X support OMF, AAF, and EDLs?
Not yet. When the APIs for XML export are available, third-party developers will be able to create tools to support OMF, AAF, EDL, and other exchange formats. We have already worked with Automatic Duck to allow you to export OMF and AAF from Final Cut Pro X using Automatic Duck Pro Export FCP 5.0. More information is available on the Automatic Duck website: https://automaticduck.com/products/pefcp/.” -
Simon Ubsdell
September 23, 2011 at 11:18 am[Craig Seeman] “It certainly is a matter of taste. Before FCPX I had no choice though. All the major NLEs where tied to track workflows, which I had been bothered by since around 1990. The scrolling up/down though in projects wasn’t simply a taste issue though. It was a GUI inconvenience that I’m glad is gone in at least one NLE.”
Here’s an illustration of why I think I prefer the track-based model for audio “track-laying” as things currently stand.
Here are two spreadsheets for food types consumed during a week, days standing in for time in the timeline, food groups standing in for types of audio clips, e.g. Fruit/Veg represent dialogue, etc.
First the traditional version:
And now the FCPX version:
Yes, indeed, the FCPX version saves you some screen real estate, 25% less vertically in this case. But it comes at a cost (for me at least) of making precisely what you have called “visual clutter”. The encroachment of lower order tracks upwards into the available space is for me not at all desirable.
(Note that I have actually stacked the decks in favour of FCPX by colour coding and font emphasis which is not actually implemnted in Roles yet though of course it will come.)
Personally I still prefer the traditional version which gives me the at-a-glance “visual feedback” that I have been going on about, and I would trade any disadvantages of increased expenditure on screen real estate to keep that.
I’m not saying I couldn’t find ways of working with the the model but it doesn’t yet feel like an improvement to me. Which is not to say that it won’t get there in the future.
Also note the traditional track-based model has a further advantage that FCPX has “lost” – just as I can very easily scan along my Fish row and see clearly what’s happening with my fish intake, so with numbered tracks my eye can scoot along a track and see what I’ve got going on in with my Musics. The track-based model makes it easier because I can keep my music tracks in view and only scroll horizontally, whereas in FCPX I would have to scroll both horizontally and vertically to hunt it down.
Again this is instant “visual feedback” that I find useful to keep things organized overall and during the nitty-gritty of editing. If I’ve edited out a scene and I need to find the music to trim it out to make a new transition, I know exactly where I need to go to find it on my designated music tracks. In FCPX I would have to hunt up and down to find where my music had go to because it doesn’t live in any one place and it can go scooting around. And the same with dialogue and effects – only more so because being generally a lot shorter they will end up even more “jumbled”.
Obviously I am talking about elaborate, long-form editing with many tracks, not 5 minute corporates with a couple of talking heads, some cutaway audio and three of four music tracks. For the latter the FCPX model is great and presents no obvious limitations. But with greater track numbers and complexity, the issues escalate quite a bit. My example only uses eight “tracks” and a very short seven day “timeline” – convert that to 24 tracks or more and drama length timelines and the FCPX model doesn’t look nearly so pretty.
So, yes, Roles make the visual clutter of the FCPX audio timeline quite a lot less frustrating, but as I’ve said before they are so far not doing a great deal more than making up for its limitations. But who knows what the future holds? I could get very excited about it when I finally see it, but I haven’t seen it yet so I’ll keep my excitement in check for a little while yet 😉
Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com -
Liam Hall
September 23, 2011 at 12:08 pmThis roles/stems malarky is bunkum. I used to go File>Export>OMF. What was so wrong with that?
Liam Hall
Director/DoP/Editor
http://www.liamhall.net
Reply to this Discussion! Login or Sign Up

