Re: how trims & cuts effect reference image wells
Re: how trims & cuts effect reference image wells
- Subject: Re: how trims & cuts effect reference image wells
- From: Brian Gardner <email@hidden>
- Date: Fri, 14 Aug 2009 17:26:51 -0700
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.
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.
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.
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?
-- Brian
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.
On Aug 11, 2009, at 10:24 AM, Darrin Cardani wrote:
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.
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:
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)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Darrin Cardani
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