November 2008 - Pro-apps-dev

Plugin not receiving -dealloc call at the expected time (Update)
by David Yamnitsky 16 Nov '08

16 Nov '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Update: I tested the FloatingWindow plugin in FCP, and the same issue occurred. -dealloc was not sent to the plugin, and the window remained open. Pressing the "Re-render" button in the window after deleting the effect caused a crash. _______________________________________________ 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

Plugin not receiving -dealloc call at the expected time
by David Yamnitsky 16 Nov '08

16 Nov '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thanks in advance, David _______________________________________________ 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… Hi everyone, I'm building a plugin which opens a separate window. It all works fine, except I'm having the problem that when the effect is deleted, the window remains open. Any attempt to manipulate something in the window which makes an FxPlug API call crashes the app. I consulted the FloatingWindow example code, which just releases the window when -dealloc is sent to the plugin object, which is the same thing I'm doing. I did some digging, and found that the FloatingWindow example receives the -dealloc call right when the effect is deleted, but my plugin receives that call rather spontaneously, either when the app is quit or when another effect is applied. Why is this? Could it be because my plugin is dynamically registered? (that seems to be the only obvious difference between the FloatingWindow example and my code). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Why does Motion return NO for supportsTemporalBitmaps?
by Darrin Cardani 14 Nov '08

14 Nov '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Nov 14, 2008, at 2:40 PM, Stonewall Ballard wrote: 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… In Motion 3.02, [_hostCapabilities supportsTemporalBitmaps] returns NO. That seems very odd to me. I thought this selector was added to distinguish versions of Motion prior to V3, where the image well bug was fixed (mostly). Is it really the case that Motion does not support temporal bitmaps? They seem to work well for me. Motion definitely still supports temporal bitmaps. We already have a bug about this stupid issue (claiming it doesn't support them when it does), but it's very low priority at the moment. Sorry for the inconvenience. This email sent to site_archiver(a)lists.apple.com

1 0

Why does Motion return NO for supportsTemporalBitmaps?
by Stonewall Ballard 14 Nov '08

14 Nov '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer:sender; bh=OxwviY0WI1pKPXm7DQtNSaOdvcESFpi7oS1SVG0rTb0=; b=Soze/0wFpU/NvP+iXmh/5bMgxOZ3yePCXOp9NOhsFcX4rFtrMdUOjboDGviW6kUdlJ 83zDkHWxRisxa1viJM4QRDHPQBSJ8k9t8Y4W4VVDkVPrTYxE6bE8Rq1sMW2JXKIUIvxc t1z+aJh1/h2/JawIafb92xZmG6NVNRGcBZWFo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer:sender; b=PtpY20zyIWsok0TPLWdq08YZw7p0BUNhQ37ALu5LZMlL2zTKOybHVe/SlpSOa+8uOH 1PYOGv3prxsm1V6w5HOAQAlmVAEHXbpvdXMun3WfdviHYveIsbssLpQ2vLnIrwmDGyD3 LEmN2wj5z2ShenVsCVi88j3SJ9KZyJrIemlos= - Stoney -- Stonewall Ballard stoney(a)sb.org http://stoney.sb.org/ _______________________________________________ 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… In Motion 3.02, [_hostCapabilities supportsTemporalBitmaps] returns NO. That seems very odd to me. I thought this selector was added to distinguish versions of Motion prior to V3, where the image well bug was fixed (mostly). Is it really the case that Motion does not support temporal bitmaps? They seem to work well for me. This email sent to site_archiver(a)lists.apple.com

1 0

FInalCutPro and External Open Directory accounts
by Dean Ingram 13 Nov '08

13 Nov '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: Parsing Final Cut Pro XML
by Jose A. Guerrero-Colón 11 Nov '08

11 Nov '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: Parsing Final Cut Pro XML
by Andreas Kiel 10 Nov '08

10 Nov '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: Parsing Final Cut Pro XML
by Helena Ju 10 Nov '08

10 Nov '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

Parsing Final Cut Pro XML
by Jose A. Guerrero-Colón 10 Nov '08

