RTAS build broken (again)

..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(289): error C2872: 'Component' : ambiguous symbol
          could be 'c:\SDKs\PT_90_PlugInSDK\AlturaPorts\AlturaSource\PPC_H\Components.h(220) : ComponentRecord *Component'
          or       'c:\documents and settings\administrator\my documents\StuxNet\development\repos\Virii\jucelibrarycode\modules\juce_gui_basics\components/juce_Component.h(33) : juce::Component'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(263): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'JucePlugInProcess::JuceCustomUIView::EditorCompWrapper *' (or there is no acceptable conversion)
          c:\documents and settings\administrator\my documents\StuxNet\development\repos\Virii\jucelibrarycode\modules\juce_core\memory/juce_ScopedPointer.h(111): could be 'juce::ScopedPointer<ObjectType> &juce::ScopedPointer<ObjectType>::operator =(juce::ScopedPointer<ObjectType> &)'
          c:\documents and settings\administrator\my documents\StuxNet\development\repos\Virii\jucelibrarycode\modules\juce_core\memory/juce_ScopedPointer.h(135): or       'juce::ScopedPointer<ObjectType> &juce::ScopedPointer<ObjectType>::operator =(ObjectType *const )'
          c:\documents and settings\administrator\my documents\StuxNet\development\repos\Virii\jucelibrarycode\modules\juce_core\memory/juce_ScopedPointer.h(154): or       'juce::ScopedPointer<ObjectType> &juce::ScopedPointer<ObjectType>::operator =(juce::ScopedPointer<ObjectType> &&) throw()'
          while trying to match the argument list '(juce::ScopedPointer<ObjectType>, JucePlugInProcess::JuceCustomUIView::EditorCompWrapper *)'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(277): error C2839: invalid return type 'Component *' for overloaded 'operator ->'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(277): error C2039: 'getPeer' : is not a member of 'juce::ScopedPointer<ObjectType>'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(278): error C2839: invalid return type 'Component *' for overloaded 'operator ->'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(278): error C2039: 'getLocalBounds' : is not a member of 'juce::ScopedPointer<ObjectType>'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(300): error C2872: 'Component' : ambiguous symbol
          could be 'c:\SDKs\PT_90_PlugInSDK\AlturaPorts\AlturaSource\PPC_H\Components.h(220) : ComponentRecord *Component'
          or       'c:\documents and settings\administrator\my documents\StuxNet\development\repos\Virii\jucelibrarycode\modules\juce_gui_basics\components/juce_Component.h(33) : juce::Component'
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(300): error C2440: 'initializing' : cannot convert from 'juce::Component *' to 'Component *const '
          Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
..\..\JuceLibraryCode\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(301): error C2227: left of '->exitModalState' must point to class/struct/union/generic type
          type is 'Component *const '

This is on Visual Studio 2010 -- RTAS Build Win32 - automated testing

OK, thanks - I've added namespaces to every Component I could find in that file, hopefully that'll sort it out!

Unfortunately that broke RTAS compilation on OS X, so we had to undo that again.

@sambecket: Now to your Windows compile problem. I am struggling to get to the same state you are in. I am on VS2015 and I am getting hundreds of other compile errors.

Could you please let me know the following:

  • did you have to do any changes to the  RTAS code, the JUCE code, or do any other hacks to compile RTAS (minus the errors you are getting now)?
  • do you happen to know which JUCE commit broke RTAS compilation? Is there a version of JUCE that compiles for you?
  • What plugin do you try to compile?
  • Are you getting the same errors if you try to compile the JUCE demo plugin?

Hi Timur, I'm sending you private message with details about PT90 compilation with VS2015. when I'll have time I'll try to build with latest tip. didn't get into that yet.

Hello Timur, unfortunately since we are on a tight schedule here we have pretty much automated all builds and testing.

The only way we could compile RTAS on Windows is on virtual machines with Windows XP and Visual Studio 2010

We have a document on our wiki... Named.. How to Compile RTAS:

Change Juce RTAS Wrapper
#pragma comment(lib, PT_LIB_PATH "PluginLib_stdcall.lib")

Linker > Input > Module Def File
C:\Documents and Settings\Administrator\My Documents\StuxNet\Development\Repos\JUCE\modules\juce_audio_plugin_client\RTAS\juce_RTAS_WinExports.def

Build Events > Post Build Event > Command Line
copy /Y "C:\Documents and Settings\Administrator\My Documents\StuxNet\Development\Repos\JUCE\modules\juce_audio_plugin_client\RTAS\juce_RTAS_WinResources.rsr" "$(TargetPath)".rsr

We do that automatically with a script.. and it builds from a current main repository.

Otherwise.. its just pain.

What SDK version are you using? PT80 or PT90?


The #pragma comment is very old and the RTAS wrapper by JUCE already includes it as far as I remember.

well you remember wrong it's still needed to change to sdcall the pragma comment

and in the first post is clearly outlined that is the pt_90 !!!

Finally I managed to fix the broken Visual Studio RTAS build without simultaneously breaking the Xcode one :-)

Please update to the newest tip and try again. @sambecket: your build should now work again.

By the way, with this newest tip I now also managed to compile RTAS using the newest toolchain (Visual Studio 2015) on Windows 8.1. Here's how it goes. First, let's compile the RTAS SDK:

1. Use the PT_90 SDK (*not* the PT_80!)

