Strange paint() behaviour in JuceAU (1.37 + 1.11)


Hi guys,
i’m trying the cool 1.37 version together with 1.11 APF.

The JuceAU GUI has a paint() bug.

Moving the mouse pointer around the gain control, the info label and the keyboard, the gui got replaced with a white color.

The test is the same in Live 5.2 and Bidule 0.92.

Any suggestion?

thanx a lot! [/img]


really? Ok, will investigate…


It’s better than it was. I’ve been experimenting with various (ppc(rosetta)/native Intel) On a Intel Duo Core macmini Tiger under freeware / demo hosts with mixed results… Some remain un-movable, other (obscure ones) complain


Ok folks, there’s a quick and easy fix for this one, in juce_mac_Windowing.cpp, line 882:

[code] if (peer->isSharedWindow)
CGRect clip;
clip.origin.x = x;
clip.origin.y = y;
clip.size.width = jmin (w, peer->getComponent()->getWidth() - x);
clip.size.height = jmin (h, peer->getComponent()->getHeight() - y);

                CGContextClipToRect (cgContext, clip);


If you let me know which ones gave trouble, I’ll take a look…


All These are on the OS X (Tiger) on a Intel Duo Core Mac Mini
Plogue Bidule Nicely demonstrates the redraw problem (without your changes above)

  • Interestingly, a few other pluggins have problems here too.
    Audacity (OS X)
    Ugli (OSX 9, ppc?)

(Tracktion (PPC/rosetta) was on this list, but it looked OK just now :slight_smile: - before your changes above…)

Not on that list
RAX (Universal)thows a divison by zero exception (which I still haven’t managed to catch)

(I’ll look for the obscure one that wouldn’t open at all, but just compained that the wrong type of window redraw(?) was being used - I didn’t understand what this meant at all)

Sometimes the problem apprears like the window doesn’t have a boarder, or the border is detached from the main display. When the border is stretched, both the window (and the separated) window resizes. Othertimes there’s no boarder, and the window can’t be moved


You clearly have a lot of patience to be playing with some of those apps! I’d forgotten how clunky Audacity is to use (or expected that they’d have tarted it up by now) - can you give me a hint about how to make it load a plugin?

Luna made my brain and eyes hurt, and refused to let me add a plugin anyway, so sod it.

The division by zero’s really trivial - rax is giving it a time sig of 0/0 and the demo code isn’t dealing with that. Just tweak the demo a bit in DemoEditorComponent.cpp:

[code]static const String ppqToBarsBeatsString (const double ppq,
const double lastBarPPQ,
const int numerator,
const int denominator)
if (numerator == 0 || denominator == 0)
return T(“1|1|0”);


It’s also causing some repaint problems on intel. To fix it, I think you’ll (unfortunately) have to turn on some of the compatibility fixes that I was hoping to avoid on 10.4 - in juce_mac_Windowing.cpp, remove the “#ifdef MAC_OS_10_3_OR_EARLIER” at lines 1303 and 1358. This means more deprecation warning when you compile, but if people are still using old fashioned UIs, then that’s the only way to do it. There’s also a problem because it’s somehow stopping mouse-moves getting to the window, but that’ll involve a more complicated fix, which I’ll try to do for the next release.


Damn third time typing this! - Curses!

That /0 error showed itself as being somewhere in parameter-update - presumablly due to parameter-passing / stack frames! -I’ annoyed I couldn’t trap something SOOOO silly!

Not so much patient, as wanting a cheap, reliable Univeral VST Host which did what I need. (Luna/Rax) - BTW These are the redraw issues I’d been banging on about in other posts, too. - It’s still an issue on those, I think.

Audacity requires another plugin to allow VSTs to be seen, but I must admit, I can’t be bothered with it anymore, either. I know someone who raves about it, so I might ask them for guidance, in case I missed something handy.

BUT - Those fixes worked for Bidule Plogue AND Tracktion 2 though (Uni version coming soon? :slight_smile: Yippee


Julian doing your two fixes (ifdef + isSharedWindow) in Bidule remains some mouse artifacts (positioning problem).

In Live the plug it’s ok, no problems with it!!!


[quote=“cialz”]Julian doing your two fixes (ifdef + isSharedWindow) in Bidule remains some mouse artifacts (positioning problem).

In Live the plug it’s ok, no problems with it!!![/quote]

Right - that just needs a little tweak, again to juce_mac_Windowing.cpp:

[code] void getBounds (int& x, int& y, int& w, int& h, const bool global) const
HIRect hiViewPos;
HIViewGetFrame (viewRef, &hiViewPos);

    x = (int) hiViewPos.origin.x;
    y = (int) hiViewPos.origin.y;

    w = (int) hiViewPos.size.width;
    h = (int) hiViewPos.size.height;

    if (global && IsValidWindowPtr (windowRef))
        HIViewConvertRect (&hiViewPos, viewRef, 0);

        x = (int) hiViewPos.origin.x;
        y = (int) hiViewPos.origin.y;

        Rect windowPos;
        GetWindowBounds (windowRef, kWindowStructureRgn, &windowPos);

        x += windowPos.left;
        y +=;




thanx jules for your patient!!!


and thank you for your bug-hunting!


(Sorry, couldn’t help myself)