10 Nov '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: Pixel Aspect on input vs. temporal
by Fiorani Gallotta Pierluigi 08 Nov '08

08 Nov '08

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Piero (You can find the above example in http://web.mac.com/piero.fiorani/PieroF_FCE_Effect/Aspect_Ratio_Adjust_2.ht…) Il giorno 07/nov/08, alle ore 23:56, Paul Schneider ha scritto: Hi Stoney, Thanks! - Paul On Nov 6, 2008, at 8:03 PM, Stonewall Ballard wrote: TIA. - Stoney -- Stonewall Ballard stoney(a)sb.org http://stoney.sb.org/ _______________________________________________ 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/piero.fiorani%40fastweb… _______________________________________________ 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… Hi Stoney, I'm not sure I'm answering your question, but I see a relation between the two figures 0,4444 and 0,39506: their ratio is 1,1250, the same that measures square pixel AR (=1) vs. NTSC 4:3 CCIR 601 pixels AR (=0,8888): in fact 1/0,8888 = 1,1250. For example I ran into this value when inserting a square pixel 4:3 NTSC (640x480) clip into a standard NTSC 4:3 CCIR 601 sequence (720x480): then FCP automatically applies the value -12,5 % to the Motion/Distort/Aspect Ratio control to fix the aspect ratio. The relationship between the 2 pixel AR and the Distort control (in this case) is the following: Motion/Distort/Aspect Ratio = 100 * (1 - <inserted clip pixel AR> / <sequence pixel AR>) that is in this example = 100 * (1 - 1 / 0,8888) = 100 * (1 - 1,125) = -12,5 %. You can check it easily in FCP. (It might appear confusing, but in this specific example you can also find out that FCP sets Basic Motion/Scale to 112,5 to fit the clip frame to the sequence frame - but this is a different story). The conclusion I draw (but this probably is just a long shot...) is that in one case with getInputBitmap... you get the pixel AR (0,395062) of the clip before it is adapted to the sequence and in the other case with getBitmap... you get the sequence pixel AR (0,4444), the same as the pixel AR of the clip after being vertically squeezed to correct its aspect ratio back to normal. I hope this makes some sense, and helps a little - even if I understand in your question you are not talking about square pixel clip but CCIR clip.... Just my 2 cents I don't see that behavior in a quick test, but my DV media is 720 x 480, not 486. 720 x 480 is FCP's idea of "standard" NTSC DV, and what you get when you create a sequence with the NTSC DV preset. It sounds like you're in a situation where your media's aspect ratio isn't the same as your sequence's. It's certainly possible that we have some inconsistencies in that case. FCP considers "DV" aspect ratio to be 0.88889, which gets divided by two when we report it to FxPlugs running on a single field. Could you file a bug report at bugreport.apple.com, and include your media? It would be great if you could trim the media down to a second or two before attaching it to the bug. In FCP 6.0.4, in a sequence set to a Pixel Aspect Ratio of NTSC- CCIR 601/DV (720x480), and a Frame size of 720x486 (CCIR 602 NTSC 40:27), the output image info says it has a pixelAspect of 0.444444. When the input is a 720x486 clip listed as Pixel Aspect NTSC-CCIR 601 in the browser, its imageInfo says it has a pixelAspect of 0.395062. The same input frame fetched via the temporal API using getBitmap:layerOffsetX:layerOffsetY:requestInfo:fromParm:atTime: reports a pixelAspect of 0.444444. At least getInputBitmap:withInfo:atTime: shows that same frame with a pixelAspect of 0.395062, the same as the regular input. Why does getBitmap:layerOffsetX:layerOffsetY:requestInfo:fromParm:atTime: produce a different pixelAspect than the other two methods? Is there any way to tell what the *real* pixel aspect of that frame? Interestingly, when I set the sequence to use square pixels, all the pixelAspects are 0.444444. BTW, 0.444444 is 640/720/2, while I would have expected to see 648/720/2, or 0.45. I don't see where 0.39506 comes from. Anyone know what's going on here? Is there any way to know what the *real* PAR of an image param is? This email sent to piero.fiorani(a)fastwebnet.it This email sent to site_archiver(a)lists.apple.com

1 0