FCP X features or lack thereof. Your opinion on the rationale.
by Tangier Clarke on Nov 4, 2016 at 4:27:05 pm

Re: FCP X 10.3

Folks, I am a proponent of FCP X for a lot of reason I don't care to rehash here and now. I've been committed since it's buggy release. The updates (large and small) have been great, but I have to wonder why some things are missing and just was curious what you all think; knowing this isn't based on fact necessarily.

Media management is stellar in FCP X. The speed and stability is great (in my experience). The way the application gets out of my way and lets me focus more on the creative process is fantastic too. I realize that FCP X has and perhaps is rethinking methods long used in editorial as evidenced the app itself, but I can't help but wonder is the strategy to leave so many [what I would call] fundamental features to third party tools.

As amazing as FCP X, I keep looking over at Premiere thinking why don't we have that yet. However, there's not enough I like about Premier Pro to switch. Is it merely Apple's intent is to provide the brain (FCP X) and let the third party developers provide the choice to the masses? Maybe Apple is trying to keep FCP X trim and slim because of their relentless pursuit of making their apps (and hardware) energy efficient; a topic seldom discussed with regard to what we do and the Apple hardware we all work on. Maybe these concerns Apple's R&D has found not to really be much of a concern for most people.

Here's what I am concerned about:

Built-in batch syncing: Can't do this [still ]like Premiere Pro or DaVinci. PluralEyes, WooWave, DaVinci, and Premiere Pro (via XML) is not a viable option me which I've detailed on the Cow and FCP.co

Better color panel: Lumetri and Color Finale are great. Is it too much to ask for that level of control built in.

Batch Export: Need I explain why this is great

Social media panel: Premiere Pro's version of dealing with social media is an innovation I would expect of Apple and is great.

Better media management: I still prefer FCP 7's media management ins many ways. I am really bothered that there's no dedicated method to deal with duplicate, triplicate clips, etc. when moving between almost identical libraries and events on different volumes. I'd like to also be able to rename clips on import that sticks at the Finder level as well.

Maybe I am missing Apple's philosophy about FCP X. Perhaps if I had that understanding I'd be more forgiving. Though as much as I like choice, at this juncture I am growing tired of having to look to third party tools for seemingly fundamental processes of [this] digital age; maybe excluding the social media panel to the extent Adobe has implemented theirs.

I didn't think at least some of those would be too much to ask for at this point, but until then the toolset is:

My opinion is if Apple and it's tools aren't aligning for you, then perhaps it's time to rethink and look at the tools that are.

Or, use the right tool for the right job, and that involves many tools. As hard as Adobe is trying, it's not a one stop shop. After Effects relies on a really strong third party eco system to fill out creative workflows, as does Premiere.

[Tangier Clarke]"Built-in batch syncing: "

I don't know what your workflow is, and I know I have helped you with this before, but currently there is no batch syncing in FCPX, and never has been. And while Batch syncing clips doesn't work in FCPX in the sense that you get new sync'd clips, you can make one long sync clip by selecting all the video and all the audio you want to sync, and making a sync map clip. You'd have to break down that sync clip with keywords, but it would work. You could even go further by opening the synchronized clip, and compound clipping the sync'd clips out of the sync map. This will take work, but it saves you money on third party.

[Tangier Clarke]"Better media management: I still prefer FCP 7's media management ins many ways. I am really bothered that there's no dedicated method to deal with duplicate, triplicate clips, etc. when moving between almost identical libraries and events on different volumes. I'd like to also be able to rename clips on import that sticks at the Finder level as well."

I would imagine this is a workflow issue. If you swap full Libraries, there are no dupes, if you start adding pieces and parts, things will duplicate as it's the safest method to making sure you don't lose work. Have you tried any XML work in Premiere? If you think FPCX has it bad, wait until you try Premiere.

There isn't going to be one tool that does it all. The FCPX Ecosystem is very strong, and yes it might cost you a little extra in third party tools.

Yes, I've used Premiere. And that's why I don't prefer it over FCP X. Although it has some very nice and wanted features; when they're working and stable.

Thanks for the reply though. One tool I forgot to mention that comes in handy is using Decimus Synk between libraries. I use that sometimes. I realize one tool won't do it all. I just thought these perhaps weren't unreasonable.

At the end of the day FCP X still lets me get through my work very efficiently and my boss has seen a complete positive difference in what we can achieve with the same time and resources going from FCP 7 a while ago.

BTW - is it my impression or did we lose some of the custom masking functions that were in the previous version? I now only see a separate Draw Mask effect, instead of it being built into the inspector.

Re: FCP X features or lack thereof. Your opinion on the rationale.by John Young on Nov 5, 2016 at 1:47:50 am

[Oliver Peters]"BTW - is it my impression or did we lose some of the custom masking functions that were in the previous version? I now only see a separate Draw Mask effect, instead of it being built into the inspector.
"

I think you're thinking of Premiere. As far as I remember, the only masks in the inspector (shape mask and color mask) are for color effects.

No, every effect in 10.3 has built in mask functuon (like Premiere) and has since 10.2.something.

_______________________________________________________________________
http://BretFX.com Up to 60% off all plugins through 11/6!

Re: FCP X features or lack thereof. Your opinion on the rationale.by John Young on Nov 5, 2016 at 1:32:59 pm

Ah, right you are. I didn't realize that because pretty much the only effect I use it on in Premiere is Opacity (not an effect technically). And the masks aren't available for that in FCPX. You can add the Draw Mask in FCPX to get the same thing. I wouldn't mind the mask being right there in the inspector, just like I wouldn't mind Crop being in the PP effects controls.

