Re: FCP 6.0.3 and FxCustomParameterAction updates
Re: FCP 6.0.3 and FxCustomParameterAction updates
- Subject: Re: FCP 6.0.3 and FxCustomParameterAction updates
- From: Pauli Ojala <email@hidden>
- Date: Fri, 16 May 2008 17:12:42 +0300
Hello Paul,
thanks for looking into the issue.
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.
Btw -- you wrote:
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?
--
Pauli Ojala
Lacquer oy/ltd
email@hidden
On 14.5.2008, at 23.31, Paul Schneider wrote:
Hi, Pauli,
I did some more research, and I think I might understand the problem.
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.
Let me know if that matches what you see.
- Paul
On May 14, 2008, at 2:14 PM, Paul Schneider wrote:
Hi, Pauli,
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?
Thanks,
- Paul
<FloatingWindow.zip>
On May 14, 2008, at 8:18 AM, Pauli Ojala wrote:
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...?
Pauli Ojala
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden