juicysfplugin.app is a standalone application, for playing around.
You can plugin your hardware MIDI keyboard, or play with the software MIDI keyboard. Or route MIDI messages into it from a virtual MIDI controller (e.g. the [macOS IAC Bus](http://re-compose.desk.com/customer/portal/articles/1382244-setting-up-the-iac-bus-on-a-mac)).
Install [JUCE](https://shop.juce.com/get-juce) 5.3 in `/Applications`.
We expect to find JUCE headers in `/Applications/JUCE/modules`.
(Optional) To target VST3, install Steinberg [VST3 Audio Plug-Ins SDK](https://www.steinberg.net/en/company/developers.html).
We expect to find a folder `~/SDKs/VST_SDK/VST3_SDK`.
(Optional) Install IntelliJ AppCode if you prefer it to XCode.
Open `juicysfplugin/Builds/MacOSX/juicysfplugin.xcodeproj` in XCode (or IntelliJ AppCode).
Build & run the "juicysfplugin - Standalone Plugin" target.
## Testing VST/AU plugins inside an audio plugin host
You'll notice that the schemes for [VST, VST3, AU, AUv3] targets are configured such that "Run" launches the executable `AudioPluginHost.app`. This lets you run the audio plugin as though it were hosted inside a DAW.
I recommend building (e.g. with XCode) the simple Audio Plugin Host that comes with JUCE Framework:
Then symlink `/Applications/JUCE/AudioPluginHost.app` to the built `AudioPluginHost.app` (because that's where I told the Run configuration to look for AudioPluginHost.app):
Note: Release **and** Debug flavors _both_ output targets [VST, VST3, AU] to the same location: `~/Library/Audio/Plug-Ins/$TARGET/juicysfplugin.$EXT`.
Whichever flavor you built _most recently_, wins.
The way I provide archives of _both_ build flavors is by archiving one, building next flavor, then archiving that (i.e. I build serially, not parallel).
But probably people only care about the Release flavor anyway.
> (This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.)
## SDKs
### Steinberg VST3
The VST3 release is built against the Steinberg VST3 SDK.
http://www.steinberg.net/sdklicenses_vst3
> This Software Development Kit is licensed under the terms of the Steinberg VST3 License,
or alternatively under the terms of the General Public License (GPL) Version 3.
# Questions
## Windows/Linux/Android/iOS version?
No _big_ barriers. The source code and all its dependencies are cross-platform. The main friction is setting up a dev environment, and learning how to link dynamic libraries on that OS (i.e. we need to link to libfluidsynth).
Some thoughts that come to mind:
- Bundling libraries portably is far easier on Windows than on macOS
- Just throw a dll next to the executable
- .NET assembly binding can be debugged using [fuslogvw](https://docs.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer)
- Windows already has plenty of free, nice soundfont plugins
- It's probably pretty hard to bundle fluidsynth into mobile apps
- Bundling would be easier if I used static linking