Re: getting a filter input's current frame number
Re: getting a filter input's current frame number
- Subject: Re: getting a filter input's current frame number
- From: Darrin Cardani <email@hidden>
- Date: Thu, 8 Oct 2009 10:22:04 -0700
On Oct 7, 2009, at 4:53 PM, Brian Gardner wrote:
This quickly turned into a show-stopper for me.
Pretty much all of the plugins I was writing
became immediately useless. So, I just stopped developing.
I'm really sorry to hear that. That really bums me out.
I think the schedule for the next point-zero FxPlug SDK release needs
to happen much sooner than expected.
Unfortunately, we can't do that. Legal tells me that we can't add new
functionality to the SDK until we have a paid release of the Studio
due to Sarbanes-Oxley (an obscure business law in the US). If it were
up to me, we'd have releases every few months, but sadly, it's not up
to me.
Being unable to get the current frame number from an input,
and consequently the corresponding 'current frame' from an image
parameter,
makes all image parameters effectively useless, as well.
As soon as a user changes the in-point, the filter gives the wrong
results.
FCP is an Editing app -- so, changing the in-point is kind of
critical functionality ....
Realistically, we can't tell FCP users to use our plugins "as long
as they don't edit them". :-)
I realize that it's much more cumbersome to do this, but couldn't you
have control which allows the user to set where to start getting
frames from in the image well clip? It means they'd have to match it
up by hand, which is a pain, but at least it makes what you're trying
to do possible.
BTW, because a corresponding problem exists with editing in-points
in Generators,
which makes image parameters useless there, I had re-written all my
FxGenerators
as FxFilters. Then, I hit this lack of -inPointOfInputFilter problem
in Filters. -- So, I have no work-around.
I've tried a half dozen work-arounds, and subsequently hit a half a
dozen bugs
(or missing APIs).
Have you filed those bugs? If not, they won't be getting fixed. We
can't fix any bugs that aren't in Radar (our bug database), so please
file them at:
<http://bugreporter.apple.com/>
Certainly, adding -inPointOfInputToFilter would be a huge necessary
step.
But, there seems to be a much broader underlying problem with
the handling of in-point changes, across all classes of effects (not
just filters).
To date, I have not written a single FxPlugin which will work
correctly when
the user starts to edit the in-point. This implies to me that the
APIs for
dealing with in-points in the FxPlug SDK really needs to be re-
addressed soon.
I hope we'll be able to add this functionality in the future.
*** I really believe that there should be some sort of (callback-
ish) methods
added to the FxBaseEffect class to allow the plugin to be informed
of in-point changes and "cloning" (e.g. caused by razor "cuts" or
"copy'n'paste").
A razor "cut" is effectively a clone of the clip along with an in-
point change to the clone.
The developer can optionally write (override) their own version of
these methods,
if they need the in-point tracking or cloning tracking functionality
(seems common).
If you read all the developer emails about these topics,
it seems that many of them are resolvable if there existed methods
in the FxBaseEffect class which would be invoked upon
the in-point change and/or cloning of an effect.
This would resolve all of the internal ID updating developers do,
as well as an frame number tracking that they keep tabs on internal
to the plugin.
Whether cloning is done to create a copy (from clipboard),
or to read it back in from disk (eg File->Open Project) -- seems like
this could just be a flag parameter passed to the (clone) callback
method.
This could also resolve a lot of initialization issues we've seen
crop up in emails.
This is an interesting idea. I'm not sure what it would take to
implement it, and I'm not sure of all the implications of doing it,
but please add this information to your bug about the in point API and
we'll consider it.
And I just want to say to any other developers out there with ideas,
now is a great time to give your ideas to us, as we're at the start of
our new development cycle. In another month or two we'll probably be
too busy implementing what we've come up with to start designing and
adding more stuff. So please let us know what you want now!
Thanks,
Darrin
--
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