site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Many Thanks Darrin, Kind regards Andreas On 16.06.2008, at 20:26, Darrin Cardani wrote: On Jun 14, 2008, at 7:41 AM, Andreas Kiel wrote: Does anybody have thoughts about this? Helena?:) Darrin -- Darrin Cardani dcardani@apple.com Andreas Kiel Spherico Nelkenstr. 25 D-76135 Karlsruhe Tel.: +49 (0)721 183 9753 eFax: +1 650 897 8094 eMail: kiel@spherico.com http://spherico.com/filmtools -- workflow tools for FCP P Please don't print this e-mail unless you really need to. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... Unfortunately Motion in some cases is not a real option. It does have some limitations when it comes to text formating. But that's not the problem. The issue is how to handle generators of any type within a FCP XML. The way to use <effect id="xxx"> seems to work fine in any case when you create an XML for FCP. My thoughts (if did understood the explanations) for that way is, that I can create a "master" and from there use instances. As said this does work fine, but very slow when it comes to many generators. Really slow. We got no errors, everything shows up as expected, but after a long brake. So the situation is to "sitting between two stools". I could give the user the option to change something within a part of second but then wait for a long time fo FCP to update, or I can use the option to rewrite all generators (or their entries) which will be faster on FCP import. To resume: in any case any of the options do work but with different speed and/or options and it's not the type of generator (this can be any) it's the way how it is treated in FCP XML import. I used the Apple generator example to create text tracks for quite a long time. This way you create one "master" generator with an "effect id = 'xxx'" and only write the changes into the XML for the "childs". This works fine and has the advantage that you can change "master" settings in a second, which will be applied to all following generators. I and my customers (which I had been in contact with) in the last time only worked on smaller (amount of title) projects, but now some bigger came up with 1000 titles and way more. And here we got an issue: the XML import takes a real (I mean real) long time. That wasn't the case with elder versions of FCP, though I can't proof when this started. Using the "non optimized way" which means writing the full generator each time reduces the import time by factor 10, 20 or more. The disadvantage is that you can't do global changes any more in that kind of speed as with the "optimized way", means that you cannot - even as an "know nothing about XML user" - open the XML in TextEditor and change one entry in the "master" and all children will follow. Same as with an app that would do it for you. creating the XML and file size isn't an issue though. Andreas, I don't know if this is the best way to handle this, or if it would even solve your problem. Could you create and then use a Motion template for your titles? One other option would be to just generate a Motion file with the text tracks and then generate your FCP file and have it reference the .motn file. The Motion file format is now publicly documented, so this shouldn't be too difficult. As I say, I don't know if that's the best solution, but might help with the problem you're seeing. This email sent to site_archiver@lists.apple.com