RTAS issues on Win32

#1

I’ve tried building the juce_RTAS demo plugin using the vcproj file included with the library itself, but it does not seem to load properly under ProTools LE 7.3.1.

When compiled in debug mode, it abruptly crashes and terminates host application on every loading attempt.

When compiled in release mode, loading the plugin causes the host to display a “Access Violation” error dialog before crashing the application.

References to both include and library files from DigiDesign SDK were properly set up before compilation, and PlugInLib itself, coming with DigiDesign SDK, was compiled on the same MS Visual Studio 2005 used for plugin compilation.

Any suggestions? Did anyone experience similar behaviours? Are there different host application to test RTAS plugin with, on Win32 platform (maybe known to provide more useful informations for debugging purposes)?

#2

It works fine for me on exactly the same version as you’re using, but PT is a strange and difficult beast…

If you want to drop me an email, I can send you my binary of the rtas demo to see if it’s your build that’s broken, or some difference between our PT set-up.

Can you pinpoint the crash any more accurately? I know it’s not possible to debug it, but maybe a few DBG() calls in the rtas code might help

#3

Thank you very much, my email is yfede@tiscali.it, I’m at home now but as soon as I will get back to office I’ll try to investigate further into the problem.

It would be great if you could paste into your reply the compiler command lines actually used by Visual Studio to compile both the 3 projects involved (JUCE, juce_RTAS and PlugInLib). I think it could be a useful comparison term for spotting important configuration differences

#4

ah - I’ve got the same crash here now… I’m on the case, will let you know when I’ve got a fix.

#5

ok, this was just a dumb error in the latest build. If you grab the tip build from sourceforge now, I’ve fixed it.

#6

I’ve had to add the following include path:
c:\yourdirectory\PT_711_SDK\AlturaPorts\TDMPlugIns\DSPManager\Interfaces
in addition to those listed at the top of juce_RTASWrapper.cpp, otherwise
DSP_OS.h and MuShEnums.h wouldn’t have been found at compile time.

Same thing was needed to compile “vanilla” 1.43 version of juce_RTAS, but this lastest one works perfectly. Well done!

#7

Good to hear it works, thanks for the tip about that folder!

#8

Now that the problem is solved on Win32, a similar behaviour appears under MacOS X 10.4.9 (PowerPC) with identical versions of ProTools LE (7.3) and ProTools SDK (7.1.1).

After having regularly compiled juce, PlugInLib and juce_RTASDemo, the resulting .dpm fails to load in ProTools making the host UI idle for a while (a minute or so) and then crashing the application.

Could this be connected to the same Win32 issue?

I will test the same build on mac intel as well and let you know the result…

#9

No, I think that was a PC-only bug…?

#10

Yes, I’ve investigated a little further and found that the crash under Mac (both PowerPC and Intel, as I’ve tested in the mean time) seems due to the specific repainting strategy implemented for the Mac platform.

As far as I could see looking at juce_RTASWrapper.cpp, editor repainting under Mac is periodically triggered by its specific Timer (forcedRepaintTimer) instance.

I think it to be the cause of the problem because this is the (top) of the resulting report when i try to load the demo into ProTools

OS Version:     10.4.9 (Build 8P2137)
Report Version: 4

Command: Pro Tools LE
Path:    ./Pro Tools LE
Parent:  bash [10760]

Version: 7.3 (7.3f117)

PID:    10858
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000008

Thread 0 Crashed:
0   ...awmaterialsoftware.JuceDemo 	0x111b9f24 juce::Timer::stopTimer() + 70 (juce_Timer.cpp:382)
1   ...awmaterialsoftware.JuceDemo 	0x112b7597 JucePlugInProcess::JuceCustomUIView::EditorCompWrapper::paint(juce::Graphics&) + 23 (juce_RTASWrapper.cpp:368)
2   ...awmaterialsoftware.JuceDemo 	0x11192979 juce::Component::paintEntireComponent(juce::Graphics&) + 1047 (juce_Component.cpp:1748)
3   ...awmaterialsoftware.JuceDemo 	0x11211110 juce::ComponentPeer::handlePaint(juce::LowLevelGraphicsContext&) + 52 (juce_ComponentPeer.cpp:388)
4   ...awmaterialsoftware.JuceDemo 	0x112ce7a7 juce::HIViewComponentPeer::RepaintManager::paint(CGContext*, int, int, int, int) + 1179 (juce_mac_Windowing.cpp:921)
5   ...awmaterialsoftware.JuceDemo 	0x112cf125 juce::HIViewComponentPeer::hiViewDraw(OpaqueEventRef*) + 821 (juce_mac_Windowing.cpp:1478)
6   ...awmaterialsoftware.JuceDemo 	0x112cf87f juce::HIViewComponentPeer::hiViewEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 595 (juce_mac_Windowing.cpp:1613)
7   com.apple.HIToolbox            	0x92dd6537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
...
...
...

To better see what actually happens within stopTimer(), I added some DBG
statements into the function body:

    DBG("In");
    if (periodMs > 0)
    {
        DBG("InIf");
        InternalTimerThread::remove (this);
        periodMs = 0;
        DBG("OutIf");
    }
    DBG("Out");

Loading this modified version produces the following on standard output:

JUCE v1.44
In
Out
Debugger() was called!
In
Bus error

This looks quite weird to me, because it shows that a first invocation of the stopTimer method resulted in bypassing the if body because of false condition (“In” and “Out” printed with no “InIf” and “OutIf”), while the second invocation entered the method but crashed before returning AND before entering the if body as well (no “Out” neither “InIf” printed).

Sounds strange, but the access to “periodMs” within the if condition somehow seems the only possible cause of crash. Suggestions on how to solve the problem?

P.S. maybe this topic needs to be renamed since it’s not dealing with Win32 issues only any longer…

#11

Erm… could it be as simple as needing a check for a null pointer:

void paint (Graphics& g) { #if JUCE_MAC if (forcedRepaintTimer != 0) forcedRepaintTimer->stopTimer(); #endif }

?

#12

This was the first issue I thought about and checked the validity of the pointer with a

jassert(forcedRepaintTimer != 0)

right before calling stopTimer();

Since I got the same error report after that check, caliming the error to happen within stopTimer, I thought that the function was being correctly invoked.
It seems it was a mistake of mine assuming so, because explicitly checking for it being not null actually worked. As for me, you can check this fix in.

#13