May 2014 - Pro-apps-dev - lists.apple.com

Re: Version of Template files for FCP X
by George Toledo 08 May '14

08 May '14

...and a bit of a hassle for debugging programming of fxplugins. On May 8, 2014, at 12:11 PM, Paul Miller <paul(a)fxtech.com> wrote: >> I so wish that FCP X would be capable to run FxPlug plugins natively >> without the necessity to go through these templates!! The templates are >> such a hinderance and trouble maker! > > Maybe we can jump in front of that bus together. > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/pro-apps-dev/gtoledo3%40gmail.com > > This email sent to gtoledo3(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Version of Template files for FCP X
by Paul Miller 08 May '14

08 May '14

I so wish that FCP X would be capable to run FxPlug plugins natively without the necessity to go through these templates!! The templates are such a hinderance and trouble maker! Maybe we can jump in front of that bus together. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Version of Template files for FCP X
by Andreas Kiel 08 May '14

08 May '14

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Version of Template files for FCP X
by Christoph Vonrhein 08 May '14

08 May '14

_______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: A user-changed-parameter update issue
by Darrin Cardani 05 May '14

05 May '14

On May 2, 2014, at 11:41 AM, Paul Miller <stelefx(a)gmail.com> wrote: > I'm using the new Buttons in FxPlug3, and one of my buttons ends up causing several parameter values to change. But the sequence of parameter update events is weird, and causes a different control to not function properly. > > Say I have this: > > [BUTTON] > Slider 1 > Slider 2 > Slider 3 > > CheckBox [OFF] > Slider 4 [Disabled] > > When CheckBox is turned on I enable Slider 4, and disable it when CheckBox is turned off. Okay fine. > > Now, I click BUTTON which causes Slider 1-3 to have new values stored in them. This is working. > > Right after this, I click CheckBox, but instead of getting a user-changed-parameter message on the CheckBox, I get user-changed-parameter messages on Sliders 1-3. > > So now CheckBox is ON but Slider 4 is still disabled, because I never got the changed message. If I now click CheckBox, then I get the proper message, and because CheckBox is now off again I disable Slider 4 (which is already disabled). At this point turning CheckBox on causes the proper update to come in. > > Any ideas? Paul, That definitely sounds wrong! Is this in FCPX, Motion, or both? Please file a bug on it. One possible solution would be to always check the status of the checkbox at the end of -parameterChanged: and enable/disable Slider 4 as necessary, regardless of which parameter changed. It’s kind of a sledgehammer approach, but might solve the issue until we can get a proper fix into the app. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

A user-changed-parameter update issue
by Paul Miller 02 May '14

02 May '14

Say I have this: [BUTTON] Slider 1 Slider 2 Slider 3 CheckBox [OFF] Slider 4 [Disabled] Any ideas? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I'm using the new Buttons in FxPlug3, and one of my buttons ends up causing several parameter values to change. But the sequence of parameter update events is weird, and causes a different control to not function properly. When CheckBox is turned on I enable Slider 4, and disable it when CheckBox is turned off. Okay fine. Now, I click BUTTON which causes Slider 1-3 to have new values stored in them. This is working. Right after this, I click CheckBox, but instead of getting a user-changed-parameter message on the CheckBox, I get user-changed-parameter messages on Sliders 1-3. So now CheckBox is ON but Slider 4 is still disabled, because I never got the changed message. If I now click CheckBox, then I get the proper message, and because CheckBox is now off again I disable Slider 4 (which is already disabled). At this point turning CheckBox on causes the proper update to come in.

1 0

A user-changed-parameter update issue
by Paul Miller 02 May '14

02 May '14

Say I have this: [BUTTON] Slider 1 Slider 2 Slider 3 CheckBox [OFF] Slider 4 [Disabled] Any ideas? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I'm using the new Buttons in FxPlug3, and one of my buttons ends up causing several parameter values to change. But the sequence of parameter update events is weird, and causes a different control to not function properly. When CheckBox is turned on I enable Slider 4, and disable it when CheckBox is turned off. Okay fine. Now, I click BUTTON which causes Slider 1-3 to have new values stored in them. This is working. Right after this, I click CheckBox, but instead of getting a user-changed-parameter message on the CheckBox, I get user-changed-parameter messages on Sliders 1-3. So now CheckBox is ON but Slider 4 is still disabled, because I never got the changed message. If I now click CheckBox, then I get the proper message, and because CheckBox is now off again I disable Slider 4 (which is already disabled). At this point turning CheckBox on causes the proper update to come in.

1 0

Re: Motion Color parameter round-tripping
by Paul Miller 02 May '14

02 May '14

On 5/1/2014 5:46 PM, Darrin Cardani wrote: On May 1, 2014, at 3:29 PM, Darrin Cardani <dcardani(a)apple.com> wrote: On May 1, 2014, at 3:18 PM, Paul Miller <paul(a)fxtech.com> wrote: On 5/1/2014 4:56 PM, Darrin Cardani wrote: It’s converting them between color spaces. I believe that the values you send to -addColorParameter: are in sRGB because that’s the color space that the user interface operates in. But your filter will process them in either linear or gamma-corrected RGB (depending on your -properties) with Rec. 709 primaries rather than sRGB primaries. But if I say I work in rec709 shouldn't it assume my default colors are also in rec709 and not convert them for me? It seems wrong to munge my default colors and give me different ones. Can you give me an implementation of the reverse of your function so I can pre-reverse-munge my defaults (when I define the parameter) so I get back what I gave you initially? Yeah, I agree that it’s weird for setting some parameter values. I think the assumption is that you’ll pick a default via the color picker. Like, you’ll make a version of the plug-in with the color picker, and you’ll either play with it, or give it to a designer or beta tester, and they’ll pick some value from it that they think should be the default. In that case, you’d want to be able to just enter the numbers from the UI into your code without converting from sRGB to Rec. 709. But that’s obviously not always the case. I’ll see if I can find a conversion routine. OK, here’s the conversion routine: color = pow(color, 1.956); if (color <= 0.0031308) { color = 12.92 * color; } else { color = 1.055 * pow(color, 1.0 / 2.4) - 0.055; } Let me know if that helps. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Thanks Darrin - that helped perfectly. I ran my default colors through that when defining the parameters and now I'm getting back the values I'm expecting.

1 0

Re: Motion Color parameter round-tripping
by Darrin Cardani 01 May '14

01 May '14

On May 1, 2014, at 3:29 PM, Darrin Cardani <dcardani(a)apple.com> wrote: > > On May 1, 2014, at 3:18 PM, Paul Miller <paul(a)fxtech.com> wrote: > >> On 5/1/2014 4:56 PM, Darrin Cardani wrote: >>> It’s converting them between color spaces. I believe that the values you send to -addColorParameter: are in sRGB because that’s the color space that the user interface operates in. But your filter will process them in either linear or gamma-corrected RGB (depending on your -properties) with Rec. 709 primaries rather than sRGB primaries. >> >> But if I say I work in rec709 shouldn't it assume my default colors are also in rec709 and not convert them for me? It seems wrong to munge my default colors and give me different ones. >> >> Can you give me an implementation of the reverse of your function so I can pre-reverse-munge my defaults (when I define the parameter) so I get back what I gave you initially? > > Yeah, I agree that it’s weird for setting some parameter values. I think the assumption is that you’ll pick a default via the color picker. Like, you’ll make a version of the plug-in with the color picker, and you’ll either play with it, or give it to a designer or beta tester, and they’ll pick some value from it that they think should be the default. In that case, you’d want to be able to just enter the numbers from the UI into your code without converting from sRGB to Rec. 709. > > But that’s obviously not always the case. I’ll see if I can find a conversion routine. OK, here’s the conversion routine: color = pow(color, 1.956); if (color <= 0.0031308) { color = 12.92 * color; } else { color = 1.055 * pow(color, 1.0 / 2.4) - 0.055; } Let me know if that helps. Darrin _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Motion Color parameter round-tripping
by Paul Miller 01 May '14

01 May '14

On 5/1/2014 5:29 PM, Darrin Cardani wrote: On May 1, 2014, at 3:18 PM, Paul Miller <paul(a)fxtech.com> wrote: On 5/1/2014 4:56 PM, Darrin Cardani wrote: It’s converting them between color spaces. I believe that the values you send to -addColorParameter: are in sRGB because that’s the color space that the user interface operates in. But your filter will process them in either linear or gamma-corrected RGB (depending on your -properties) with Rec. 709 primaries rather than sRGB primaries. But if I say I work in rec709 shouldn't it assume my default colors are also in rec709 and not convert them for me? It seems wrong to munge my default colors and give me different ones. Can you give me an implementation of the reverse of your function so I can pre-reverse-munge my defaults (when I define the parameter) so I get back what I gave you initially? Yeah, I agree that it’s weird for setting some parameter values. I think the assumption is that you’ll pick a default via the color picker. Like, you’ll make a version of the plug-in with the color picker, and you’ll either play with it, or give it to a designer or beta tester, and they’ll pick some value from it that they think should be the default. In that case, you’d want to be able to just enter the numbers from the UI into your code without converting from sRGB to Rec. 709. _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Yeah, I'm afraid your assumptions about how it will be done vs. how we actually do it are off a bit. Can't we just have a developer-friendly way of doing this stuff, like FCP7 had? Like set a flag in our Info.plist and have FCP just expose all of our groups, input pots, and other parameters the way we intended? What you have might be nice for power-users, but it literally makes me want to jump in front of a bus. If you read a tweet "Paul Miller killed by bus", you don't want that on your conscious do you?

1 0