RTAS / Windows Issues

[quote]Create a new plugin project with Introjucer, drag in your various source code files for your project, and make sure the only checked plugin format is RTAS (you can forget about going polymorphic on a Windows RTAS build, trust me!) Make sure you get your VS2008 paths set correctly, I prefer to use absolute paths and I keep all my SDKs in C:\SDKs\ for ease of access.
Follow Jules’ instructions: set the __stdcall method on the DigiCode and RTAS Wrapper files in your project.
Make sure to put the following lines in Linker–>Input–>Ignore Specific Library: msvcrt.lib; MSVCPRT.LIB; MSVCPRTD.LIB
Build, and it should work. Make sure to copy both the .dpm and .dpm.rsr files into your RTAS plugins folder so they will show up.
[/quote]

…but if you’re using the introjucer to create your project, then it’ll automatically do those last three steps for you, right? I’ve tested building rtas projects without needing to manually mess about with project settings.

That would have been nice, but no, I definitely had to do all of these steps manually. I’m certain I have the latest Juce tip and Introjucer. If it can be fixed easily, cool, if not, simply adding those steps to a readme would be enough. I don’t fault you at all for this one, it’s Microsoft products we’re dealing with here after all. :x

It definitely sets the __stdcall flag for those files… Are you talking about the modules branch or the master branch?

Now that I’ve investigated things more closely, it appears that I’m not on the most current tip as I said previously. Mind you, I’ve downloaded the latest tip, but I used an older path for both Juce and the Introjucer by accident. Sorry for any confusion I may have caused, I’ll have to try the latest tip and start fresh when time permits.

[quote=“Soilworker”]
PS - Don’t worry about the SimplePlugin project from Avid. They included that simply to mock, frustrate, and torment developers. :)[/quote]

IIRC, if you build the SimplePlugin project, it will automatically create the PluginLib builds (or whatever the libraries are called) as part of the build process. Which is fairly convenient.

Sean Costello

Nope - Release works fine, but Debug doesn’t link for me in Vis Studio 2008 - something to do with arrays if I remember right.

[quote=“valhallasound”][quote=“Soilworker”]
PS - Don’t worry about the SimplePlugin project from Avid. They included that simply to mock, frustrate, and torment developers. :)[/quote]

IIRC, if you build the SimplePlugin project, it will automatically create the PluginLib builds (or whatever the libraries are called) as part of the build process. Which is fairly convenient.

Sean Costello[/quote]

Assuming you can get it to build. It’s been finicky for me, but it can be done. My comment wasn’t meant to be taken overly seriously, however I’ve found it easier to compile PluginLib by itself.

Hello,

Then maybe Jules you could change jucer_ProjectExport_MSVC.h
and make introjucer set manifest to true in release config ?
That would avoid further peoples to spend a day crashing their head against the wall… (especially hard to find out what happen when there is no debug in windows PT)

Thanks,

Salvator

Still can’t get it to link, even the release build. The linker complains about 97 unresolved symbols (references to CSmartStructure, CPlugInData, etc.). I probably missed some library dependency or the lib path is broken for me.

Do you use the introjucer ?
I found it very usefull to make all path correct etc…

Salvator

Yes, I used the Introjucer to setup the project. I suspect the PluginLib might not have compiled correctly.

I’m trying to build a simple RTAS plugin using Introjucer and PT80SDK on VC2010 Express and Win XP. I have followed steps but getting a lot of link errors like…

1>PluginLib.lib(CDSPProcessGroup.obj) : error LNK2001: 外部シンボル ““class IDSPManager * __stdcall GetIDSPManager(void)” (?GetIDSPManager@@YGPAVIDSPManager@@XZ)” は未解決です。
1>PluginLib.lib(CDSPProcessType.obj) : error LNK2001: 外部シンボル ““class IDSPManager * __stdcall GetIDSPManager(void)” (?GetIDSPManager@@YGPAVIDSPManager@@XZ)” は未解決です。
1>PluginLib.lib(CAdaptorPlugIn.obj) : error LNK2001: 外部シンボル ““public: virtual __thiscall CPlugInData::~CPlugInData(void)” (??1CPlugInData@@UAE@XZ)” は未解決です。
1>PluginLib.lib(CAdaptorPlugIn.obj) : error LNK2001: 外部シンボル ““protected: void __thiscall CBaseSet::AddMember(void *)” (?AddMember@CBaseSet@@IAEXPAX@Z)” は未解決です。

Please ignore japanese.

I confirmed that PlugIn.lib exists in WinBag. It would be very helpful if someone could give me some advice. Thank you.

I also have the same error(97 unresolved symbols), perhaps. Does anyone have any tips?

Hey, sorry to revive a 6 month old thread but has anyone found a solution to this? I’m trying to compile the RTAS version of the JUCE demo plug-in JUCE tip 2.018 on VS 2010 with PT SDK v8.0. After a number of project setting tweaks, I have run into the dreaded 97 unresolved symobls mentioned above. They are all pretty similar to these 2 examples:

1>PluginLib.lib(CAdaptorPlugIn.obj) : error LNK2019: unresolved external symbol “public: __thiscall CPlugInData::CPlugInData(void)” (??0CPlugInData@@QAE@XZ) referenced in function “public: __thiscall S_RTASP_CustomDataAdmin::S_RTASP_CustomDataAdmin(void)” (??0S_RTASP_CustomDataAdmin@@QAE@XZ)
1>PluginLib.lib(CAdaptorPlugIn.obj) : error LNK2001: unresolved external symbol “public: virtual void __thiscall CSmartStructure::AddMember(struct CSmartStructure::CMember *,class CSmartStructure::CMemberP *)” (?AddMember@CSmartStructure@@UAEXPAUCMember@1@PAVCMemberP@1@@Z)

Any thoughts on building RTAS by any means? I have had no luck for the past week and I have read the howTo.txt and the forums very closely. Thanks!

&D

I also ran into the same issue today, with a new Introjucer project using today’s juce, PT_80_SDK and VS 2010.

I rebuilt the PlugInLib.lib in the winbag folder with VS2010 (via the SimplePlugin.sln) but also end up with those 97 unresolved external symbol when I build my plugin.
So can anyone else try out if anything has turned wrong in recent IntroJucer versions? Or is there anything special I should know about rebuilding PluginLib.lib?

I also have the ‘97 unresolved externals’ issues with VC 2010 PT_SDK_80. Any help would be greatly appreciated!

Personally I had always had better luck with MSVS2008.

Salvator

I’ve tried compiling PluginLib with VC2008 and VC2005. This brought it down to 18 unresolved externals (CPluginControl_Continuous.obj and GetDefaultPath.obj). Any help is greatly appreciated.

If you re-built RTAS PlugInLib.lib yourself and link your plug-in to it (instead of simply linking to Digi-provided one) then, depending on your PlugInLib build settings, the calling convention of your library might be __cdecl instead of __stdcall. This was my case. Due to different ABI your plug-in is unable to link to your ‘custom’ library. Experiment with calling convention settings for those RTAS-related files in your plug-in project:

juce_RTAS_Wrapper.cpp
juce_RTAS_DigiCode1.cpp
juce_RTAS_DigiCode2.cpp
juce_RTAS_DigiCode3.cpp,

in particular change their “C++/Advanced/Calling Convention” property from “__stdcall” to “__cdecl”.

Haven’t been over in the Windows world lately, but I’ll bet this is the same as Mac. Do you have a debug version of ProTools? The normal version of PT will not run under debug and will immediately exit in that case. If you haven’t already, you’ll need to grab the debug-enabled PT from the developer website.

If you already knew all this, then forgive me for presuming.