Rescaling v2.0.3 - differences between VST2 and VST3

Question

After my recent find with the first loading problem and solution here, I've tested out both VST2 and VST3 2.0.3 rescaling functionailty. VST2 shows the handle, but when I try to rescale in Cubase 9.5.40, the handle works and I get a white 'refresh' area but the window seems to 'fight' with me and keeps trying to scale to smallest possible window size. When I release I get a small (like pixel small) window for the synth so I have to close it, reopen it and the view resets back to original size - so resizing doesn't work correctly on VST2 64bit for some reason.

VST3 64 bit 2.0.3..... now we're cooking. Works superbly, scales in real-time and fills up a 4K screen so well. On closing then reopening VST3 remembers the size and position on screen so there's no issues there.

Once 2.0.5 is repackaged (to house the VST3 64bit version instead of the 32bit as per this link) I'll test both VST2 and VST3 for rescaling. If VST2 fails in Cubase I'll try in Reason and see what that does (might work differently), and will test other DAWs (got a fair slew of them... Reaper, Studio One, Samplitude, Waveform, Harrison Mixbus, plus I can test in Soundforge for the FX as an insert to see what happens in that).

Answer 1

Many thanks for the detailed info (again)!

v2.0.6 for all platforms has now been posted.   This build fixes the installer issue on Windows.   Also, I added some additional logging info to the startup/shutdown process to see if I can figure out where those long scan times are happening.   I am still not able to reproduce this issue, and have tried Bitwig/Waverform on all platforms, Waveform,Ableton,Bitwig,Cubase on Mac and Windows, and they all work nicely for me... go figure, the developer's machine seems happy ;)

I also added a feature to remember the latest plugin window size in preferences, this might be good for those DAWs that don't recall the window size, and any newly created plugins will use the window size of the last closed plugin UI.

Comments

BTW, thank you again for finding that wacky Windows installer issue.   That was something that we missed, as it only happens when you choose one bit type and no the other.   Anyone (including us), just taking the defaults, would never have found that.  Cheers!

---

No problem - since I use both VST2 and VST3 it's pretty handy to check both for those who only use one or the other. I do like a good breakage of things at times, and know the pain when things just wig out :D Also guess your dev machine gets plenty love lol ;) all good, will check out 2.0.6 and see what happens. I'll just install on top of 2.0.3 and see if everything checks out fast (prebuilt database from 2.0.3), and then I'll uninstall, blank-slate it and see if I get the hanging splash again. If I do I'll youtube private link it so you can see and I'll send the logs too

Answer 2

v2.0.3 VST2 works fine in Reason, rescale window all good. It does take a while for the patch database to build (I presume this is what is happening in the background while the daw is 'hanging', but once finished WaveRazor appears). On restarting any DAW the plugin loads up instantly. This patch database build seems to have happened on both my machines (Win10 x64, laptop and pc), so both were fresh installs uniquely.

If it is possible to have the popup progress bar for the patch database build for newbie users to understand something is happening and not bug out or mash up a half build database that might be a good approach. Something to do with:

mokzen - mokReBuildUserPatchEntries, patchFolder is NOT directory stat: patch << this was in the log file today, after I installed 2.0.3 on top of 2.0.2 (without uninstalling)

hope this helps a bit more

Comments

In v2.0.9, the startup/creation stuff should be more stable and a bit faster.   The update to the db (when installing a Waverazor update) should be nearly as fast as normal now.    So for most users, the slower startup (which is now faster) will only happen one time.