Speaking of relinking (my comment upstream), I went to move a Library + media from one hard drive to another overnight. Then relink everything today. The only change was the volume name. All relative paths stayed the same. Media external to the Library. The relinking process is embarrassingly long and slow compared with Adobe. You have no option to pick the first match to give FCPX a head start. This was only a few hundred clips and I'm on one of the faster set-ups available (8-core nMP w/Promise2 RAID). That's got to be improved.

[Jeremy Garchow]"Just choose the drive or the entire encompassing folder, couldn't be easier."

That's what I do and it is insanely slow compared with Premiere. Within the encompassing folder will be numerous subfolders - especially in the case of cameras like the C300. FCPX has to first search through all of those folders to find the right match. Takes a lot longer than it should if you have hundreds of files.

No benefits that I can see. I recently upgraded my own two machines - a 2010 tower and a 2015 MBP. The newer machine has been fine. The tower has been largely fine, but a number of functions are slower. No issues related to editing though.

No idea how fast PPro is, but I recently had to reconnect over 800 clips of a library and that took maybe 20 secs at best. And yes, with various subfolders, including a bunch of those convoluted RED folders.

[Robin S. Kurz]"[Tangier Clarke] "Is it merely Apple's intent is to provide the brain (FCP X) and let the third party developers provide the choice to the masses? "

Yepp. And that's a brilliant strategy, too, imho."

I agree. I'd like to see even more of it. There are only a handful of core features that cover most editing scenarios, so they invested their energy exactly where they should have: organization, interface, and the heart of "the experience".

After the NAB presentation in 2011, and before we got the release, I speculated about -- AND HOPED FOR -- a scenario where Apple did virtually nothing BUT the core. I imagined -- AND HOPED FOR -- being able to buy something like a codec pack from the camera manufacturer as an in-app purchase. Why wait for Apple to build in support for the 99K Ginormo camera some time in the next year...or more...when Ginormo has that codec ready TODAY, and could supply it INSTANTLY...if Apple had a structure that allowed it.

In fact, long after the release, I've continued to advocate for even more of this than is out there....but I'm really glad that they've stuck to this basic strategy. Keep the heart of the experience lean, mean, and fast, and let third-party developers provide functions that look like niches to the world at large, but are life-and-death within our niche. Leave that development in the hands of people for whom it's their whole world, and it will inevitably work better than what ANY host developer (not just Apple) could ever hope for.

The irony is that when host developers half-ass some feature or another that sort-of covers some of the features in a third-party plug-in or helper app, it can sometimes be enough to kill that much, much better alternative. The third-party developer's opportunity to monetize their efforts can become so choked off that they have to walk away from growing the product.

So it's critical for the development of core features for THIS market that Apple NOT be the ones developing those features!

Again, no criticism of Apple implied. It's true for ALL host developers. Build robust platforms for third parties, then leave them alone to do their jobs.

After Effects is one product that got this right in spades: an incredibly robust plug-in architecture, plus scripting, expressions, and other tools to easily enable custom functions that maybe only a handful of people in the whole world might need, but they do need.

Speaking of which, the After Effects Expressions forum has been one of our top 10 since we opened it. Depending on what's happening in the world, it can slip into the top 5. Don't for a minute underestimate the importance of this.

To put it another way, one of the most critical core features of After Effects is its extensibility for other people to go beyond its core features!

(As a former developer of third-party effects when I was at Boris FX, for whom I DO NOT speak on this count, the one area where I'm most underwhelmed is with X's support for a third-party effects architecture. The Noise Industries/FX Factory ecosystem certainly does a remarkable job with this...but I sat across from Gabriele de Simone at Boris FX when he was developing what became FX Factory...and I moved into his much nicer office when he left to go solo LOL...and I'm telling you that he was doing even more in his development tools over a dozen years ago than Apple's plug-in architecture allows today.

Likewise, not speaking for Gabe either of course...but as still a somewhat interested observer, this is one area where I feel that Apple is well behind the rest of the industry, and would have a fairly easy time jumping way ahead if they wanted to -- not building these features themselves, but building better hooks.)

Admittedly, Adobe is playing a different game than Apple, and its understanding of "core features" and "target markets" is inevitably vastly vaster. All the more remarkable, though, that as massive as their "core" feature sets become, Adobe is still deeply committed to third parties.

Which, coming back around, should not be taken as a criticism of today's Apple in general, or FCPX in particular. Apple was once justifiably famous for eating its young. Steve resented anyone making money from Apple that Apple wasn't getting a slice of in return (user groups and sites like ours included), and Apple famously bought and let atrophy a significant handful of products and technologies that our entire market would have benefited from Apple just keeping their hands off.

So it heartens me that this appears to be holding up as Apple's modus operandus for FCPX. I still want more. I want scripting, I want in-app codec packs, more robust effects hooks, and the like, blooming like a thousand flowers.

[Tim Wilson] " I still want more. I want scripting, I want in-app codec packs, more robust effects hooks, and the like, blooming like a thousand flowers."

But the rub is - what is core? I have been totally happy both with NLEs and DAWs to have third party developers handle the FX plugins. I consider core functionality to also support established industry standard interchange for collaborative workflows.

Apple have gone part of the way with xml although any hope that there could be a standard in xml seems impossible. In other areas standards have been agreed to like AAF, OMF AES-31, EDL etc. These standards may be legacy but they are still in use and a part of established workflows. I don't think it is advantageous to leave all that to third party developers as these are critical to stable commercial workflows.

