RTAS build broken (again)

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!

2 Likes

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…

@fabian , I know @timur got it going on your team last time.
I strongly suggest you keep 3rd Party Libs in a REPO with modifications and basic README.md , here it makes it now really easy for me to maintain many SDKs as clean of binaries as possible and they do compile using a build-script for Win/Mac.

Make SURE you’re using PT90! not 80 as I remeber timur discovered the hard way few posts above.

Here is my README.md parts that are useful…

The Avid (Digidesign) PluginLib Hell Survival Guide

Digidesign RTAS building is tricky. you can look on JUCE’s wrapper to see the pragma and additional conditions to handles many issues with it.
This also should be the last source from Digidesign as RTAS is officially dropped.


* Modifications (all should be logged within GitHub) but I also keep it here.
  • AlturaPorts/AlturaSource/PPC_H/CGBase.h #57: added “&& !defined(_WIN32)” to avoid over-defining signed long…
  • AlturaPorts/TDMPlugIns/PlugInLibrary/Utilities/CAOSManager.cpp #34: added "#include " to handle std::max error
  • AlturaPorts/TDMPlugIns/PlugInLibrary/RTASP_Adapt/ASConnUtil.h #24: conditioned “<Component.h>” into the #if WINDOWS_VERSION
  • AlturaPorts/TDMPlugIns/PlugInLibrary/Utilities/FicBasics.h #30: added conditional “#if !(i386)” to avoid include “ppc_intrinsics.h” (no PPC support!)
Windows Project Modification: - Use latest toolset (as of writing this it is v140_xp (VS2015) - Switch "Code Generation Runtime" to static (/MT & /MTd) for ALL LIBRARIES AND PROJECTS. - Calling convention of Digidesign's are __stdcall (/Gz) as opposed __cdecl (/Gd) by projects.

(you should also build your Projucer as static /MT or /MTd).
Dont waste your time trying to get DEBUG going from Projucer exported solution.
_ITERATOR_DEBUG_LEVEL=0 - needed ONLY in x32/Debug for RTAS. but will cause all other builds to fail.



Mac Building:

PLEASE USE SCRIPT PROVIDED AT “SoundRadixLib” (build_avid_libs.sh)

  • Requires Mac OS X 10.6 SDK!
    Open Xcode project from AlturaPorts/TDMPlugIns/PlugInLibrary/MacBuild
    I’ve made 2 Xcode configurations:
  1. Plugin Library, supports min deployment 10.6 no c++11/libc++
  2. Plugin Library libcpp, support min deployment 10.7 with c++11/libc++
    Build Debug/Release to generate both libraries.



Win Building:

  1. Build AlturaPorts/Fic/Source/SignalNets/WinBuild/RTASClientLib
  2. Build AlturaPorts/TDMPlugIns/DSPManager/WinBuild/DSPManagerClientLib
  3. Build PluginLibrary FROM AlturaPorts/TDMPlugIns/SamplePlugIns/SimplePlugIn/WinBuild/SimplePlugIn
    (SimplePlugin actually builds the PlugInLibrary with stdcall which is also required for linking!)
  • In addition for Windows please remember you need to have the rsr or you’ll get DAE error upon loading the plug-in.

Note,
Now after I have solutions as VS2015 we simply have build_avid_libs for both Mac/Win and they work.
So while RTAS is a second class citizen, under Windows at least (where they still keep some typedefs from 16bit! age) it seems RTAS can be compiled for eternity :wink:

3 Likes

Just head-up. our repo now builds RTAS. but guess some linking is broken.
I’m investigating…

(VM machine with Win7/PT9)

1 Like

OK. RTAS should build again with the latest develop.

What I really don’t understand is why, in 2017, anyone is still compiling RTAS? It has been discontinued by Avid back in 2013! Let it die and move on to AAX :slight_smile:

Now it is possible (with some small tweaks) to build on Mac/Win.

Still the binaries won’t be loaded.

I’ve tested PT9 on macOS 10.6 and Windows 10 with Pro Tools 10.x latest.
(on Mac I’ve surely made is 10.6 deployment and it does build 32-bit arch properly).

Because there are several producers out there, still working on Pro Tools 9.
Even some “important” hollywood producers/ songwriters are exactly like that …

My personal preference would be also “to move on to AAX” (of course), but you
can’t force them to do that :slight_smile:

2 Likes

I don’t support RTAS with my plugins, but I get requests for it on a regular basis. Mostly from ‘high profile users’.

Number of RTAS users that take the time to send me an email / my user base = 0.7%

1 Like

@fabian another passport-banned RTAS player is:
juce_RTAS_WinExports.def

Here is our commit:

Summary (at least for our repo):

JUCE repo issues:

We don’t intend to provide RTAS for any new product release. but for current products we do our best to support it as there is a user-base sadly stuck in the early 2kes.

1 Like

Fixed another issue when using new AAX level-meters.

1 Like

OK I think I’ve fixed this now. It will appear on develop in a few minutes.

RTAS should compile and load on both OS X and Windows. Just need to fix the AAX level meters…

  • Xcode: For me latest Projucer doesn’t add the AlturaPorts paths / addRTASPluginSettings().
  • But there’s one change I’ve noticed that should also break AU for older hosts and that’s the lack of “Build Carbon Resources” required for aging RTAS & Audio Units.

Update:
Found the commit that breaks this and commented on it.


CC: @t0m

1 Like

Thank you for catching that. I’ve restored the old behaviour.