You can simply add a Uuid as a member.
And you can add it to your setStateInformation, if you want it to be persistent.
The uuid of the PluginDescription is actually rather to identify the type of your plugin than the instance.
You may still run into problems, e.g. FinalCutProX will create a hand full of instances of your plugins, each rendering a part of the waveform. I didn’t a good way to identify which one is the actually heard one or which is a background one, so you have to make sure, that they absolutely don’t interfere (plus not write the parameters, but rely on FCPX to set the parameters from the automation, otherwise it gets messy)
I tried that actually, but the problem is, that this UUID will be generated by the time the plugin will be instantiated, but it’ll only be restored by the time getStateInformation() is called … this discrepancy is currently the source of some problems for me.
I thought it might be a problem. Unfortunately the hosts are not prepared to support such a kind of self awareness of plugins, AFAIK. I didn’t find a solution for that, so I had to change my design to be agnostic to which instance it is.
Maybe if you describe your use case, sometimes it is possible by thinking outside the box…
Well, my plugins register themselves with a background application using IPC methods, so i either need to assign a new ID at registration time or (in case they’re restored) use the ID restored from the plugins memory block.
There are some ways around it, of course, i.e. registering and assign a different ID in case the plugin is restored, etc. etc. … but they’re all equally tedious and somehow uncomfortable, so i couldn’t decide on one yet …
I had a similar use case, so I ended up that the connection is my identification. I assume you are thinking how to make sure, that the parts of the state in the server sync up with the parts in the client.
My solution was to keep the server dumb, and push the plugin’s state upon connect.
Not sure if that works for you though.