Just can't build RTAS on Windows

#1

Hi,
This is going to sound silly, but whatever I do I just can’t get it to work. It’s not like I haven’t done it before.

With the latest tip of Juce (with Introjucer automatically generating projects) I CAN NOT build a simple RTAS plug-in. I will end up with various, and different link errors.

I have tried VS2005, VS2008, VS2010, VS2012 - none will work, but for various reasons.
I have tried RTAS SDK 8 and 9, with various fails.

Is the Introjucer truly capable of generating RTAS projects? Is there anything I need to add? Something simple I have forgotten?

EDIT: Perhaps a better question is: What versions of things do you use?

#2

I haven’t had success with VC2012 and RTAS… All other formats work fine. However I had issues trying to compile PlugInLib with VC2012 so it may not be a JUCE issue.

Rail

#3

[quote=“Rail Jon Rogut”]I haven’t had success with VC2012 and RTAS… All other formats work fine. However I had issues trying to compile PlugInLib with VC2012 so it may not be a JUCE issue.

Rail[/quote]
Oh, Pluginlib seem to compile easily for me under 2012. Officially, Digidesign only support vs2003 and vs2005… I suggest you abandon vs2012 for RTAS - or if you manage, please share it with us!

#4

Well if you want to share your PlugInLib VC2012 solution with me I’ll see if that works here… and that may give me a clue to getting the RTAS/JUCE combo happening…

I can give you an email contact via PM.

I have VC2012 running in Win8 and VC6 in XP so would like to get VC2012 working if possible.

Thanks,

Rail

#5

Works for me with PT_80_SDK and MV Visual C++ 2008 Express.
Tried several other combo, but it was very picky with different issues each time, and I only had luck with this setup.
IntroJucer all the way though I’m not using the very latest tip either (about 2-3 months old).

Hope this helps,

Salvator

#6

[quote=“Salvator”]Works for me with PT_80_SDK and MV Visual C++ 2008 Express.
Tried several other combo, but it was very picky with different issues each time, and I only had luck with this setup.
IntroJucer all the way though I’m not using the very latest tip either (about 2-3 months old).

Hope this helps,

Salvator[/quote]

You can successfully compile a DEBUG RTAS plugin with JUCE and SDK8 ?

I get Link errors like:

due to:

 #if JUCE_DEBUGxxx // (the debug lib in the 8.0 SDK fails to link, so we'll stick to the release one...)
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Debug\\lib\\"
 #else
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Release\\lib\\"
 #endif

A Release build links fine. This is with VS2012 using an IntroJucer VS2010 created plugin. I had to change some things to get it to compile after opening the solution:

  1. Change the compiler to the 110_xp compiler (thanks Mike)
  1. Add the preprocessor definition: _STDINT

Cheers,

Rail

#7

Indeed RELEASE build only with this setup.

Salvator

#8

I experienced a lot of issues with RTAS until I changed the build type to multithreaded–not multithreaded DLL. Don’t worry. It’s still a DLL, but everything it needs is linked into it at build time instead of at load time. You still get a ton of warnings, but the thing works.

#9

I’ve come up with a working solution for VS2012 with the latest JUCE tip and SDK9 which allows a full Debug build (linked to a debug Lib) and I tested it attached to a debug host build and it allows breakpoints and works fine. Just waiting for Mike to verify my results.

Rail

#10

Using VS2010 successfully here

#11

I’ve also used both VS2008 and VS2010. Make sure that you’ve built the RTAS library to the same spec as you’re building the plugs themselves. As I indicated earlier, for me that’s Multithreaded, non DLL (sorry I don’t remember the specific option text).

Oh, and also read through Jule’s example stuff. He includes a very important note that tells you that several of the RTAS wrapper files must be built as stdcall rather than cdecl. If you don’t do that, you’ll get link errors that will never sort out.

#12

[quote=“Mikey”]I’ve also used both VS2008 and VS2010. Make sure that you’ve built the RTAS library to the same spec as you’re building the plugs themselves. As I indicated earlier, for me that’s Multithreaded, non DLL (sorry I don’t remember the specific option text).

Oh, and also read through Jule’s example stuff. He includes a very important note that tells you that several of the RTAS wrapper files must be built as stdcall rather than cdecl. If you don’t do that, you’ll get link errors that will never sort out.[/quote]

My system doesn’t require those changes – you build the IntroJucer generated project with very few changes.

Calling Convention: __cdecl (/Gd)

Runtime Library: Multi-threaded Debug DLL (/MDd)

(which are both stock settings for an IntroJucer generated plugin).

Rail

#13

Okay - I haven’t heard back from Mike if he got this to work yet… but figured I’d share and see if others get success as well:

Okay - working perfectly… with a full debug build and I was able to attach it to the Dev debug build and use breakpoints….

Using VS2012 and SDK9

Here’s what I did:

  1. Load the SDK 9 SimplePlugIn session and let VS2012 convert it.

  2. Change the compiler Platform Toolset to Visual Studio 2012 - Windows XP (v110_xp) for both Debug and Release builds of the 2 projects in the solution.

What we’re doing here is building the PlugInLib_stdcall.lib which is what we’ll use for our JUCE plugins.

  1. Add the Preprocessor Definition _STDINT for both Debug and Release builds of the 2 projects in the solution.

  2. Compile the solution and verify you have PlugInLib_stdcall.lib in your WinBag Debug and Release folders.

