The dynamic number of input clips could also be under plugin, rather than host, control. For example an int param on the plugin could be used to control the number of input clips. So an API is needed to have the plugin add and destroy new inputs.
Dynamic Number of Input Clips Proposed
Standard version: 2.0
Major Change
Some plug-in developers wish to have a variable number of input clips to their effects. At run time a user would be able to keep wiring more and more input to the effect. Not all hosts could support this, but many could.
To do this you would need to have properties indicating whether the host was capable of doing this, and whether the plug-in wanted such behaviour.
Given the current 'fetch by name' method of working, we would need some sort of way of generating names for such input clips and finding out how many of them there were eg “OfxVariantClip_” with a number post-pended to the name. Once done this would fairly easily fit in with the current API.
Wiring in and creating such a new clip would be detected by the instance changed callback without any modification, simply passing in the name of the newly created clip.
Some clip property defaults would probably need to be set during effect description, as we do with normal clips. This could be done by creating a clip descriptor called “OfxVariantClip” and setting properties on that, this would not represent a real clip and would magically be used to seed variant input properties.
(Pierre Jasmin): Growable node like Shake had is fine. An alternative or complement could be show hide input connectors. For example in Nuke we do have a tool with multiple clips input options and after a certain number we have to connect useless ones until the one we need show up. Implementing this via Show-Hide. I liked how Combustion popuped a wiring box for large amount of inputs to facilitate such wiring.