KVR Audio

EvilDragon · Post by **EvilDragon** » Tue Mar 30, 2021 6:14 pm

It seems like on Windows 10, 20H2, creating a COptionMenu that uses multiple columns and has submenus is rendered broken:

I unfortunately cannot find any other program that I own, that uses raw Windows APIs for drawing (i.e. not a framework like VSTGUI or JUCE), has multi-column menu with submenus to see if it's really a MS issue or a VSTGUI issue...

Just FYI, Surge Synth Team did fork VSTGUI in Jan 2019 at commit 37af1b00. That fork (with a number of our own fixes to VSTGUI) is available here.

We're about a month away from releasing 1.9, I would personally like to know if it's a MS thing or not so that we can then either axe the multi-column menu in this particular instance. Interestingly, a COptionMenu that doesn't have submenus works just fine!

Also, this only happens on Windows because VSTGUI implements multi-column menus only for Windows.

Thanks to anyone willing to answer!

EvilDragon · Post by **EvilDragon** » Thu Apr 01, 2021 1:41 pm

Hmmm, just discovered that Serum also has this multi-column menu with submenus for their preset menu, and that works fine in 20H2... and is also VSTGUI... Darn it!

S0lo · Post by **S0lo** » Sat Apr 03, 2021 11:08 am

I'm under the impression that Serum is VST2, hence it's probably also using VSTGUI 3 (not VSTGUI 4). So if that works fine, then the issue could be with VSTGUI 4

EvilDragon · Post by **EvilDragon** » Sat Apr 03, 2021 11:42 am

Good point there! Although IIRC Steve is working on VST3 version too, so... who knows?

But the main thing here is: the multi-column menu renders fine on all Windows versions PRIOR to 20H2... I can't see anything suspicious in here.

mystran · Post by **mystran** » Sat Apr 03, 2021 1:33 pm

Nvm, didn't register the other check, ignore this.

lkjb · Post by **lkjb** » Sat Apr 03, 2021 6:54 pm

I had the impression IPlug also uses plain Windows menus which for example QRange uses for its settings. I haven't been pushed to 20H2 yet so can't say whether this is a problem in QRange/IPlug, too. I also might be wrong regarding the implementation in IPlug.

I think I'd build a simple VSTGUI plugin with only a COptionMenu and compile it using different VSTGUI versions to narrow down the culprit.

EvilDragon · Post by **EvilDragon** » Sun Apr 04, 2021 7:50 pm

Hrmmm...

https://github.com/steinbergmedia/vstgu ... onmenu.cpp

History of win32optionmenu. Unsure if anything here would be the cause. Unless this repo only contains VSTGUI 4. When was VSTGUI 3.6 released?

lkjb · Post by **lkjb** » Mon Apr 05, 2021 8:21 am

Are you sure this is a Windows 10 20H2 issue? After compiling the github code and running the plugin (debug & release, current Reaper x64) in a Windows 10 Home 20H2 (build 19042.867) VM the menus were shown as expected.

Is there a reason for the airwindows plugins being included in the solution? At least a quick search didn't reveal any usage.

baconpaul · Post by **baconpaul** » Mon Apr 05, 2021 10:05 pm

lkjb wrote: Mon Apr 05, 2021 8:21 am Are you sure this is a Windows 10 20H2 issue? After compiling the github code and running the plugin (debug & release, current Reaper x64) in a Windows 10 Home 20H2 (build 19042.867) VM the menus were shown as expected.

We made it off-by-default at head to avoid the bug. If you go to the workflow menu you can toggle it back on and then it will probably break (it does in our 20H2 tests)

lkjb wrote: Mon Apr 05, 2021 8:21 am Is there a reason for the airwindows plugins being included in the solution? At least a quick search didn't reveal any usage.

They are used to put the airwindows into the FX bank. The usage is in src/common/dsp/effects/airwindows and all of them are linked.

lkjb · Post by **lkjb** » Tue Apr 06, 2021 6:03 pm