Every time a new version of OS or NLE software comes out there can be a lag getting new bugs ironed out. There are suddenly many developers that need to react. I know the people behind AATranslator are constantly chasing such variables and I have long said that bog standard legacy interchange like OMF and dear old EDL are stable and reliable fall backs during times of software change. If they are core then they still work. If interchange is possible only via a new variant of fcpxml (currently in its 6th iteration) then it breaks all interchange.

Sure not everyone agrees with this definition and so the debate goes on.

[Michael Gissing]"In other areas standards have been agreed to like AAF, OMF AES-31, EDL etc"

Sure there are clearly defined standards for AES-31 and even for some EDL 'flavours' but that doesn't mean that everyone fully supports or adheres to those standards and as far as AAF and OMF goes the word 'standard' should never be used in the same sentence.

The [unnecessary] complexity of OMF, AAF (and MXF) make them a "Use at your own risk format." Although there are other formats that can be in the same category, these three are the worst. They are self proclaimed standards that never should have been created. Although the container format is always a standard, the methods of describing data within the container are not. They each have multiple ways of describing the same thing and since everyone has a slightly different way of doing things within the containers, they might as well not exist at all. To call it any kind of standard really is a stretch. OMF is literally a format within a container format. AAF and MXF are much worse because they are a format within a container within a structured storage format.

Anyway, I thing you get the idea of what I think of those formats as far as 'standards' go ;-)

[Michael Rooney]"To call it any kind of standard really is a stretch."

We'll take that for granted. LOL Thanks for your help in any case. 😀

[Michael Gissing]"If interchange is possible only via a new variant of fcpxml (currently in its 6th iteration) then it breaks all interchange."

Exactly the reason Apple should be out of the XML business. The less they touch, the better.

Thank the Godz (at least in their 1966-1973 iteration; pictured below) that QuickTime is less important over time. It was a running, not very funny joke that every time Apple used to update QuickTime, it would break FCP. Same for iTunes for that matter. New iTunes = busted FCP.

Not to overly pick on Apple. Many of the issues I describe here are endemic to many, if not most, host application developers. But this is a thread about FCPX features or the lack thereof, and my whole-hearted support for Apple developing less, and actively nourishing a third-party ecosystem to do more.

[Michael Gissing]" AAF, OMF AES-31, EDL etc. These standards may be legacy but they are still in use and a part of established workflows. "

The key to interop has been unchanged since Hippocrates: "First, do no harm." Even if it's not your standard, don't break it. Needless to say, this is all too rarely the case, and not just for Apple. Jay-z Louise, how often does a render blow out something as basic as timecode? Way too often, in every host, when it should happen NEVER.

So to be honest, the last thing ANY developer should have to worry about is keeping up with EDL or OMF support or whatever -- unless the host developer (Apple or anyone else) decides to get out of the way and neither support it nor try to replace it. That remains to me the best possible scenario.

[Michael Gissing]"Every time a new version of OS or NLE software comes out there can be a lag getting new bugs ironed out."

That's MORE true for host developers than third parties. BY FAR. Why? Because you know how many people at the host developer have time to give a crap as the main part of their job? FAR FEWER than at the third party!!!

See also my previous example of Apple Legacy breaking FCP Legacy with every new QT and iTunes release. Really, the only thing that anybody needs to know about FCPX is that this doesn't happen anymore. Sold! LOL

(Or does it and I've just missed those posts? In which case, just add it to the list of things I'm wrong about.)

In fairness to host developers, you can't just be throwing out releases willy-nilly, not even patch updates. For one, you have to create an installer and test the ever-loving shit out of it, which is insanely more work than you think.

I thought I had a pretty good idea of what this meant from being involved in release engineering at a plug-in developer, but when I got to Avid, holy cow, I had NO IDEA what was involved in developing a host-app installer. Beyond engineering, release engineering, and QA, the simplest of patches reverberates up and down every part of the company: documentation, sales, the web team, marketing, legal, on and on.

All of which implies that "not breaking third party plug-ins" is a priority, which, guess what.

OR [host developer name here] could just skip the whole megillah, let the third-party do the thing, and if there's a problem, the third-party is responsible for cleaning up...which they routinely do, often within hours of a bug report....which typically have more to do with something the host developer broke without even noticing, because host developers inevitably lack the development or QA resources to track all this.

Codecs really are a bigger deal than any kind of vfx. Think about how many codecs you've been waiting around for hosts to support over the years. It's insane. All any host would have to do to fix this is open the door and say, "Anybody out there got a better renderer than ours? Raise your hand."

That's one thing 3D developers get right for sure. Rendering is a function that CAN be farmed out, and IS farmed out. If FCPX would just hand off the rendering of camera codecs, you'd never have to wait again, EVER. The day you could buy a camera, you could use the codec.

Why not? Because host developers insist on standing in the way. It's been proven for generations (software-ly speaking) that other people can produce higher quality renders than the best hosts -- LET THEM.

ProRes is sort of a workaround of course, as was Avid DNxHD when it was released four years earlier. But they're both still bound by things like frame size, frame rate, definitions of what a frame MEANS, all that kind of thing, and annoying for files recorded in formats that ProRes doesn't support yet. Yet.

So the core function as defined today is, "We're the only ones who can render. You'll have to wait for us to support it, but our QA team is so small and so narrowly focused, that we may get to it, and we may not. And if you find a bug that we missed, you'll have to wait xxxx months before you can get the fix...even though the third-party camera or plug-in developer fixed it for us in 24 hours."

The core function as I'd LIKE to define it is "build hooks for render engines" -- which is well-established engineering -- and offer options for third-party codec management. Let the codec be 100% supported the day the camera is released, not because Apple has had to take their off the ball and rush out a new release to support the six maniacs who need that codec on Day One, but because the manufacturer has kept their eye on the ball, been test-rendering all along, and knows that their codec is render-ready on Day One.

