Renaming of plug-in instances

[sunmachine]

The CP plug-in header displays the name of the plug-in that is used in the CP network.
When you have more than one instances of the same plug-in all instances have the same name.
So it would be great to be able to rename an instance directly from within the plug-in header instead of doing so in the CP Manager.

[CopperPhil]

Actually you can rename a plug-in instance double-clicking on its name in the Plug-in slots list.

I just see that it causes a weird flicking effect. I'll fix it.

[CopperPhil]

But ok I understand... you mean "using the wrapper in a 3rd party host"

Ok I'll add the rename capability from the wrapper's header

[sunmachine]

Great! That will make it more user-friendly since you won't have to switch to the CP Manager and then find out which instance is the right one to rename

[CopperPhil]

The thing is I'm not sure a textbox located in a plug-in GUI is correctly handled in any case by any host. I'll probably need to use a popup dialog box. But ok, I'll do something

[sunmachine]

Oh right... text boxes in plug-ins are an evil thing...
There are a lot of threads in the Studio One forum about this

[sunmachine]

The whole wrapping thing will hopefully only a temporary thing anyway.
From a user point of view I don't want to care about which version (CP or non-CP) of a plug-in to choose when I load it.
When I need CP support afterwards I just want to enable it instead of replacing the plug-in instance (and save the settings first and load them again in the new instance).
So ideally the host would have a built-in CP-wrapper that can be enabled and disabled for each plug-in if needed.
Any plans to provide a simple to integrate plug-in-wrapping-SDK for this purpose?

[CopperPhil]

Yes you're right (again)

We have some piece of code that we could share with host developers to do that. But actually not packaged as a SDK.

The plug-in wrapping is just a step forward to the future: plugins would be natively supporting CopperLan.

Wrapping just allows parameters remote control in high resolution, but it can't do anything for musicality. Moreover wrapping is quite hazardous due to the multitude of plugins having their own (weird) behaviors.

CopperLan brings a lot of musicality expression enhancements that would be great for instrument plug-ins. And it's far more easy to add CopperLan to a plug-in than wrapping it...

[sunmachine]

Yeah, native plug-in support would of course be the best!
But you have to start somewhere... and the wrapper will make people wanting more I guess...

The future is bright!