Plug-in not appearing in DAW

Ive created a successful build of my basic plug-in but I can’t seem to be able to create an instance of one in protools or reason

I know now that reason doesnt like VST3 so Ive been focusing on PT, but even if I copy the VST3 file over to the correct folder on my PC it doesnt appear in the DAW

I have the VST3, AU, and Standalone options marked in projucer before opening in visual studio and building the files

Ive looked into other discussions here but havent seen any other possible solutions, could I be missing something in my code? is there a different solution I might have missed?

any help is welcome, thanks!

Reason only supports 64-bit VST2 plugins. Pro Tools only supports AAX plugins.

While you can use JUCE to build VST2 and AAX plugins, in both cases you’ll need to find your own copies of these SDKs, and sign licenses with Steinberg and Avid respectively if you wish to distribute plugins in these formats.

1 Like

is VST2 considered VST Legacy within Projucer?

also, are the SDKs and liscences something difficult and/or expensive to get a hold of, im only starting out my coding/dev journey and am currently working on a student project

Thank you for your explanation!

Yes, VST2 is the same as VST Legacy in the Projucer.

The VST2 and AAX SDKs are not too difficult to get, but you may need to contact Steinberg/Avid. For a student project, I’d recommend building an Audio Unit or VST3 plugin, although you’d need to find a different plugin host for testing. You could try REAPER, or the AudioPluginHost project which is in the extras folder of the JUCE repo.

You simply CANNOT get a VST2 license from Steinberg anymore. That’s been my understanding for awhile, unless something has changed. So you can make them for your own personal use, but you cannot sell/distribute them. Steinberg wants to kill off VST2.


Register as Protools Developer

Register with Pace and get eden sdk and code sign the plugin in the plugin…

Other wise it won’t show up in Protools.

However, as of now Protools aax sdk is currently broken with Juce 6… but I might be ignorant to that.

Huh? I successfully built a JUCE 6 based AAX plugin yesterday so I definitely cannot confirm that :wink: JUCE 6 & AAX SDK works as expected! If you have got issues with that I think it’s better to discuss that in a dedicated forum thread :slightly_smiling_face:

Edit: Found your thread. As I see it you are complaining about the fact that AAX is not ready for universal binary x86_64/ARM builds on macOS yet but JUCE is since version 6, so this is no JUCE 6 thing at all but only matter of chosing the right architecture settings for the AAX target, which is not that hard.

1 Like

I’ll be the first to admit I’m a terrible programmer.

How in the world did you get it to build? I’m getting linker failures.

Is there Xcode settings or juce settings?


With CMake it ‘just works’.

Last time I tried it in the Projucer I had to create another exporter for Mac just for AAX and only enabled x86 there.

I’m also using CMake only for nearly a year now because it is so much easier to use from my point of view. Don’t know much about the current Projucer and I also barely use XCode but CLion as IDE and Ninja as build system instead, however I assume that there is a way to do it there. But from your post I’m not sure if you already understand the technical problem? Understanding that will likely help you understanding errors and finding the solution that fits your project best. So let me try to give a quick explanation:

So Apple decided to switch the CPU architecture for their computers from Intel x86_64 CPUs to their own “M1” chips which are based on an ARMv8 architecture. Code compiled for x86_64 won’t run on ARM (and also not the other way round). At the moment there are a lot of “old” x86_64 based macs still out there, so current mac software should be built twice, as an x86_64 version and as an ARM version. Since the usual user does not know anything about CPU architectures, Apple uses so called universal binaries, that means binaries actually containing two versions of the binary, one slice compiled for x86_64 and one slice for ARMv8.
The clang-based compiler toolchain used by XCode 12 makes it easy for you to compile your code as universal binary in one run, it will simply compile it twice and put together both binary slices into a universal binary. Now if you are linking to a third party library and are building a universal binary, the library you are linking against needs to be universal binary too – otherwise one slice of the binary won’t be complete.
If you are using XCode 12.2 or higher, it will offer you to build your project for “Any Mac” – this means it will attempt to build a universal binary. If you try that for an AAX plugin you will fail, since the AAX SDK as a dependency for that target is not configured to be built as universal binary at this time point, so it will fail to link to the non-existing ARMv8 slice at link time. Therefore you can build all your formats as universal binary, except for your AAX target which should be x86_64 only. With CMake all the magic is this single line

set_target_properties (myPlugin_AAX PROPERTIES OSX_ARCHITECTURES x86_64)

I’m quite sure that there is a similar option in the Projucer. You certainly don’t have to use CMake to do this. I hoped this helped you to get an idea what’s the problem. We will simply have to stick to this workaround until Avid releases a universal binary AAX sdk.

O wow thanks for the info. I didn’t know how that would effect us. They’ve been doing double files since they started thats why we have the hidden files in finder and why things don’t really delete on Mac.

That M1 is crazy doesn’t it use a neural net with the graphics card to use both processors. Since CPU is fast one calulation and GPU is slow with many calculations at once?

thats the setting you have to manual change in Xcode if you want tax to build as of now.

Managed to cause me a mild panic, we’ve only been distributing aax for a couple of weeks, I was sure they worked last time I checked them! :joy:

1 Like