|
XML import bug in 4.5Posted by Peter Reventlow
After updating to FCP 4.5 I noticed XML import does not behave as it should do according to the manual. My Automatic Duck Import Pro plug-in does not work correct (refusing to import all tracks in a sequence), and Automatic Duck told me that Apple has indeed changed something in the XML implementation in 4.5.
Now I have discovered new issues with XML import. If I, using FCP 4.1, import an XML file with embedded importoptions set to NOT create a new project, FCP just imports it in an existing project, just as it should do. If I try the same thing in 4.5, FCP asks me to create a new project - not the correct thing to do. Could any of you please verify this? Copy and paste the text below into an empty TextEdit document, select "Make Plain Text" in the menu "Format" and save it using an .xml fileextension. Create a new project in FCP. Import this in FCP using menu File -> Import -> XML... Does it want to create a new project? What version of FCP are you using? It is also supposed to not display an error upon import - does it do that? If the lines get mangled in the webbrowser download the same XML file here: [www.dharmafilm.com] All the best - Peter Using FCP 4.5 OS X 10.3.2 QT 6.5.1 Copy and paste into TextEdit from next line ----> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xmeml> <xmeml version="1"> <importoptions> <createnewproject>FALSE</createnewproject> <targetprojectname>No name</targetprojectname> <defsequencepresetname>DV PAL 48 kHz</defsequencepresetname> <displaynonfatalerrors>FALSE</displaynonfatalerrors> <filterreconnectmediafiles>TRUE</filterreconnectmediafiles> <filterincludemarkers>FALSE</filterincludemarkers> <filterincludeeffects>FALSE</filterincludeeffects> <filterincludesequencesettings>FALSE</filterincludesequencesettings> </importoptions> <bin> <name>My xml-imported bin</name> <children> <clip> <name>Jeremy Solo</name> <duration>188</duration> <rate> <ntsc>FALSE</ntsc> <timebase>25</timebase> </rate> <in></in> </clip> </children> </bin> </xmeml>
I got this error log to go with them in both:
Wed, May 19, 2004, 7:46 AM - Errors Found Importing testxml.xml bin:children:clip(Jeremy Solo) - Unknown key (in) encountered.( line 10 ) Both 4.1.1 and 4.5 created a new project on entering FCP using this xml file. I'm assuming the sit file is exactly the same as the text in your post, right, I used your download. Did the rest of you guys test in both? 10.3.3 and 6.5.1 Now if I create the XML from FCP 4.1 or 4.5, on import, it responds properly to the command to eiither generate a new project or use my choice. So I'm seeing in both its ignoring the imbedded tag to false the createnewproject.
Chawla,
The text in my post and in the .sit file are the same. There is one (other) odd thing about FCP 4.1.1 and XML import; If you click on the browser and then imports the XML file using the menu Import, you get the behavior I wrote about in my first post. But if you click on FCPs Viewer first and then imports using the menu Import, FCP asks you to create a new project even if the tag <createnewproject> is set to false. I just found out because I was currios to why your system acted differently. My FCP 4.5 wants to create a new project wether the Viewer or Browser is clicked on before the XML import.
FCP (4.1.1 & 4.5) "should", if you're using embedded import option <createnewproject> set to FALSE, just import the XML file into the active project in FCP no matter what window is active. So, active-window wise, 4.5 is bug-free, it just does not respect the embedded <createnewproject> import option. 4.1.1 respects <createnewproject> as long as you have the browser window active.
I know this is an old post, but I ran into it via Google and it's likely to be searched for again. The reason you're prompted for a new project is this line in the xml
<targetprojectname>No name</targetprojectname> indicates that you are importing into a project called "No name" which probably doesn't exist. I'm not sure why a default front most project is not used when it doesn't match or is null, but that seems to be the current behavior. best, Dale Bradshaw Creative Workflow Hacks Sorry, you do not have permission to post/reply in this forum.
Moderators:
Tom Wolsky, Nick Meyers
|
|