4.2.1 and RTAS on OSX: -7400 error

While everything compiles fine, I can’t load the JUCE demo plugin in Pro Tools 10 anymore, getting a -7400 error. A bit of research told me that this error might have to do with a missing resource file, and indeed the RTAS rez part is gone in JUCE. Since there was a similar issue with the AU resources which broke compatibility with carbon hosts, I assume the same thing is going on here. Would it be possible to re-rez the RTAS module, because otherwise, it seems, RTAS won’t work anymore?


Any thoughts on this? This is the last issue that is holding me back from a new release (which has been delayed for weeks already since I decided I’d update to JUCE4)… Pretty pleeease!

1 Like

Hey @timur ,
Looks like you’ve removed ALL SYMBOLS from the RTAS build?

@siedschl , could you make sure on your machine also run:
nm -U <dpm_folder_here>/Contents/MacOS/<plug-in_name>

on my machine I get nothing… (even for debug…)

oops. seems like this is the alias (at least on my machine) making a small bundle with no real binary in it.

I vote to remove RTAS support for future versions of Juce all together, no reason to keep that old horse on life support imo, if anything there can still be done updates to existing projects using the old Juce versions. This will only slow down progress of supporting SDKs that are still maintained and supported in more than one host.

@ttg, indeed when using the default setting to build a Universal Binary, the JuceDemoPlugin in RTAS format contains no symbols. It is 17.8 MB big here though. When I change it to a 32 bit build the symbols are there (and the binary has the same size). It doesn’t change the original loading error though, so I still suspect it’s the rez thing.
@onqel: as per this highly unrepresentative study, there should still be about 30 percent RTAS users out there. I think that number is not too far off, there’s probably quite some studios out there who are afraid to change a running system. Sure, RTAS is on the way out, but if this issue here really is caused by not supporting Carbon, I think it should be fixed, the same way it has been fixed for AUs (see here ).

1 Like

@siedschl you’re correct about the rez. I’m diffing older Xcode builds and it had “Build Carbon Resources” with juce__RTAS__MacResources.r

you can find it on older JUCE commits to try and add it (I’m trying it as we speak but still no luck :wink: )

I’ve also noticed the following:
juce_audio_plugin_client_RTAS_1…4 are missing -w compiler flag.
and juce_audio_plugin_client_RTAS_utils.mm is missing

Though now I get compiler errors due to some JUCE defines not assigned properly.

I do not disagree that this should be fixed since RTAS is officially still supported by JUCE, what I intended to say is that I personally think they (ROLI) should consider removing stuff that is likely to be “deprecated” soon by the music community, to be able to take a big step forward in terms of removing countless workarounds added to make stuff like this continue working (my respirator reference)… That study/poll tells me that 15% are still on a RTAS/PT system that doesn’t natively support AAX also, but it could be interesting to make a similar poll to see how many of the JUCE customers are still actually building RTAS plugins.

I for one am still building RTAS because the market is asking for them.

I’m all in favor of removing it, but unfortunately it is still not possible while such a large percentage of the user base is still stuck with it.

In this case, a workaround is not required, it is a regression that has broke and it is sufficient to restore the rez thing like it has been broken and then restored in the case of AU

sorry, I meant to write “stuff like that” and I was not referring explicitly to this current issue, but I understand what you are saying regarding the rez issue and it should be a simple fix.

We are working on fixing this currently. I’ll let you know when this is finished.

If anyone wants to speed up the process of getting this fixed then I could use some help building RTAS’ plugin library. See this thread: Xcode/Mac: RTAS still broken with latest tip

This should be fixed on the latest tip on the develop branch. You’ll need to rebuild the projucer and re-save your project with the newly built projucer. Thanks for reporting this.

Thanks, will try this tomorrow. Sorry, didn’t see your previous post about needing help with building the library…

Works well, thanks! Stupid question, maybe: how about the VST format, wouldn’t the same issue arise for Carbon hosts as well?

It’s more a problem with Carbon AudioUnits. But that should work as well.

If there’s such a vote then I vote to preserve RTAS support. It may depend on the niche you’re aiming for, but when making plugins for professional audio engineers, there are many which still use their old systems and don’t hurry to upgrade.

If it will be removed then I’ll have to maintain it anyhow, like I already do for example for side-chain support in RTAS which isn’t available in the main branch… (btw our branch available at https://github.com/soundradix/JUCE and anyone may use our changes as long as you can use JUCE).

At some point it may make sense to drop support for RTAS, like PowerPC support was recently dropped from JUCE. But for us that time hasn’t yet arrived…

1 Like

Just wondering if you can guide me about how it is working for you?

Am I missing something?

Here are my steps:

  • Pull latest development repo.
  • Build fresh Projucer
  • Open NoiseGate from Projucer
  • Setting Minimum Deployment Target to 10.7 (or 10.6)
  • Referencing to my RTAS libraries.
  • Saving and opening in Xcode.
    result is aliases (symlinks) to the dpm within Digidesign/Plug-Ins
    and the NoiseGate.dpm is 12KB…
    (tried also release).

(My RTAS libs worked fine until 4.2…)

So it seems RTAS built properly for Release and not debug.
(In addition our installer script was still using the monolithic concept and I’ve missed the postinstall script overwriting the dpm)

p.s. @juceteam , would be nice to remove x64 Arch as it keeps a warning on build and isn’t necessary :wink: