Re: Guidelines for FxDynamicParameter
Re: Guidelines for FxDynamicParameter
- Subject: Re: Guidelines for FxDynamicParameter
- From: Ben Syverson <email@hidden>
- Date: Fri, 8 Sep 2017 18:15:39 -0500
Darrin,
Okay, for #3, that sounds good, although it’s counter-intuitive that the index
of the parameter list doesn’t correspond to the UI order. Perhaps that should
be reflected in the docs?
#1 is now rdar://34341983 <rdar://34341983>
I was able to resolve the crashing bug in #2 while removing parameters. It
turns out, you must remove the parameters from a group before you remove the
group itself. I don’t think that’s in the docs either, but it probably should
be. It would also be helpful as a convenience if removing the group would
simply remove all of the group’s parameters rather than crashing.
Thanks again for all your help!
Ben
> On Sep 8, 2017, at 11:18, Darrin Cardani <email@hidden> wrote:
>
> 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
>> <mailto: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