site_archiver@lists.apple.com Delivered-To: Pro-apps-dev@lists.apple.com Hi Brian, Sorry for the delay in responding; I was on vacation last week. - Paul On Aug 14, 2009, at 7:26 PM, Brian Gardner wrote: Hi, Darrin. Thank you for your suggestion about caching the generator's startTime. I gave this a try, but ran into difficulties. The main problem seems to be that the the startTimeForEffect returns a completely different value when renderOutput is called from the timeline versus the viewer. So, detecting changes between the current startTimeForEffect value and the cached value seems problematic. Because just double clicking the generator in the timeline to load it into the viewer (may) cause the value to become different, even though the generator has not been cut or trimmed. The startTimeForEffect, vs. the inPointOfTimelineForEffect, vs. the startTimeOfImageParm (with respect to a generator) all seems very confusing to me. Could you please explain what these are? I've read the docs, but they don't really say much beyond the method name. -- Brian On Aug 11, 2009, at 10:24 AM, Darrin Cardani wrote: Let me know if you have any questions. Here's the plugin I used: <ImageWellChangeTester.zip> Darrin On Aug 7, 2009, at 10:55 AM, Brian Gardner wrote: I'm tryng to get my head around what happens to a FxPlugin (especially a generator) when it is trimmed or cut inhalf then it's parts are moved around on timeline. And what a plugin which has reference image parameter(s) should/could do to appropriately update itself. I would assume the FCP 7 will make a copy of the generator (or clip+filter), then make two API method calls, to which our plugins can optionally respond: My plugin should respond to these two methods, and update it's internal state for accessing the appropriate frame ranges of it's reference image parameters to meet the new post-cut state of the edit. Is my assumption anywhere near correct? If so, what are those FxGenerator 2 methods to which my FxPlug should respond? If not, how does it really work? And how should/can my generator respond to a cut edit, so that it can appropriately access it's reference image parameters? -- Brian _______________________________________________ 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/dcardani%40apple.com -- Darrin Cardani dcardani@apple.com _______________________________________________ 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/pschneider%40apple.com _______________________________________________ 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... I think that the main problem you are running into is that you can't actually trim a generator in FCP. Just as generators don't have intrinsic dimensions, frame rates, or durations, they also do not have in and out points in Final Cut. So blading a generator is no different than putting a second generator on the timeline next to the first. You can see this with the built-in Caustics generator; if you blade it, the animation starts over at the cut. Similarly, if you drag the "in point" of the Caustics generator, you are just changing the duration. The animation still starts at the same frame. Of course, this is problematic if you have a generator with an image well that references real media, and you would like your generator to behave more like a proxy for that real media in the timeline. We don't have a good solution for that. As to your other issues: the timing differences between the viewer and the timeline (canvas) are long-standing in Final Cut. Basically, the canvas is calling you to render in the context of an item in the sequence, while the viewer calls you to render in the context of just the item (as if it wasn't in a sequence, but you just opened it from a bin). This causes confusion with timing, especially if you are using the TimingAPI. You can see the effects of this in some of our built-in effects as well. This causes a lot of confusion, but we can't change it without some fairly large architectural changes. The way we send you -parameterChanged for image parameters when they haven't actually changed is just a bug. In short, I don't think you'll be able to accomplish what you want. It sounds like you have a generator that references media, and you want to apply the same trimming that's been done to the generator to your referenced media. But you can't, because generators aren't trimmed like media in FCP. This seems like a symptom of a larger problem, which is that many developers would like to write a plugin which is more like a media proxy than a generator. In your case, in addition to allowing the user to set in and out points on your generator, you probably also want to constrain the duration of the generator to match the media. Please file a bug detailing all the things you'd like to be able to do. Immediately after a Cut (razor), the 2nd half returns a -1 as the startTimeForEffect (as well as a -1 for the inPoint and outPoint). Once it renders into the viewer, the numbers are then changed to be relative to the viewer (not timeline). Then, once it is rendered into the canvas (by moving the playhead to be over the 2nd half) of the cut generator, the numbers are again altered to be relative to the timeline. I vaguely remember someone else having issues with the startTime being unexpectedly 0. Perhaps they'd hit the same viewer vs canvas issue? Getting a generator's image parameter to correspondingly react to a cut seems rather daunting. Perhaps I am just missing something, and a better understanding of these TimingAPI methods would resolve it? PS: In FCP, changing any parameter (except the image parameter, itself) seems to cause a parameterChange message for the image parameter. This is the opposite of what I was expecting. Brian, The way you suggest it should work would be a good design. However, that's not how it works currently. :( Paul's out on vacation, and he'd have a better idea of how it works in FCP, but I'll go over what Motion does. I believe that FCP does basically the same thing, but am not positive. An image well is a parameter like any other. When you change the clip duration or the start point, you change the value of the parameter, so the host app will ask your plugin to re-render, just as if the user changed the value of a slider or checkbox. It should first call your plugin's -parameterChanged: method with the ID of the image parameter, but upon testing, I've discovered that it does not (at least in Motion - you should try in FCP). This is a bug you should write up. So all your plugin knows is that something changed and it should rerender. One way you can track what's changed is by caching the image in the image well's start time and duration. In your - renderOutput: method, you can use the FxTimingAPI to see if the image parameter's start time or duration is different from your cached value and do the appropriate thing if it's changed. It's not as convenient as getting a -parameterChanged: message, or a notification directly, but it should be workable. 1.) a method invoked to the original generator passing it the old and new duration. (to the 1st half of cut object) 2.) another method invoked to signal the new copy of the generator, passing it the old and new relative start frame offset. (to the 2nd half of the cut generator) This email sent to dcardani@apple.com This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com