I’m using plugins like Slate FG-X and Kazrog Kclip with Wavelab Pro 9:0:3 and I’m having problems controlling the parameters of the plugs with my mouse.
Everytime I switch to another parameter, it seems the mouse is sticking to the previous parameter making it very difficult to alter other parameters. The only way I can change another parameter is to hide the plug and make it visible again. Not a very comfotable workflow.
I’ve read another post stating the same issue but it hasn’t been solved yet. I’ve done some investigating and it seems that VST-plugins can be tricky, so maybe that’s the cause of the problem.
I’m also using Logic on the same computer and no problems there with the plugs (audio units).
Any other users facing the same problem?
I’m on OS-X Yosemite (10.10) and a standard (wired) magic mouse.
The Kazrog developer came into the bottom of the following thread with updates, so if that doesn’t help, it would be helpful to report mouse hangs to them. I don’t remember seeing Kazrog mouse sticking reports.
Same for Slate. Mouse problems on Mac were reported to them at the bottom of the following thread, but it might speed things along if you reported the problems to them as well.
The issues I was having related to this cleared up around version 9.0.20 but I can’t say I tested every plugin. The big ones for me were AirEQ and iZotope Ozone and RX5 modules.
I have massive issues like that with Accusonus ERA-D, beside other problems. WL9Pro is the only application where I get this. (Yosemite 10.10.5 Microsoft Mouse)
I just tried the Tokyo Dawn Labs Nova EQ (Gentleman’s Edition) and this issue exists for me in that plugin:
I hope that either plugin developers can figure out what is wrong on their end, or this can be resolved in WaveLab. It’s the only DAW I’ve seen this happen in.
Somehow it was solved on the WaveLab side for me in quite a few plugins but apparently not all.
Allow me to play devil’s advocate for a second and point out that…
“It’s the only DAW I’ve seen this happen in”
…is a strong indicator.
The problem is that all the mentioned developers have their stuff running stable and fine in countless plugin host environments, operating systems and plugin formats, most of them being far more restrictive regarding threading and general code quality than the VST world. All these devs use exactly the same UI code across all formats and operating systems, so it has to be solid from the beginning.
Maybe the wavelab team could meet up with the cubase team for an afternoon and find out what the differences really are. I mean they HAVE a working code in house (Cubase, Nuendo), it’s a bit shizophrenic to make third party devs work on this. This could be a reason why so few answered.
The closest match I’ve found regarding the reported problems is this statement from JUCE mastermind Jules saying:
"Thanks for the heads-up, but it sounds like something that’d be impossible to fix.
My guess is that Wavelab must be setting up OSX mouse-tracking areas on the window, which screws up a lot of mouse-move event handling. If that’s the case then it’s one of those “sorry, would need to be fixed in the host” bugs."
IMHO, this is exactly what is happening here. Only Wavelab mac (win seems fine), and no other plugin host on the planet seems to occasionally lock/steal (i.e. not pass through) mouse-up events. These of course are essential to the proper function of user interfaces, and sadly, fully at the control of the hosting software. One missing mouse-up will break the mouse interaction of any plugin, no matter how well they are programmed. The first layer of mouse handling of windows generated by wavelab is 100% under control of wavelab, it’s then WL’s job to pass them down to the plugin windows.
While I don’t feel great pointing my finger at wavelab, I see no other reasonable option in this specific case. But I’m open for suggestions of course.
FabienTDR, it’s great that you’ve come in to comment on this since most plugin developers don’t, and I hope the conversation continues until resolution, but why only JUCE? AFAIK Waves, UAD, Fabfilter, Sonnox don’t exhibit the problem and never did. And it’s great that you posted the link, but the second post there says it doesn’t happen with JUCE in OSX 10.8, so what could account for that? I happen to have an OSX 10.8 machine I’ll be trying this on at some point.
Kazrog was noted in the first post in this thread as having sticky mouse, and the developer came in here and supposedly fixed all issues with his plugin. I haven’t tried the new version but maybe somebody else has and can comment.
Don’t want to sidetrack this because I hope Steinberg comments on it, but I’m not sure others haven’t possibly solved this somehow.
But I hope the Wavelab team does as well. The problem is, without doubt, exclusive to WL mac.
Question does this stuff happen to sliders only (knobs, text-sliders)? Or do you run into the same trouble when interacting with nova’s display as well?
I’ve reproduced the mouse issue in the latest version of my plugin KClip, and I’m in agreement with Jules’ post here that was linked earlier in the thread:
That said, I could try some clever Mac specific hacks/workarounds in the mean time. Of course, this would have to be done in such a way that wouldn’t interfere with proper mouse handling in other Mac DAWs.
One thing of note is that if I click over a knob, then click again to sort of “confirm” my mouse position, I can get the knobs behaving consistently. Annoying, but it works.
So Slate won’t be able to fix it either? They say they have a new version of FG-X coming out that will be fully tested in Wavelab before official release, but it’s not even in Beta yet, so I don’t think they’ve gotten that far.
Any ideas why JUCE and Wavelab would be ok in OSX 10.8, but nothing after 10.8?
Can’t comment specifically on Slate, but honestly, it’s really not up to any of us plugin devs to fix this. The problem has been isolated beyond any reasonable doubt.
Speculative reasoning follows…
It stands to reason that there was some change in UI event handling in later versions of Mac OS X that affect whatever specific implementation exists in Wavelab with regard to handling mouse events inside child windows (e.g. plugins.) This is why it also stands to reason that this issue is beyond the scope of what JUCE (or any other UI framework) can reasonably attempt to resolve. In other words, since the issue (a) happens only in Wavelab, and no other Mac DAW and (b) does not happen in the Windows version of Wavelab, it seems that there must be some special/unusual thing that Wavelab is doing on this platform that is causing a delay in mouse events transmitting to child windows.
I think Mac (as opposed to Windows) WaveLab users are probably in the minority which why this issue is under reported and also less noticed in beta testing by the developers (if they do any at all). It seems there are more Windows users overall though I think WaveLab holds the majority of users for mastering software for Mac. I know that’s confusing but hopefully it makes sense.
WaveLab Users = Mostly Windows
Mac Based Mastering Studios = Mostly WaveLab
Anyway, I assumed this problem was resolved because earlier this year it went away for me with iZotope and AirEQ where I saw it regularly. The rest of the plugins I normally use never showed this such as UAD, Waves, FabFilter, Plugin Alliance, DMG etc.
I heard Ian Shephard talk about the Tokyo Dawn Labs Nova EQ on his podcast and he noted that he liked the plugin but that the interface was “quirky” in WaveLab. I was pretty sure I knew what he was referring to so I thought I’d try the EQ myself and see if it was this issue.
I normally try to avoid the smaller plugin companies because in reality, there tends to be more minor (and sometimes major) bugs with smaller plugin companies in WaveLab and I don’t have the time for such things.
I will say that TDL Nova EQ and KClip are such great plugins that I really hope that someday soon they will work as well in WaveLab as they do in other DAWs.
Maybe the plugin developers using the JUCE system don’t use the last JUCE framework version. I have run a JUCE demo plugin today (latest version), and I can’t reproduce the problem with WaveLab 9.0.30. Therefore, you may ask your plugin manufacturer is they really use the current version of this framework.
Based on what I’ve seen and heard, it’s probably a Mac-only issue. There is something interesting about the default plugin setting where if you have the “Drag Mode” in the plugin settings set to “Velocity Speed”, the cursor may disappear while you are adjusting a knob. If you set it to “Linear”, this doesn’t happen.
At first I thought it was another bug but I guess it’s by design so I just keep it set to “Linear”. I tested it in REAPER too and it’s the same so it must be intentional.
I can’t reproduce any problem in wavelab pro, latest version on win 7 (64 bit), and we haven’t received any reports from the windows side, so it should be fine. Yes, this is mac only.
can I assume this issue for Nova is also Mac-only?