Starting today, the Diva GUI does not redraw. It is completely unusable. It was fine a few days ago.
Some things I did since I last saw it working:
- Upgraded to OS X 10.9 (from 10.8)
- Updated Diva to 1.3 beta (1593 => 1973)
- Updated the Native Instruments plugins.
Environment:
Macbook Pro Retina
Mac OS X 10.9
Reaper 4.54 32-bit
Diva VST rev 1973 (also tried going back to 1593)
This also happens with other u-he plugins, e.g. Zebra 2 demo.
The AU version works fine.
Steps to reproduce (in Reaper):
- Open the FX window of a track.
- Insert Diva (VST)
- Click on "Patches".
- Diva still shows the main view, not the patches browser.
- Resize the FX window: Diva now shows the patches browser.
- Same for twisting knobs or clicking on buttons.
Bug: Diva GUI does not redraw (VST, Mac)
-
- KVRer
- 18 posts since 25 Oct, 2013 from Hamburg
-
- u-he
- 30247 posts since 8 Aug, 2002 from Berlin
-
- KVRAF
- 1946 posts since 25 Feb, 2005
teatinker wrote:Starting today, the Diva GUI does not redraw. It is completely unusable. It was fine a few days ago.
Some things I did since I last saw it working:
- Upgraded to OS X 10.9 (from 10.
- Updated Diva to 1.3 beta (1593 => 1973)
- Updated the Native Instruments plugins.
Environment:
Macbook Pro Retina
Mac OS X 10.9
Reaper 4.54 32-bit
Diva VST rev 1973 (also tried going back to 1593)
This also happens with other u-he plugins, e.g. Zebra 2 demo.
The AU version works fine.
Steps to reproduce (in Reaper):
- Open the FX window of a track.
- Insert Diva (VST)
- Click on "Patches".
- Diva still shows the main view, not the patches browser.
- Resize the FX window: Diva now shows the patches browser.
- Same for twisting knobs or clicking on buttons.
There are reports that all plugins in Studio One on 10.9 do the same.
Mac Studio M4
15.7.3
Cubase 15, Ableton Live 12
15.7.3
Cubase 15, Ableton Live 12
-
- KVRist
- 46 posts since 20 Mar, 2008
Getting the same behavior (also 10.9) in REAPER 4.5x. This is not a production machine so it's not really a concern.
Just to add a small bit of detail:
Whenever you use the module changing drop down menus it seems to force a redraw.
Also the underlying functions are working, it's strictly a draw issue; I have several parameters MIDI-learned to a controller and, while the controls/labels don't move at all during adjustments, you can certainly hear the parameter adjustments taking place.
Just to add a small bit of detail:
Whenever you use the module changing drop down menus it seems to force a redraw.
Also the underlying functions are working, it's strictly a draw issue; I have several parameters MIDI-learned to a controller and, while the controls/labels don't move at all during adjustments, you can certainly hear the parameter adjustments taking place.
-
- u-he
- 30247 posts since 8 Aug, 2002 from Berlin
Unfortunately we're currently occupied by soem releases, thus we have not much time to explore Mavericks. We however don't use third party libraries or wrappers. That means, our VST2.4 is real VST2.4, our VST3 is real VST3 and our AUs are real AUs, while all of our window handling and drawing code is directly written using MacOS X methods. Thus I think that whatever goes wrong is either related to us keeping backwards compatibility with Leopard, or it may be related to hosts doing something out of specs.
Either way, we'll have real difficulties to look into this right now. If we need to give up Leopard compatibility for Mavericks then we'll do so *after* the next update cycle. If it's a host issue then we need to wait until the hosts are updated. If it's something else we would like to see confirmation that a fix/workaround for these issues exists.
Either way, we'll have real difficulties to look into this right now. If we need to give up Leopard compatibility for Mavericks then we'll do so *after* the next update cycle. If it's a host issue then we need to wait until the hosts are updated. If it's something else we would like to see confirmation that a fix/workaround for these issues exists.
-
- KVRian
- 574 posts since 20 Aug, 2013
What exactly do you mean with "doesn't redraw"?
Does it happen instantly on plugin load or after a while or...?
I literally have a Reaper project open on our Mavericks machine right this second, all our plugins are displaying and GUIs are updating nicely.
Does it happen instantly on plugin load or after a while or...?
I literally have a Reaper project open on our Mavericks machine right this second, all our plugins are displaying and GUIs are updating nicely.
-
- KVRist
- 46 posts since 20 Mar, 2008
If I can I'll try to make a screen grab later but basically:
Any control that I use doesn't move/redraw; any button I push, likewise. Until you manually force the redraw (which, as I said, I've been doing by activating the drop down menus), then the control will show the new position (but since you can't see the control moving you're basically guessing as to where you just set any given parameter). This behavior is instant on plugin load.
And as reported, this is only occurring in the VSTi, the AUi seems to be working normally on my system.
Might also be worth mentioning that mine is a clean install (I did the upgrade install, then blanked my drive and reinstalled from scratch). Not sure if that makes a difference but I'm not seeing this problem widely reported so I'm looking for ways my little MBP might be different.
For me this is the lowest possible priority; I did not (and will not) update my production machines until I'm seeing the results I want from my test machines. So don't take my repeated posting here as a plea for help; just trying to provide info.
Any control that I use doesn't move/redraw; any button I push, likewise. Until you manually force the redraw (which, as I said, I've been doing by activating the drop down menus), then the control will show the new position (but since you can't see the control moving you're basically guessing as to where you just set any given parameter). This behavior is instant on plugin load.
And as reported, this is only occurring in the VSTi, the AUi seems to be working normally on my system.
Might also be worth mentioning that mine is a clean install (I did the upgrade install, then blanked my drive and reinstalled from scratch). Not sure if that makes a difference but I'm not seeing this problem widely reported so I'm looking for ways my little MBP might be different.
For me this is the lowest possible priority; I did not (and will not) update my production machines until I'm seeing the results I want from my test machines. So don't take my repeated posting here as a plea for help; just trying to provide info.
-
- KVRian
- 574 posts since 20 Aug, 2013
If not a plea for help, it may still help solve one (or even more) potentially undiscovered bug(s) for others.ngarjuna wrote:don't take my repeated posting here as a plea for help; just trying to provide info.
I can now reproduce this behaviour, couldn't before because I was using Reaper x64.
It occurs only with VST2 in 32-bits... AUi x86/x64 and VSTi x64 are fine.
Let's see what we can do about that!
-
- u-he
- 30247 posts since 8 Aug, 2002 from Berlin
The 32-bit VST version is the only one left with Carbon code. It may well be that some function we use is deprecated in Mavericks.
I'm sure we'll know more shortly.
I'm sure we'll know more shortly.
-
- KVRer
- 26 posts since 5 Apr, 2004
Can confirm seeing similar behavior with Diva 32-bit VST on OS X 10.9 in Studio One 2.6.1 32-bit. When clicking on any of the tabs beneath the Lower Panel in Diva, it would seem like nothing happened, then when clicking on the main Data Display up top, the UI would switch to whatever tab that had previously been clicked. The 64-bit VST2 and 64/32-bit VST3 and AU worked as expected.
Fwiw, I experienced similar GUI issues with SoundToys 32-bit VST effects as well, where clicked items wouldn't open and automated events wouldn't move; along with CPU spiking in several plugins (Iris, Play, SoundToys, even Diva a couple of times). The only way to get no spiking whatsoever was to run Studio One in 32-bit mode with 32-bit VSTs only, but then the GUIs didn't work.
It seemed like a bit of a mess, so reverted back to a 10.6.8 clone and everything is working again. (Edit: Back on 10.9 because of the following temp fix.)
Fwiw, I experienced similar GUI issues with SoundToys 32-bit VST effects as well, where clicked items wouldn't open and automated events wouldn't move; along with CPU spiking in several plugins (Iris, Play, SoundToys, even Diva a couple of times). The only way to get no spiking whatsoever was to run Studio One in 32-bit mode with 32-bit VSTs only, but then the GUIs didn't work.
It seemed like a bit of a mess, so reverted back to a 10.6.8 clone and everything is working again. (Edit: Back on 10.9 because of the following temp fix.)
Last edited by Akshara on Thu Nov 14, 2013 10:29 am, edited 1 time in total.
-
- KVRer
- 26 posts since 5 Apr, 2004
Though not specific to u-he plugins only, I wanted to add a discovered workaround to the discussion for anyone researching the problem with unresponsive VST 2.4 GUIs after upgrading to OS X 10.9, as it may be a temporary fix and allow for continuing forward with Mavericks and 32-bit only VSTs.
In the DAW host, open any VST 2.4 plugin which has a text input field on the UI itself and type into that field. I use Klanghelm's VUMT meter and type a zero into one of the Trim knob fields then hit Enter. Once that occurs, all of the GUIs across all VST 2.4 plugins become unlocked and respond to input and automation.
I've been able to repeat this consistently, at least within Studio One. Preset menus, GUI elements and read automation work properly. The unlock persists between closing and opening projects or songs, yet has to be reapplied when closing and opening S1 itself. The process does not work when using one of the built in effects, only a third party VST 2.4 plugin which has a text UI field.
The fix comes from ExcitingPotatoes in post 12 of the Mavericks plugins GUI issue discussion at the Cockos forum. Am thankful to him/her as it genuinely works.
In the DAW host, open any VST 2.4 plugin which has a text input field on the UI itself and type into that field. I use Klanghelm's VUMT meter and type a zero into one of the Trim knob fields then hit Enter. Once that occurs, all of the GUIs across all VST 2.4 plugins become unlocked and respond to input and automation.
I've been able to repeat this consistently, at least within Studio One. Preset menus, GUI elements and read automation work properly. The unlock persists between closing and opening projects or songs, yet has to be reapplied when closing and opening S1 itself. The process does not work when using one of the built in effects, only a third party VST 2.4 plugin which has a text UI field.
The fix comes from ExcitingPotatoes in post 12 of the Mavericks plugins GUI issue discussion at the Cockos forum. Am thankful to him/her as it genuinely works.