August 2011 - Pro-apps-dev - lists.apple.com

Re: .moef parameter ids
by Darrin Cardani 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Aug 24, 2011, at 9:58 AM, Darrin Cardani wrote: > On Aug 24, 2011, at 9:54 AM, Paul Miller wrote: >> It comes down to the root of my original question. The parameter ids in the "filter" section of the XML are by in-code ID - as I defined them in the code. >> >> The other parameter IDs for the published section are apparently from creation order, starting at 1. >> >> Lets say I have a parameter ID of 10 in the code and it's the first parameter I created. The published section will have it with an id of 1, and the filter section with an id of 10. >> >> Now in the future I add a new parameter with an id of 9 and put it before the original one. The previous control will now be the second one in the published list, not the first anymore. If I don't update the moef it seems it will think parameter id=10 is still the first parameter in the published section but instead parameter id=9 will be. I don't know how it's supposed to deal with that - I haven't tried it either :-) > > Oh, I see. Yeah, that seems like it would be a problem. I'll see if anyone here thinks differently (no pun intended). Oh, actually, I forgot, the parameters don't have to be in order. Here's a test I just ran: 1) Create a new Final Cut Effect in Motion 2) Apply the Hue/Saturation filter to the effect source drop zone 3) Publish the Hue and Saturation parameters 4) Save the effect 5) Open the effect in a text editor and look for the "publishSettings" section. Note that the parameters are id=1 for Hue and id=2 for Saturation. 6) In Motion, click on the "Project" layer in the layer list and select the "Project" tab in the Inspector. 7) Drag the Saturation parameter so it's above the Hue parameter 8) Save 9) Re-open the effect in a text editor and look for the "publishSettings" section. Note that now the Saturation is first, but its id is still 2, and Hue is second, but its id is still 1. So it shouldn't be a problem. You should be able to insert a new parameter above the old one, but with a higher ID. Darrin -- Darrin Cardani dcardani(a)apple.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Paul Miller 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Now in the future I add a new parameter with an id of 9 and put it before the original one. The previous control will now be the second one in the published list, not the first anymore. If I don't update the moef it seems it will think parameter id=10 is still the first parameter in the published section but instead parameter id=9 will be. I don't know how it's supposed to deal with that - I haven't tried it either :-) Oh, I see. Yeah, that seems like it would be a problem. I'll see if anyone here thinks differently (no pun intended). This is why I expected to see the same parameter id used in all parameter references, and was confused by why one seemed to use a different system than the other. This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Darrin Cardani 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Aug 24, 2011, at 9:54 AM, Paul Miller wrote: >> It shouldn't mess up the published list if you add an FxPlug parameter later. What makes you think that? (I haven't actually tried it - but I can't think of anything that would mess it up.) As always, if you do add parameters later, just make sure you use versioning (via the FxVersioning API) so you can recognize older instances of your plug-in. > > It comes down to the root of my original question. The parameter ids in the "filter" section of the XML are by in-code ID - as I defined them in the code. > > The other parameter IDs for the published section are apparently from creation order, starting at 1. > > Lets say I have a parameter ID of 10 in the code and it's the first parameter I created. The published section will have it with an id of 1, and the filter section with an id of 10. > > Now in the future I add a new parameter with an id of 9 and put it before the original one. The previous control will now be the second one in the published list, not the first anymore. If I don't update the moef it seems it will think parameter id=10 is still the first parameter in the published section but instead parameter id=9 will be. I don't know how it's supposed to deal with that - I haven't tried it either :-) Oh, I see. Yeah, that seems like it would be a problem. I'll see if anyone here thinks differently (no pun intended). Darrin -- Darrin Cardani dcardani(a)apple.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Paul Miller 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… It shouldn't mess up the published list if you add an FxPlug parameter later. What makes you think that? (I haven't actually tried it - but I can't think of anything that would mess it up.) As always, if you do add parameters later, just make sure you use versioning (via the FxVersioning API) so you can recognize older instances of your plug-in. It comes down to the root of my original question. The parameter ids in the "filter" section of the XML are by in-code ID - as I defined them in the code. The other parameter IDs for the published section are apparently from creation order, starting at 1. Lets say I have a parameter ID of 10 in the code and it's the first parameter I created. The published section will have it with an id of 1, and the filter section with an id of 10. Now in the future I add a new parameter with an id of 9 and put it before the original one. The previous control will now be the second one in the published list, not the first anymore. If I don't update the moef it seems it will think parameter id=10 is still the first parameter in the published section but instead parameter id=9 will be. I don't know how it's supposed to deal with that - I haven't tried it either :-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Darrin Cardani 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Aug 24, 2011, at 9:43 AM, Paul Miller wrote: > On 8/24/2011 11:24 AM, Darrin Cardani wrote: >> >> On Aug 24, 2011, at 8:46 AM, Paul Miller wrote: >> >>> I'm trying to make some sense of the parameter IDs in the .moef files, since I am writing some code to generate about 250 of them. >>> >>> In the publishSettings and sceneNode elements, parameters seem to have ids based on their created index (ie. they start at 1). >>> >>> But in the filter element parameters have ids that match the ids I gave them in the code. >>> >>> How can I relate one to the other? (since I want to publish some of them depending on the values of other parameters). >> >> I'm not sure I fully understand what you're asking. Are you trying to publish some of your FxPlug's parameters based on the values of some of the scene node's parameters? For example, if the scale of an element is over 50%, then publish your plug-in's color parameter, or something like that? >> >> The Motion XML format is described here: >> >> <http://developer.apple.com/library/mac/#documentation/AppleApplications/Con…> >> >> Generally, scene nodes have IDs that are sequential because the user can create any number of them, but their parameters have fixed IDs. For example, Transform is always id 100 and Position id 101, I believe. > > Ok I understand the sequential part of it. But it does mean if I add a parameter to an FxPlug later it'll mess up the published list, right? > > I'll do my XML edits by parameter name instead - bypass the whole issue. It shouldn't mess up the published list if you add an FxPlug parameter later. What makes you think that? (I haven't actually tried it - but I can't think of anything that would mess it up.) As always, if you do add parameters later, just make sure you use versioning (via the FxVersioning API) so you can recognize older instances of your plug-in. Darrin -- Darrin Cardani dcardani(a)apple.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Paul Miller 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 On Aug 24, 2011, at 8:46 AM, Paul Miller wrote: I'm trying to make some sense of the parameter IDs in the .moef files, since I am writing some code to generate about 250 of them. In the publishSettings and sceneNode elements, parameters seem to have ids based on their created index (ie. they start at 1). But in the filter element parameters have ids that match the ids I gave them in the code. I'm not sure I fully understand what you're asking. Are you trying to publish some of your FxPlug's parameters based on the values of some of the scene node's parameters? For example, if the scale of an element is over 50%, then publish your plug-in's color parameter, or something like that? The Motion XML format is described here: <http://developer.apple.com/library/mac/#documentation/AppleApplications/Con…> I'll do my XML edits by parameter name instead - bypass the whole issue. _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… On 8/24/2011 11:24 AM, Darrin Cardani wrote: How can I relate one to the other? (since I want to publish some of them depending on the values of other parameters). Generally, scene nodes have IDs that are sequential because the user can create any number of them, but their parameters have fixed IDs. For example, Transform is always id 100 and Position id 101, I believe. Ok I understand the sequential part of it. But it does mean if I add a parameter to an FxPlug later it'll mess up the published list, right? This email sent to site_archiver(a)lists.apple.com

