How about talking with the Cubase team to find out how they approached addressing this, given it seems that they have addressed the issue?
A quick note and comparison on WaveLab vs. Cubase re: @TheAndyMac 's notes on this issueâŚ
For many affected plugins, Cubase does offer a better default view. It also offers the ability to resize windows for many plugins, which seems to solve the too-small issue about 50% of the time. Some examples of Cubaseâs success in this area over WaveLab are posted below.
That said, other developers as noted above (TopTen, Blue Cat, Audified, etc.) have developed solutions to this issue for their plugin hosting tools which seem to work for almost 100% of plugins tested. So while the Cubase team has partially resolved this issue (possibly through plugin resizing), there are other developers who appear to have completely solved it (likely through per-window scaling).
Also, it is interesting to note that some current Steinberg plugins (Rev-X; Compressor 276; Sweet Spot Morphing Channel Strip; etc.) display too small in WaveLab (see examples below). If Steinberg itself does not comply with the best practices necessary to display plugins usefully in WaveLab, it may be unreasonable to expect that the entire spectrum of 3rd-party developers would do so.
Just a few quick WaveLab vs. Cubase examples, where the Cubase approach solves the issue. Screenshots taken on same screen (3840x2160, 150% Windows scaling) on the same Windows 10 computer with both applications full-screen. Please note: These examples are just a few among thousands of other affected plugins; they are simply a few quick examples to show where Cubase displays them more nicely than WaveLab on a 4K screen. Of course, some of these particular examples are not really mastering plugins, but thatâs not the point; they are just quick examples of how plugins display in WaveLab vs. Cubase.
Steinberg Yamaha Compressor 276 in WaveLab Pro 11
Steinberg Yamaha Compressor 276 in Cubase Pro 12:
To not clutter up this thread too much, additional examples are minimized.
Click here to expand and see more examples...
Steinberg Yamaha EQ 601 in WaveLab Pro 11:
Steinberg Yamaha EQ 601 in Cubase Pro 12:
Steinberg Yamaha Rev-X in WaveLab Pro 11:
Steinberg Yamaha Rev-X in Cubase Pro 12:
Steinberg Yamaha Sweet Spot Morphing Channel Strip in WaveLab Pro 11:
Steinberg Yamaha Sweet Spot Morphing Channel Strip in Cubase Pro 12:
iZotope Trash 2 in WaveLab Pro 11:
iZotope Trash 2 in Cubase Pro 12:
Soundtheory Gulfoss Master in WaveLab Pro 11 (normal size):
Soundtheory Gulfoss Master in Cubase Pro 12 (normal size):
Native Instruments Solid EQ in WaveLab Pro 11:
Native Instruments Solid EQ in Cubase Pro 12:
Zynaptiq Intensity in WaveLab Pro 11:
Zynaptiq Intensity in Cubase Pro 12:
Toneboosters FIX4 in WaveLab Pro 11:
Toneboosters FIX4 in Cubase Pro 12:
Cableguys MIdishaper in WaveLab Pro 11:
Cableguys Midishaper in Cubase Pro 12:
MIA Laboratories Fat in WaveLab Pro 11:
MIA Laboratories Fat in Cubase Pro 12:
Toontrack EZmix in WaveLab Pro 11:
Toontrack EZmix in Cubase Pro 12:
Still not sure why this is such a huge issue for you (âinhibiting use of WLâ.)
Itâs not our job to promote WL product usage worldwide - itâs Steinbergâs.
PG has already stated clearly that this is not happening, yet you continue to pound away at it. Why?
TheAndyMacâs suggestion is perfect - maybe itâs time to chat with the Cubase Team?
Or switch to one of these other products in your screen caps that delivers what you clearly seek?
VP
Hi everyone. My two cents here.
What I find hard to understand is, why two applications from the same company exhibit different behaviours towards plugin scaling? That is: Cubase 12 scales plugin windows in a nice way, WaveLab doesnât.
I agree with TheAndyMacâs suggestion too.
HiDPI is widely used now. WaveLab, being a commercial software, should deal with it in a reasonable manner. People pay for software not only for features, but to have a hassle-free experience, and it appears that WL has some issues with that. Even Audacity (a very good software by the way, considering itâs open source) deals better with HiDPI.
4 Likes
Hi Josiaspiano
This is because while the two products (WL and Cubase) are under the Steinberg âumbrellaâ - they are coded and managed very differently.
And what is done with Cubase (scaling wise) is not a one-to-one relationship with WL (as we can see).
VP
I believe itâs worth an explanation here. Cubase/Nuendo and Wavelab have two different code bases using two different GUI frameworks.
2 Likes
I would like to mention that WaveLab uses by default a tabbed window to host several plugins under the same roof, unlike Cubase and most hosts. I hardly think itâs feasible to host in the same window, plugins using different HDPI scaling.
Some plugin manufacturers are reluctant to invest the resources necessary to properly support HDPI in their plugins. I believe that WaveLabâs development resources are better spent elsewhere than on compensating for this lack of support. Everyone must do their part.
4 Likes
Philippe, thank you for taking the time to review once again, and thanks for all you do each day to make our audio-producing lives better. Your heroic efforts in the past demonstrate that, if there was any straightforward, tenable way to achieve this within a reasonable budget and timeframe, likely you would; it just seems that given the current state of Windows and WaveLab, itâs a huge task.
This makes a lot of sense. The tabbed interface is a very useful feature, and it adds another layer of complexity to the already complex (and buggy) world of Windows development. Perhaps it makes this request completely infeasible.
For what itâs worth, one of the above-mentioned developers explained that their approach is to sandbox every entry point into every plugin. While this is not always possible for every single plugin, it facilitates per-window scaling and seems to handle most cases in that host application. Of course, to your point, this may not be of any help given the WaveLab tabbed interface.
This is true, and the entire weight of an issue like this should not fall on your shoulders. Current developers like iZotope and Native Instruments should do more.
Itâs easy to understand the sentiment: Why should WaveLab have to do all the work and let plugin developers of the hook? Development isnât free. Someone has to bear the real costs, in time and resources.
Sadly, as we are all aware, a wide variety of very useful plugins exist, with many loyal users in studios worldwide, which will never be updated to fully support 4K+ display due to the realities of the world. The very challenging situation for developers of software like WaveLab is that these plugin hosts are the singular places that a multitude of plugins are used. All the various problems and lack of upkeep evident in any given plugin is on full display (literally) within the host.
Should users just move on and abandon needed/favorite plugins, even if they just bought them last week from a current developer and perhaps need them for a specific client session? Maybe thatâs indeed the fair solution - just use something else or retrofit your monitors- but in reality busy users just need to utilize their plugins with minimal hassle on their current hardware.
While itâs truly unfair, if a developer of a given plugin host can somehow solve this problem at the host level, in one swoop it removes the problem across the board for thousands of plugins and untold users. If it simply canât be done, thatâs fair; but the result will be that users will continuously encounter situations where some needed/favorite plugins are unusable in a sharp-UI WaveLab on 4K monitors.
This situation is clearly the fault of the plugin developers, but the real-world effect is that since users want to utilize their plugins in WaveLab, by fiat it becomes a WaveLab issue - unfair yet real.
But maybe itâs simply not possible to fix it.
Again, thanks to Philippe for the wonderfully useful, innovative tool that is WaveLab!
@PG1 Philippe,
A quick thought on how it might be possible to provide a simple, usable solution for this situation.
The problem to solve: (a) Some plugins display nicely in other hosts but display too small to be usable in WaveLab on HiDPI monitors; (b) many plugin developers still do not have good solutions for this even in December 2024; and (c) understandably you donât want to spend time and resources changing the implementation of plugin display in WaveLab for all the reasons you previously specified.
What if there was a quick-and-easy âplugin zoomâ tool built into WaveLab, which could be instantiated at any time for any plugin?
At its most basic, the zoom tool would simply let the user temporarily see an enlarged version of the plugin interface. A more sophisticated solution would generate a live scaled view (think of a virtual camera providing an enlarged view) of the plugin that the user can temporarily interact with as needed. Or perhaps there could be a âspotlightâ zoom which would enlarge any portion of the plugin being interacted with (like a magnifier glass).
This solution would be fairly easy to implement and would not involve having to change anything about the default plugin display; and if this tool didnât work well for some reason with any particular plugins, it would be noted as an âas-isâ convenience tool that might not always get perfect results. If it helped even 50% of the time, Iâd use it frequently.
A nice bonus of this tool would be that it could once-and-for-all provide a solution accommodating any current and future issues with plugins displayed too small, without having to change anything about the native implementation of plugin display. It would just be an add-on feature that helps some users see their plugins better as needed.
1 Like
WaveLab canât technically modify the pluginsâ UI to zoom inside them.
And a zoom that would be a screen zoom (hence, somehow independent from plugins and WaveLab), would not be easy to do, and moreover, such utilities already exist
(if you search for: âscreen zoomâ).
@PG1 thank you for the swift response and for your kind, thoughtful consideration.
Yes, in fact one of the closest utilities to what is proposed is:
Blacksun Magnifixer
It is different from the numerous other magnifier/zoom tools in that it doesnât occlude the actual interface being magnified; it provides a separate, windowed, zoomed view of the interactive mouse area.
However, to use such a tool with WaveLab a user would constantly have to manually adjust it (changing the view location; changing the view size; locking/unlocking the mouse centering; etc.) because the tool doesnât know what the user is wanting to look at. Very tedious and slow and not really a solution for studio work.
The advantage of a built-in WaveLab tool is that it would always know exactly what the user wants to view (the targeted plugin) and could just magnify that with a quick click or hotkey.
After struggling with 4K + Windows scaling + WL in HiDPI + some plugins, I gave up and downgraded to a 2K with 100% scaling. The issue is indeed strange; most plugins worked fine, some worked fine in Cubase but behaved strangely in WL, while a couple struggled in both. And, at least one manufacturer managed to fix the problem on their end (Leapwing). Others couldnât. Odd indeed, but itâs obvious that desktop scaling is a major factor.
1 Like