Uhbik 2.0 Public Beta Revision 18148 (yes, really)

[sacer]

ableton is a kick in the ass with vst3 support, all vst3 synths with more than 127 parameters are taking up to a half minute for switching a preset. I reported this Bug 2022 but they have no idea how to fix it. Clap, ARA2 and IPluginCompatibility are high demanded Centercode features in Ableton, but I think we will have to wait many years more. I remember how long they took to switch from 32 Bit to 64 Bit or to introduce VST3.
It's a much better performance if you don't have to install vst2 Plugins for backward compatibility to old projects. My new notebook has only few vst2 plugins like old Camel Audio Alchemy installed. The performance of scanning more than 1000 VST3 Plugins performs very well. To have installed all old vst2 Plugins parallel on my main system slows down the whole system.

[Dip200]

I would like to request to add the "default vst bypass button" that basically every vst plugin has, so it's possible to bypass the plugins with one click from the Cubase Mixer view.

[ThomasLehmann]

We have done our part, as have certainly done many other plug-in and host developers. It's really weird and it makes me angry when some of the biggest players in the field can't be arsed.

But this could also be a form of boycott. Many plugin manufacturers are still not discontinuing their VST 2 versions. I think Uhe is way ahead in this regard.

[medienhexer]

We have done our part, as have certainly done many other plug-in and host developers. It's really weird and it makes me angry when some of the biggest players in the field can't be arsed.

But this could also be a form of boycott. Many plugin manufacturers are still not discontinuing their VST 2 versions. I think Uhe is way ahead in this regard.

Kind of pointless, though, isn't it? Steinberg discontinued their development kit, they stopped assigning plugin IDs half an eternity ago. So there can not be any new vst2s, only those which are grandfathered in. Also, they cut off any ARM compatibility that way. So we're talking only old versions of Windows on x86 CPUs.

We can moan all we want, but if you've ever tried to access the internet on a 2013 version operating system, you will be surprised at all the things you're cut off from. A lot of websites will have stupid hardware demands which that system may not be able to meet and even Firefox or Opera have to cut off support for old systems at some point. TLDR; technology progresses and if you earn your money with software, you better be up to keeping current.

[Urs]

So, many developers do obviously continue to support VST2, regardless of the clauses in the VST3 License Agreement. But I think that's burying heads in the sand. Which is why we don't continue to support VST2, and why we worked with Steinberg directly to map out what we can and can't do, and what's the best way forward for our users.

[kmonkey]

I never thought I'd say this, but wow, UHBIK's new knobs are really sexy, and I really like them. I just quickly went through some of the presets, and it's another purchase for sure.

[limitlesssss]

nothing in Uhbik is plain anymore.

Dear Urs, is the following change to the knob behavior possible with your plug-ins? At least as an option?

With Kilohearts plug-ins and also Bitwig, when you click on a knob to change its value, the cursor disappears, and you can change the knob's value in any direction as much as you want without hitting any wall or anything like that. And as soon as you release the mouse button, the cursor reappears EXACTLY where it was before. This makes them very tweakable.

It would be great if u-he adopted this behavior, at least as an option.

[ThomasLehmann]

We have done our part, as have certainly done many other plug-in and host developers. It's really weird and it makes me angry when some of the biggest players in the field can't be arsed.

But this could also be a form of boycott. Many plugin manufacturers are still not discontinuing their VST 2 versions. I think Uhe is way ahead in this regard.

Kind of pointless, though, isn't it? Steinberg discontinued their development kit, they stopped assigning plugin IDs half an eternity ago. So there can not be any new vst2s, only those which are grandfathered in. Also, they cut off any ARM compatibility that way. So we're talking only old versions of Windows on x86 CPUs.

We can moan all we want, but if you've ever tried to access the internet on a 2013 version operating system, you will be surprised at all the things you're cut off from. A lot of websites will have stupid hardware demands which that system may not be able to meet and even Firefox or Opera have to cut off support for old systems at some point. TLDR; technology progresses and if you earn your money with software, you better be up to keeping current.

Just two weeks ago, I bought a newly released !VST plugin from a well-known manufacturer, which also released a VST 2 version alongside the VST 3 version, by the way.

But fundamentally, I agree with your points. I didn't mean to imply that one should cling to old stuff forever; especially with software, development is very rapid. And actually, it speaks FOR a manufacturer (like Uhe) that quickly adapts its products to new requirements (especially old products from its portfolio for free!). But as long as it's possible to keep the old format running in parallel for a little longer, there's no need to artificially shut it down. Of course, one might also be subject to legal constraints, I understand that. But as long as Steinberg doesn't actually do anything about this, they could just leave it alone (for now) and continue supporting it as long as other do. Incidentally, I don't use Steinberg products anymore because of Steinberg's mentality. Pushing other manufacturers and trying to dictate the market is shameful in my opinion. I would also welcome the fact that VST generally "dies" at some point and the CLAP format prevails. Of course, this should be primarily supported by DAW manufacturers. Such interfaces should generally be open source.

I'm generally open to new formats, but unfortunately, I've had a lot of bad experiences with VST 3 plugins, but not with VST 2.

[medienhexer]

We have done our part, as have certainly done many other plug-in and host developers. It's really weird and it makes me angry when some of the biggest players in the field can't be arsed.

But this could also be a form of boycott. Many plugin manufacturers are still not discontinuing their VST 2 versions. I think Uhe is way ahead in this regard.

