Uhbik 2.0 Public Beta Revision 18517

[Urs]

You're basically describing some parts of our UX/UI roadmap. We have hundreds of feature wishes and concepts that we might evaluate or try at some point. However easy to accomplish some of these sound, they may require substantial effort. They may also pose drawbacks.

When I first implemented "hide mouse cursor on drag" in about 2004, I did not like it. It was okay for knobs, but it had made MSEG type of things impossible to operate. I decided to throw it out, but then again, like UI scaling, today there are different needs.

I personally prefer shift-on-mouse-down over fine-whenever-shift-is-pressed because it frees my left hand while I fine-mouse a parameter. More importantly, some UI controls work with absolute mouse position without shift, and relative position if shift is pressed. Dynamically switching between the two does not work with such controls, because letting go of shift will result in a jump to the absolute position. There are solutions fort that, but I feel that those are awkward, like freezing the mouse pointer or temporarily disappearing it.

So yeah, it's not like we haven't thought of any of this, but finding an implementation that works not just for a handful of widgets (we have implemented 100+ widgets in 25 years) isn't a quick endeavour, and certainly nothing to rush into without hesitation.

[limitlesssss]

You're basically describing some parts of our UX/UI roadmap. We have hundreds of feature wishes and concepts that we might evaluate or try at some point. However easy to accomplish some of these sound, they may require substantial effort. They may also pose drawbacks.

When I first implemented "hide mouse cursor on drag" in about 2004, I did not like it. It was okay for knobs, but it had made MSEG type of things impossible to operate. I decided to throw it out, but then again, like UI scaling, today there are different needs.

I personally prefer shift-on-mouse-down over fine-whenever-shift-is-pressed because it frees my left hand while I fine-mouse a parameter. More importantly, some UI controls work with absolute mouse position without shift, and relative position if shift is pressed. Dynamically switching between the two does not work with such controls, because letting go of shift will result in a jump to the absolute position. There are solutions fort that, but I feel that those are awkward, like freezing the mouse pointer or temporarily disappearing it.

So yeah, it's not like we haven't thought of any of this, but finding an implementation that works not just for a handful of widgets (we have implemented 100+ widgets in 25 years) isn't a quick endeavour, and certainly nothing to rush into without hesitation.

I appreciate the thorough answer Urs. So it's more complicated than I thought. Thank you again Urs.

[MrJubbly]

I don't know what would be the best way to communicate this to users.

But, thanks to u-he staff-members, I recently discovered that pretty much all recent CLAP formats of u-he plugins become OS Scaling-aware (on Win 11 at least) when they are set at the "Default 100%" via the internal plugin menus.

i.e. the Plugins scale correctly, according to the Win 11 scaling factor.

This has been a huge relief to me, using a 4K UHD display on Win 11 set to 250%. All u-he CLAP plugins are now beautifully and suitably large, comfortable and easy to use in a UHD display setup.

What I'm trying to say is, there must be many other users, currently using these plugins set to their maximum internal UI scaling setting of 200%, who don't realize that they can make them even larger and more suitable to their UHD + OS scaling settings, by changing the plugins back to 100% and letting them match/synchronize with the Windows OS scaling instead.

