site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi, Pauli, Hope that helps, - Paul On May 16, 2008, at 10:12 AM, Pauli Ojala wrote: Hello Paul, thanks for looking into the issue. Btw -- you wrote: -- Pauli Ojala Lacquer oy/ltd pauli@lacquer.fi Hi, Pauli, I did some more research, and I think I might understand the problem. Let me know if that matches what you see. - Paul On May 14, 2008, at 2:14 PM, Paul Schneider wrote: Hi, Pauli, Thanks, - Paul <FloatingWindow.zip> On May 14, 2008, at 8:18 AM, Pauli Ojala wrote: Pauli Ojala _______________________________________________ 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/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... But if you are managing your own floating window, you're giving the user a way to change parameters that aren't in the viewer. Final Cut isn't set up to handle that. Is it a potential stability issue that we're allowing the user to do this in FCP? Should we do something about it? I was able to reproduce the problem with my test plugin by loading something else in the viewer. If I loaded bars & tone into the viewer, the canvas stopped redrawing in response to clicks in my plugin's floating window. If I reloaded the clip with my filter applied into the viewer, the floating window started working again. I've filed an enhancement request against Final Cut, to the effect that we should redraw the canvas on any parameter change, not just a parameter loaded into the viewer. In the meantime, I think you'll either have to instruct your customers about this limitation, or avoid the problem by making your dialog modal (so the user has to close it before they can load something else into the viewer). The first solution allows for a more flexible workflow, but might also lead to confusion. I haven't personally seen the problem on my own systems, only a few of our customers have reported it. I'll ask them to try the barebones Cocoa window Fxplug you wrote, to see if it works correctly. I'll let you know when there's more information. But if you are managing your own floating window, you're giving the user a way to change parameters that aren't in the viewer. Final Cut isn't set up to handle that. Is it a potential stability issue that we're allowing the user to do this in FCP? Should we do something about it? On 14.5.2008, at 23.31, Paul Schneider wrote: It turns out that in Final Cut, we only redraw the canvas in response to a parameter change if the parameter is visible in the viewer. This means that we don't update if hidden parameters are changed (a known bug). It also means that if you load something else into the viewer (a different clip in your timeline, say), we will stop updating when you change your parameters. Usually, this isn't an issue, because the user can only change parameters that are loaded in the viewer. But if you are managing your own floating window, you're giving the user a way to change parameters that aren't in the viewer. Final Cut isn't set up to handle that. This behavior isn't new with 6.0.3; it's always been like this. But it's possible that some of your customers noticed it around the time they upgraded. there were very few FxPlug-related changes in Final Cut 6.0.3, and I'm not aware of any that might have caused a difference in our behavior here. I wrote a very simple FxPlug filter that manages its own floating Cocoa window, with a button in the window to trigger a redisplay. It seems to work correctly in 6.0.3. I've attached it - if it works on your systems, perhaps you can spot a difference between this plugin and what you're doing? Also, when you say "we're receiving reports", do you mean that you've tested your plugin in 6.0.3, and something that always used to work now always fails? Or do you just mean that some of your customers are reporting problems? Hello, I'm hoping someone on the FCP FxPlug team might be able to give some insight into a problem that our users have been experiencing. Our plugin Conduit uses a private Cocoa window for its nodal effect editor UI. When the user modifies something in the editor window, we use FxCustomParameterActionAPI and FxParameterSettingAPI to set a new value for a custom parameter on the FxPlug instance. Ever since Motion 2.0, this method has worked fine for triggering a render in the host application. This way we don't need to run the editor modally; the user can keep the window open while moving around on the host app's timeline, which is very convenient. Now we're receiving reports that the FCP 6.0.3 update has broken this behaviour. Apparently the Viewer doesn't update anymore in response to events in our editor window. However, one user mentioned that switching from FCP to Finder and then back to FCP does trigger the expected render in the Viewer in FCP. So it sounds like the problem might be some fairly trivial bug somewhere -- as in the viewer not getting the equivalent of [- NSView setNeedsDisplay:] after the FxPlug parameter has been modified...? This email sent to pschneider@apple.com This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com