Look, you may think codecs are a terrible example because ProRes has been handed down by The Godz (1966-1973 incarnation) and needs no improvement, and it is the duty of all mortals to bow down to The Godz (which I actually kind of agree with, vis a vis The Godz themselves anyway)...

....but the point is, I want every host developer asking themselves, every time, what's the LEAST we can do ourselves? What's the MOST we can do to support our third-party partners who are doing better work in these areas than we ever will?

Interop is a great example. How many DAWs in various configs do you reckon Apple has laying around for testing? The number is likely in the neighborhood of the number of people on the FCPX team who use DAWs enough to know what life-saving interop looks like.

No offense intended. Merely speculating. Nevertheless, Apple's never going to do as good a job as X2Pro or AATranslator or any other third party. Their time is better spent doing almost anything else.

[Michael Gissing]"I know the people behind AATranslator are constantly chasing such variables"

Of course they are, but that's life as a third-party developer. When I was at Boris, we supported 24 different host applications, and every one of them had different architectures, in some cases wildly so. I know Boris has added more hosts since then.

The thing is, you know how many people at [host developer name here] are keeping up with this kind of thing as their one and only job? Your guess is as good as mine, but it ain't many. Maybe none.

Which is why Michael, Simon Ubsdell, Boris, the X2Pro folks, and all of the many third-party developers who stand in the breach to meet needs that are no less life-and-death to me just because they're life and death only to me, are GODZ.

Which is why they should all wear their hair and dress exactly like The Godz. That would be awesome.

[Tim Wilson]"Exactly the reason Apple should be out of the XML business. The less they touch, the better.
"

Maybe I misunderstanding you here, but if Apple doesn't give you a way out, how do you get out?

FCPXML in fairly short order, was a stable interchange format. And now on it's 6th update (v1.6) you can drag and drop XMLs in and out of the application. So I can drag something from KeyFlow Pro, for example, and have it update FCPX. I can drag a Project from FCPX in to X2Pro and create an AAF. So, pretending I didn't know anything about FCPXML, how could this be done if Apple didn't create the language and capability to perform these tasks?

[Michael Gissing]"Apple have gone part of the way with xml although any hope that there could be a standard in xml seems impossible."

You do know what the "X" stands for and why that is exactly the whole point, right?

[Michael Gissing]"In other areas standards have been agreed to like AAF, OMF AES-31, EDL etc."

Okay, now that's an apples and oranges comparison if I've ever seen one. Those are not only completely inflexible (i.e. not extensible beyond what information they already support), but therefore painfully limited exchange formats — some not having changed since the 80's or 90's. XML is not only 100% open, it also has any and everything covered that all of them combined have covered… plus a few hundred percent of other things on top, with the support growing with each new version. So why in the world would I ever consider any of them when given the choice?? That makes no sense to me, sorry. For purely nostalgic reasons?

[Michael Gissing]"I don't think it is advantageous to leave all that to third party developers as these are critical to stable commercial workflows. "

So which of the relevant 3rd party tools or their workflows could in any way be considered "unstable", have ever been, or are sure to have been more "stable" if Apple were the ones updating them instead? For you having to wait three months instead of maybe three days or even weeks for a critical update to just that particular functionality is more advantageous? Right.

[Michael Gissing]"There are suddenly many developers that need to react."

Which they did… a mere day after the update came out, if not the same day. Never mind that beyond that they can react exponentially faster and more often than Apple to address any specific issues there might be with any particular tool or function, within which the brilliance lies. The Intelligent Assistance to Apple update ratio alone is an easy 10:1. Therefore, if you consider these matters "critical to stable commercial workflows", then you're in fact unwillingly making my exact point.

And how is that in any way different than if PPro, Avid or who ever else updates their (completely closed, proprietary) file format btw? And exactly which 3rd party app do you know of that can open e.g. a PPro or Avid project WITHOUT potentially losing the vast majority of information (e.g. filters, titles etc. etc.) in the process? Ever compare an FCP X roundtrip to Resolve to any of the above?? You should.

[Michael Gissing]"OMF and dear old EDL are stable and reliable fall backs"

:-)))) Right.
Again… if you're willing to potentially lose 50+% of what makes up your project, sure. Good luck with that.

[Michael Gissing]"If interchange is possible only via a new variant of fcpxml"

Only it's not, sorry. You can export in the current AND the last (way over a year old) version of FCPXML. As always. No problem. Which is why I'd say the whole thing is a complete non-issue. Unless you can tell me how to get to and from any other NLE at anywhere near the level of reliability than you can with X via (even the old) FCPXML? Or is the fact that others choose to only support (if even) the old XMEML but (surprise surprise) not FCPXML and don't even have their own exchange format, somehow much better/smarter/more developer friendly, I'm just not seeing it? Something that would make the exchange with FCP X and various other apps that support it that much easier, cleaner and smoother btw (i.e. actually useful). But e.g. Adobe is apparently as interested in that as they are in fixing long standing bugs, from what I'm hearing.

Oh yeah… having to rent your entire workflow from them, not just the editing part to actually get things done (since you lose most everything trying to go elsewhere), means more money in their pocket. Silly me.

What's Apple making off using an open XML and not a limited, proprietary file format? Oh, right… 😏

Thanks for the reminder Robin. I forgot one of the most important reasons to have standard file transfer protocols built in.

Rarely do I find editors who truly understand collaborative workflows and so when it comes time to hand over I find this incredulity that the editor should be responsible to hand over exactly what the post facility needs to effectively and efficiently do the finishing work.

