Use new plug-in format

General JUCE discussion
1

Hi,

we are currently working on an application, that is a kind of plug-in host (based on JUCE example)

What I need to know is whether it is possible to work with our own internal format (Waves API), instead of existing ones (VST, VST3 or AU...) for reaching the purpose of opening a plug-in. What is the best way to do it? Is there a tutorial?

Plus, I need to know how works the plug-ins scanning system. Where do you recommend me I start reading?

 

Thanks you,

Nathaniel Perez

Waves Audio ltd.

2

The juce_StandaloneFilterWindow.h file shows how to launch a JUCE-based plugin in a simple standalone application. You don't need any referecnes to VST/AU/etc. It simply loads an instance of your own custom AudioProcessor. As it just so happens, someone asked about this recently on the list, so here is some further reading for you. Good luck.  

http://www.juce.com/forum/topic/standalone-app-and-plugin-template/tutorial

3

Hi,

thanks for the answer, but I think I have not made my point clear enough.

Our plug-ins are not JUCE based at all...so it seems juce_StandaloneFilterWindow.h can't help here, as it is intended for opening JUCE plug-ins.

Our plug-ins dlls are not platform dependant, and instead are run via shell dlls, that are specifically implemented for each one of the common architectures such as VST, AU, DAE, AAX...The hosts see those shells as plug-ins, and the shell is responsible for opening the real plug.

Now we have also so-called Stand alone apps (not Juce based for now), which open plug-ins via our own architecture. We can see it as a kind of alternative format. And what we need is to open plug-in from JUCE based plug-in host, via our own API.

Do you think there is a way for it?

 

Thank you,

Nathaniel Perez

Waves Audio ltd.

4

Well, kind of a low level start, but there's DynamicLibrary for loading dlls/dylibs. And then DirectoryIterator for scanning a directory for files. One could build a beginning of a plugin scanning/loading system from those.

If your plugins have a GUI, I would assume those want a native parent window onto which the plugin custom GUI can be attached. The ComponentPeer class can be used to obtain a native GUI window handle that could be passed as the parent window for your plugins. (The Component class has getPeer() which can be used to get the associated ComponentPeer instance.)

5

 We can see it as a kind of alternative format. 

To add to Xenakios' post, if you want to go low-level, you can go the hardcore route of designing your own juce::AudioPluginFormat.

There aren't tutorials for this - it's a massive undertaking.

You don't have to look very far for exmaples, mind you: all of the in-the-box derivatives give many hints on how to about this whole thing.

Examples of hosting support:

  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_processors/format_types/juce_VST3PluginFormat.cpp
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_processors/format_types/juce_LADSPAPluginFormat.cpp

Examples of client-side support:

  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/AU/juce_AU_Wrapper.mm
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/AAX/juce_AAX_Wrapper.cpp
  • https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/RTAS/juce_RTAS_Wrapper.cpp