Now that I’ve migrated to the Juce 2.0 platform (latest tip as of a few hours ago) I’m beginning to experience some of the same Windows RTAS build problems as you guys. I’ll let you know what solutions (if any) I arrive at. This is by far the most finicky plugin format.
Any luck with this search??
Harrie
Hi Jucers…
Whilst developing an RTAS wrapper for IPlug I had problems with Windows debug builds failing to work with the PT8 and PT9 sdks. Debug builds didn’t work with the Digi examples (Template NoUI etc) either. I manage to debug my plugins enough by linking against the release builds of the digi static libraries (PluginLib etc) rather than the debug builds. Not sure this is exactly the same issue mentioned here, but i thought i’d say in case it helped.
EDIT - i also had to define NDEBUG for my debug build.
oli
I upgraded my RTAS builds to vs2010 and got the 97 unresolved symbol linker errors. Adding DSPManager.lib, DSPManagerClientLib.lib and RTASClientLib.lib to my plugin project seems to have fixed this.
Nice one, thanks! Can confirm this works…
Sorry, I never saw this thread originally… I guess I should add those to the list in juce_RTAS_Wrapper.cpp.
Jules, could please take a look at both the 8.1 and 9.0 RTAS SDKs? There are some differences in the required include folders (Avid really made a hash of their entire include structure) and it might be nice for Introjucer to have a checkbox or something to select the appropriate version.
Happily, it’s the end of the road for RTAS. We’ll have to build versions for a while, but it will eventually fade into the sunset.
I’m trying to wake up this grisly old thread once again. I have Windows clients who really want RTAS versions of my plugs for PT 10. The problem is that I still can’t build RTAS on Windows, using either the PT8 or PT9 SDKs. In trying to be a good boy, I built Introjucer from today’s tip, and it doesn’t even come close to building RTAS. The symptom is the same, whether for the PT8 or PT9 SDK (once I add the additional includes needed for PT9) The linker complains about redefinitions between juce_RTAS_Digicode2.cpp and PluginLib. It then goes on to complain about several undefined symbols. No matter how I jigger the project, I can’t get anything that works.
Has anybody built RTAS on Windows with a recent version of juce? Is there such a thing as a baseline plugin project that actually builds?
Let me quickly add that I’ve tried this with VS2008 and VS2010. Pretty much the same thing either way.
Got an RTAS build working today with the latest JUCE and VS2010 after a lot of trial and error. Here’s what worked for me:
[list]
[]Ignore libcmt.lib in Linker->Input settings[/]
[]Make sure you have the following Avid libraries to Linker->Input settings: PlugInLib.lib, DSPManager.lib, DSPManagerClientLib.lib, RTASClientLib.lib[/]
[]Set “enable incremental linking” to “No” in Linker->General (may or may not be necesarry)[/]
[]If you’re getting the “LNK1123: failure during conversion to COFF: file invalid or corrupt” error and you have VS2012 also installed alongside VS2010, you need to fix this by replacing the cvtres.exe in VS2010 with the one from VS2012.[/][/list]
Every time I build RTAS in Windows, it’s always a new adventure…
One of the critical things is to make sure that your RTAS library and your plugin DLL use the same values for build type (I forgot what the name of the build param is–it’s one of the C++ settings). In other words, if you’re building the plugin as Multi-Threaded DLL, make sure the RTAS library is built the same way. For reasons related to my software security, I build as simply Multi-Threaded so that my plugins are self-contained, if somewhat larger. In that case, the library you recommend excluding is a library I must use. In the grand scheme of things, it may not matter as long as the settings are the same for your main plugin build and the RTAS library. Otherwise you get into that incompatible cycle of symbols that get pulled in from two different places. Once you get all of that lined up properly, you don’t have to worry so much about explicitly including and excluding the runtime libraries–the linker will operate as it should.
But there’s no denying that RTAS is a monumental PITA.
[quote=“Mikey”]One of the critical things is to make sure that your RTAS library and your plugin DLL use the same values for build type (I forgot what the name of the build param is–it’s one of the C++ settings). In other words, if you’re building the plugin as Multi-Threaded DLL, make sure the RTAS library is built the same way. For reasons related to my software security, I build as simply Multi-Threaded so that my plugins are self-contained, if somewhat larger. In that case, the library you recommend excluding is a library I must use. In the grand scheme of things, it may not matter as long as the settings are the same for your main plugin build and the RTAS library. Otherwise you get into that incompatible cycle of symbols that get pulled in from two different places. Once you get all of that lined up properly, you don’t have to worry so much about explicitly including and excluding the runtime libraries–the linker will operate as it should.
But there’s no denying that RTAS is a monumental PITA.[/quote]
+1 to all of this. I knew I forgot to mention something big… :o