You can now close the SimplePlugIn solution.

  1. Create a new IntroJucer RTAS plugin - I created a VS2012 project. Set the Platform Toolset & Extra Preprocessor definition as above in the project in IntroJucer.

    In IntroJucer:

    For the debug build add the preprocessor definition: _ITERATOR_DEBUG_LEVEL=0

    Add _STDINT as a global preprocessor definition.

    Change the compiler Platform Toolset to Visual Studio 2012 - Windows XP (v110_xp)

  2. Save the project and open it in VS2012.

  3. In the project properties I set the Linker Output File to put the DPM file in my Dev build’s DAE/Plugins folder:

Note: You’ll set this to the path to your Dev build’s \dae\Plug-Ins folder wherever it is on your system.

  1. For Custom Build steps I added:

Command Line: copy /Y $(OutDir)$(TargetName).dll.rsr …\ProTools_3PDev\dae\Plug-Ins$(TargetName).dpm.rsr

Outputs: …\ProTools_3PDev\dae\Plug-Ins$(TargetName).dpm.rsr

Execute after: Link

and saved the properties.

Note: You’ll set these to the path to your Dev build’s \dae\Plug-Ins folder wherever it is on your system.

Now we need to change some code in juce_RTAS_Wrapper.cpp

From line 104…

 #if JUCE_DEBUG // (the debug lib in the 8.0 SDK fails to link, so we'll stick to the release one...)  // <<-----  Change from JUCE_DEBUG_XXX to JUCE_DEBUG so we'll link to the Debug Libraries
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Debug\\lib\\"
 #else
  #define PT_LIB_PATH  JucePlugin_WinBag_path "\\Release\\lib\\"
 #endif

 #pragma comment(lib, PT_LIB_PATH "DAE.lib")
 #pragma comment(lib, PT_LIB_PATH "DigiExt.lib")
 #pragma comment(lib, PT_LIB_PATH "DSI.lib")
 #pragma comment(lib, PT_LIB_PATH "PlugInLib_stdcall.lib")		// <<----  This one gets changed
 #pragma comment(lib, PT_LIB_PATH "DSPManager.lib")
 #pragma comment(lib, PT_LIB_PATH "DSPManagerClientLib.lib")
 #pragma comment(lib, PT_LIB_PATH "RTASClientLib.lib")
#endif

Build the solution and attach it to the debug Pro Tools dev build and you should be all good.

Let me know if this works for you.

Rail
#14

That’s cool! Can’t wait to try it. Why do we need to switch to PlugInLib_stdcall instead of PlugInLib?
Great work!

#15

[quote=“Mike”]That’s cool! Can’t wait to try it. Why do we need to switch to PlugInLib_stdcall instead of PlugInLib?
Great work![/quote]

The default PlugInLib build is __cdecl (/Gd) so rather than try and change the JUCE code… do what Avid do with their example, rebuild the Library.

I looked at how they git their example to work and saw they used the PlugInLib_stdcall library… so tried it with my IntroJucer plugin and it worked.

Rail

#16

I edited my instructions above to remove changing the link setting for Late Download DLL files… since I can’t actually see any PlugInLib.dll in the Pro Tools folder… so I don’t think that it’s needed (I removed the PlugInLib.dll from the list on my project and it worked fine).

Rail

#17

[quote=“Rail Jon Rogut”]I edited my instructions above to remove changing the link setting for Late Download DLL files… since I can’t actually see any PlugInLib.dll in the Pro Tools folder… so I don’t think that it’s needed (I removed the PlugInLib.dll from the list on my project and it worked fine).

Rail[/quote]
Yes I think that was unnecessary, although harmless.

#18

[quote=“Mike”][quote=“Rail Jon Rogut”]I edited my instructions above to remove changing the link setting for Late Download DLL files… since I can’t actually see any PlugInLib.dll in the Pro Tools folder… so I don’t think that it’s needed (I removed the PlugInLib.dll from the list on my project and it worked fine).

Rail[/quote]
Yes I think that was unnecessary, although harmless.[/quote]

Exactly!

I just figured if Jules reads this thread I’d be complete.

Let us know if this works for you.

Cheers,

Rail

#19

Anyway I tried this but stumbled on a few oddities. Using vs2012, I could not build some of the files, the compiler referring to GetProcessInformation or something similar being redefined. This could be true for 2 reasons, either the toolset being set to something wrong, such as v110, or that _WIN32_WINNT for some other reason is set to an incorrect value. I got stuck. I had once build this successfully. Argh!

Instead I tried building with vs2010, with better results. Actually, I’m fine using just vs2010, but it’s a sign of health if you are not depending on particular development tool versions.

HOWEVER - and here’s yet another issue - I’m compelled to build with a static CRT and that just won’t work for me.

So, at the moment I’m letting my frustration settle before trying again.

#20

[quote=“Mike”]Anyway I tried this but stumbled on a few oddities. Using vs2012, I could not build some of the files, the compiler referring to GetProcessInformation or something similar being redefined
[/quote]

I would get that if I didn’t use the 110_xp Toolset - make sure all your projects are using this toolset. I have VS2012 Update 2 installed.

Also make sure you have defined _STDINT otherwise you will get other redefinition errors.

Rail