No GUI elements in my plugin when compiled for x64 VST


#1

Hi all:

I am porting my code to x64 VST tonight (just got Windows 7 machine + VS2010). For some reason, none of the UI elements are showing up in my GUI window. The background image does, but nothing else shows up. I can adjust the controls from the host’s parameter view, and the Win32 version compiles on the same machine with no problem, so I have no idea why compiling for x64 would make a difference.

To test things, I took my custom LookAndFeel, embedded font, and control classes, and ported them over to the JuceDemoPlugin. Which now looks like my look and feel, even compiled as x64. So the issue doesn’t seem to be with my LookAndFeel classes or custom controls.

Any idea what might be going on here? I’m new to x64 development, so I am unsure what type of weirdness might be going on here.

Thanks,

Sean Costello


#2

OK, some more details:

I removed my background graphic, and now my editor window is a blank (dark blue) screen. The weird part is, my UI elements are still there, just invisible. If I move the mouse to where the sliders should be, and click ‘n’ drag, I can change the parameters (the parameter view of the host confirms this). So, what kind of change in x64 would cause such strange behavior?


#3

The only thing I can think of where I’ve seen this before is when you try to turn on a combination of optimisation flags and the MS compiler completely screws up the floating point behaviour of the graphics code, making all the values go out of range… Try turning off some of the more aggressive optimisation options and see if that helps.


#4

I can confirm this for VS2005 on win7 64bit. As soon as I turn on /O2 for my x64 release build, the GUI stayed empty, displaying only the background colour. I did not yet find a workaround except disabling optimization with /Od.


#5

Really? I make pretty heavy use of the optimization flags in my plugin, to bring the CPU down. It is one of the selling points of it, to be honest.

Is there any way of selectively optimizing specific files, such that my DSP code is fully optimized, while the GUI code is less optimized?


#6

Yes, you can certainly use different flags for different cpp files. You can even use pragmas to turn on the optimisation.


#7

See, I did not know that! Any quick instructions on how to use different flags for different .cpp files? EDIT: It is just a right mouse option for each file in Visual Studio. Nice…

This brings up a topic that is unrelated except regarding optimization: At one point, I tried turning on auto-vectorization, but it seemed to break the XML parsing code.


#8

I just figured out that in my case it was the /fp:fast switch that caused the drawing errors when enabling optimization for the x64 build. After switching to /fp:precise everything seems to work as expected.


#9

I remember something like this when trying to port my code to x64. The solution I found was to create 2 separate projects (i.e vcproj). One for the audio stuff compiled with all the optimisation (/fp:fast, /O2 …) and one for the other stuff (/fp:precise).


#10

You don’t need more than one project - in VC, every file can have different compile settings, and you can even use pragmas within files to enable/disable optimisation levels.


#11

I know that but it is simpler for me. I don’t have to set up my file every time a create a new one. I just have to select the project I want my file to be


#12

Sounds vastly more difficult to me!


#13

Weird. I thought I had typed the exact same post. But it disappeared, so I figured I didn’t actually send it. Steffen, did you write the above post? Seriously, this is kinda weird.

Sean Costello


#14

Yes, I am pretty sure that it was me who wrote that.


#15

Wow. I guess there are only so many ways to phrase a sentence about fp:precise versus fp:fast. I still am having deja vu. I was also fighting the flu when I wrote my post, which might be a factor…

Anyway, I found the same thing about the floating point precision flag and x64. It is also worth noting that using fp:precise didn’t slow down my code in any way that I could notice.

Sean Costello


#16

Had the same pronblem. Switching to fp:precise resolved it:

http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5172