Open orchetect opened 9 months ago
A TON of work has been put into this thus far. Like literally weeks, full-time. But this remains very much a living and breathing in-progress effort. It's very close to reaching a point of satisfactory capability, stability, and accuracy. The goal now is to fine tune, work out some bugs, cover edge cases, and add unit testing to further improve its rigidity so it can be production-ready.
Currently, the parsing model is not complete (ie: does not implement 100% of the FCP XML 1.11 DTD). It may in future, but there is no compelling reason other than completeness. There exists a lot of ancillary elements possible in the DTD that are somewhat irrelevant to the main goal of DAWFileKit at present, which is markers extraction and interchange.
Also, the model is primarily designed to be read-only and is not yet capable of writing the model to disk as XML. That is a very possible addition to DAWFileKit in future, but will require a substantial refactor and is not a priority at this time.
DAWFileKit is currently capable of parsing and reasoning on:
It's taken quite some time to start shaping the codebase and API into something more ergonomic and it's so much more effort than just writing an XML parser. FCPXML is a bit heady and labyrinthian, and takes time to get into to really understand and be able to reason on, and there's not a ton of great documentation out there.
Reasoning on the model to achieve things like this was challenging to get right:
Multiple layers and references need to be considered and consulted to compile just one piece of reasoning datum such as these, and there are many ways to get it wrong. That's why it's taken so long to build and unit test.
After a massive second-pass refactor, I'm getting close to stabilizing the API and getting a robust core feature set done.
XMLElement
wrappers.The goal is to have this pushed to a new release in the next week or so.
The re-refactor is basically complete on fcpxml-refactor
branch.
There should be a forthcoming merge to main and release soon.
Merged PR to main.
Baseline
Parsing and Element Extraction
sync-clip
rolesmc-clip
rolesanalysis-marker
fcpxml
ExtractionSettings
to allow filtering out elements that are either partially or fully out-of-bounds, and therefore not visible on the main timelineabsoluteStart
toinTime
. AddoutTime
property tocontext
, calculated from inTime + duration.Frame Rate Scaling
Frame rate scaling for clips using
conform-rate
child element.As support for timeline/media frame rate pairs are added, this table will be updated. (Project rates in the 1st column and media rates in subsequent columns.)
X
= implemented and unit tested?
= should work in theory, being reciprocals of already-tested rate pairs, but have not been explicitly unit testedAuthoring
Refactors
resources
parameter in inits and force them to parse exclusively from the XML, including parsing out resources when necessaryTimecode
can result in subframe aliasing where Final Cut Pro shows timecode for elements (markers, captions, keywords, etc.) 1-2 subframes offCMTime
orFraction
and convert toTimecode
ad-hocTechnical
debugDescription
output forAny*
enum cases, etc.Sendable
To Investigate
note
is a child element for clips, but an attribute for annotationsframeDuration
, in which case we would need to add frame rate info for each one of these to derive itTesting
0
lanes extend past clip(s) beneath them