Sounds like an uninitialised variable to me. The new version might call/initialise things in a different order, so that could be showing up the error. I’ve built plenty of plugins that work with it in release mode, so would guess that the bug is in more likely to be in your code than the library.
you can run the release version with the debugger too (to see if there are errors)
If you are on VST-Win:
I had my own LookAndFeel-Class stored in static pointer, which was deleted with DeletedAtShutdown-Class.
With the new VST-Wrapper the deletion happens when number of plugins is zero (with the old when the DLL is detached). When Cubase starts and detect that a plugin changed it will created and closed, and your own LookAndFell will be deleted. So you have to be a little bit careful, maybe like that
//in MyOwnLookAndFeel.h
class MyLookAndFeel : public LookAndFeel , public DeletedAtShutdown
{
static MyOwnLookAndFeel* MyOwnLookAndFeel::get_MyOwnLookAndFeel()
//in MyOwnLookAndFeel.cpp
static MyOwnLookAndFeel* myOwnLookAndFeel_static = 0;
MyOwnLookAndFeel::~MyOwnLookAndFeel()
{
LookAndFeel::setDefaultLookAndFeel(0);
myOwnLookAndFeel_static=0;
}
MyOwnLookAndFeel* MyOwnLookAndFeel::get_MyOwnLookAndFeel()
{
if (myOwnLookAndFeel_static==0)
{
myOwnLookAndFeel_static=new MyOwnLookAndFeel;
};
return myOwnLookAndFeel_static;
};
// in my Plugin Window Constructor
LookAndFeel::setDefaultLookAndFeel (MyOwnLookAndFeel::get_MyOwnLookAndFeel());
I didn’t just assume it was a bug in the library - sorry if it came across that way. Could be me, Microsoft, Cakewalk etc. I was just hoping the answer was more obvious than proofreading line by line again with limited debug info. I know, I know, it builds character!
It’s not Look and Feel, or not just that. The background doesn’t show up either - it’s a Jucer UI, paint gets called with legitimate-looking coordinates, but it comes out blank.
Setting opaque to true in the Component constructor shows black rectangles where the components should be, so they exist, they’re drawn and they work, but I guess the colours and alpha get lost somewhere. I did check (without the optimized-out macro) that the colours are initialized before L&F.
Yeah, I wasn’t trying to say “how dare you say it’s a bug in the library”! I just meant that it sounds more likely to me that the culprit will be somewhere in non-library code. It’s an odd one, though. Have you tried just adding a simple “setColour (red); fillRect (…)” to check that basic drawing ops are working at all?
It’s not your SSE code - just when SSE is on the compiler uses xmm scalars instead of floating stack at its discretion, which on the P4 can fly, using any pipeline instead of just Xe-87. So any graphics changes that violate SSE (SSE2 here) ettiquette could break it.
Graphics seem to be slower too; my CPU meter, on a waveform-display project, is at +100%, but much less when there’s less wave data displayed. Though it could just be knocking over the cache because I use too many arrays. Mostly that project is using drawLine.