each FxPlug has a unique identifier string (UUID) associated with it [https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/FXPlug_overview/BundlingAndInstalling/BundlingAndInstalling.html]
and as a developer it’s useful for me when creating a new version to be able to easily set that UUID (so that it matches a previous version to maintain project compatibility with projects using the old version) and/or to be able to easily generate a new UUID to allow multiple versions to coexist during development. Currently, each time I think I’d need to directly edit the plist files and/or use the terminal command to generate new UUIDs but I was thinking it would be cool if VUO exposed the UUID for editing / regenerating.
Currently, the FxPlug’s UUID is generated based on the bundle identifier. So if you keep the bundle identifier the same, the UUID will be the same, and it will maintain project compatibility.
If, on the other hand, you want to change the UUID, you can do so by altering the bundle identifier (e.g., add a .dev suffix, as in com.kingluma.invertImageColors.dev).
Does that meet your needs, @kingluma? Or is there some reason you’d need to change the UUID independently of the bundle identifier?
the FxPlug’s UUID is generated based on the bundle identifier.
Ah, OK - yes, I expect that works fine for my purposes. So basically the ability to preserve the UUID or generate a new UUID are indeed already exposed in the UI that way (through the bundle identifier field) - and the default bundle identifier is based on the vuo comp name so if the vuo comp for the new updated version of my vuo comp is named a little differently (myEffect_v101 rather than myEffect_v100) I just need to explicitly change the bundle identifier (to something like “com.kingluma.myEffect_v100” or whatever the original identifier was) when exporting in order to have it replace the previous version and maintain project compatibility… Thanks
How about parameter ID numbers ? I seem to remember when reading the XML for a Motion template that it refers to the individual parameters by an ID number rather than the text based name… do those numbers get generated based on the port name in the vuo comp ? (or should that be exposed in the port details UI…)
How about parameter ID numbers ?
Good question. Those numbers are currently auto-generated by Motion, not something that Vuo tries to control. As a result, the ID numbers aren’t necessarily preserved as you add/remove/reorder published input ports.
Technical details:
My coworker tested this by exporting 2 versions of a composition, one having an extra published input port inserted among the others.
Here’s a snippet of the Motion template before:
<target object="10026" channel="./2/3" name="SampleCenter X"/>
<target object="10026" channel="./2/4" name="SampleCenter Y"/>
<target object="10026" channel="./5" name="SampleSize"/>
<target object="10026" channel="./6" name="Exposure"/>
</publishSettings>
And after:
<target object="10026" channel="./2/3" name="SampleCenter X"/>
<target object="10026" channel="./2/4" name="SampleCenter Y"/>
<target object="10026" channel="./5" name="SampleSize"/>
<target object="10026" channel="./6" name="Opacity"/>
<target object="10026" channel="./7" name="Exposure"/>
</publishSettings>
Upon updating to the new plugin version, peoples’ existing Final Cut Pro X projects would have their Exposure values mapped to Opacity, which would be wrong.
To solve this, perhaps Vuo could generate an ID number for each published input port based on the port’s name (similar to how it generates the UUID based on the bundle identifier).
@kingluma, does that seem like a reasonable solution to you?
Those numbers are currently auto-generated by Motion, not something that Vuo tries to control. As a result, the ID numbers aren’t necessarily preserved as you add/remove/reorder published input ports… To solve this, perhaps Vuo could generate an ID number for each published input port based on the port’s name (similar to how it generates the UUID based on the bundle identifier). kingluma, does that seem like a reasonable solution to you?
I think it’s reasonable, and renaming of a parameter could be done to the template in the Motion UI rather than Vuo (while still maintaining the ID number). This (defining/changing final param names in Motion) should allow for a way to rename parameters for improved clarity or localization in another language etc without creating incompatibilities with existing versions of the effect
Great, we’ll make that change.
Implemented in Vuo 2.0.0-beta4.