If I enable "Use multiple Columns in Patch Browser Menu" I see the same horizontal menu with Windows 2004 Pro (build 19041.867) as I see with Windows 20H2 Home which looks quite like the screenshot above. Also, a quick test in a Windows 7 VM shows the same menu, maybe I misunderstand the issue.

baconpaul · Post by **baconpaul** » Tue Apr 06, 2021 10:25 pm

lkjb wrote: Tue Apr 06, 2021 6:03 pm If I enable "Use multiple Columns in Patch Browser Menu" I see the same horizontal menu with Windows 2004 Pro (build 19041.867) as I see with Windows 20H2 Home which looks quite like the screenshot above. Also, a quick test in a Windows 7 VM shows the same menu, maybe I misunderstand the issue.

Well that's good information. It means the bug isn't because of 20H2 but is because of "something else" which impacts some of our users. For the users not impacted, the experience with that menu swapped is way better, but of course, we can't make that a default for the reason you shared.

I wonder what it is if not the OS version! (I'm on MacOS so am not an expert in the vagaries of different windowses).

EvilDragon · Post by **EvilDragon** » Wed Apr 07, 2021 3:02 pm

This is weird because it works on my 2004 desktop (19041.867) just fine! Unsure if monitor matters, but 1920x1200, no OS scaling... using iGPU on my i7-6700K for graphics.

S0lo · Post by **S0lo** » Wed Apr 07, 2021 4:50 pm

EvilDragon wrote: Sat Apr 03, 2021 11:42 am I can't see anything suspicious in here.

In this, there is the lines:

Code: Select all

if (nbEntries < 160 && _menu->getNbItemsPerColumn () > 0 && inc && !(inc % _menu->getNbItemsPerColumn ()))
flags |= MF_MENUBARBREAK;

I'd try to debug here and see if flags variable gets the MF_MENUBARBREAK flag each and every time. If thats so then there is a lead here. It looks like it shouldn't get the MENU BAR BREAK until once in while. (i.e when inc is a multiple of getNbItemsPerColumn())

EvilDragon · Post by **EvilDragon** » Wed Apr 07, 2021 7:08 pm

Yep, it does...

https://imgur.com/aXyI9NQ

But only on my Surface, my desktop it's A-OK...

That's even with modifying the code to be:

Code: Select all

if (nbEntries < 160 && _menu->getNbItemsPerColumn () > 0 && inc && !(inc % _menu->getNbItemsPerColumn ()))
{
	printf ("Got menu column break at %d (pointer %p)!\n", inc, _menu);
	flags |= MF_MENUBARBREAK;
}
else
{
	flags &= ~MF_MENUBARBREAK;
}

lkjb · Post by **lkjb** » Wed Apr 07, 2021 7:22 pm

In CPatchBrowser.cpp, line 171, the following code sets contextMenu->nbItemsPerColumn to one as usercat_pos is zero.

Code: Select all

if (multicolmenu)
{
  contextMenu->setNbItemsPerColumn(usercat_pos - 1 + 2);
}

If I hardcode setNbItemsPerColumn(10) at this point the menu shows 10 items per column but the "Load from Patch..." part is making the other colums having some space below.

Further inspection reveals that in my case line 156:

Code: Select all

if (i == storage->firstUserCategory)
{
  usercat_pos = root_count;
}

is never true as storage->firstUserCategory equals storage->patch_category.size() (the for loops maximum). As soon as I add a user patch the menu is shown as it probably should be. This also should explain why it didn't work in all my tests but worked on EvilDragon's 2004 machine where Surge is probably regularily used.

One question out of interest: how is VSTGUI integrated in the Visual Studio solution? I haven't found any source files or "MF_MENUBARBREAK" when searching the solution. I got to the win32optionmenu.cpp file by creating a compile error in it using a text editor and opening it from Visual Studio's compile output when surge-headless didn't compile any more. I might have to add that I'm not familiar with CMake and was very pleasently surprised when I got the created project to compile by cloning with recursion and running CMake. This is not a common experience when glancing at bigger open source projects.

(SOLVED) Can anyone confirm this issue in Windows 10 20H2? (VSTGUI)