[Solved] VST2 not detected by Live with SDK 3.6.7

Yes, renaming the bundle does not work here as well on Mac. I have tried creating a new target with wrapper_extension vst instead of vst3 and modifying the Bundle identifier to com.steinberg.vst.again. But that does also not work for me. What is the trick here to get the AGain example plugin run as a VST2 plugin on Mac?

I am also stuck at the same point as the others in this thread.

Will, what exactly do you change in your separate target for VST2, just the extension (as well as adding the few VST2 wrapper lines in the source code)?

Is anybody able to build VST2 on Mac? Did you find a solution?

The easiest way to see it is to download my software, create a new empty project (pass thru code) and then use Make VST to create a VST2/VST3 project for VS and XCode. Follow the instructions for preparing the 3.6.7 SDK (super easy to do, and has to do with conforming to the previous SDK paradigms for dealing with the base-code portion, and will not harm the 3.6.7 SDK in any way). There are videos on the website demonstrating how the XCode version creates a VST2 plugin specifically in Live 9 for MacOS.

We are prepping for a Cat 5 hurricane right now, so I don’t have a lot of free time between that and classes/University responsibilities. If I do get some time, I may work on a stand-alone example in XCode for you guys - but it will really just be a Make VST project with all the RAFX stuff removed (which is also super easy to do).

  • Will

www.willpirkle.com

Thanks, Will! I will try that. Hopefully, it won’t be too dramatic for the region around Florida, but the hurricane seems to be very strong. I wish you all the best!

Thank you Will!

If someone found a direct solution without the need of RackAFX and MakeVST, please let us know here.

Hi,
what’s the output of

nm YOURPLUGEXECUTABLE | grep VstPlugMain

This is the entry point for every VST2.x plug-in on macOS.

Cheers
Arne

Here is a stand-alone VST project for XCode/MacOS. It was created with RackAFX → Make VST, and then stripped of all RAFX code. The plugin does nothing - by default it will just pass audio in Live 9 as a VST2 plugin. It has no controls and no custom GUI.

http://willpirkle.com/special/MyVSTProjects.zip

To use it:

  • unzip the file to reveal a directory called MyVSTProjects
  • copy that folder into your public.sdk/samples/vst folder
  • open the MyVSTProjects folder, then open the subfolder VSTDemoProject; the xcode project file is in there to launch
  • prepare the SDK according to the instructions here: Enabling VST2 in the VST3 SDK – Will Pirkle Audio Technology

Preparing the SDK only involves 2 steps: 1) making sure you have the VST2 part of the SDK installed (you already should have this) and 2) copying a single folder called “mac” into your /base subfolder - that’s it. You can ignore the part about “four layer deep hierarchy” as planting the MyVSTProjects folder into your public.sdk/samples/vst folder takes care of that.

Start XCode and build the plugin (select the proper target bit-depth for debug mode plugins). The build phases automatically copy the .vst and .vst3 files into the proper location on your Mac so there is nothing to do but run the DAW app. The XCode project is already setup to use Ableton Live 9 as the target debug app but you can change that.

Hope that helps -
Will

Hi Arne,

VSTPluginMain is contained in the binary. nm again | grep VSTPluginMain yields a hit.

00000000000185c0 t _VSTPluginMain


Regards,

Joscha

So, VSTPluginMain exists, VstPluginMain (as you wrote) does not exist.

Yeah, it’s ‘VSTPluginMain’.
This means that the plug-in is correctly exporting the only needed symbol for the host.
The next thing you can check is if your plug-in gets refused by the dynamic linker to load into Live.
Tick the options ‘Dynamic Library Loads’ in the Xcode scheme editor : Run->Diagnostics.
And set Live as Debug executable and run your plug-in and watch the debugger output for logs generated by the dynamic linker.
Maybe there’s something of interest.

Hi Arne,

What bothers me is that I’m compiling the (only?) VST2 sample project there is in the VST3 SDK.
I’m not trying to use my own code.
Are you sure it’s working for you guys ?

Thanks.

Baptiste

Hi Arne,

here is an excerpt of the output given by the logger.

[…]
dyld: loaded: /Users/joscharieber/Library/Audio/Plug-Ins/VST/again.vst/Contents/MacOS/again
dyld: unloaded: /Users/joscharieber/Library/Audio/Plug-Ins/VST/again.vst/Contents/MacOS/again
dyld: loaded: /Users/joscharieber/Library/Audio/Plug-Ins/VST/bx_panEQ.vst/Contents/MacOS/bx_panEQ
dyld: loaded: /Library/Audio/Plug-Ins/VST3/SPAN.vst3/Contents/MacOS/SPAN
dyld: loaded: /Library/Audio/Plug-Ins/VST3/Steinberg/Padshop.vst3/Contents/MacOS/Padshop
[…]

When I also check “Dynamic Linker API Usage” it gives more info:

