Re: Guidelines for FxDynamicParameter
Re: Guidelines for FxDynamicParameter
- Subject: Re: Guidelines for FxDynamicParameter
- From: Darrin Cardani <email@hidden>
- Date: Wed, 06 Sep 2017 09:50:07 -0700
Ben,
This is one of the more confusing aspects of our apps. When the user tells the
app to add a plug-in to some footage, whether via a pop-up menu, dragging and
dropping, cut/copy and pasting, or selecting it in a list and pressing the
“Apply” button, the app first creates an instance of the plug-in and puts it on
the drag & drop pasteboard. This is where your -addParameters method will get
called.
The application will then create a copy of what’s on the pasteboard and apply
that copy to the footage. When creating a copy, it will call your plug-in’s
-initWithAPIManager: method, but won’t call -addParameters. Since it already
has an instance of the plug-in, it just copies the parameters itself. This
means that anything you set up in -addParameters that isn’t a parameter will
not actually make it into the instance that the user is actually using.
I believe the reason we do this is so we have a single path in our code that
all plug-in instantiation goes through, regardless of how the user interacted
with the app. The reason we make a copy instead of just applying the one on the
pasteboard is because the user can do a cut and paste or copy and paste
multiple times. So we have to leave one on the pasteboard for that scenario.
So I see a few ways you could deal with this:
Set up your array in -initWithAPIManager:. You know the first 2 parameters are
always the same and have the same IDs, so just add them to your array there.
If you have a naming scheme that allows you to discern parameters or their
types, you can iterate over the parameters you have and call
[-FxDynamicParameterAPI parameter:name:] to get the name of each parameter and
figure out its type from that, and do away with the array.
Keep a 3rd hidden parameter that is your array of parameters. Then it will get
copied when your parameters get copied.
Let me know if any of those will work. Generally, if your plugin has data that
can’t be generated at runtime, you need to stick it into a parameter for the
app to save it. If you don’t do that, how are you planning on regenerating the
list of the dynamic parameters when the user opens a saved document?
Darrin
> On Sep 6, 2017, at 6:53 AM, Ben Syverson <email@hidden> wrote:
>
> Hi all,
>
> I’m working on a project that uses dynamic parameter creation, and running
> into issues.
>
> I have two params which are always present (a “Show Editor” button and a
> hidden custom parameter to store a project file). I’m adding these in
> addParameters.
>
> In order to keep track of my parameter list, I’m using an NSMutableArray
> property on the instance, self.paramsByIndex. So in addParameters, I’m adding
> my first two parameters to my array.
>
> The first problem is that when I’m updating the paramList, my first two
> params aren’t there. Is addParameters called on a separate instance of my
> FxPlug?
>
> It’s making it really difficult to keep my list of parameters in sync with
> what’s returned from the dynamic API (parameterIDAtIndex:, etc).
>
> Are there any guidelines for how & when to manage dynamic parameters? At this
> point, I’m printing NSLogs to try to understand which of my FxPlug methods
> are called in what order, and whether they’re all coming from the same
> instance.
>
> Thanks!
>
> Ben
> _______________________________________________
> 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