I’m working on a standalone plugin; I’ve made it using StandaloneFilterWindow, so I used the same processing code I wrote for a VST/AU plugin.
The plugin produces MIDI events; so in the StandaloneFilterWindow I have enabled the Midi Output selector. Then I use something like MIDI Yoke or LoopBe to route MIDI events to other apps, so I choose the proper MIDI stream from the Midi Output selector (for example MIDI Yoke).
I’m monitoring the MIDI events passing through MIDI Yoke, but no events are received.
It works good as audio-to-midi plugin in a host, but it does not work as standalone application.
I think you need to handle the midi output yourself when working in standalone mode. MidiOutput::openDevice(int index) will return a midi output device that you can send notes to.
StandaloneFilterWindow creates an AudioDeviceSelectorComponent (here I enabled the Midi Out selector), passing its AudioDeviceManager.
The AudioDeviceSelectorComponent already selects the default MidiOutput and assigns it to the AudioDeviceManager.
else if (comboBoxThatHasChanged == midiOutputSelector)
{
deviceManager.setDefaultMidiOutput (midiOutputSelector->getText());
}
Now, the AudioDeviceManager adds an AudioProcessorPlayer as callback for audio and Midi Input:
Sorry, I don’t have any code for this, nor have I ever tried to do it myself. Perhaps I’m over simplifying this, but if you call AudioDeviceManager::getDefaultMidiOutput() after the midi device has been selected it will return the current MidiOutput object. Once you have this can’t you just call one of its send midi methods to output some midi notes?
What do you mean by “fact that plugin’s can’t output midi when inside a DAW by any chance”. They certainly can as far as I’m aware? Just make sure you enable MIDI out in your AppConfig.h file.
It’s a complicated subject, MIDI OUT from a plugin to the Host is possible in the latest AU and VST (i have no idea bout AAX), it’s not available in some previous AU specifications.
You can always talk to MIDI devices directly but you must watch out for timing and threading, you should never produce MIDI events from within the Editor class (your GUI events will cause big delays in MIDI events),
you should produce MIDI events in a different thread or in the audio thread. You will never get correct time sync between your host and the external device, there is no way of knowing when to transmit MIDI events
to the external device from the Audio thread, it’s not possible because of latencies inside the host.
If you plan to send devices from your own classes on the UI thread, use the startBackgroundThread () method and send the vents using sendBlockOfMessages() method, all the threading stuff will be handled by JUCE.
I’ve copied the entire juce_StandaloneFilterWindow.h in my source directory, renaming it to myStandaloneFilterWindow.h and renaming all occurrences of StandaloneFilterWindow to MyStandaloneFilterWindow.
My standalone MIDI effect (no audio channels needed) unlike the plugin, doesn’t receive or send midi messages by default…
Is this has been taken care of in JUCE 5 or its something that we need to do it manually like the example above?