2. Inside the SDK folder, open the following three VS2005 projects in VS2015, auto-convert them to the newer toolchain, ignore warnings:

  • AlturaPorts\Fic\Source\SignalNets\WinBuild\RTASClientLib
  • AlturaPorts\TDMPlugIns\DSPManager\WinBuild\DSPManagerClientLib
  • AlturaPorts\TDMPlugIns\PlugInLibrary\WinBuild\PlugInLibs

3. Change the build properties as follows:

  • C/C++ --> Code Generation --> Runtime Library = Multi-threaded (/MT) for Release and Multi-threaded Debug (/MTd) for Debug
  • C/C++ --> Advanced --> Calling Convention = __stdcall (/Gz)

4. Compile the three projects in the exact order as listed above. Fix compiler errors in DigiDesign's code as you go. On my machine, I had the following ones (other people may have a different experience):

  • AlturaPorts\AlturaSource\PPC_H\CGBase.h: int32_t: redefinition: remove the line with the typedef that causes the error

  • AlturaPorts\TDMPlugIns\PlugInLibrary\Utilities\CAOSManager.cpp: std::max not found: add an #include <algorithm> at the top

  • AlturaPorts\AlturaSource\PPC_H\Processes.h: 'GetProcessInformation': second C linkage of overloaded function not allowed: remove lines 259-263

Now that should have worked and we can compile our actual JUCE plug-in. I tested with the audio plugin demo on the newest tip. Here's how I got it to compile:

  • C/C++ --> Code Generation --> Runtime Library = Multi-threaded (/MT) for Release and Multi-threaded Debug (/MTd) for Debug (to match the RTAS stuff)
  • ...but don't touch the calling convention, this surprisingly has to stay at __cdecl (/Gd)
  • If you get a weird linker error that says something like _ITERATOR_DEBUG_LEVEL: mismatch '2' vs. '0', you need to add the following preprocessor define (In the Introjucer, or in the build properties C/C++ --> Preprocessor --> Preprocessor Definitions) 
    _ITERATOR_DEBUG_LEVEL=0  (...or 2, can't remember which way around ;-)

...and with all that stuff the RTAS version of the JUCE audio plugin demo did compile and link for me on VS2015.


P.S. RTAS support is deprecated, please use AAX instead :-)

1 Like

Excellent guide. What do you think about making a sticky post out of itin the plug-ins section, regularly updated so that one can refer to that when in "troubled waters"?

That would save a lot of time for people that can't simply drop RTAS for now

Yes, I can do a sticky.

Looking at that guide I'm not sure anymore we need to use the static runtime library... maybe /MT and /MTd setting is not needed anywhere at all and we can use the default /MD and /MDd. Not sure, will check, but that'd make everything easier.

@ttg: why did you suggest the static runtime library?

An older thread – but you may want to check pout my post #13 in it:



RTAS is broken as of https://github.com/julianstorer/JUCE/commit/2da1bc5f4185a3de4ebdb5239e6640d7b2f45273

  • Mac Only (Windows builds from my tests).

    External/JUCE/modules/juce_audio_plugin_client/RTAS/juce_RTAS_DigiCode_Header.h:67:12: fatal error:
    ‘MacAlwaysInclude.h’ file not found
    #include <MacAlwaysInclude.h>
    1 error generated.

  • In progress (still testing this).
  • One thing I didn’t notice, when compiling for i386 and x86_64 it WON’T FAIL but the result will be garbage as it won’t have the 32-bit contents.
    (try file <result.dpm>)

This is the culprit (commented by @yairadix):

Fixed now - https://github.com/soundradix/JUCE/commit/0f754187733626c4e61a194b10fd14ca5bf4dd71

1 Like

Is this going to be added to the JUCE codebase?

Just keep in mind that this patch got us back to functional Mac builds.
But still Win builds requires more changes and fixes (not only RTAS) as Windows now also became a separate build target platform.

Now also made fixes in SR’s branch to three issue on Windows :

  • MSVCTargetBase::addExtraSearchPaths, which adds the necessary include paths isn’t called so include paths aren’t added.
  • juce_audio_plugin_client/utility/juce_CheckSettingMacros.h verified that JucePlugin_WinBag_path is defined for the Shared Code target, which is wasn’t - so just removed the check.
  • Shared code tries to invoke RTAS’s DllMainRTAS function which doesn’t exist for the other targets so their linkage failed.

RTAS in JUCE feels like a second class citizen. Like a med-student coming back from the holidays only to be stopped at the airport by Trump’s visa ban :confused: Sad!


OK, I think I fixed this on develop. But I couldn’t really test it as I just can’t seem to get the RTAS plugin lib to compile again (any tips?). Please let me know what’s still missing in my commit.

Yup, that pretty much sums it up :slight_smile: !

In all seriousness, we still support RTAS and will do our best fix any bugs that come up. However, we do not regularly test RTAS and we do not port any new features to RTAS. You should also expect that RTAS support will eventually be discontinued altogether as JUCE will progressively require newer C++ compilers as time moves on.

What’s the problem with the RTAS SDK? Searching the forums I see the it worked for you in May - what changed since?

We build the RTAS library with latest Xcode but with the OS X 10.6 SDK. If there are other tips those are probably here in a forum thread.

No, we had finally gotten it working on Mac back then. But now, I can’t seem to find the magic combination on Windows anymore.

Oh I see. Don’t remember/know what’s necessary for PT SDK on Windows, but in any case some of the bugs caused enabling RTAS to make the build of other formats fail, so at least that should be testable before setting up the RTAS build…