Zebra Legacy 2.9.4 Update Released – CLAP, AAX, Key Control

[NAD]

Is VST3 > CLAP migration a thing? Will it ever be a thing?

[Urs]

Is VST3 > CLAP migration a thing? Will it ever be a thing?

Yes, it's a thing.

[Urs]

To be clear, I exclusively use CLAP formats of u-he plugins for all my current/new projects.

However, I still require VST2 formats for opening many old projects, which used those instead.

I have no objections to this current update being the last version to include VST2 formats in the installer.

I only wish for any subsequent updates not to uninstall the already installed VST2 format of this current release from my device.

Otherwise, it would not be productive for me to install those future updates.

I do not know how the installers/uninstallers work, but we'll always have VST2 versions in our release archive (https://u-he.com/support/#downloads), and you'll certainly be able to run legacy VST2 versions in parallel to current versions for years to come.

[Urs]

Please let your host developers know that iPluginCompatibility is the way forward - for VST. In future hopefully relevant policies are thought out better and more responsibly.

What on earth is "iPluginCompatibility"? (Neither Google nor KVR Search have been friendly to me... )

It's a feature of VST3 that allows a host to replace a VST2 plug-in with a corresponding VST3 plug-in. Like, when there is not VST2 plug-in anymore, a VST3 plug-in can be used instead when opening old project files.

It is a key concept to successfully transition from VST2 to VST3. But while Steinberg has made legal provisions to end VST2 plug-ins and hosts, they seem to not have made provisions to enforce host developers to support iPluginCompatibility. Hence, only very few hosts support it, but users really need all VST3 hosts to support it rather soon.

In all fairness, there are other means to do this, but they were not available to us when we started VST3 support. We started supporting VST3 too soon, and now we need the agreeably much better and more flexible iPluginCompatibility method.

[MrJubbly]

To be clear, I exclusively use CLAP formats of u-he plugins for all my current/new projects.

However, I still require VST2 formats for opening many old projects, which used those instead.

I have no objections to this current update being the last version to include VST2 formats in the installer.

I only wish for any subsequent updates not to uninstall the already installed VST2 format of this current release from my device.

Otherwise, it would not be productive for me to install those future updates.

I do not know how the installers/uninstallers work, but we'll always have VST2 versions in our release archive (https://u-he.com/support/#downloads), and you'll certainly be able to run legacy VST2 versions in parallel to current versions for years to come.

Thank you for that reassurance. That is all I require. The first thing I typically now do, when opening up older projects which used VST2 formats of u-he plugins, is I manually migrate all those instances to their CLAP equivalents.

So eventually, I may no longer require any VST2 formats, once such migration to CLAP has been completed for all those legacy projects, which I do like to still want to access, for preservation and remixing purposes.

So long as I can access legacy VST2 versions of the u-he plugins, whether that be via separate (depreciated/discontinued) installers, that will suffice for my requirements.

Of course, if/when Image-Line get around to adding "IPluginCompatibility" to FL Studio, even that may no longer be required. But either way, I'm glad I will still be able to access and open those older projects with u-he plugins on my Windows device.

Thank you.

[tasmaniandevil]

I only wish for any subsequent updates not to uninstall the already installed VST2 format of this current release from my device.

The Mac installer will not delete the VST2 plugin.

The Windows installer will run an uninstaller routine before performing an update, so this will remove the VST2 plugin.

But you can simply copy the VST2 plugin before running the update installer, and then move it back to the VST2 folder afterwards.

[tasmaniandevil]

The new update gives me this warning in Logic Pro 11.01 on MacMini M1 Sonoma

Version 2.9.4 is running fine in Logic 11.0.1 on Sonoma over here.

This message usually shows up if Logic tries to load an out-of-date version of the plugin. Do you maybe still have an older version of the AU plugin in the AU plugins folder?

You could try to uninstall and then reinstall to hopefully fix this.

https://u-he.com/support/faq.html#compa ... :uninstall

Or you can contact our support so we can help.

https://u-he.com/support/#contact

[MrJubbly]

I only wish for any subsequent updates not to uninstall the already installed VST2 format of this current release from my device.

The Mac installer will not delete the VST2 plugin.

The Windows installer will run an uninstaller routine before performing an update, so this will remove the VST2 plugin.

But you can simply copy the VST2 plugin before running the update installer, and then move it back to the VST2 folder afterwards.

I didn't realise that difference between mac and Windows installers. Is there any way to prevent the uninstallation also also from happening on Windows?

If I changed the VST2 files access permissions to "Read Only?" Would they still work properly? And would that prevent them from being uninstalled?

Thing is otherwise, I'm probably gonna have to do quite a lot of post installation file maintenance work from now on, anytime I update a future u-he plugins. Since I own your entire product line (all u-he plugins).

I guess that would mean, I would have to create a local back-up (e.g. zipped archive) of all my currently installed u-he xxx.dll plugins and their corresponding 'xxx.data' shortcuts within my VST2 installation folder (the final VST2 formats thereof).

Then after any future updates, navigate to the VST2 plugins folder and drag and drop those VST2 formats back into that installation location.

Would that suffice, just manually copying both the '.dll' and '.data' shorcut files back into the same VST2 plugins installation folder where they were previously located?

Any advice on either of these proposed work arounds?

[defiantnerd]

Please let your host developers know that iPluginCompatibility is the way forward - for VST. In future hopefully relevant policies are thought out better and more responsibly.

What on earth is "iPluginCompatibility"? (Neither Google nor KVR Search have been friendly to me... )

https://www.google.de/search?q=iPluginCompatibility

[tasmaniandevil]

Would that suffice, just manually copying both the '.dll' and '.data' shorcut files back into the same VST2 plugins installation folder where they were previously located?

Yes, that's totally sufficient.

And maybe really do write to the support team of your host, asking them to please consider implementing iPluginCompatibility as soon as possible. If no one asks, they'll likely see no need to do it.

[krans]

Am I the only one having trouble instaling it on Linux?
Both the Zebra2 and ZebraHZ installer tell me that there are too many arguments on line 7.

[tasmaniandevil]

Am I the only one having trouble instaling it on Linux?
Both the Zebra2 and ZebraHZ installer tell me that there are too many arguments on line 7.

Maybe better to ask about it in the Linux sub-forum, so the Linux wizards can help: viewforum.php?f=292

We tested it without problems in an Ubuntu based Linux. And so far no other Linux users have install issues with our current releases.

[MrJubbly]

Would that suffice, just manually copying both the '.dll' and '.data' shorcut files back into the same VST2 plugins installation folder where they were previously located?

Yes, that's totally sufficient.

And maybe really do write to the support team of your host, asking them to please consider implementing iPluginCompatibility as soon as possible. If no one asks, they'll likely see no need to do it.

Thanks for confirming. That shouldn't be too much of a hardship then.

Since I can just create a single archive of all the final VST2 releases for these u-he plugins and drag and drop them back into the VST2 installation folder after installing any future u-he updates without VST2 support.

Not too much headache for retaining backward compatibility for my older projects.

As for lobbying Image-Line to include iPluginCompatibility, it has been requested and their staff have confirmed that they are aware of it (along with several other methods of plugin migration). However, I don't believe they have confirmed that they will support it.

At least they now support CLAP, which is my plugin format of choice both now and for the future. I always use CLAP plugins now, when each become available in that format.

Thanks again.

[Urs]

I‘ve been lobbying Steinberg to lobby for iPluginCompatibility with other host developers.

[Urs]

I‘ve been lobbying Steinberg to lobby for iPluginCompatibility with other host developers.