I’m doing my best BIlly Preston imitation trying to put together a Windows RTAS. I have an existing project–VST–which builds and works fine. For reasons I won’t go into here, I need the RTAS build to be a separate build–not the combined style plugin. I’ve been carefully through [color=#0040FF]How to use this framework.txt [/color](which could use freshening up–it doesn’t reflect your V2 change in file structure). I’ve been getting through most of the issues (although who knows what dragons await), but I’m really getting stuck on [color=#0040FF]juce_RTAS_WinExports.def[/color]. I do have it defined as the Linker/Input/Module Definition file. But I’m still getting stuck with the linker complaint:
[quote]1>juce_RTAS_WinExports.def : error LNK2001: unresolved external symbol NewPlugIn
1>juce_RTAS_WinExports.def : error LNK2001: unresolved external symbol _PI_GetRoutineDescriptor[/quote]
First of all, I can’t help but wonder if that NewPlugin must be changed to my plugin name (which would also require a change in [color=#0040FF]juce_RTAS_DigiCode3.cpp[/color]). The __stdcall convention is applied to the files specified in the How to document.
I did spend a little time (as little as possible) with the Introjucer, just trying to find some settings inside the generated project. No luck there.
After searching through the forum and bashing my code around (trying both the V8 and V9 ProTools SDKs) I’ve gotten just about zilch done. I’m not nuts about the idea of RTAS for Windows, but I’ve still got to do it.
I keep running across a strange bit of code in juce_RTAS_DigiCode3.cpp. Down at the bottom if the file is this little bit of code:
short __stdcall NewPlugIn (void*) { return 0; }
short __stdcall _PI_GetRoutineDescriptor (long, void*) { return 0; }
What makes it strange is that this is else clause to [color=#0040FF]#if JucePlugin_Build_RTAS[/color]. If you want to build an RTAS, you must define [color=#0040FF]JucePlugin_Build_RTAS[/color] to 1. But if you do, the instantiations of [color=#0040FF]NewPlugIn[/color] and [color=#0040FF]_PI_GetRoutineDescriptor[/color] are excluded. What in the heck is going on?
By the way, I’m using Visual Studio 2010. I’ve tried to build the demo plugin (fail) and create an RTAS plugin with Introjucer (fail).
I haven’t had any major issues with Windows RTAS, so the basic configuration of JUCE for doing this is definitely correct. I did use the combined plugin approach though… if that’s where the issue is, why don’t you build a combined plugin and just discard the VST?
Thanks for responding. Your suggested solution is OK for my own products, but I’m currently doing some work for a client who has a legitimate need to separate the formats. I’m getting the feeling that it’s been a while since anyone has tried that with Juce on Windows.
Actually, we’re doing separate plugin formats on Windows, but only with Juce 1.53 and VS2005.
I can enlighten you on the two definitions: they’re dummy definitions that are intentionally excluded if you’re building RTAS. There used to be a comment above them but it seems to have disappeared in Juce 2.x :
// (defining these stubs just makes it easier to quickly turn off the RTAS build without removing
// the exports table from your project settings)
short __stdcall NewPlugIn (void*) { return 0; }
short __stdcall _PI_GetRoutineDescriptor (long, void*) { return 0; }
The real definition of NewPlugIn is found in DLLMain.cpp from the RTAS SDK, which gets included by juce_RTAS_DigiCode3.cpp if you only enable RTAS. I think _PI_GetRoutineDescriptor comes from PluginLib.lib, but it’s defined in Dispatcher.cpp anyway.