1 0

Re: .moef parameter ids
by Darrin Cardani 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On Aug 24, 2011, at 8:46 AM, Paul Miller wrote: > I'm trying to make some sense of the parameter IDs in the .moef files, since I am writing some code to generate about 250 of them. > > In the publishSettings and sceneNode elements, parameters seem to have ids based on their created index (ie. they start at 1). > > But in the filter element parameters have ids that match the ids I gave them in the code. > > How can I relate one to the other? (since I want to publish some of them depending on the values of other parameters). I'm not sure I fully understand what you're asking. Are you trying to publish some of your FxPlug's parameters based on the values of some of the scene node's parameters? For example, if the scale of an element is over 50%, then publish your plug-in's color parameter, or something like that? The Motion XML format is described here: <http://developer.apple.com/library/mac/#documentation/AppleApplications/Con…> Generally, scene nodes have IDs that are sequential because the user can create any number of them, but their parameters have fixed IDs. For example, Transform is always id 100 and Position id 101, I believe. Darrin -- Darrin Cardani dcardani(a)apple.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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

.moef parameter ids
by Paul Miller 24 Aug '11

24 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 I'm trying to make some sense of the parameter IDs in the .moef files, since I am writing some code to generate about 250 of them. In the publishSettings and sceneNode elements, parameters seem to have ids based on their created index (ie. they start at 1). But in the filter element parameters have ids that match the ids I gave them in the code. How can I relate one to the other? (since I want to publish some of them depending on the values of other parameters). _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: string parameters in FCPX also not working?
by Paul Miller 22 Aug '11

22 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 On Aug 22, 2011, at 9:18 AM, Paul Miller wrote: Bug #10001565 filed with (very simple) test code and sample motion template. On 8/22/2011 11:59 AM, Darrin Cardani wrote: I know Custom parameters are a no-go in FCPX but has anyone gotten a STRING parameter to work? It's working in Motion, but won't remember its value in FCPX after exiting and restarting. This is likely related to the issue with custom parameters not getting saved. Can you please file a bug and we'll look into it? This shows the problem that parameter values pushed in the parameterChanged: callback don't stick when the project is saved (whenever that happens). _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: string parameters in FCPX also not working?
by Paul Miller 22 Aug '11

22 Aug '11

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 I think it's worse than this. Now I'm trying to set the value of an Integer parameter and the new value for it is also not remembered when the project is saved. I'll write a test plugin to show you what I mean. This all works in FCP7. _______________________________________________ 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: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Parameter supervision works in FCPX, with the caveat that the UI isn't properly updating at the moment. We have a bug on it, but I don't know its current status off the top of my head. Basically, if you select another item in the FCPX timeline and then re-select the item with your filter applied, do you see the changes? Switching between clips seems to be okay - FCPX remembers the updated parameter values as long as I don't exit. Once I exit, they are all lost and everything reverts to the default values. Any direct changes I made after the parameter value updates are properly saved. Also, it seems FCPX ignores both the FxCustomParameterActionAPI action group and the apparently new FxUndoAPI undo groups. So after I push the other parameter values they do not undo when I undo the supervised control twiddle. This email sent to site_archiver(a)lists.apple.com

1 0