June 2008 - Pro-apps-dev - lists.apple.com

Re: FCE: pixel aspect changing based on canvas window background?
by Steve Christensen 18 Jun '08

18 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Paul, steve On Jun 18, 2008, at 2:29 PM, Paul Schneider wrote: Hi Steve, - Paul On Jun 17, 2008, at 5:29 PM, Steve Christensen wrote: Here's what I'm doing: 1. Launch FCE with no project (looks like it defaults to DV NTSC). 2. Drag a DV movie to the timeline. 3. Apply my filter to the DV clip (filter is using FxBitmaps). 4. Make sure that the viewer window background is set to black. I'm seeing: inputA: 720 x 240, pixelAspect = 0.444444 output: 720 x 240, pixelAspect = 0.444444 Now I'm seeing: inputA: 703 x 468, pixelAspect = 0.790123 output: 703 x 468, pixelAspect = 0.888889 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… I understand about changes in size, pixel aspect and scale due to different rendering settings and have that handled. My question was directed more at the differing pixel aspects, which as you say could be a bug. I'm currently ignoring the input pixel aspect and just using the output pixel aspect for both images; this seems to be working OK for what I'm doing. Are there any cases, though, where the input and output pixel aspects would actually be different (and thus I'd get bitten)? When you switch your background to anything other than black, Final Cut enters its legacy "Non-RT" display path. The render settings in this path are quite different. There is some documentation for this in the FxPlug SDK, in a document called "Rendering FxPlug Effects In Final Cut.pdf". Stills are handled differently than video in this path. The mismatched aspect ratios for the input and output seems to be a bug; I'll check it out. Let me know if the document doesn't answer your questions, or if it leaves you with more questions than answers (certainly possible!). 5. Change the canvas window background to one of the other options (i.e., checkerboard). Is there a reason for the change in pixel aspect, and in particular seeing different aspects for the input and output images? I see slightly different behavior for still images. While the pixel aspect changes between a black background and any of the others, the input and output pixel aspects are the same. Why the difference between still images and video? This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCE: pixel aspect changing based on canvas window background?
by Paul Schneider 18 Jun '08

18 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Steve, - Paul On Jun 17, 2008, at 5:29 PM, Steve Christensen wrote: Here's what I'm doing: 1. Launch FCE with no project (looks like it defaults to DV NTSC). 2. Drag a DV movie to the timeline. 3. Apply my filter to the DV clip (filter is using FxBitmaps). 4. Make sure that the viewer window background is set to black. I'm seeing: inputA: 720 x 240, pixelAspect = 0.444444 output: 720 x 240, pixelAspect = 0.444444 Now I'm seeing: inputA: 703 x 468, pixelAspect = 0.790123 output: 703 x 468, pixelAspect = 0.888889 steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… When you switch your background to anything other than black, Final Cut enters its legacy "Non-RT" display path. The render settings in this path are quite different. There is some documentation for this in the FxPlug SDK, in a document called "Rendering FxPlug Effects In Final Cut.pdf". Stills are handled differently than video in this path. The mismatched aspect ratios for the input and output seems to be a bug; I'll check it out. Let me know if the document doesn't answer your questions, or if it leaves you with more questions than answers (certainly possible!). 5. Change the canvas window background to one of the other options (i.e., checkerboard). Is there a reason for the change in pixel aspect, and in particular seeing different aspects for the input and output images? I see slightly different behavior for still images. While the pixel aspect changes between a black background and any of the others, the input and output pixel aspects are the same. Why the difference between still images and video? This email sent to pschneider(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

FCE: pixel aspect changing based on canvas window background?
by Steve Christensen 17 Jun '08

17 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Here's what I'm doing: 1. Launch FCE with no project (looks like it defaults to DV NTSC). 2. Drag a DV movie to the timeline. 3. Apply my filter to the DV clip (filter is using FxBitmaps). 4. Make sure that the viewer window background is set to black. I'm seeing: inputA: 720 x 240, pixelAspect = 0.444444 output: 720 x 240, pixelAspect = 0.444444 Now I'm seeing: inputA: 703 x 468, pixelAspect = 0.790123 output: 703 x 468, pixelAspect = 0.888889 steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 5. Change the canvas window background to one of the other options (i.e., checkerboard). Is there a reason for the change in pixel aspect, and in particular seeing different aspects for the input and output images? I see slightly different behavior for still images. While the pixel aspect changes between a black background and any of the others, the input and output pixel aspects are the same. Why the difference between still images and video? This email sent to site_archiver(a)lists.apple.com

1 0

Re: XML Generator Question
by Helena Ju 17 Jun '08

17 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)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(a)apple.com Andreas Kiel Spherico Nelkenstr. 25 D-76135 Karlsruhe Tel.: +49 (0)721 183 9753 eFax: +1 650 897 8094 eMail: kiel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/hju%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Please feel free to write up an enhancement request to get the behavior you want. I' wrote it up as 6011972 yesterday (in case you want to refer to that bug number). Regards, Helena On Jun 17, 2008, at 10:21 AM, Andreas Kiel wrote: 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 hju(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: XML Generator Question
by Andreas Kiel 17 Jun '08

17 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)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(a)apple.com Andreas Kiel Spherico Nelkenstr. 25 D-76135 Karlsruhe Tel.: +49 (0)721 183 9753 eFax: +1 650 897 8094 eMail: kiel(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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(a)lists.apple.com

1 0

Re: XML Generator Question
by Helena Ju 16 Jun '08

16 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: XML Generator Question
by Darrin Cardani 16 Jun '08

16 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Jun 14, 2008, at 7:41 AM, Andreas Kiel wrote: Does anybody have thoughts about this? Helena?:) Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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(a)lists.apple.com

1 0

XML Generator Question
by Andreas Kiel 14 Jun '08

14 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi all, Does anybody have thoughts about this? Helena?:) Thanks and kind regards Andreas _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… 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. This email sent to site_archiver(a)lists.apple.com

1 0

Open Positions in Apple Pro Apps
by Darrin Cardani 10 Jun '08

10 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thanks, Darrin -- Darrin Cardani dcardani(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… The following are open positions within Apple's Pro Apps division. If you or anyone you know is interested, let me know: Video Editing Cocoa UI Engineer - <http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=10070&Cu… > Producer, Pro Apps User Interface Design - <http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=10102&Cu… > UI Cocoa Engineer for Soundtrack Pro - <http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=12437&Cu… > Sr Server Engineer - <http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=15015&Cu… > Software Engineer - <http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=23332&Cu… > This email sent to site_archiver(a)lists.apple.com

1 0

Off Topic: Looking for New Opportunities
by Ed McNichol 08 Jun '08

08 Jun '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0