[…]
dyld: loaded: /Users/joscharieber/Library/Audio/Plug-Ins/VST/again.vst/Contents/MacOS/again
dyld_image_path_containing_address(0x11710e000)
dyld_image_path_containing_address(0x11710e000)
_dyld_is_memory_immutable(0x11710e000, 28)
_dyld_is_memory_immutable(0x1174eee75, 17)
_dyld_is_memory_immutable(0x1174eefc9, 36)
_dyld_is_memory_immutable(0x1174ef097, 18)
_dyld_is_memory_immutable(0x1174ef0a9, 9)
_dyld_is_memory_immutable(0x1174ef25b, 36)
_dyld_is_memory_immutable(0x1174ef363, 13)
_dyld_is_memory_immutable(0x1174ef370, 11)
_dyld_is_memory_immutable(0x1174ef37b, 14)
_dyld_is_memory_immutable(0x1174ef496, 27)
_dyld_is_memory_immutable(0x1174efcde, 20)
_dyld_is_memory_immutable(0x1174efd04, 18)
_dyld_is_memory_immutable(0x1174efd16, 11)
_dyld_is_memory_immutable(0x1174efd21, 13)
_dyld_is_memory_immutable(0x1174efd3b, 17)
dlopen(/Users/joscharieber/Library/Audio/Plug-Ins/VST/again.vst/Contents/MacOS/again) ==> 0x1013a3711
dlsym(0x1013a3711, SWELL_dllMain)
dlsym(0x1013a3711, SWELL_dllMain) ==> NULL
dlsym(0x1013a3711, VSTPluginMain)
dlsym(0x1013a3711, VSTPluginMain) ==> NULL
dlsym(0x1013a3711, main_macho)
dlsym(0x1013a3711, main_macho) ==> NULL
dlclose(0x1013a3711)
dlclose(), found unused image 0x1013a3710 again
dlclose(), running static terminators for 0x1013a3710 again
dlclose(), deleting 0x1013a3710 again
dyld: unloaded: /Users/joscharieber/Library/Audio/Plug-Ins/VST/again.vst/Contents/MacOS/again
[…]

I fixed the issue. Just add _VSTPluginMain to the file VST_SDK/VST3_SDK/public.sdk/source/main/macexport.exp.

Yes, that was it !
Thanks a lot.

Baptiste

This is a little weird though since VSTPluginMain is marked VST_EXPORT in vst2wrapper.cpp which expands to attribute ((visibility (“default”))) under XCode so the VST2 entry point should get exported by default.

Did you try placing something like #errorGNUC undefined” under #define VST_EXPORT in line 3059 in vst2wrapper.cpp to see whether this is the actual source of your problem?

That’s correct - it is already exported. The problem was that they added the exported symbol file to the XCode projects in SDK3.6.7 but they didn’t add _VSTPluginMain to it. If you look at previous XCode projects from the previous SDKs (going back to at least 3.6.0), you’ll see that although the exported symbols file does exist, it isn’t actually used in the included XCode projects.

The reason my project did not have any issues was because it was based on the previous SDK paradigm of not using the exported symbols file at all. When I added it, but without the _VSTPluginMain entry point, then the VST2 didn’t show up any more. So, having the exported symbols file (now) included in the XCode project appears to override the existing exports.

One solution to this issue would have been to simply remove the exported symbols file from the XCode project.

BTW: a similar but opposite issue exists on the Windows side. If you look at the SDK 3.6.7 Visual Studio projects, you’ll see they’ve removed the module definition file (exported symbols) for the individual projects.

I did find the new file winexport.def in the …/source/main directory, but I could not find where it was being used in the VS project for the sample code. If I remove it from the SDK, the sample projects still compile correctly and appear in the various DAWs (???)

My VS projects have their own .def files like the previous SDKs, including the VSTPluginMain entry point for VST2. Now, I get a compiler warning that VSTPluginMain is being exported twice.

So my new question is how is the GetPluginFactory entry point being exposed for the VST3 plugins in Visual Studio projects? Are there some new files in the 3.6.7 SDK or some place the new winexport.def file is being included?

  • Will

Hi Will,

not adding _VSTPluginMain to the exports is intended/correct I believe, since using the vst2wrapper is optional and the vst2 entry point could not be defined at all when compiling a plugin. In my opinion, they should settle for a consistent way of exporting the relevant symbols on all systems, though, using the attribute or __declspec qualifiers, so there’s no confusion as to which exp/def files to use or not to use. I think what we’re seeing here is a result of the overal novercal way - no offense, since I’m glad they are still supporting it at all in their latest SDK - vst2 is handeled.

Hi Ray

In my opinion, they should settle for a consistent way of exporting the relevant symbols on all systems

Agreed. I had been using 3.6.7 since the day it was released, and only realized the MacOS projects had been modified to use the exported symbols file because of this thread.

It would be nice to have SDK release notes that not only listed the bug-fixes, new features, and paradigm shifts, but also listed any changes made to the VS and XCode projects as well, so we could more easily upgrade existing projects to the new SDK.

  • Will