Using the latest versions of JUCE and XCode, I now get a bunch of errors like “No member named ‘strerror’ in the global namespace; did you mean ‘::juce::strerror’?” when compiling the RTAS plugin client files. This seems to be related to commit eda613… from beginning of September, where the location of “namespace juce” has been moved into those client files. The namespace now brackets the inclusion of some std-lib files ("include " and the like) which, as far as I can see, causes this issue.
Does moving
#include "../../juce_core/system/juce_TargetPlatform.h"
#include "../utility/juce_CheckSettingMacros.h"
up a few lines, outside of the juce namespace, in
modules/juce_audio_plugin_client/RTAS/juce_RTAS_DigiCode1.cpp
modules/juce_audio_plugin_client/RTAS/juce_RTAS_DigiCode2.cpp
modules/juce_audio_plugin_client/RTAS/juce_RTAS_DigiCode3.cpp
modules/juce_audio_plugin_client/RTAS/juce_RTAS_Wrapper.cpp
fix things?
No, I get a bunch of structurally similar errors then, e.g. “No member named ‘__gnu_cxx’ in the global namespace”. XCode stops after 20 errors so I can’t say whether the original errors are resolved or just encountered later in the compilation process.
Without moving those lines, the problematic inclusion chain is juce_RTAS_DigiCode_Header.h -> MacAlwaysInclude.h -> PluginAssert.h -> (and from here on into std territory).
Fixed.
1 Like
just curious, how many versions ago of ProTools did Avid discontinue support for RTAS?
Pro Tools 10 is the latest which supports RTAS plug-ins. Pro Tools 11 was released in 2013.
In terms of compatability, Pro Tools 9 is the last without AAX meaning RTAS is a requirement.
PT10 will be more than happy to have your AAX as long as you keep 32 bit arch.
1 Like
Now getting a bunch of “Expected ‘;’ after top level declarator” with the new commit… I’ve simply rolled back the RTAS files to the version before commit eda613… for the time being.
Are you attempting to build a 64 bit RTAS plug-in? For me that’s the only way I can get that error, but I’ve patched my version of the RTAS SDK in the past and can’t remember exactly what changes I made.
The steps I took to build an RTAS plug-in were:
AlturaPorts/TDMPlugIns/PlugInLibrary/Utilities/FicBasics.h:31
- Commented out
#include <ppc_intrinsics.h>
AlturaPorts/TDMPlugIns/PlugInLibrary/RTASP_Adapt/ASConnUtil.h:25
- Commented out
#include <Components.h>
Compiled the RTAS library with Xcode 9 in 32 bit, using the 10.6 SDK, setting the default compiler, and adding __FLOAT_H=1 to the preprocessor macros.
Then, to build the plug-in, I set OSX Architecture to Universal Binary (32-bit) and C++ Library to GNU libstdc++.
What have I missed?
You are right, I hastily tried to compile the GainPlugin example and didn’t see that 64 bit was set by default for RTAS. All’s good when compiling for 32 bit.
In that context, it’d make sense if Projucer would set the RTAS architecture to 32 bit by default.
1 Like
I only now got around to look at the Windows side, and there’s one more small fix that needs to be done: in juce_RTAS_WinUtilities.cpp, move the “namespace juce {” opening bracket to line 49. Otherwise, you’ll get errors from Windows SDK files.
Edit: and, just like for XCode projects, it’d be great if RTAS was not added to a 64 bit target by Projucer.
Fixed on the develop branch.
1 Like
What are the chances for removing RTAS from Projucer-generated 64 bit projects? Or would this need too much restructuring for an officially deprecated format?