Re: Guidelines for FxDynamicParameter
Re: Guidelines for FxDynamicParameter
- Subject: Re: Guidelines for FxDynamicParameter
- From: Darrin Cardani <email@hidden>
- Date: Fri, 08 Sep 2017 09:18:09 -0700
Ben,
Thanks for the explanation. Both #1 and #2 sound like bugs to me. Please file
Radars. I admit I’m surprised by the first one! Very strange!
For #3, that sounds normal to me. The parameter and ID associations are stored
in something like a C++ map or an Objective-C dictionary, so their order when
iterating may not match the order you see them in the UI. The host app does add
up to 3 additional parameters. The Mix parameter, as you’ve discovered, and it
may also add 2 hidden checkboxes. One says that points should be in the input
image space vs. the output image space, and the other says that point
parameters have their Y-values flipped. These are for legacy plug-ins. At some
point we switched how we represent points and needed to add these flags so that
older instances of plug-ins would render how they used to and newer instances
would render the new way. You shouldn’t ever touch them. (In fact, I’m not sure
if we support those older versions anymore, so we might even be able to remove
them!) They are harmless.
Darrin
> On Sep 7, 2017, at 7:21 PM, Ben Syverson <email@hidden> wrote:
>
> Darrin,
>
> Yeah, this is what I expected for FCPX, and for that reason, I don’t think my
> FCPX templates will expose any parameters other than the “Show Editor” button.
>
> As for my plugin: it’s conceptually similar to Conduit. The user will open my
> Editor window, where they can add and remove elements that have parameters.
>
> When the Editor is closed, my plugin will compare the old param list to the
> new one. If the IDs of the params haven’t changed, the plugin will use the
> FxParameterSettingAPI to update the param values. If the list has changed
> (params added or deleted), my plugin will remove all of the previous dynamic
> parameters, create the new ones, and set their values.
>
> The three issues I’m running into currently are:
>
> 1) I’m creating parameter subgroups dynamically, and at the end of every
> group, the same Mix slider is repeated:
>
> <Screenshot 2017-09-07 21.16.26.png>
>
> 2) In my -removeAllDynamicParameters method, calling -removeParameter: on the
> FxDynamicParameterAPI is an instant crash. I’m calling it on the main thread,
> between calls to the action API (-startAction: and -endAction:)
>
> <Screenshot 2017-09-07 21.18.33.png>
>
> 3) When I attempt to iterate over the parameters using -parameterIDAtIndex:,
> I get strange results. My dynamic parameters are first, then come the two I
> create in -addParameters, then come two parameters I didn’t create (10001 and
> 10002, Mix and ???).
>
> Id at index 0: 46 // First dynamic param
> Id at index 1: 49
> Id at index 2: 50
> (snip…)
> Id at index 15: 75
> Id at index 16: 800 // Show Editor button
> Id at index 17: 808 // Custom param to store project data
> Id at index 18: 10001 // Mix
> Id at index 19: 10002 // ??
>
> Any insights would be greatly appreciated!
>
> Ben
>
>
>> On Sep 7, 2017, at 12:15, Darrin Cardani <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>> Oh - one other thing just occurred to me. Are you looking at this in Motion
>> or FCPX. While FCPX will properly read and create the dynamic parameters
>> stored in a template, the template will not be re-saved with new parameters
>> if the user performs an action that makes the parameter list change while in
>> FCPX.
>>
>> So, let’s say you have an “Add color” button in your plug-in’s UI. In
>> Motion, the user can press “Add Color” several times to add more color
>> parameters to the parameter list. When they save the document, all the
>> colors they added will be saved. When they re-open the document, Motion will
>> show all the colors they added.
>>
>> Now let’s say the user makes a Final Cut Effect in Motion and they add 2
>> colors. They publish all the parameters, including the 2 extra colors and
>> save the template. Now they go into FCPX and apply the effect to a clip.
>> They should see all the parameters, including the 2 extra colors.
>>
>> At this point, if the user presses the “Add Color” button, the new 3rd color
>> will be added to the inspector and your plug-in will be aware of it. But if
>> they quit and re-open their project, the 3rd color will be gone because FCPX
>> does not update the template file. (And it would be bad if it did, because
>> other projects using that template would get updated, which is probably not
>> what the user wants.)
>>
>> Darrin
>>
>>> On Sep 7, 2017, at 10:00 AM, Darrin Cardani <email@hidden
>>> <mailto:email@hidden>> wrote:
>>>
>>> Ben,
>>>
>>> I’m a little lost as to what you’re trying to do. Can you walk me through a
>>> first use of your plug-in and then a second use of it? For dynamic
>>> parameters your plug-in added before the user saved, your plug-in shouldn’t
>>> have to create them on document open. They should be created for you by the
>>> host app. If you’re not seeing that, let me know. (But they won’t be
>>> created until after -addParameters is called.)
>>>
>>> The FxRetrievalAPIs should be available during -addParameters. I don’t know
>>> that we’ve ever tested whether they work properly during that time, though!
>>> (One doesn’t usually need to retrieve parameter values when you just
>>> created the parameter in the same function and set its value.)
>>>
>>> Darrin
>>>
>>>> On Sep 6, 2017, at 6:44 PM, Ben Syverson <email@hidden
>>>> <mailto:email@hidden>> wrote:
>>>>
>>>> Darrin,
>>>>
>>>> Okay, that makes some sense. Thank you!
>>>>
>>>> My second hidden parameter stores what is essentially a JSON
>>>> representation of the param array, so that can be used to create the
>>>> parameters.
>>>>
>>>> But in order to create the parameters in -addParameters, I would need to
>>>> retrieve that JSON value from the hidden param. Is it possible to use
>>>> FxParameterRetrievalAPI within -addParameters, and if so, what time should
>>>> I pass in?
>>>>
>>>> Or should I add the dynamic parameters outside of -addParameters?
>>>> Currently I’m checking to see if they exist during -renderOutput: and if
>>>> not, I’m creating them on the main thread. But that feels hacky.
>>>>
>>>> Thanks for your help!
>>>>
>>>> Ben
>>>>
>>>>
>>>>> On Sep 6, 2017, at 11:50, Darrin Cardani <email@hidden
>>>>> <mailto:email@hidden>> wrote:
>>>>>
>>>>> 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
>>>>>> <mailto: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
>>>>>> <mailto:email@hidden>)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>>
>>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Pro-apps-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden <mailto: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