December 2010 - Pro-apps-dev

Re: RIP downloads page
by Jon Chappell 21 Dec '10

21 Dec '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=digitalrebellion.com; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-Identified-User; b=NWu8QKjRxa/JSHIZ72HQt5H/Y22p5nYfG5qiFnA4QoHCUNvWfGa+UiQg6J1ZiLDhnEb+ziEDMsojEQX3OumNzpOqGejzz7LvDlwp6alApqGg799/CwtKxcj65FTFjgaF; _______________________________________________ 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

RIP downloads page
by Martin Baker 21 Dec '10

21 Dec '10

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:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=ewZ/Hgw2qFuphwL7ynbgSKe0fpV2ER+WcdeRJJl9N88=; b=uLtJZsV0VwafWaRr0d+DwlJMfBxMKkxNM9mmhP4kD5+v60Zh8UGPaz8OpotZMat3My PNDA9Ozq6XliWQOfd4VkWPi1QDUG6ha90oZlUjgTSFxo05eL61RzOYtsiqySmblbGsyh RDmRMVvxjII0ZIMK4pTJQgApDWHcxSmGRVKTY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=ilEDvClj+b7zHCdtqXgYc9jLV8+TvZqlwfLW9zcjw4XZotyEktDKldXSZ3gK3QRUAI AS1Fxs8NUzUvF9imVJb2d2461G6RwPDtF9XCscGgR3jAL9XMotGnCM72kmCmb/GkSloZ mMWFUamOfGmvKClXHuwq4pdLbr9ofw+/eFFS8= So the downloads page on apple.com is being axed. The signs were there (no updates since 3rd Dec) and it was kinda inevitable that there would be a conflict of interest with the Mac app store. Good news for MacUpdate and Cnet but bad news for those developers like us with plug-in products that can't be hosted in the app store. :-( Martin Baker www.digital-heaven.co.uk www.twitter.com/digitalheaven www.videospaceonline.com www.finalcutters.com www.funkycloud.com/lifeshaker ------------------------------------------------------ Digital Heaven Ltd is registered in England and Wales Company registration number: 3628396 Registered address: 55 Lynwood Drive, Worcester Park, Surrey KT4 7AE VAT registration number: GB 736 0989 03 _______________________________________________ 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: Final Cut Pro getInputImage() returning up-side-down image?
by Garrick Meeker 16 Dec '10

16 Dec '10

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com I think I just ran into this in FCP. In Motion 4 it seems to work correctly. I was just caching the image from the last render call but I'd like to avoid hogging this memory. Did you file a bug about this? Is there any workaround in FCP, or is it reliable enough that we can assume an upside down image (until a future version of FCP fixes this)? On Oct 19, 2010, at 12:40 PM, Darrin Cardani wrote: > > On Oct 19, 2010, at 11:57 AM, Paul Miller wrote: > >> On 10/19/2010 1:55 PM, Paul Miller wrote: >>> In response to a button (custom UIButton view) press I'm calling >>> getInputImage() to fetch the full-frame (progressive) image for the >>> current frame. The returned image has an orientation of top-left, but >>> it's actually up-side-down in memory. What did I do wrong? >> >> Oops - sorry for the C-style function format. I'm referring to the getInputBitmap method of the FxTemoralImageAPI. > > > Hmm.... it doesn't sound like you've done anything wrong. I can't imagine a situation where we would send you an upside down image and it would be correct. Could you file a bug about this? > > 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/garrick%40digitalanarch… > > This email sent to garrick(a)digitalanarchy.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: Reading temporal textures in FCP
by Eberhard Ammelt 01 Dec '10

