Ongoing and future support for Final Cut Pro X Adapter

[json-lim]

We were going through the Final Cut Pro X XML Adapter code, and observed that it was exporting fcpxml files of version 1.8 which is becoming outdated. The latest version of Final Cut Pro is only capable of exporting versions 1.9 and 1.10.

Is there any ongoing support for this project, or are there any plans to support this in the near future?

Cc-ing @ssteinbach since you are the earliest committer for the adapter file, but feel free to tag anyone else.

[jminor]

Let's check to see if the original author, @eric-with-a-c is able to take a look, or if anyone else in the community would like to take a look at updating this adapter.

There have been improvements to the FCP 7 XML adapter since it is often used for interop with Premiere or Resolve, but I don't think that modern Final Cut Pro supports that format any more.

[jminor]

Also @json-lim if you have a sample file which demonstrates the problem, it could help if you file an issue with that as an attachment. Then a developer who doesn't have Final Cut Pro installed might be able to help out.

[apetrynet]

We should also mention that we're moving towards splitting out the adapters to their own repositories, in part to avoid blocking updates and fixes like this.
So, the future of this adapter should in theory be more accessible for maintenance.

If @eric-with-a-c has time to look at this, perhaps it would be a good idea to begin the process of moving the adapter?
We have a template repository to help the process.

[eric-with-a-c]

Hello all! I started working on an updated version of the adapter a while back with the intention of moving it to another repo as @apetrynet suggests above. Unfortunately, due to other pressing projects, work stalled a bit on the FCP X adapter. It may be another month before work picks back up on it.

On a slightly related note, a desire has been expressed by OpenTimelineIO maintainers (maybe @jminor but I can't remember) for NLEs to start natively supporting otio. Does anyone know if there is any indication that native otio support is coming to FCP X?

[latenitefilms]

I would REALLY like to see the FCPXML Adapter continue to be updated. I've been hesitant to respond here until now, as I don't really have the time/energy/brainpower to take on yet another project - HOWEVER, I think FCPXML support is REALLY important and now with LLMs like Claude Code & Codex - it's a lot more possible to just get agents to update things.

I have a private Swift-based FCPXML framework that we could use as reference.

I will try have a proper look at this at some point.

[apetrynet]

Cross posting from Slack thread:

The adapter is still available for development in its own repo
We just don't include it with the bundled adapters as it was contributing to more confusion than solution in its current state.
If you need the adapter as is, you can still install it via pip. I also found this which I didn't know of until now.

[GraemeGriffiths]

(Another slack cross-post):
Hi folks, I'm working on the Rode implementation of OTIO and I had looked at FCP (and posted here, where the consensus was that nobody really uses FCP anymore). It didn't sit as a particularly satisfying result so I'm very grateful to Chris for bringing it back up. We had a brief chat about it in the TSC meeting last night(/morning YMMV). I was, indeed trying the fcp_xml plugin and not the fcpx_xml which was why I couldn't import into FCP. Using fcpx_xml I can get a working FCP timeline (for a varying definition of "working").

First issue is #1985 - exactly as we get on Premiere - it can't find the media as it was created on our unit and then the SSD moved to the NLE host. Relative paths have never worked (as discussed on #1985)so I have to put absolute paths in and obviously they are incorrect once the SSD is on the host. Resolve (bless you Black Magic) manage to handle this (it's not exactly rocket science you just have to work out the base directory to cut and replace) but Premiere, and now, FCP fail to do this so they can't find the media. I have a script that does the relocation and once I've run it and otioconverted the result I can import the timeline and media. Now I've worked on this a while it may be worth a revisit but my original attempts with relative paths didn't work on any NLEs. As discussed in the #1985 discussion the path really only makes sense relative to the otio file, not the CWD as defined in the docs.

My findings on converting a current Rode OTIO and importing into FCP:

1. No transitions - known in advance but disappointing.
2. Static sources flash for one frame rather than continuing as a static source.
3. No move/scale/crop of layers - this is entirely expected. I've got it working in Resolve and Premiere by reverse engineering their OTIO exports (import mine, correct the move/crop/scale, export the otio and see what metadata they use). They both define their own metadata and the maths was, at times, baffling but essentially they do the same thing (I would encourage OpenTimelineIO to attempt to standardise/schema this stuff as it is a lot of work and I'll basically have to do it for any NLE that comes along if we want to support them). In order to get move/crop/scale working with FCP I will need to know what metadata the fcpx_xml adapter is passing on (if any).
4. The video tracks aren't kept as they are in the OTIO - if I have a logo applied (top layer of a DSK) I export it as a single track (with gaps when it wasn't displayed) but when the timeline gets to FCP the logo layer is simply the top layer of the stack (so it hops up and down depending on the number of layers in a scene). This isn't a deal-breaker, you effect the same video, it's just weird.

So, compared to yesterday we can, mostly, support a new NLE which is great. The user will have to go through some hoops but, since they're going to need to run the otioconvert anyway adding a script isn't the end of the world.