It seems that FCP always defines something called a element for a clip, which tells the host which track within the clip to use. Odd.ĭelving a little deeper into the Resolve XML export there’s another potential inconsistency that stands out. No sequence, no error log, no crash, nothing … the import process just completes without actually importing or creating anything. The file no longer throws an error but no sequence magically appears either. So, we edit the Resolve generated XML file and manually add in that extra formatting … and hey presto, the dreaded “Project import went wrong” message disappears. Resolve, it seems, only uses a the basic “” identifier to denote sequence elements within it’s XML file export format, and whilst it’s a simplified syntax it’s still fully adherent to the FCP XML spec, and imports without issue into FCP … even if its not how FCP itself describes a element, the latter always using the more fully formed “” identifier. Well I couldn’t see anything “hopelessly” wrong … but I got extremely lucky with the tests I tried and it turns out I might have figured out the incompatibility anyway.

So I had a look at using Resolve’s XML export function (for FCP) to bring graded edits back into Edius … comparing FCP’s native XML exports with Resolve’s XML export formatting and seeing if anything looked hopelessly wrong (because if you try and import one straight into Edius you just get a vague “Project import went wrong” error). Obviously a lot of the issues are outside of any possible user control (for example we can’t force Edius to start embedding/retaining more edit metadata in it’s AAF files, nor can we force Edius AAF files that reference copied media to just describe dissolves rather than render and embed that media too … and it goes both ways as we can’t force Resolve to better interpret these Edius AAF files) but with a fair amount of trial and error I’ve found some things we can work around, like using a free translator app (AAF Converter) to translate Edius AAF files directly to FCP XML files which can then be imported into Resolve without issue.Īll this has served well for getting otherwise complex project references out of Edius and into Resolve … but getting projects back into Edius has been a bit of a sticky issue.

that being establishing a workflow to allow Edius and Resolve 9 to play a bit more nicely together. So I had some time a while back to revisit one of my favourite pastimes. * Built for use with Blackmagic Design’s Davinci Resolve v9 *

Pluraleyes for edius 7