Mouse-Zoom broken in Wavelab 11.1.10

I will check the issue later when working on WaveLab 11.1.20.
Now I work on other stuff.

Unfortunately no fix for this issue with 11.1.20.

I was not able to reproduce a problem.

So, I want to bring up the matter with the jumpy zoom again.
I just made a clean reinstallation of Windows 10 (22H2) on my Laptop, with only very basic drivers installed before the installation of Wavelab Pro 11.1.20 to rule out any possible complications with other software (not counting the vast amount of useless bloatware, that Windows comes with from the beginning). I started Wavelab without changing any preferences, used the Signal generator to create a simple Wave and tried to provoke the described issue by zooming in and out + moving the mouse cursor while in Spectrogram view - and I got the same jumpy zoom result…

The settings in Windows for the mouse-wheel don’t seem to affect the zoom behavior in Wavelab. And as it doesn’t seem to matter, wether I use my main PC with an over 5 year old installation of Win 10 (although I upgraded the CPU, RAM and GPU last summer), or my Laptop with a super fresh installation, I have to suspect Wavelab itself to be the culprit (since version 11.1, that is). The only thing I can think of hardware-wise, what MIGHT for whatever reason be a possible cause of problem, is that I use mice with dedicated navigation thumb-buttons and a DPI-switch to change the resolution on the fly - although I don’t use any special driver or software from the manufacturer (to be precise, on my main PC I use a somewhat old Logitech G400, on my Laptop I used an even older original Logitech MX 518 and replaced it a few days ago with a Cherry MW 3000).

PG, if you can’t reproduce the problem yourself, is there any way for me to log the exact input data in Wavelab (like exact mouse cursor position, exact state/action of the mouse-wheel, recognized shortcuts and execution of actions … something like that), maybe with help of the integrated Diagnostics function? I already looked a bit into it, but didn’t find a suitable log code…

Short update:
I tried to use a very simple mouse without any additional buttons (just left click, right click and scroll wheel + scroll click), same issue occured, so probably no mouse-related issue.
I even did an upgrade on my main computer from Win 10 Pro to Win 11 Pro 22H2 (although not a clean reinstallation, just via update), no changes here either. I’m out of ideas, except the modified zoom functions from Wavelab 11.1.10 beeing the culprit, for whatever reason.

In the next minor version, it will be possible again to select audio and wheel-scroll in the same time (actually, in a smoother way).

But concerning the issue “the zoom level is sometimes jumping wildly around,” I just can’t reproduce it. Using the diagnostic function would not help I am afraid, because mouse actions are highly volatile.
Can you reproduce this in the montage and audio waveform editor? (that is, not with the spectrum view).

Yes, I can. In the editor with waveform view it seems to happen very rarely, to be fair (or maybe it is not noticable enough). But as mentioned some time ago within this thread, it occurs more often and obvious when there is more to compute - like the spectrogram/wavelet/loudness view in the editor, or a larger montage with multiple tracks and several tens/hundreds/thousands of clips.
To be clear, it seems to occur mostly random, so it might not be exactly “reproducable”. It just feels like Wavelab is choking on too much input at some point and doesn’t do what it is supposed to do.

Well, I had some faint hopes, but it’s still not as it used to be …

I just updated to Wavelab Pro 11.2.00. I’m very glad about about the fix P-5930 (“Horizontal scrolling via the mouse-wheel, in combination with a range selection, now works as expected.”), selections and moving clips while scrolling now work very well again … Except - any mouse movement (seemingly regardless the axis) occasionally leads to unwanted zoom. This seems very connected to my original jumpy-zoom problem …
Wavelab, since version 11.1.10 or so, just doesn’t seem to like any mouse movement while I’m trying to do another mouse-based function with at least 2 button inputs (including combined input from the keyboard). So far I can reproduce problems with the following functions I tested, in the editor and montage alike:

  • hold [Ctrl] + scroll [Mouse-Wheel] (horizontal/time zoom) + mouse movement occasionally leads to jumping horizontal zoom levels.
  • hold [Shift] + scroll [Mouse-Wheel] (vertical/level or frequency zoom) + mouse movement occasionally leads to jumping vertical zoom levels.
  • hold [Middle-Mouse] + scroll [Mouse-Wheel] (vertical/level or frequency zoom) + mouse movement occasionally leads to jumping vertical zoom levels.
  • hold [Left-Mouse] + scroll [Mouse-Wheel] (select or move clips along the time axis) + mouse movement occasionally leads to unwanted horizontal zooming.

When I hold my mouse as still as possible or lift it far enough from the table to absolutely avoid any registration of movement, all of these functions work perfectly fine.

For what it’s worth, the combination hold [Alt] + scroll [Mouse-Wheel] to scroll vertically across multiple tracks of a montage doesn’t seem to be affected by any mouse movement, as well as [Alt] + [Shift] + [Mouse-Wheel] for vertical track zoom.

I also did an Wavelab update on my laptop, tried a bit and ended up with the same results. So I can’t really believe that I’m the only person experiencing this, since I can reproduce this on 2 very different systems (my main PC: Win 11 Pro 22H2 | AMD Ryzen 9 5900x | 32GB DDR4 RAM | NVIDIA GeForce RTX 3080 | LG 4K display @ 60Hz without High-DPI scaling – my Lenovo laptop: Win 10 Pro 22H2 | Intel Core i5-6300U | 8GB DDR3 RAM | Intel HD Graphics 520 | Integrated Full-HD display @ 60 Hz without High-DPI scaling).