Is there some way that u-he can better communicate this fact to their customers? And in doing so, you may even receive less pressure to add higher-res support to your existing plugins, if more users were aware of how these settings interact (or don't) with the OS scaling factors.

As it stands, there is no way as a user, I would assume that setting a plugins' internal UI scale setting to just 100% (which is aware of OS scaling) would offer a more suitable and larger UHD scaling to the plugin than by setting it to 200% (which is unaware of OS scaling).

Perhaps, just making that more obvious with some indicator, or descriptive term within the plugins' UI scaling menu would suffice?

I know some people will say, well just use your bloomin' eyes, isn't it obvious? lol! ... But this OS scaling awareness seems to have been a fairly recent addition and is only currently supported for CLAP formats of u-he plugins (which I am fine with, since I intend to only use CLAP now anyway for new projects). However, it never used to be like that and so, I still assumed 200% would/should appear larger than 100% (and so had all my u-he CLAP plugins set to that instead).

Anyway, I've now switched all your plugins back to 100% default now and they are all scaling beautifully (almost filling the full screen in 4K). So I'm very happy and they look GREAT!

I just think this should be made more obvious for any other customers also using these great CLAP u-he plugins on their UHD devices.

[tasmaniandevil]

As it stands, there is no way as a user, I would assume that setting a plugins' internal UI scale setting to just 100% (which is aware of OS scaling) would offer a more suitable and larger UHD scaling to the plugin than by setting it to 200% (which is unaware of OS scaling).

This is not correct. Our scaling is aware of the OS scaling at any GUI size.
But our internal scaling system is limited to scale from 50% up to 200%.

If you use a larger Windows system scaling, e.g. 250%, then you might want to set the plugin's own scaling to 100%, so it doesn't override the Windows system scaling.

[MrJubbly]

As it stands, there is no way as a user, I would assume that setting a plugins' internal UI scale setting to just 100% (which is aware of OS scaling) would offer a more suitable and larger UHD scaling to the plugin than by setting it to 200% (which is unaware of OS scaling).

This is not correct. Our scaling is aware of the OS scaling at any GUI size.
But our internal scaling system is limited to scale from 50% up to 200%.

If you use a larger Windows system scaling, e.g. 250%, then you might want to set the plugin's own scaling to 100%, so it doesn't override the Windows system scaling.

Apologies if the way I tried to explain it was factually incorrect.

So it's more technically correct, to state that all u-he plugins are always aware of the Windows system scaling, but override that setting (effectively "ignoring" it, for all intents and purposes - in terms of actually displaying a larger/smaller UI to the end user)...

Apart from, u-he's "CLAP format" plugins, wherein, if a user sets the internal UI scaling to 100%, they no longer override the external Windows scaling, and will instead then scale in line with those OS scaling settings?

But ultimately, unless a UHD user sets their internal UI scaling for the CLAP format u-he plugins to 100%, those plugins will always likely appear smaller on their UHD 4K display, for any user who happens to have an OS scaling of more than 100%?

Case in point: The following Uhbik plugin example, first set to 100% default internally (and apparently being aware of and using, the Win 11 OS scaling of 250%)

Uhbiq - Internal UI scaling 100%, Win 11 OS Scaling 250%.jpg

Versus, that same Uhbik plugin, when set to 200% default internally (and apparently, being aware of, but no longer using the Win 11 OS scaling of 250%).

Uhbiq - Internal UI scaling 200%, Win 11 OS Scaling 250%.jpg

By the way, this second example is also the case for all other internal UI scaling parameter values, whether they be set to 90%, 110%, 120%, whatever! The only setting which actually uses the external Win 11 OS scaling setting is the internal "100%" default setting ... and only for CLAP plugins (i.e. VST/VST3 apparently don't scale like this even when they're set to "100%").

Couldn't/Shouldn't this be made a little simpler and more obvious to the end user (as per my initial request above?)

One proposed solution: I think a "OS scaling" toggle should be added to u-he's internal scaling menu (even if that was just a little led light). So that when the toggle is enabled, all internal scaling settings will abide by the OS scaling factors. And when the toggle is disabled, all internal scaling settings shall override the OS scaling factor.

Even if this toggle was automatic (i.e. not manually selectable to the user). So the plugin could itself determine which settings would be too large for the current display boundaries). But just some additional visual cue to inform the end user what was happening. It would make a lot more sense to know when the OS scaling settings were/were not being overridden by the plugin.

At least, that would be more apparent to the end user, don't you think?

[tasmaniandevil]

But ultimately, unless a UHD user sets their internal UI scaling for the CLAP format u-he plugins to 100%, those plugins will always likely appear smaller on their UHD 4K display, for any user who happens to have an OS scaling of more than 100%?

No. Only if your Windows system scaling setting is higher than 200%.

At least, that would be more apparent to the end user, don't you think?

There certainly is room for improvement here, no question about that.

[koalaboy]

No. Only if your Windows system scaling setting is higher than 200%.

Out of curiosity, why the constraint on 200% ? I really love that u-he take the care to get things right, and personally I don't need more than that as I work on 32" 4K monitors, but I'd love to know if there's a technical reason for the limit, or if it's just a case of most users never going over 200.

