The problem is that the new version of the plugin adds the Bool parameter to the V1 project and so you will always wind up with V2. It might have worked if you've added a hidden INT to the project declaring the version of the plugin used in the project. Then the parameter will not be overwritten be the new version of the plugin.
This could also work (though it's not a great solution) if you set the default value of the parameter based on whether you updated the project or not, I would think. Or am I misunderstanding the problem?
Martin's main problem is not to determine which version of plugin is currently running, but to figure out which version of the plugin was used when the project was created.
For example: The "old" plugin only had one parameter (a popup with 3 items: "Yes", "No", "Maybe"). V2 of the plugin has the same popup menu, only that it has 5 items: "Sometimes", "Always", "Yes", "No", "Maybe". The project was created and the popup was set to "No". If the V2 plugin now opens the project and it reads the value, then it winds up with "Always" and not with "No", which is now 2 places further dow the list.
Martin's question is now: How can the V2 plugin figure out if the project was created with the V1 or the V2 plugin?
The (current) necessity to create a template for FCP X adds a whole new layer of problems in terms of the things you try to do. Nothing is really transparent when the plugin runs inside a template under FCP X.
THE solution to all of this is (in my opinion) to make FCP X able to read FxPlugins natively without going through templates. Then we will be able to create parameters dynamically, have custom parameters, we could create labels (which I so badly need(!!!) for me newest plugins)... and much more.
Motion templates and native FxPlugs solve 2 different problems. We (and our users) want all FxPlugs to be able to work properly with Motion Templates. Some of the pieces that you mention above are missing at the moment, and that's unfortunate.
Also, the idea with templates is that they will not just contain a copy of every parameter in every plug-in, but that developers will think through specific tasks that users need to perform and will provide templates for those tasks rather than raw plug-ins with dozens of parameters that most users won't understand.
I understand the thought process.
The problem I see is that not all FCP X customers have Motion 5. So when they want to use a complex plugin, which has (and needs) 38 parameters, then I need to display all of the 38 parameters inside FCP X. To make it easier for the customer to use the plugin I need labels and also custom parameters... and sometimes I need to create parameters dynamically... meaning that not all parameters are displays all the time, or that parameters are needed that depend on other parameters. This is very, very hard to do with templates. A native FxPlug plugin would have much better control over the parameters.
My 2 cents.
@Darrin: Will FCP X ever get a native FxPlug interface?
I'm not able to comment on future functionality.
I understand. (I had to try through :-) )