X seems to be the most limited NLE in terms of being able to output formats that sound post in particular want. Luckily for me I get very few projects from X but almost every time there is this question of why does the editor have to buy third party software for the very occasional job of exporting interchange formats, particularly AAF/ OMF for audio.

So that's why it would be so much better to have these built into the NLE like everyone else. It is just a PITA to have to explain to X editors why they must be able to provide industry standard interchange. So rather than lecture me about why I don't need something, accept that I do know what I want and why I want it.

[Michael Gissing]"X seems to be the most limited NLE in terms of being able to output formats that sound post in particular want. Luckily for me I get very few projects from X but almost every time there is this question of why does the editor have to buy third party software for the very occasional job of exporting interchange formats, particularly AAF/ OMF for audio."

By this logic, you'd never have to buy any third party utility to help out with any workflow or creative capability (like a plugin) because every program would have exactly what you need built in? If your DAW doesn't have a certain effect or filter, you are going to trash it and find a DAW that does have that filter built in even though the rest of the DAW doesn't fit your needs creatively?

And why doesn't every DAW support the open and free to use fcpmxl, or provide a free translation tool?

[Jeremy Garchow]"And why doesn't every DAW support the open and free to use fcpmxl, or provide a free translation tool?"

Exactly. As far as I can see, Apple has in fact done their homework and even continue to do so. So how is it asking too much to now have others do their's (many of which are and don't seem to have a problem with it)?? That's the "standard" logic I'm having a really hard time following. But then I guess some people would have thought it a much better idea to "standardize" FCPXML 1.0 and leave it at that?

Especially since it's funny how e.g. Adobe has found time to fiddle with (as in change) the XMEML they export several times, but never found any time to simply support FCPXML. Even AFTER they bought Automatic Duck who were already doing it! Meanwhile FREE software such as Resolve support the new FCPXML the day after it is released.

[Michael Gissing]"when it comes time to hand over I find this incredulity that the editor should be responsible to hand over exactly what the post facility needs to effectively and efficiently do the finishing work."

So remind me… when, how and where do I not have that ability with FCP X again? Be it via XML or with 3rd party apps? I'm very curious.

[Michael Gissing]"X seems to be the most limited NLE in terms of being able to output formats that sound post in particular want."

I'm sorry… which would those be again?

[Michael Gissing]"why does the editor have to buy third party software for the very occasional job of exporting interchange formats, particularly AAF/ OMF for audio."

