-
FCP X features or lack thereof. Your opinion on the rationale.
-
[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.
– RK
____________________________________________________
Deutsch? Hier gibt es ein umfassendes FCP X Training für dich! -
[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 😉
http://www.aatranslator.com.au
-
[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?
-
[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.
– RK
____________________________________________________
Deutsch? Hier gibt es ein umfassendes FCP X Training für dich!
Reply to this Discussion! Login or Sign Up