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

[Inger Wrongwriter]

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

Thank you! You just pointed out that Google isn't as "smart" as I thought regarding syntax. I Googled "What is iPluginCompatibility" and that yielded me a completely different result.
Sorry for going off topic.

[Funkybot's Evil Twin]

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

You may have better luck lobbying host developers directly. I imagine a quite a few of them of them wouldn't mind hearing from you. You're a big name in the industry. And you almost certainly have a better reputation with non-Cubendo host-developers than Steinberg.

[Urs]

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

You may have better luck lobbying host developers directly. I imagine a quite a few of them of them wouldn't mind hearing from you. You're a big name in the industry. And you almost certainly have a better reputation with non-Cubendo host-developers than Steinberg.

We have been doing this, but there are no results at all.

I have therefore arrived at the stance that the effort we put into compliance is way more than enough. E.g. in case people haven't noticed, all the recent and soonish updates are *mainly* due to the policy change in regards to VST2 - one last update before we have to say good bye. We're almost literally losing a year or two in which we would have loved to attend to more interesting matters. (We've also had to completely rebuild our internal tool chain to use CLAP instead of VST2)

We can not fix this mess for those who make the policies.

[Funkybot's Evil Twin]

We have been doing this, but there are no results at all.

I have therefore arrived at the stance that the effort we put into compliance is way more than enough. E.g. in case people haven't noticed, all the recent and soonish updates are *mainly* due to the policy change in regards to VST2 - one last update before we have to say good bye. We're almost literally losing a year or two in which we would have loved to attend to more interesting matters. (We've also had to completely rebuild our internal tool chain to use CLAP instead of VST2)

We can not fix this mess for those who make the policies.

It's just my opinion, and I apologize in advance, but I think you guys get too hung up on following rules that no one's planning on enforcing sometimes. If Steiny's lawyers actually reached out and personally told me stop developing VST2, I would figure it out at that time. Would probably be a little slap on the wrist or a sternly worded letter. Until that day, I would've just kept running my business and moving forward with higher-priority development. I totally get that you took it seriously and didn't want be flat-footed but on the other hand, **** them.

As an end user, I've migrated to Clap or VST3 out of necessity. I'm not banking on any project migration functionality at all. I expect I'll be doing that manually or keeping old VST2 versions around for as long as possible.

But you're a good egg Urs Heckman.

[Urs]

Obviously, quite some lawyering was involved. Agreements were reached. Deadlines were set. Plans were made. Things were put in motion. Here we are.

Anyhow. I sense a sense of urgency that is not there. Our current releases will probably live unchanged for a few years until the VST2 versions will become obsolete entirely. But even then they will still be in the archives - thanks to our lawyering effort. We have time to get this done.

Who knows, by then we probably don't need iPluginCompatibility anymore as every host might then support CLAP's "State Conversion" feature, which allows a CLAP plug-in to name a whole list of plug-ins it can replace, including our olden VST2s.

(If the current adoption rate of CLAP continues - twice the number of hosts every year - we'll soon run out of hosts that don't support it yet. We might have to task an AI to write new ones if we want to keep up the adoption rate.)

[alberto_balsalm]

Any chance of fixing the issue with the lack of persistence of the "selected on top" parameter in the rack? It reverts upon reopening the GUI. It would also be really really nice to have persistent reordering of the modules, seeing as it's the same problem - they revert back to default ordering upon reopening the GUI and they're not saved in the patches (well, I guess patch saving is a more problematic thing).

As a side note, I've discovered that there's an "alwaysSyncToPrefs" option in the script file. Oscillator tabs, as it turns out, respond to it, and if you enable this parameter on all 4 OSC tabs (you know, the 3 Phase-FX-Mixer ones), it will make open tabs persistent on reopening the GUI. As opposed to always defaulting to the Phase tab upon reopening, which can be annoying sometimes.

For anyone curious, for the default ZebraHZ skin, add these to the script file (search for the name of the control to find the proper line, i.e. search for "Osc1Tabs", "LayerSelector 25044", etc.

PROPERTY control='Osc1Tabs' name='alwaysSyncToPrefs' id='0' value='YES'
PROPERTY control='LayerSelector 25044' name='alwaysSyncToPrefs' id='0' value='YES'
PROPERTY control='LayerSelector 25112' name='alwaysSyncToPrefs' id='0' value='YES'
PROPERTY control='LayerSelector 25251' name='alwaysSyncToPrefs' id='0' value='YES'

[tasmaniandevil]

As a side note, I've discovered that there's an "alwaysSyncToPrefs" option in the script file.

That's the "set as default view" feature. You don't need to edit any scripts to use it. Just right-click on the tabs in the GUI to access it.

[alberto_balsalm]

That's the "set as default view" feature

It doesn't seem to do anything, I've tried it multiple times (and again just now, to be sure). Tried it in both Reaper and Bitwig, using the latest version, on a Win10 system.

[zvenx]

As a side note, I've discovered that there's an "alwaysSyncToPrefs" option in the script file.

That's the "set as default view" feature. You don't need to edit any scripts to use it. Just right-click on the tabs in the GUI to access it.

Hi, I had reported this awhile ago and forgot to bring it up again this cycle.

In Cubendo, you can configure any plugin to a default settings (view and parameters), that you want the plug in to load as when by default for every new instance, and save that as your default preset.

So for your instruments, I would choose the preset tab, set as default view, choose a patch that sounds great, and save that as cubendo's default preset.

Some of your instruments would respect that preset tab default view, some wouldn't..
(I just this week (after decades) abandoned saving a Cubendo default preset for u-he stuff and the Set as default view works properly now), but so you know, set as default view then saving that as Cubendo's default preset only works in some of your plugins (from memory, ACE, Diva,Fitlerscape, Zebralette 3 and the Repro's work... Zebra does not work... don't remember what the others do)

rsp

[tasmaniandevil]

It doesn't seem to do anything, I've tried it multiple times (and again just now, to be sure). Tried it in both Reaper and Bitwig, using the latest version, on a Win10 system.

This feature determines which tab will be visible whenever you load a new instance of the plugin. It doesn't determine the state of the tabs each time you close and open the GUI of an existing instance.

To set it, you first have to select the tab you want to use as the default. And then you right-click and choose "set as default view".

The next instance of the plugin will then load with the chosen tabs visible.

[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.

Just a quick update regarding iPluginCompatibility within FL Studio. One of Image-Line's lead developers just confirmed in a recent discussion that FL Studio will be supporting it. No confirmed timescale of when, as yet. But at least now, FL Studio users can take some reassurance that it will be supported (at some point).

However, FL Studio does not currently support "IPluginCompatibility" and it has not yet been confirmed by Image-Line if they ever will support that method of plugin format migration (at least to my knowledge).

We will.

[Urs]

Cool!

[MrJubbly]

Who knows, by then we probably don't need iPluginCompatibility anymore as every host might then support CLAP's "State Conversion" feature, which allows a CLAP plug-in to name a whole list of plug-ins it can replace, including our olden VST2s.

That sounds like the holy grail.

Then finally, all the (non-proprietary audio plugin format) DAW users can all breathe a sigh of relief, and simply use CLAP plugins and forget about the previous issues with the various different plugin formats and simply get on with the joys of making music.

[tasmaniandevil]

In Cubendo, you can configure any plugin to a default settings (view and parameters), that you want the plug in to load as when by default for every new instance, and save that as your default preset.

So for your instruments, I would choose the preset tab, set as default view, choose a patch that sounds great, and save that as cubendo's default preset.

Some of your instruments would respect that preset tab default view, some wouldn't..

That's because the "set as default view" option is independent of a function that would restore the last used tab when reopening a GUI or when loading a host saved preset. For this we need layer memories. Some plugins have them, others don't (but we have tickets to eventually add them).

[GruvSyco]

(We've also had to completely rebuild our internal tool chain to use CLAP instead of VST2)

I think this is possibly one of my favorite U-he traits. Walk the walk if you're going to talk the talk.