Funny. Because I am constantly asking myself why other editors feel they have to rent their own work and pay continuous ransom money just to continue to be able to access it. Literally thousands more. Just one of life's mysteries I guess. 😏 Somehow I'm not bothered by having to pay 10 bucks more, maybe even 100 here and there (as in one time expense)… or not. My choice. That's assuming I actually ever need to feed to a ridiculously inferior format from the 80's for some ungodly reason. Which I fortunately never have had to (since the people asking didn't even grasp that they could just as well take an XML and get MUCH better results). Horses for courses I spose.

I like my license "built-in" and paying much less for it. But I guess that's just me.

[Michael Gissing]"accept that I do know what I want and why I want it."

And I can't think of a single thing that FCP i.e. XML can't give you. But hey, if the "built-in" aspect is so utterly essential to you and not just a (rather worn) talking point, you're free to pay thousands to get it elsewhere, no? I for one know which I prefer. To each his own.

[Darren Roark]"If it's built in to the app and therefore seldom updated it must be more professional. "

😄

Another reason I'm glad none of that ancient, painfully limited, proprietary nonsense is built-in? Because that forces the one or other person/developer to finally get off it and demand others do, too! To actually claim anyone actually needs EDL with a straight face just boggles my mind, sorry. No, no one needs EDL, but everyone needs to kill EDL and others for the useless, vastly inferior exchange format of yestercentury that they are. Or is anyone actually going to claim that there is any reason EDLs of all things are still used other than laziness, complacency or even just plain spite? DAWs would even have by far the least work supporting XML, since none of the vastly more complex video attributes and information is of any interest to them. So yeah… what's their excuse if not the aforementioned? Or make a side-car app for your DAW like Marquis Broadcast has, sell it for less and even make a buck off it!

And yes — staying with Apple — just as I greet the fact that the iPhone does not have a headphone jack and the new MBP doesn't have PCIMCIA or an SD slot or Firewire or USB 3. That, for me, is what is called forward thinking progress, whether someone want to call me a "fanboi!!1!" for it (or for lack of any real arguments) or not. 😏

[Robin S. Kurz]"Another reason I'm glad none of that ancient, painfully limited, proprietary nonsense is built-in? Because that forces the one or other person/developer to finally get off it and demand others do, too! To actually claim anyone actually needs EDL with a straight face just boggles my mind, sorry. No, no one needs EDL, but everyone needs to kill EDL"

I wasn't aware that it was still needed anywhere! As you say, why on earth would any DAW still need one!

[Steve Connor]"As you say, why on earth would any DAW still need one!"

A DAW in fact being the one needing it the least by far. I don't actually even know of one that supports the use of them (are there any??). EDLs are entirely useless when it comes to audio, i.e. even more so than they are for video.

The SOP at many high-end color grading facilities in LA is to require EDLs. Not XML, AAF, etc. The reason is that they are using Linux-based systems and parse the EDLs into what they need. They also will not accept anything that requires speed changes, mixed frame rates, etc.

[Darren Roark] "Just because something is a standard operating procedure doesn't make it right."

And that in a nutshell is why I want editors to own tools that (for whatever crazy reason to them) allows them to deliver what the next facility down the chain actually wants. When I am grading or mixing I am not going to dictate to the director what is right or wrong in their film. I try to give them what they want with value added. If you think post facilities are wrong then you just aren't doing your job.

I really don't need to explain why OMFs are sometimes better than AAFs or why fcpxml is not a supported format in my DAW when it does AAF,OMF AES-31 and gosh yes EDLs. Sometimes I need everything. XML relinking is always an adventure and if I say I need an EDL to drop into a text editor so I can do a quick find on a file name when I am on the phone to the edit room to tell them which files are missing from the drive then bloody well should give me an EDL. So stop wasting my time by telling me what limited tools that suit you are always enough. I get that you and Robin don't get it. I'm used to working with editors that at least accept that I might just know what I need.

[Michael Gissing]"So stop wasting my time by telling me what limited tools that suit you are always enough. I get that you and Robin don't get it. I'm used to working with editors that at least accept that I might just know what I need."

I'm more of a post sup at this point, more assisting/finishing work than feature editing. For my clients I try and remove as many time/labor consuming redundant tasks as possible.

I do turn over an end product that is agreed upon, sometimes it has to be negotiated as you are right, no two places are 100% alike. Talent should always take priority over the tools.

I am able to offer to the colorists who are finishing in Resolve is a fully conformed drp project file in lieu of having to perform a cumbersome and time consuming EDL conform.

If they are using Resolve and it works as promised, there should be no issue in accepting that as providing the end result should be welcomed.

I also turn over an EDL via the 3rd party app (and Resolve) as many distribution companies require it in the deliverables.

On a $2mil and under budgeted film the two things always in short supply are time and money. Since they can rarely raise more money I've been able to buy extra creative edit time for the director because of saving time in finishing without causing an end rush.

Most places require several days to a week for conform and ingest time. I provide a fast RAID drive that they can media manage to their shared storage system with all the media linked and online in Resolve or if they choose they can work directly from the drive.

As far as DAW turnovers go, a recent feature I sent an AAF to a sound designer who works on Walking Dead, he said it was one of the best turnovers he has ever received and he has been in the business since the early 80s.

Each character's lav had a bed of tracks, everything was laid out in advance and there was no conform of the ISOs to do. All I said was I wish I could have taken the credit for that but it's just how it comes out when the show is prepped properly and the location audio person is on the ball.

[Michael Gissing]"If you think post facilities are wrong then you just aren't doing your job."

I don't think post facilities are always wrong, having worked at enough of them the reality is the client makes a promise and then hands off a nightmare so they need to CTA. What I take issue with is them charging for conform services I do not want to hire them for.

So to clarify, I do provide all the requested turnovers.

I just don't want my clients to spend the extra time and money when it isn't necessary to use archaic formats.

[Darren Roark] "So to clarify, I do provide all the requested turnovers."

Apologies. My comments were misdirected. They probably only applied to Robin.

I find the majority of editors are absolutely professional and work hard to get handovers right. I am turning over mostly sub $400,000 broadcast docos where a day of mucking around a handover is a catastrophe.

[Michael Gissing]"I am turning over mostly sub $400,000 broadcast docos where a day of mucking around a handover is a catastrophe."

Every doc has it's own set of variables don't they?

Ideally if it's a new to me vendor I try and offer a dress rehearsal turnover a couple weeks before their deadline that buys some time padding at the end when everything inevitably changes last minute.

The spanner that gets thrown in the works are the many places jumping the Blackmagic pirate ship to other color systems because they can charge more for them.

What is becoming a standard here is these places keep a Resolve system for conforming regardless of what NLE the show was cut in, then they send a FCP 7 XML from there to Baselight, Pablo or Lustre so all the FCP X timeline advantages in Resolve with mixed framerates becomes a moot point.

[Darren Roark]"The spanner that gets thrown in the works are the many places jumping the Blackmagic pirate ship to other color systems because they can charge more for them. What is becoming a standard here is these places keep a Resolve system for conforming regardless of what NLE the show was cut in, then they send a FCP 7 XML from there to Baselight, Pablo or Lustre so all the FCP X timeline advantages in Resolve with mixed framerates becomes a moot point."

Surely BMD pushing Resolve down-market factors in, but even if that's the prime motivation for people to look at other color systems, I think that's a good thing. Each system has its own approach and design philosophy, its own strengths and weaknesses -- and a diverse, vibrant color ecosystem beats a Resolve monoculture in my book.

When you want to cut with FCPX instead of the "standard" Premiere Pro or Media Composer, you have good reasons other than "it costs less," right? What if the colorist wants to grade with Baselight or Nucoda or Mistika instead of the "standard" Resolve? I can see why a colorist would want to prioritize the grading toolset over the conform toolset. Sometimes letting the creative talent work with their favorite tool is the best call.

To bring this vaguely back to topic, interchange exists to make this possible. Apple's FCPXML interchange is a mixed bag, simultaneously brilliant and egotistical. On the one hand, it's modern, extensible and admirably complete; on the other, it's new(ish) and requires the rest of the world to adapt to it rather fitting in with all the pre-existing infrastructure.

[Walter Soyka]"When you want to cut with FCPX instead of the "standard" Premiere Pro or Media Composer, you have good reasons other than "it costs less," right?"

It allows many tedious tasks to be automated, you can easily use production audio, faster outputs, and when the editor knows it the ones I work with all say something similar, they can work as fast as they can think.

Costing less and efficiency.

[Walter Soyka]"Each system has its own approach and design philosophy, its own strengths and weaknesses -- and a diverse, vibrant color ecosystem beats a Resolve monoculture in my book."

Absolutely. It's when I run into places here in LA who use Resolve for TV work and use one of the other more fussy systems for features in the same rooms with the same colorist and refuse to budge, it can get irritating. (This is usually due to the insistence of grading DPX on features as opposed to camera native because of 'proprietary color science'.)

Considering the movies I work on have about the same budget as an episode of network scripted TV, it gets a bit silly.

[Walter Soyka]"Apple's FCPXML interchange is a mixed bag, simultaneously brilliant and egotistical. On the one hand, it's modern, extensible and admirably complete; on the other, it's new(ish) and requires the rest of the world to adapt to it rather fitting in with all the pre-existing infrastructure."

I have turned over a few features where the finishing vendor had no idea it was cut in FCP X. I actually try and avoid that subject if possible. If they want an EDL or FCP 7 XML I can give them that.

I just don't want to pay facility fees and spend the time for using them if they aren't absolutely necessary.

[Michael Gissing]"I find the majority of editors are absolutely professional and work hard to get handovers right. I am turning over mostly sub $400,000 broadcast docos where a day of mucking around a handover is a catastrophe."

But this goes the other way too. If I get back something that I didn't give you, I then have to muck around for a day getting it all back together.

The problem I have with EDLs is that they don't describe everything that is going in the timeline. By the time projects get to you, the colorist or sound designer, it has been months and months of toil, changes, experiments, and collaboration. An EDL completely blows all of that up. When things were on physical reels, and you need to grab them from a specific place, sure, but now with everything that we have at our disposal, including a lot of things that can be done in the NLE and not in a specialized environment in terms of effects and composites, an EDL does not represent my final thoughts, decisions, and months of work.

An FCPXML gets really really close.

I too, like Darren's folks, use Resolve to conform. I can make almost any piece of interchange from it, if that's what is required. Most of the projects I work on get graded in Baselight, so it's possible to go from FCPX to whatever you want if you have the right tools. Resolve uses fcpxml, and despite some frame size hiccups, the speed changes, even multiple speed changes within a clip, round trip seamlessly. There must be something within fcpxml that allows this as xml isn't as good, and EDL is a joke. So why do I have to stick with EDL that won't help me, or the finisher, see my intentions in the timeline?

[Jeremy Garchow]"By the time projects get to you, the colorist or sound designer, it has been months and months of toil, changes, experiments, and collaboration. An EDL completely blows all of that up."

My point exactly. Thank you.

Anyone that actually insists they need EDLs or actually think they are somehow a good idea let alone the best choice in any case in today's digital workflow, has, at minimum, little to no respect for their own work imho (or just edits really boring stuff 😄). Everyone else should do their best to get any and everyone they know off the harebrained idea of supporting it's use any day longer, just "because".

Sometimes there are keyframes missing or out of place. Some text doesn't translate (formatting/etc) but that's not surprising. Pretty minor stuff, really. For the most part, everything is there and more accurate than xmeml.

Resolve has some weird bug where if there's a variable speed change on the clip, it puts it in a compound clip that can't be decomposed.

This effects me if I am editing 4k in 1080 timeline, those conformed clips render 1080 from Resolve, when they should be 4k. What's weird is that Resolve lists all he clips as 4k, even the compound clip, but it will render it at 1080. You can't copy/paste the variable speed change in Resolve, so you have to rebuild all those changes by hand, which is cumbersome when there's a lot of them and everything is shot at 2500fps. :)

[Jeremy Garchow] "By the time projects get to you, the colorist or sound designer, it has been months and months of toil, changes, experiments, and collaboration. An EDL completely blows all of that up."

Which is why it is just an additional tool that is sometimes the simplest way to find missing media. I never use an EDL to import a project unless nothing else works which is extremely rare. But it is an easy and simple list. Why do I sometimes want it? Because I still have a great tool called Shotlister that takes an EDL and displays it graphically. It ends up looking like an old dubbing chart. There are heaps of ways I can display timecode and reel information like relative and absolute offset which helps enormously when reversioning doco cut downs. Yes there are other tools but Shotlister has some amazing ways to globally adjust a timecode offset specific to a reel, handy when reconforming polywav audio where there is an offset between the code the editor has been working with on the camera sound and the iso recorded wavs which is extremely common.

I am not saying that EDLs should be used as the principal form of interchange but that interchange mix is sometimes necessary. And I know full well that using third party software that X can provide all those options. So I'll say it again. My opinion which I am perfectly happy for you to just accept and not try to lecture me on is that interchange formats are core to NLE software.

The fact that it isn't with X causes issues with some editors refusing to buy the third party software. Simple valid reason to argue my point. I really only care about getting the maximum time to do creative work and the minimum time coaching recalcitrant editors who think they know better.

[Jeremy Garchow] "But this goes the other way too. If I get back something that I didn't give you, I then have to muck around for a day getting it all back together."

Which is why I always try to get the project in and out via the best means which is the xml/AAF. I get annoyed when speed, framing, flops etc etc do not translate. X is annoying in that any third party plugin that is used in the timeline causes the fcpxml to import into Resolve as a compound clip which as you know is a pain to decompose if it has speed change information. Hopefully Resolve will work out a way to do an optional smart decompose on import.

Increasingly however I am finishing in Resolve so I am not outputting back to an NLE. So the issue of disappearing keyframes or speed/sizing info is not an issue. By far the most annoying thing in all this is text because I am doing docos. Increasingly the best procedure now seems to be creating all text as tiff or png with alpha rather than translating text generators which never works. I had a doco with hundreds of subtitles recently using a proprietary plugin in Avid. I spent far too much time trying to find software to translate the subtitles into anything - Premiere, Resolve, FCP7 but nothing worked. In the end the editor who was thousands of miles away emailed an EDL of the subtitle track and a text document with all the subtitles in order which was trivial to do with Avid as all that was built in. You see sometime the editor doesn't own the gear and can't go and buy third party plugins to solve problems like this. I was able to run the EDL and copy paste the text in in a few hours after wasting more than a day searching for alternatives to the uber simple EDL to give me the 'placeholder' events.

So in short EDL is the ultimate fall back that almost always works but is the last resort. That's it in a nutshell.

[Michael Gissing]"Hopefully Resolve will work out a way to do an optional smart decompose on import."

I would imagine this is a Resolve issue as reimporting the same XML back into any other system does not produce a nested (or compound) clip. Blackmagic have definitely written weird fcpxml in the past, including xmls that would only work on the originating host machine.

For text, I always send an alpha channel movie the length of the timeline. It's so easy and effortless to export a text only movie from FCPX, and the movie is small as there's not a lot of information in it.

But yes, hours of EDL copy-pasta works too.

For FCPX, there's donation-ware for subtitles that also makes life easier than EDL:

[Michael Gissing]"with hundreds of subtitles recently using a proprietary plugin in Avid."

Wait. So you paid for an additional, non-standard tool to allow for additional functionality that you needed??! And then you're here and… oh never mind… 🙄

[Michael Gissing]"I was able to run the EDL and copy paste the text in in a few hours after wasting more than a day searching for alternatives to the uber simple EDL to give me the 'placeholder' events."

Wow. Now I know why you were talking about "mucking around for a day". That being the most "mucking" variation of an otherwise simple task, apparently born out of further ignorance (that you accuse me of) I guess. Because I don't know about the other NLEs, but with X you could of had that 100% for free (or a small payment for an even better result) and within minutes with a few clicks and XML ex- and imports e.g. via SRT. But clearly there is little point in explaining how, seeing how you are so convinced that EDL is somehow an uber brilliant, helpful solution no matter what.

[Michael Gissing]"You see sometime the editor doesn't own the gear and can't go and buy third party plugins to solve problems like this."

Right. After spending literally thousands on their NLE (other than X of course), it's now asking way too much of them to spend less than $100 on an app to serve in (their) "critical to stable commercial workflows"? Instead it's totally acceptable and sensible to buy something else (how much was it?) that doesn't even do the job.

Now we have truly left the "rationale" part of this thread and (long) entered the absurd imho.

[Robin S. Kurz]"Now we have truly left the "rationale" part of this thread and (long) entered the absurd imho."

The Oxford Dictionary chose "post-truth" for it's word of the year which in our industry has a deeper layer of irony.

It doesn't matter how much your NLE costs or how well it works as long as the company you bought it from does a great job of making you feel like you are continually making the best decision in continuing to use it, facts take a backseat to the feeling of being 'right'.

[Robin Kurz]"Now we have truly left the "rationale" part of this thread and (long) entered the absurd imho."

'Humble' opinion. Yes that is the most absurd thing you've said in this whole thread. I know you don't like anyones opinion if it differs from yours but your counter arguments largely ignore what I say and why. I find arguing with you as pointless as engaging with a bot. Your comments are snide jeering at anyone who dares to challenge your confirmation biases. That is why I have often dismissed your comments as ignorance. Your mind is closed as is this now pointless discussion

[Jeremy Garchow]"There must be something within fcpxml that allows this as xml isn't as good, and EDL is a joke. So why do I have to stick with EDL that won't help me, or the finisher, see my intentions in the timeline?"

I have my suspicions that Resolve has some fcpx tricks in it's timeline when in fcpx mode.

fcpxml has nearly every piece of information from the cut where fcp7 xml is very limited. It's even worse with Adobe's mutated fcp6 xml.

[Darren Roark]"I have my suspicions that Resolve has some fcpx tricks in it's timeline when in fcpx mode. "

Yes, it seems to work really well, despite a few hiccups. Blackmagic has modeled some of the FCPX timeline features, so I imagine that helps with a cleaner translation. Xmeml isn't nearly
as complete, but I sometimes have to use it to get to Adobe stuff. It's not as easy, or fun! :)

[Michael Gissing]"And that in a nutshell is why I want editors to own tools that (for whatever crazy reason to them) allows them to deliver what the next facility down the chain actually wants."

[Michael Gissing]"At times I need xml, OMF, AAF and EDLs"

And again: so?Which of those are you not able to deliver with FCP X i.e. FCPXML literally within seconds? Odd how you've avoided that question over and over. But then… maybe not so much.

So basically all this lamenting is because of a whopping 30 seconds more (if even!) you need for an export? Because sorry if I feel compelled to call complete bs on your "a day of mucking around" hyperbole. Even if that's actually the case, then FCP is most definitely not the spoke in your wheel.

[Michael Gissing]"I get that you and Robin don't get it."

Right. It's most definitely us. :-)))

[Michael Gissing]"if I say I need an EDL to drop into a text editor so I can do a quick find on a file name when I am on the phone to the edit room to tell them which files are missing from the drive then bloody well should give me an EDL."

So you've never heard of the timeline index nor e.g. Producer's Best Friend (not to mention EDL-X). Okay.

[Robin Kurz]"Or is anyone actually going to claim that there is any reason EDLs of all things are still used other than laziness, complacency or even just plain spite?"

Yes. I sometimes want one for none of those reasons. You are just plain ignorant if you can't accept that more than one form of interchange has viable practical uses. At times I need xml, OMF, AAF and EDLs just to sort the mess that some know all editors create. I always want a reference video too or is that too old school?

You might embrace the Apple concept that we all need to be forced off working interchange formats but you do not pay for the workflow consequences of that disruptive attitude. I accept that Apple plays that way and will never build in anything other than fcpxml. Don't expect me to love them for it because it costs me time and I don't charge by time but by the job.