The updates to Uhbik (as with the other plugins) have been fantastic, and are a great example of why u-he remain one of my (maybe even 'the' top) favourite developers.

[Urs]

No. Only if your Windows system scaling setting is higher than 200%.

Out of curiosity, why the constraint on 200% ?

Because we have a dilemma. Vector Graphics are super fast on Mac because the system offers a reliable way to render on the hardware. Unfortunately, pixel graphics are super slow on Macs. On Windows it's the other way round. Pixel stuff is super fast and vector is slow, since we render on the CPU. That again is so because the system offers what feels like twelve different ways to access the hardware acceleration, but none reliably so. So we're still running our own rasteriser and stuff.

For that reason, we need to generally keep UI "contained" to resolutions that render fast on either system. Instead of endless scaling of small UIs we need to create bigger UIs that are big enough at 200% scaling. Unfortunately those don't fit on laptops anymore, so we're at a crossroads.

We will eventually bite the bullet and support one of the dozens of options for hardware acceleration we have on Windows, and move to vector based UIs throughout our catalogue. But that is some major project...

[koalaboy]

No. Only if your Windows system scaling setting is higher than 200%.

Out of curiosity, why the constraint on 200% ?

For that reason, we need to generally keep UI "contained" to resolutions that render fast on either system. Instead of endless scaling of small UIs we need to create bigger UIs that are big enough at 200% scaling. Unfortunately those don't fit on laptops anymore, so we're at a crossroads.

Thanks for the detail. Much appreciated, and makes perfect sense.

[MrJubbly]

Out of curiosity, why the constraint on 200% ?

Because we have a dilemma. Vector Graphics are super fast on Mac because the system offers a reliable way to render on the hardware. Unfortunately, pixel graphics are super slow on Macs. On Windows it's the other way round. Pixel stuff is super fast and vector is slow, since we render on the CPU. That again is so because the system offers what feels like twelve different ways to access the hardware acceleration, but none reliably so. So we're still running our own rasteriser and stuff.

For that reason, we need to generally keep UI "contained" to resolutions that render fast on either system. Instead of endless scaling of small UIs we need to create bigger UIs that are big enough at 200% scaling. Unfortunately those don't fit on laptops anymore, so we're at a crossroads.

Would it be considered unacceptable to unlock that constraint for the current Windows releases, where that would present less of an issue to Windows users? Or must we be continue to constrained by our Mac brethren?

For what it's worth I find the current pixel based UIs gorgeous scaled with even the OS scaling on Windows at 250% and even higher 300% with no detrimental CPU demands noticeable.

We will eventually bite the bullet and support one of the dozens of options for hardware acceleration we have on Windows, and move to vector based UIs throughout our catalogue. But that is some major project...

Neither have I noticed any poor CPU performance with your newer, more Vectorial UIs on their maximum internal scaling settings, like Filterscape and Zebralette3 (Which are already well calibrated for large 4K displays without any OS scaling).

And I don't currently have a top of the line CPU. Just a 12th Gen i7.

But either way, all u-he plugins perform very well at all scaling settings, either with/without OS scaling enabled/overrides.

[Ploki]

didn't notice until now that Uhbik EQ lost it's graph.

i mean... no harm done. looks great

[Urs]

didn't notice until now that Uhbik EQ lost it's graph.

i mean... no harm done. looks great

Yeah, the task to figure out how to make it efficient and good kind of got stuck with me, and I have to be everywhere in every project - mostly because half of the dev team is pretty new to much of our stuff. So we dropped it for now. The foundations are still there, so hopefully one day one of the new devs transcends the depths of our frameworks and can revive it.

[Urs]

(it's one of those two dozen things where we're like "oh gosh, we have all this tech stuff and we're not doing anything with it...yet", usually because it's not 100% there and we simply have to face the reality that we need to get some stuff done...)

[Ploki]

i'm super happy to sacrifice freq response plot for a working Apple Silicon beta

[Dirkitator]

I think I have found a little bug.

In Bitwig, in the runciter in the clap version I can't assign the source parameter in the modulation sector to any remote in the remote pages.
With Filter Type and Shape it works.