Kind of pointless, though, isn't it? Steinberg discontinued their development kit, they stopped assigning plugin IDs half an eternity ago. So there can not be any new vst2s, only those which are grandfathered in. Also, they cut off any ARM compatibility that way. So we're talking only old versions of Windows on x86 CPUs.

We can moan all we want, but if you've ever tried to access the internet on a 2013 version operating system, you will be surprised at all the things you're cut off from. A lot of websites will have stupid hardware demands which that system may not be able to meet and even Firefox or Opera have to cut off support for old systems at some point. TLDR; technology progresses and if you earn your money with software, you better be up to keeping current.

Just two weeks ago, I bought a newly released !VST plugin from a well-known manufacturer, which also released a VST 2 version alongside the VST 3 version, by the way.

But fundamentally, I agree with your points. I didn't mean to imply that one should cling to old stuff forever; especially with software, development is very rapid. And actually, it speaks FOR a manufacturer (like Uhe) that quickly adapts its products to new requirements (especially old products from its portfolio for free!). But as long as it's possible to keep the old format running in parallel for a little longer, there's no need to artificially shut it down. Of course, one might also be subject to legal constraints, I understand that. But as long as Steinberg doesn't actually do anything about this, they could just leave it alone (for now) and continue supporting it as long as other do. Incidentally, I don't use Steinberg products anymore because of Steinberg's mentality. Pushing other manufacturers and trying to dictate the market is shameful in my opinion. I would also welcome the fact that VST generally "dies" at some point and the CLAP format prevails. Of course, this should be primarily supported by DAW manufacturers. Such interfaces should generally be open source.

I'm generally open to new formats, but unfortunately, I've had a lot of bad experiences with VST 3 plugins, but not with VST 2.

Well, Steinberg used to maintain the central list of plugin IDs. Even if you don‘t consider the license terms, in the world of backwards compatibility, you may encounter old version of DAWs which identified plug-ins by their ID. Any newly released plug-in can only re-use an existing ID to bypass being blacklisted. So releasing new vst2 at this point is playing with fire.

Also, if you look behind the scenes, there is no way to just keep compatibility going. Every supported operating system, every supported standard and every DAW needs extra effort invested in building and testing and installing.

[MrJubbly]

But... rant follows:

However, apparently some DAW manufacturers have spent absolutely no time on this...

So, I communicated the above referenced quote (in full) to Image-Line on their forum, with regard to FL Studio's VST2 to VST3 migration support and they responded with some good news ...

FL Studio 25 will have full support for these interfaces. Yes, we dragged our feet on this.

What is wrong with VST3 support inside FL Studio?

In this case I was just talking about the code needed to migrate VST2 plugins to VST3 automatically. FL Studio 24 and earlier supported the initial method for that, FL Studio 25 will support all the methods known to me.

Note: FL Studio 25 is currently in its Public Beta testing stages.

[AmethystClassic]

Really enjoying the plugins, working smoothly.

A basic question: do you need to set up ordinary side chain compression by setting the envelope modulation target? Which parameter should I modulate, ratio, threshold....output gain?

[Naenyn]

Just FYI,
I had some older files (maybe from an alpha build, I'm not sure which version I had on this system) hanging around in ~/Library/Application Support/u-he which were causing weird issues with control placement/alignment and labels to appear in the wrong places. I was also seeing the issue shown in this post: viewtopic.php?p=9086369#p9086369

Yep, super weird. Usually, the Mac installer is pretty good at removing all old files.
This might happen because of the plugin renaming.
We'll check if we can improve the installer or if we need to add a note to manually uninstall the old alpha first.

Just wanted to mention I also had this problem. I had to clean up things in the system-level /Library/Application Support/u-he as well as my user's ~/Library to get things to look normal.

[Urs]

Really enjoying the plugins, working smoothly.

A basic question: do you need to set up ordinary side chain compression by setting the envelope modulation target? Which parameter should I modulate, ratio, threshold....output gain?

The external side chain functionality of Uhbik currently only applies to the envelope follower. The idea here is the same though, the envelope follower can be used to duck signals in every effect. But it can also do a whole lot more, e.g. you can use a snare or whatever drum from a different track to randomise several parameters in each Uhbik.

I am not 100% sure but I think that the Inflation functionality can't work with an external side chain, and thus this wasn't an option. But then, the external input in Uhbik was only really added during our recent crunch. We can keep external side chain compression as a feature request, maybe as an alternative to Inflation then.

Hmmm... does the word "side chain" on the UI suggest otherwise maybe? - We try to use precise terminology, and "side chain" refers to internal signal wiring - the incoming audio signal is split up into the audio path and the modulation path (<- side chain). The correct term for using a second signal in a compressor is called "external side chain".

As many people use "side chain" and "external side chain" synonymously and as all Uhbiks have latter I guess it makes sense to rename this...?

[Medenka]

As many people use "side chain" and "external side chain" synonymously and as all Uhbiks have latter I guess it makes sense to rename this...?

Yes. Or add int/ext switch. If you have ext but not int, that's confusing.

[enCiphered]

I honestly never paid much attention to Uhbik.
With the announcement of 2.0, I’m curious: how does it compare to something like MeldaProduction's MXXX? I already own MXXX, so I’m wondering if Uhbik brings anything unique to the table, or if it would mostly overlap with what I already have.
Are there features or character aspects in Uhbik that make it worth having in addition to MXXX, rather than redundant?
Would love to hear your thoughts, especially from those who’ve used both!

If this is too off-topic, I apologize.