Latest RTAS Juce demo plugin doesn't load in ProTools 10 on Windows

Audio Plugins
1

Hi,

I just built the included Juce demo plugin for RTAS using VS2008 and it won't load in ProTools 10 (last version 10.3.8, running on Win7):

"Pro Tools could not load the following plug-ins either because no valid authorization could be found, the iLok key was not connected or the plug-in was damaged: JuceDemoPlugin.dpm"

I wanted to do this because my own plugin does load and work fine, but sometimes crashes ProTools on exiting PT (no clear pattern yet...), and I wanted to check if the demo plugin in Juce 3.x at least works fine, and if so, first move with my plugin to Juce 3.x and check and debug there (I'll need to update to 3.x anyway)...

What I did:

  • updated Juce repo to latest 3.x tip
  • built latest IntroJucer, opened JuceDemoPlugin, enabled RTAS, saved project
  • using PT SDK 8.0 (rebuilt libs using VS2008, using this info: http://www.juce.com/forum/topic/howto-building-rtas-vs2008)

Jules, can you confirm that the 2008-built RTAS demo plugin builds and works fine in PT10 on your machine?
And which combination of VS and RTAS SDK are you using?

I also noticed that there is no .rsr file being generated for the demo plugin: is that normal?

Any help appreciated...

Koen

 

2

Just giving some more info:

When checking the settings the PT80 SDK uses and the ones the Introjucer generates for the plugin project, I see that there is also a difference in the struct alignment settings: PT SDK 80 uses alignment of 2 bytes, whereas the Intojucer project uses "Default" alignment (I guess that means 4 bytes right?).

I hope that's all fine? (as my plugin does build and works, except for that crash when colosing PT, I'd think it should be fine, unless that crash could also be related to this?)

3

By the way, when I rebuild the PT 80 SDK PlugInLib project, I have to choose between 6 different configs:

  • Debug|Win32
  • Debug_default_aligned+cdecl|Win32
  • Release|Win32
  • Release_default_aligned+cdecl|Win32
  • Release_HCP|Win32
  • Release_HCP|Win32

I just chose the standard Debug|Win32 and Release|Win32 configs, but maybe I should use one of the others.
Which ones are you using Jules?

 

4

I now also noticed that the runtime libs the Juce demo plugin was using are the DLL versions, so I switched them to static (non-DLL) versions. Now ProTools gives this error:

"The plug-in could not be made active because a DAE error was encountered. DAE error -7400 was encountered."

Shouldn't this just work when I use the Introjucer and the included Juce demo plugin? Sorry, getting a bit frustrated now...

 

 

5

Wouldn't it make more sense to move to VC2010 or later and the PT 90 SDK? (I don't even have a VC2008 install any longer, so can't really help with this)

6

OK, I can move to 2010 and try that.

Do we need to use the PT 90 SDK (and not PT 80 which I thought was what's stated in the getting it all to work documentation)?

 

 

7

I think the 9.0 is a better bet - the old how-to docs are probably a bit out of date now..

8

OK thanks, I'll give that a try then. That does raise 3 questions:

Is that also what you recommend on MacOSX (the 9.0 SDK)?

What is the lowest version of ProTools in which RTAS plugins built with Juce and the SDK 9.0 will work (need to know this to properly inform my clients)?

Does that mean that plugins built this way will not work any longer on Windows XP (the 9.0 SDK says: "OS X/Windows 7", whereas for 8.0 Windows XP was still mentioned)? I know, XP is going to be abandoned anyway by Microsoft next month, so maybe I shouldn't bother, but it's good to know still.

I would also appreciate it highly if you could confirm for yourself and update the documentation to a setup that is known to work fine and is being supported by Raw Material Software, even if it was just for the Demo plugin.
Right now, it seems like using Juce to build RTAS plugins is a bit open-ended with different people giving different setups, and it's unclear to know what really works (I thought our setup did, but apparently not). There are just too many combinations to "try and see if it works" without having an insight (which you surely have) into which versions, calling conventions, build settings, etc... to use to get building RTAS plugins with Juce to work...

The Introjucer is a tremendous big help and I thank you very much for that, but it still remains that we need to know what to do at the PT SDK side to make it work correctly with Juce.

Going to get the 9.0 SDK now...

9

So I went ahead with the PT_90_PlugInSDK and VS2010 (latest updates), and wrote down my steps below.

There already popped up some ambiguities in the steps to do, so please bear with me (maybe you use this as a guide to update the docs into a new "step-by-step" text file to ship with Juce). I'll wait for the answers before I continue:

 

1. unzip the SDK file (gives folder PT_90_PlugInSDK)

2. there is no VS2010 project in the repository for JuceDemoPlugin
- built the Introjucer with VS2010
- opened the .jucer file in built Introjucer
- checked "Build RTAS"
- created new VS2010 target
  --> QUESTIONS:
     . which Platform Toolset to choose now? (I left it at (default))
     . which Runtime Library setting to use now? (I left it at (default))
     . other things that should be set/changed?
  --> CHANGES:
     . RTAS folder was set to c:\SDKs\PT_80_SDK --> changed to C:\SDKs\PT_90_PlugInSDK
- saved project

3. At this point, as the old docs are said to be out-of-date, I don't know if I need to do something (and what?) with the PT90SDK. So, I'm not rebuilding anything for now.
--> QUESTIONS:
    . do we need to rebuild anything now?
    . if so, wich projects, and with which settings?

4. opened the VS2010 project for the demo plugin and built the Release version

5. build fails: "LINK : fatal error LNK1104: cannot open file 'C:\SDKs\PT_90_PlugInSDK\WinBag\Release\lib\PluginLib.lib'"
--> so, yes, we do need to rebuild some libs as it seems
--> QUESTIONS:
    . which libs do we need to rebuild?

6. I went ahead and assumed (but please confirm) that I need to rebuild at least PlugInLib,
   so I openened the solution in VS2010:
   for C:\SDKs\PT_90_PlugInSDK\AlturaPorts\TDMPlugIns\PlugInLibrary\WinBuild\PlugInLibs.sln
      I see these 6 configurations:
        Debug
        Debug_stdcall+2byte
        Release
        Release_stdcall+2byte
        Release_HCP
        Release_HCP_stdcall+2byte
      QUESTIONS:
      . which configs do I choose here for PlugInLib?
      . do I also need to rebuild C:\SDKs\PT_90_PlugInSDK\AlturaPorts\Fic\Source\SignalNets\WinBuild\RTASClientLib.sln?
        (here there are only 2 configs: Release and Debug, so no choice here, unless we need to change settings?)
      . do I also need to rebuild C:\SDKs\PT_90_PlugInSDK\AlturaPorts\TDMPlugIns\DSPManager\Winbuild\DSPManagerClientLib.vcproj?
        (here there are only 2 configs: Release and Debug, so no choice here, unless we need to change settings?)
      . are there other projects in the PT 90 SDK I should rebuild?
      . if only these are rebuilt, can we be sure that the other libs in C:\SDKs\PT_90_PlugInSDK\WinBag\Release\lib will be compatible with the ones we did rebuilt? (there are 4 other libs in the WinBag folder: DSI.lib, DSPManager.lib, DAE.lib, DigiExt.lib)
     
Once I receive the answers to the open QUESTIONS, I'll continue!

 

10

While waiting for the correct up-to-date guidelines with answers to the open questions above, I gathered some more info about the PT80 and PT90 SDKs and their settings in relation to those of the Juce Demo Plugin. These are the out-of-the-box settings as you get them without changing anything:

Juce Demo Plugin facts

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    Default (except for juce_RTAS_... files which use 2 Bytes (*))
    Calling convention:               __cdecl (except for juce_RTAS_... files which are __stdcall)
    Preprocessor Definitions:      no _SECURE_SCL entry (and no _HAS_ITERATOR_DEBUGGING entry in Debug)

(*) the project settings for these files use Default for Struct Member Alignment, but these files include juce_RTAS_DigiCode_Header.h, which does a #pragma pack (2) on Windows, so they are also using 2 Bytes alignment

   
RTAS 8.0 SDK facts

PlugInLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

out-of-the-box settings (Release_default_aligned+cdecl):
    Runtime Library:                    DLL
    Struct Member Alignment:    Default
    Calling convention:               __cdecl
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug_default_aligned+cdecl)

DSPManagerClientLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

RTASClientLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

RTAS 9.0 SDK facts

PlugInLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    Default
    Calling convention:               __cdecl
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

out-of-the-box settings (Release_stdcall+2byte):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug_stdcall+2byte)

DSPManagerClientLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

RTASClientLib

out-of-the-box settings (Release):
    Runtime Library:                    DLL
    Struct Member Alignment:    2 Bytes
    Calling convention:               __stdcall
    Preprocessor Definitions:      _SECURE_SCL=0 (and _HAS_ITERATOR_DEBUGGING=0 in Debug)

Notes

There is a difference between the 9.0 and 8.0 version for the PlugInLib: whereas in 8.0 the normal Release build uses 2 Bytes alignment / __stdcall, in the 9.0 version the normal Release build uses Default alignment / __cdecl.

Also, these were the 3 libs for which I could find a project to rebuild them: PluginLib.lib, DSPManagerClientLib.lib and RTASClientLib.lib.   
There are actually 4 other libs that get linked in: DAE.lib, DigiExt.lib, DSI.lib and DSPManager.lib. But for these 4 other libs, I didn't find projects to rebuild them, so the only option is to use them as-is, even if we don't know with which settings they were built (probably VS2005?).

Regarding the _SECURE_SCL and _HAS_ITERATOR_DEBUGGING, the PT SDK says:

Due to known performance issues, these options are disabled in the libraries that are distributed with the 8.0 and 9.0 SDKs.
It is required that these options be disabled in any plug-in project built with these SDKs. If there is a mismatch of these options with any statically included library, you may experience hangs and crashes in your plug-in, so please note this change when converting your plug-in projects from an earlier version of the SDK.
To explicitly enable or disable these options for the entire SDK, modify their definition in each of the following projects and re-build:
Plug-in Library - \AlturaPorts\TDMPlugIns\PlugInLibrary\WinBuild\PlugInLib.vcproj
DSP Manager Client Library - \AlturaPorts\TDMPlugIns\DSPManager\WinBuild\DSPManagerClientLib.vcproj
RTAS Client Library - \AlturaPorts\Fic\Source\SignalNets\WinBuild\RTASClientLib.vcproj

So it looks like the Introjucer-generated project is not adding these preprocessor defintions to disable these options. Or, alternatively, if we do want to work with the settings the Introjucer generates (no preprocessor definitions), we need to remove the options in the PT SDK project files as well and rebuild them. But as it is now, it could lead to these hangs and crashes, right?

 

11

See: http://www.juce.com/forum/topic/just-cant-build-rtas-windows

Rail

12

Edited post above with (apparently important) info on preprocessor definitions:

After reading the remarks in the PT SDK README.TXT and seeing the changes Rail Jon Rogut had to make manually for VS2012, it looks like the Introjucer is not doing the right thing here, and we have a mismatch. Unless I'm missing something...
 

 

13

Jules,

could you please supply info to the questions above, so I can go on trying to make things work myself... ?

Or build and test the demo yourself and update the build instructions in the repository accordingly?

Thanks,

Koen

 

14

Sorry - this is one of those posts which deserves my full attention, and I don't have very much attention to spare right now... Having a very quick look at your questions, I don't instantly know the anwer to many of them without doing a lot of research and experimenting. If anyone can chime-in with their experiences here, it'd be appreciated!