01 Dec '10

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com Hello Paul, Darrin in my first tests the textures had the same image as the current frame though texture ids were different. Now I'm also getting white textures, so it seems the result is quite unpredictable. I'll try your suggestions and copy textures. With respect to VRAM usage, it might turn out that reading temporal bitmaps is the better approach. (?) Thanks, Eberhard > > Hi Eberhard, > > It's possible that we will re-use textures after -renderOutput. Do the textures have the frames you expect when you retrieve them? If so, you may need to do a vram-to-vram copy to keep your own copies alive across calls to -renderOutput. > > > On Dec 1, 2010, at 5:40 AM, Eberhard Ammelt wrote: > >> Hello Darrin, >> >> the problem seems to be related to caching of textures. The plugin uses a contiguous range of texture frames and keeps the recently used ones retained so mostly only one frame needs to be read from the timeline per "renderOutput:" call. >> Is it wrong to retain textures beyond the scope of "renderOutput:"? >> >> Eberhard >> >>> Eberhard, >>> That's something that should work correctly. My only guess would be either to make sure you're actually sending different time values (within the valid range for the clip) for each frame. If that's happening correctly, it could be a bug in FCP (though I'd think someone would have run into this sooner if it were). >>> >>> Darrin >>> >>> On Nov 19, 2010, at 6:08 AM, Eberhard Ammelt wrote: >>> >>>> Hello, >>>> >>>> I'm trying to read a contiguous range of textures from the timeline in FCP (7.0.2) using "getInputTexture:". >>>> All the returned textures seem to contain just the current image though the texture ids are different. >>>> Am I missing anything? >>>> >>>> Thanks, Eberhard _______________________________________________ >>>> 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/dcardani%40apple.com >>>> >>>> This email sent to dcardani(a)apple.com >>> >>> -- >>> 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/pschneider%40apple.com >> >> This email sent to pschneider(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… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Reading temporal textures in FCP
by Darrin Cardani 01 Dec '10

01 Dec '10

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com And if you do that, be sure you don't keep too many around, as it can seriously affect the performance of the rest of the app. (More so in Motion than FCP since it's more heavily GPU based.) VRAM is not that big when you've got lots of uncompressed HD frames laying around. Darrin On Dec 1, 2010, at 9:04 AM, Paul Schneider wrote: > > Hi Eberhard, > > It's possible that we will re-use textures after -renderOutput. Do the textures have the frames you expect when you retrieve them? If so, you may need to do a vram-to-vram copy to keep your own copies alive across calls to -renderOutput. > > > On Dec 1, 2010, at 5:40 AM, Eberhard Ammelt wrote: > >> Hello Darrin, >> >> the problem seems to be related to caching of textures. The plugin uses a contiguous range of texture frames and keeps the recently used ones retained so mostly only one frame needs to be read from the timeline per "renderOutput:" call. >> Is it wrong to retain textures beyond the scope of "renderOutput:"? >> >> Eberhard >> >>> Eberhard, >>> That's something that should work correctly. My only guess would be either to make sure you're actually sending different time values (within the valid range for the clip) for each frame. If that's happening correctly, it could be a bug in FCP (though I'd think someone would have run into this sooner if it were). >>> >>> Darrin >>> >>> On Nov 19, 2010, at 6:08 AM, Eberhard Ammelt wrote: >>> >>>> Hello, >>>> >>>> I'm trying to read a contiguous range of textures from the timeline in FCP (7.0.2) using "getInputTexture:". >>>> All the returned textures seem to contain just the current image though the texture ids are different. >>>> Am I missing anything? >>>> >>>> Thanks, Eberhard _______________________________________________ >>>> 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/dcardani%40apple.com >>>> >>>> This email sent to dcardani(a)apple.com >>> >>> -- >>> 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/pschneider%40apple.com >> >> This email sent to pschneider(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/dcardani%40apple.com > > This email sent to dcardani(a)apple.com -- 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… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Reading temporal textures in FCP
by Paul Schneider 01 Dec '10

01 Dec '10

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com Hi Eberhard, It's possible that we will re-use textures after -renderOutput. Do the textures have the frames you expect when you retrieve them? If so, you may need to do a vram-to-vram copy to keep your own copies alive across calls to -renderOutput. On Dec 1, 2010, at 5:40 AM, Eberhard Ammelt wrote: > Hello Darrin, > > the problem seems to be related to caching of textures. The plugin uses a contiguous range of texture frames and keeps the recently used ones retained so mostly only one frame needs to be read from the timeline per "renderOutput:" call. > Is it wrong to retain textures beyond the scope of "renderOutput:"? > > Eberhard > >> Eberhard, >> That's something that should work correctly. My only guess would be either to make sure you're actually sending different time values (within the valid range for the clip) for each frame. If that's happening correctly, it could be a bug in FCP (though I'd think someone would have run into this sooner if it were). >> >> Darrin >> >> On Nov 19, 2010, at 6:08 AM, Eberhard Ammelt wrote: >> >>> Hello, >>> >>> I'm trying to read a contiguous range of textures from the timeline in FCP (7.0.2) using "getInputTexture:". >>> All the returned textures seem to contain just the current image though the texture ids are different. >>> Am I missing anything? >>> >>> Thanks, Eberhard _______________________________________________ >>> 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/dcardani%40apple.com >>> >>> This email sent to dcardani(a)apple.com >> >> -- >> 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/pschneider%40apple.com > > This email sent to pschneider(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… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Reading temporal textures in FCP
by Eberhard Ammelt 01 Dec '10

01 Dec '10

site_archiver(a)lists.apple.com Delivered-To: Pro-apps-dev(a)lists.apple.com Hello Darrin, the problem seems to be related to caching of textures. The plugin uses a contiguous range of texture frames and keeps the recently used ones retained so mostly only one frame needs to be read from the timeline per "renderOutput:" call. Is it wrong to retain textures beyond the scope of "renderOutput:"? Eberhard > Eberhard, > That's something that should work correctly. My only guess would be either to make sure you're actually sending different time values (within the valid range for the clip) for each frame. If that's happening correctly, it could be a bug in FCP (though I'd think someone would have run into this sooner if it were). > > Darrin > > On Nov 19, 2010, at 6:08 AM, Eberhard Ammelt wrote: > >> Hello, >> >> I'm trying to read a contiguous range of textures from the timeline in FCP (7.0.2) using "getInputTexture:". >> All the returned textures seem to contain just the current image though the texture ids are different. >> Am I missing anything? >> >> Thanks, Eberhard _______________________________________________ >> 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/dcardani%40apple.com >> >> This email sent to dcardani(a)apple.com > > -- > 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… This email sent to site_archiver(a)lists.apple.com

1 0