November 2011 - Pro-apps-dev

Re: [inputImage origin] incorrect for .moef?
by Paul Schneider 30 Nov '11

30 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com In the meantime, you can see if you are running inside FCPX by checking [[NSBundle mainBundle] bundleIdentifier]. On Nov 30, 2011, at 1:34 PM, Darrin Cardani wrote: > Paul, > This seems familiar to me. I think this is something I worked on recently, and I believe will be fixed in a future release. If you could send me a sample plugin – it can just print to the console, doesn't need to do much of anything – I can figure out if it's been fixed, or if we need to do additional work on it. > > Thanks, > Darrin > > On Nov 30, 2011, at 10:50 AM, Paul Young wrote: > >> I'm trying to make sense of an apparent upside-down buffer issue in an >> FxPlug2 plugin I'm developing. >> >> I'm of course still looking for things I may be doing wrong on my end, >> but here's what I think I'm seeing: >> >> In Motion 5 (5.0.1), when my renderOutput: method is called, the >> inputImage & outputImage return 0 (kFxImageOrigin_BOTTOM_LEFT) for >> origin and the first row of pixels, upon inspection, is indeed the >> bottom row of the image. >> >> In FCPX (10.0.2), using a .moef for the same plugin, when my >> renderOutput: method is called, the inputImage & outputImage return 0 >> (kFxImageOrigin_BOTTOM_LEFT) for origin but the first row of pixels, >> upon inspection, is the TOP row of the image. >> >> (The same is true for FxImageInfo.origin in the various places I've checked it.) >> >> In both cases, FxHostCapabilities indicates that Motion is the host. >> (I guess this almost makes sense in this .moef model... but it's a bit >> of a head scratcher... might rather have "Motion-Inside-FCPX") >> >> This is software-only rendering (32-bit float bitmaps). I've confirmed >> that I can create new bitmaps stamped as kFxImageOrigin_TOP_LEFT. >> >> There's plenty of mention in the docs about FCP buffers being top >> down, but perhaps they're getting stamped incorrectly on their way >> through the Motion rendering engine? >> >> Has anyone else seen this? Any ideas on how to work around it? >> (Including a reliable way to detect that FCPX is the host? Not ideal >> but workable in the short term.) >> >> Many thanks, >> >> paul >> _______________________________________________ >> 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 > > _______________________________________________ > 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: [inputImage origin] incorrect for .moef?
by Darrin Cardani 30 Nov '11

30 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Paul, This seems familiar to me. I think this is something I worked on recently, and I believe will be fixed in a future release. If you could send me a sample plugin – it can just print to the console, doesn't need to do much of anything – I can figure out if it's been fixed, or if we need to do additional work on it. Thanks, Darrin On Nov 30, 2011, at 10:50 AM, Paul Young wrote: > I'm trying to make sense of an apparent upside-down buffer issue in an > FxPlug2 plugin I'm developing. > > I'm of course still looking for things I may be doing wrong on my end, > but here's what I think I'm seeing: > > In Motion 5 (5.0.1), when my renderOutput: method is called, the > inputImage & outputImage return 0 (kFxImageOrigin_BOTTOM_LEFT) for > origin and the first row of pixels, upon inspection, is indeed the > bottom row of the image. > > In FCPX (10.0.2), using a .moef for the same plugin, when my > renderOutput: method is called, the inputImage & outputImage return 0 > (kFxImageOrigin_BOTTOM_LEFT) for origin but the first row of pixels, > upon inspection, is the TOP row of the image. > > (The same is true for FxImageInfo.origin in the various places I've checked it.) > > In both cases, FxHostCapabilities indicates that Motion is the host. > (I guess this almost makes sense in this .moef model... but it's a bit > of a head scratcher... might rather have "Motion-Inside-FCPX") > > This is software-only rendering (32-bit float bitmaps). I've confirmed > that I can create new bitmaps stamped as kFxImageOrigin_TOP_LEFT. > > There's plenty of mention in the docs about FCP buffers being top > down, but perhaps they're getting stamped incorrectly on their way > through the Motion rendering engine? > > Has anyone else seen this? Any ideas on how to work around it? > (Including a reliable way to detect that FCPX is the host? Not ideal > but workable in the short term.) > > Many thanks, > > paul > _______________________________________________ > 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 _______________________________________________ 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

[inputImage origin] incorrect for .moef?
by Paul Young 30 Nov '11

30 Nov '11

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=mime-version:from:date:message-id:subject:to:content-type; bh=TSyWzEMjxfThQxiqU1oIy5X+USu9KbT/dO7UH/xZhf8=; b=jDH1cRJDlKc0CjjX9TDk2sVWnwvePFKFfnPywP+AaYWy58lmJdTydNsJlP09CMzXjB HXsAwI68Q3X63TvLXKzOGhjtRQplnboKeEn7gATdgt56PleJWbM5T2DO6LgBoBQzxJyZ ZpaA6+xuYKU8f+F2V9VSJ7RU6nFcxyk/+179c= I'm trying to make sense of an apparent upside-down buffer issue in an FxPlug2 plugin I'm developing. I'm of course still looking for things I may be doing wrong on my end, but here's what I think I'm seeing: In Motion 5 (5.0.1), when my renderOutput: method is called, the inputImage & outputImage return 0 (kFxImageOrigin_BOTTOM_LEFT) for origin and the first row of pixels, upon inspection, is indeed the bottom row of the image. In FCPX (10.0.2), using a .moef for the same plugin, when my renderOutput: method is called, the inputImage & outputImage return 0 (kFxImageOrigin_BOTTOM_LEFT) for origin but the first row of pixels, upon inspection, is the TOP row of the image. (The same is true for FxImageInfo.origin in the various places I've checked it.) In both cases, FxHostCapabilities indicates that Motion is the host. (I guess this almost makes sense in this .moef model... but it's a bit of a head scratcher... might rather have "Motion-Inside-FCPX") This is software-only rendering (32-bit float bitmaps). I've confirmed that I can create new bitmaps stamped as kFxImageOrigin_TOP_LEFT. There's plenty of mention in the docs about FCP buffers being top down, but perhaps they're getting stamped incorrectly on their way through the Motion rendering engine? Has anyone else seen this? Any ideas on how to work around it? (Including a reliable way to detect that FCPX is the host? Not ideal but workable in the short term.) Many thanks, paul _______________________________________________ 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: Invalidating custom data based on clip
by Ben Syverson 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Darrin, If the dragging bug could be fixed, then finishInitialSetup seems like it could work. But after filing that enhancement request, it seems the larger issue is that an FxPlug has no way to know that its input has changed since the last time it was run. My request asks for an "inputUUID" in FxRenderInfo. The UUID would stay the same across invocations and hosts, as long as the input remained identical. That way you could cache data for that particular input. But as soon as *anything* about the underlying clip is changed (for example, an earlier effect is tweaked), it would generate a new UUID to alert our FxPlug about a change in the input. That makes it pretty flexible, agnostic to the type of information the FxPlug is caching, and hopefully simple to implement! In the meantime, a combination of finishInitialSetup and Pete's hacky checkbox idea (thanks Pete!) should be enough. Thanks! Ben On Nov 28, 2011, at 13:11, Darrin Cardani wrote: > Ben, > Some here suggested that maybe using -finishInitialSetup could work. It's called once when a plug-in is added, but not after deserialization. It's called when a plug-in is copy/pasted elsewhere. It looks like it's not currently called when a plug-in is dragged from one piece of footage to another, but that's probably a bug. Let me know if it that might be workable. > > Darrin _______________________________________________ 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: Invalidating custom data based on clip
by Darrin Cardani 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Ben, Some here suggested that maybe using -finishInitialSetup could work. It's called once when a plug-in is added, but not after deserialization. It's called when a plug-in is copy/pasted elsewhere. It looks like it's not currently called when a plug-in is dragged from one piece of footage to another, but that's probably a bug. Let me know if it that might be workable. Darrin On Nov 28, 2011, at 10:17 AM, Darrin Cardani wrote: > Ben, > > Shoot, that's a good point. Short of something like you're already doing, I'm not sure what a good solution is. You could probably create a slightly more sophisticated "checksum" that involved not only the first frame, but maybe things like length of the clip, maybe a sample from another time, or something like that? It's a kludge, but might be more robust than what you're dealing with now. > > If you could write up an enhancement request describing how you'd like this solved in the long run, that would be great. > > Thanks, > Darrin > > On Nov 28, 2011, at 9:44 AM, Ben Syverson wrote: > >> Darrin, >> >> Hmm, on second thought, this regenerates the data each time the project is opened, which is less than optimal. It's potentially very expensive to generate this particular custom data, so I'd prefer to do it only once. For example, imagine computing optical flow for the clip. >> >> Currently I'm checking out the first frame as a bitmap and reading a few bytes to make sure they match the stored values. However, this is obviously stupid, because two different clips might have identical first frames. >> >> I would add a "Regenerate" button using the custom UI, but then that rules out FCP X. >> >> Any other ideas? >> >> Ben >> >> >> On Nov 28, 2011, at 11:23, Darrin Cardani wrote: >> >>> Ben, >>> Each plug-in instance has their -initWithAPIManager: method called, regardless of how they're created. Maybe you could do something like have a singleton which doles out custom IDs, and call it in the -initWithAPIManager: method. Then, whenever you go to use the custom data, if the id for that data doesn't match the id generated in -initWithAPIManager:, you throw it out and generate unique data for it. Would that work? >>> >>> Darrin >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 _______________________________________________ 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: Invalidating custom data based on clip
by Peter Litwinowicz 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-topic: Invalidating custom data based on clip User-agent: Microsoft-MacOutlook/14.13.0.110805 _______________________________________________ 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: Invalidating custom data based on clip
by Darrin Cardani 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Ben, Shoot, that's a good point. Short of something like you're already doing, I'm not sure what a good solution is. You could probably create a slightly more sophisticated "checksum" that involved not only the first frame, but maybe things like length of the clip, maybe a sample from another time, or something like that? It's a kludge, but might be more robust than what you're dealing with now. If you could write up an enhancement request describing how you'd like this solved in the long run, that would be great. Thanks, Darrin On Nov 28, 2011, at 9:44 AM, Ben Syverson wrote: > Darrin, > > Hmm, on second thought, this regenerates the data each time the project is opened, which is less than optimal. It's potentially very expensive to generate this particular custom data, so I'd prefer to do it only once. For example, imagine computing optical flow for the clip. > > Currently I'm checking out the first frame as a bitmap and reading a few bytes to make sure they match the stored values. However, this is obviously stupid, because two different clips might have identical first frames. > > I would add a "Regenerate" button using the custom UI, but then that rules out FCP X. > > Any other ideas? > > Ben > > > On Nov 28, 2011, at 11:23, Darrin Cardani wrote: > >> Ben, >> Each plug-in instance has their -initWithAPIManager: method called, regardless of how they're created. Maybe you could do something like have a singleton which doles out custom IDs, and call it in the -initWithAPIManager: method. Then, whenever you go to use the custom data, if the id for that data doesn't match the id generated in -initWithAPIManager:, you throw it out and generate unique data for it. Would that work? >> >> Darrin > > _______________________________________________ > 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 _______________________________________________ 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: Invalidating custom data based on clip
by Ben Syverson 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Darrin, Hmm, on second thought, this regenerates the data each time the project is opened, which is less than optimal. It's potentially very expensive to generate this particular custom data, so I'd prefer to do it only once. For example, imagine computing optical flow for the clip. Currently I'm checking out the first frame as a bitmap and reading a few bytes to make sure they match the stored values. However, this is obviously stupid, because two different clips might have identical first frames. I would add a "Regenerate" button using the custom UI, but then that rules out FCP X. Any other ideas? Ben On Nov 28, 2011, at 11:23, Darrin Cardani wrote: > Ben, > Each plug-in instance has their -initWithAPIManager: method called, regardless of how they're created. Maybe you could do something like have a singleton which doles out custom IDs, and call it in the -initWithAPIManager: method. Then, whenever you go to use the custom data, if the id for that data doesn't match the id generated in -initWithAPIManager:, you throw it out and generate unique data for it. Would that work? > > Darrin _______________________________________________ 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: Invalidating custom data based on clip
by Ben Syverson 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Ah, yes, that's a great idea! Thanks Darrin, Ben On Nov 28, 2011, at 11:23, Darrin Cardani wrote: > Ben, > Each plug-in instance has their -initWithAPIManager: method called, regardless of how they're created. Maybe you could do something like have a singleton which doles out custom IDs, and call it in the -initWithAPIManager: method. Then, whenever you go to use the custom data, if the id for that data doesn't match the id generated in -initWithAPIManager:, you throw it out and generate unique data for it. Would that work? > > Darrin > > On Nov 28, 2011, at 8:36 AM, Ben Syverson wrote: > >> Hi all, >> >> I have an FxPlug that generates unique custom data for each clip. I'm concerned that currently, a user can copy the effect and paste it into another effect, and my FxPlug doesn't know that data is now invalid. >> >> Is there a convenient way to identify the current clip and compare against it? Or is there a better way of going about this? >> >> Or should I just tell users "don't do that?" >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> 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 > > _______________________________________________ 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: Invalidating custom data based on clip
by Darrin Cardani 28 Nov '11

28 Nov '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Ben, Each plug-in instance has their -initWithAPIManager: method called, regardless of how they're created. Maybe you could do something like have a singleton which doles out custom IDs, and call it in the -initWithAPIManager: method. Then, whenever you go to use the custom data, if the id for that data doesn't match the id generated in -initWithAPIManager:, you throw it out and generate unique data for it. Would that work? Darrin On Nov 28, 2011, at 8:36 AM, Ben Syverson wrote: > Hi all, > > I have an FxPlug that generates unique custom data for each clip. I'm concerned that currently, a user can copy the effect and paste it into another effect, and my FxPlug doesn't know that data is now invalid. > > Is there a convenient way to identify the current clip and compare against it? Or is there a better way of going about this? > > Or should I just tell users "don't do that?" > > Thanks, > > Ben > > _______________________________________________ > 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 _______________________________________________ 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