I must say I don’t see what you mean. The video you posted on Jul 22 is not explicit. I have yet to understand what the problem you describe is, because I see none at all. Maybe somebody else can shed light on this?

Yeah, I thought so. But I know myself how it can be, if you are told about a problem, that you cannot understand or relate to, until you experience that problem yourself. And I know, that understanding a problem is an important key to fix it (which might be especially true for software programming, I would guess).
I can only try to make another video of my problems, maybe even with explanation voiceover, but I would have to figure some things out for that …

Here we go. Best watch in highest possible resolution, and maybe play it slower to the catch on the details:

2 Likes

Thank you for this very well-made video, which must have taken you some time to produce. I now have a good understanding of the problem; in fact, it’s what I had imagined but could never reproduce. However, I think this video will be helpful for me to troubleshoot the issue.

2 Likes

@Laturec What is the (good) software you have used to record this screen session? Thanks

I’m glad the video helped you so far. Even better, if you actually can find and fix something through this.

The software I used for the screen capture is OBS Studio, which is free and seems to be used even by professional content creators. Editing was done in Adobe Premiere Pro CC. I have edited a few video projects before, but this was indeed my very first project in this format (including the voiceover), so it took most of my last saturday.

1 Like

What OBS plugin are you using to capture the mouse button activity and the modifier key activity (eg. “Control key Pressed”).
Steinberg might provide small videos for documenting local WaveLab mouse actions in the future, and the software to achieve that… is yet to determine. The famous Camtasia cannot record the modifier keys when using the mouse.
OBS Studio seems to fir the bill, but I could not find the plugin to achieve this Modifier key recording.

Ah, right, I didn’t think about that. These are not OBS Studio plugins, but actually 2 different small programs.

The free tool MPos reads the cursor position - although I noticed on a frame-by-frame view, that the coordinates seem to be updated only after 3 to 4 frames (being 50 to 60 milliseconds with 60Hz), for whatever it matters.

And the tool responsible for mouse button and keyboard input with the nice visuals is Carnac, also free.
The other tool you can see in my earlier short videos in this thread is QiPress. The Lite version is free for non-commercial use, and there is a paid Pro version for commercial use with several more functions.

I think a visual documentation of the possible mouse actions is a good idea. But as these videos might probably be very short and cropped to a certain area, I could also imagine for you to just create your own overlays/icons/graphics in the right combination within the video. This will take some more efforts, as the graphics have to be created and edited into the video, but you wouldn’t have to rely on the look and possible limited functions of an external logging-tool.

1 Like

Just a quick update for my originally described problem: It still haunts me in WaveLab Pro 12.0.10, using Windows 11 Pro 23H2.


Further I found another anomaly related to zooming with the mouse wheel, using the Horizontal Zoom controller wheel on the bottom right corner of the main window - the one you can either click & drag with the mouse cursor, or spin with the mouse wheel (number 3 in the picture from the WebHelp).

I do not use the controller wheel very often, as I mostly zoom with the shortcut [Ctrl] + [Mouse Wheel], but I noticed at some point, that the zoom by mouse wheel did not behave as expected when using the controller wheel - it was either just further zooming in or further out, regardless the direction I rotated my mouse wheel.

So with some testing I found, that using the shortcut [Ctrl] + [Mouse Wheel] basically “locks” the controller wheel into the same direction that I zoomed to last - if I zoomed in with the shortcut, the controller will only zoom in - if I zoomed out with the shortcut, the controller will also only zoom out. The spinning animation of the controller wheel goes also only in that particular direction, regardless of the actual mouse wheel input.
To make the controller wheel work normally again, I have to use the click & drag method on it, or just double click on it.
Using the click & drag function itself works flawless.

This problem is true for all the Horizontal Zoom controller wheels - so in the upper Overview and the lower Main View section of the Editor, and also in the Montage - regardless of the current Display mode.

Scrolling the Vertical Zoom controller wheels with the mouse wheel work fine, even when I use the [Shift] + [Mouse Wheel] shortcut before.

I can reproduce this in WaveLab Pro 12.0.10, in WaveLab Pro 11.2.0 and even in WaveLab Pro 10.0.70.

Thanks for your effort to communicate your findings. This being said, I still don’t see any issue, I mean something that affects zoom workflow in general.

On the other hand, concerning zoom workflows, I would like to recall this great WaveLab 12 addition: “zoom to peak” (for the level).
Also, for the horizontal zooming, while you make a selection with the mouse, you can now move the mouse up and down (with Shift pressed) to zoom in-out at the place of the selection edge.

You are not wrong, zoom workflows do work in general. And there are enough options to chose from, maybe too many for my personal use cases and habits.

But unfortunately not all of them work flawlessly for me (which does not mean that they do not work at all, just to be clear), otherwise I would not have created this topic.
As a user I can just try to report the appearance of a problem in conjunction with the circumstances or even possible causes. And either you as developer can reproduce the problem on your side and fix it, or it is a very system-specific problem for me, that I have to arrange myself with, especially if no one else can confirm my findings.

Considering the vast possibilies of how you can build a PC (selection of core components, manufacturer and compatibility of these components, firmware/drivers, operating system, system settings, other software, peripheral hardware, …) I would not be surprised if there is some room for unexpected errors you can not cover as a dev, you might know that better than me. But I’m sure I have seen a few other topics about problems where I thought myself: “Huh, this works fine for me.”
For some time now I wanted to completely reinstall my PC (clean new Win 11 + applications installation), and see if that would change anything, but I have reasonable doubts about that… let alone the missing motivation to setup everything again, too.