-
Where we are: No need for debate
-
[Bill Davis] “I know nothing about Apple’s (or Adobe’s) internal decision making. And I also understand that working with “selected partners” is vastly different than giving everyone the keys to the kingdom, ala “open source” initiatives.”
I’m not talking about the keys to the kingdom — just the tools that first-party developers build specifically to allow third-party developers to improve the first party’s products and add value for the first party, the third parties, and the users.
Nobody loses when an application has strong ecosystem around it — so why not do everything you can to encourage the development of that ecosystem?
[Bill Davis] “It’s essentially an Ars Technica piece on how sometimes, “openness” isn’t always the best and clearest path to excellence. It’s not necessarily on point regarding this particular discussion. But it did expand my thinking on my general view of circumstances where “openness” sometimes has unintended and very negative consequences.”
Bill, thanks for the link. It was an interesting read!
Speaking generally, I think closed platforms versus open platforms are like centrally-planned economies versus free markets: in trying to limit your downside, you also limit your upside. You trade reduced opportunity for reduced volatility. You have the stability of a single designer, but you are confined to the limits of their imagination, interests, and values. You know exactly what you will get, but you place the entire burden for the growth and development of the platform on a single entity.
A walled garden is a lovely place — as long as you’re content to be confined. Like you pointed out, Apple is proving this tradeoff works well for many.
I argue for openness in FCPX in the abstract because it would give third-party developers the flexibility to create solutions that even Apple wouldn’t have considered, and it would let niches be served even if Apple has no interest in them. I argue for openness in FCPX in practical terms because it’s simply necessary for workflows where Apple does not or cannot provide end-to-end solutions.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Walter Soyka] “I argue for openness in FCPX in the abstract because it would give third-party developers the flexibility to create solutions that even Apple wouldn’t have considered, and it would let niches be served even if Apple has no interest in them. I argue for openness in FCPX in practical terms because it’s simply necessary for workflows where Apple does not or cannot provide end-to-end solutions.”
Walter, I’m curious about this comment. How open do you need FCPX to be?
Let’s say FCPXML matures to a robust language, what more would you want? Do you think FCP7 was more open or just had more robust communication? Just curious as to how you think an NLE could be more of an “open platform” without it being an open source project. i.e. By open, do you mean expand its capabilities in it’s own framework?
Jeremy
-
[Jeremy Garchow] “Walter, I’m curious about this comment. How open do you need FCPX to be? Let’s say FCPXML matures to a robust language, what more would you want? Do you think FCP7 was more open or just had more robust communication? Just curious as to how you think an NLE could be more of an “open platform” without it being an open source project. i.e. By open, do you mean expand its capabilities in it’s own framework?”
The value of an interchange standard is governed by the network effect — the more apps can use a specific interchange standard, the more valuable it is.
I do not personally need EDL or XMEML specifically, as some other posters here may — I just need to move an edit across apps and platforms. As the rest of the industry adopts FCPXML (which I think is inevitable), then my interchange problem will go away.
I’d argue that FCP7 was more open in two ways: interchange and plugins.
FCP7 could input an edit from and output an edit to many other systems using existing interchange standards. FCPX, with an entirely new standard, doesn’t (yet) have that same broad support or value bolstered by the network effect.
FCPX plugins are still a mystery. Ideally, I’d like to see both Apple and Adobe adopt OpenFX, which is an open standard for plugin development. I am not holding my breath, though.
Failing that, I’m very worried about the apparent resistance to custom UI for plugins — that’s going to severely limit what developers can accomplish within the app. I hope that is resolved quickly.
I don’t believe that open source would be necessary at all, but broad and deep APIs for development within FCPX to add capabilities beyond image and audio processing could be very interesting. Look at what FoolCut could accomplish with AppleScript — it’s the perfect example of how adding extensibility to an app enables new solutions.
Adding import plugins (for media or data other than FCPXML), asset management outside the event browser, direct access to metadata, keywords, properties, keyframes — the more FCPX features and data exposed by the APIs, the better.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
Awesome thanks for the response. It’s what I thought you might be thinking, but I wanted to be sure.
[Walter Soyka] “I don’t believe that open source would be necessary at all, but broad and deep APIs for development within FCPX to add capabilities beyond image and audio processing could be very interesting. Look at what FoolCut could accomplish with AppleScript — it’s the perfect example of how adding extensibility to an app enables new solutions.”
Actually, it’s more than Applescript I think. Applescript simply triggers the send in this case (meaning when you send things back to FCPX from other apps, you don’t have to import the XML but the script simply triggers an Applescript that opens FCPX, File > Import FCPXML). I don’t think FCPXML is Applesriptable yet, but I’m not 100% sure. I don’t understand the nuts and bolts well enough.
To add another talking point/point of contention, at a recent LAFCPUG meeting, Philip Hodgetts says that Foolcut is doing an end around and using AXEL (private API), which is FCPX’s internal format. Supposedly this a no-no as Apple recommends FCPXML for third parties. This is how they were able to get so much out of the program without the new XML language. Again, I don’t understand enough about it to speak fluently. Video:
https://youtu.be/KnxZxamimE4?t=3m49s
Jeremy
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
[Walter Soyka] “Ideally, I’d like to see both Apple and Adobe adopt OpenFX, which is an open standard for plugin development. I am not holding my breath, though.”
I’d never heard of this before but went to openfx.org and checked it out. Currently it seems that the environment is Win32 only. It’s not 64-bit and it’s not cross platform, so for your safety, please DO NOT hold your breath!
-
[Michael Gissing] “Five years ago I asked the tech people in the Australian Broadcasting Commission when we would be able to deliver files”
That will change when the NBN rolls around. Which may take another 5 years… or ten… -
[Dennis Radeke] “I’d never heard of this before but went to openfx.org and checked it out. Currently it seems that the environment is Win32 only. It’s not 64-bit and it’s not cross platform, so for your safety, please DO NOT hold your breath!”
Hi Dennis,
It turns out that there are (confusingly) two projects, both named OpenFX. I was not talking about the one you found (which I had never heard of before, either). I was talking about this OpenFX [link]: an open plug-in API for 2D visual effects.
OpenFX was originally developed at The Foundry, then transferred to the Open Effects Association and released under a BSD-style license. Its goal is to provide a common framework to simplify effects development and make effects more widely available to artists across different hosts.
OFX effects run on Nuke, Fusion, Composite, Baselight, Film Master, SCRATCH, Mistika, and Piranha, and then run on Windows, Mac, and Linux environments with 64-bit support. GenArts and RE:Vision FX are among the founders of the Open Effects Association.
Sony added OFX support to Vegas last year to get their users access to some high-end effects without requiring their developers to target Vegas specifically. AE wouldn’t get that immediate benefit, since GenArts and RE:Vision already support AE well, but as a user, I’d love to see developers able to focus more on developing effects and less on maintaining the same effects across multiple host applications.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events
Reply to this Discussion! Login or Sign Up