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: Paul Schneider <email@hidden>
- Date: Fri, 23 May 2008 10:08:31 -0400
Hi, Pauli,
thank you very much for providing the FloatingWindow FxPlug sample.
I've had the users that were reporting problems with our plugin in
FCP 6.0.3 run the sample, and it works as expected for them, so the
problem is clearly in our FxPlug code.
Were you able to reproduce the problem with my bars & tone steps? My
guess is that this what your users are hitting. Even if not, someone
is bound to hit it eventually.
Can you elucidate a bit as to why the getAPI call is necessary here,
and why one must check for its return value before proceeding?
I'm only getting the current value of the parameter so I can increment
it to get the new value. Getting the value first shouldn't be
necessary. You do have to make sure you are assigning a new value to
the parameter (one that is not identical to the old value).
Also, I notice you're releasing the value returned from the get
method. Is it always the case that -getCustomParameterValue retains
the object before returning? That doesn't seem intuitive (I had
expected that the setter retains but the getter doesn't, like
standard Cocoa classes).
You're right - that was a mistake on my part. Values returned from -
getCustomParameterValue shouldn't be released. It looks like FCP is
incorrectly returning retained references from -
getCustomParameterValue; I've filed a bug. Motion does NOT return a
retained reference from getCustomParameterValue.
- Paul
On May 23, 2008, at 9:24 AM, Pauli Ojala wrote:
Paul,
thank you very much for providing the FloatingWindow FxPlug sample.
I've had the users that were reporting problems with our plugin in
FCP 6.0.3 run the sample, and it works as expected for them, so the
problem is clearly in our FxPlug code.
The only significant difference is in the -forceRerender method. I
have a few questions concerning your implementation, more
specifically this section:
----
NSNumber* oldValue = nil;
if ([getApi getCustomParameterValue:&oldValue
fromParm:kParamID_Button])
{
NSNumber* newValue = [NSNumber numberWithInt:[oldValue intValue] +
1];
[actApi startAction:self];
[setApi setCustomParameterValue:newValue toParm:kParamID_Button];
[actApi endAction:self];
}
[oldValue release];
----
My old version didn't call -getCustomParameterValue at all, it just
went straight ahead with the actionAPI/setAPI calls. I guess that's
probably why my code started failing. Can you elucidate a bit as to
why the getAPI call is necessary here, and why one must check for
its return value before proceeding?
Also, I notice you're releasing the value returned from the get
method. Is it always the case that -getCustomParameterValue retains
the object before returning? That doesn't seem intuitive (I had
expected that the setter retains but the getter doesn't, like
standard Cocoa classes).
The FxPlug API reference doesn't seem to make any mention of the
retain/release policy for these methods. If it's right that -
getCustomParameterValue always retains, my code has been leaking a
scary amount of parameter value objects... I'd encourage you to add
a big warning about this in the documentation!
Best regards,
Pauli
--
Pauli Ojala
Lacquer oy/ltd
email@hidden
On 14.5.2008, at 21.14, 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