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.
I am working on a similar feature. I am using Uuid().ToString in the plugin constructor. I load the plugin on a track in Live and Reaper, but each time I close the plugin window (not unloading/removing the plugin) the uuid changes.
How can I retain the uuid for each instance until I unload the plugin?
Actually, I have different behaviours between DAW. For instance, if I add AU plugin several times in the same track, the uuid is maintained in Ableton Live 10. On the other hand, uuid changes for every VST instance no matter if it is or not in the same track in Reaper.
That way you can be sure, it won’t change accidentally (unless you do const_cast it, obviously).
If you see different values for the uuid, there are different instances. The host is free to do that for various reasons, e.g. hot swap to a different sample rate, FinalCut uses additional instances to render the preview of the waveform, and much more…
Well, if you are storing and loading the Uuid, then it all cannot work. That was my first problem with FinalCut as well, because all background instances will read the same state, and hence bear the same uuid.
This approach only works as a lifetime uuid. It does not work by design as persistent uuid for your problem.