JUCE handling of MIDI plugins

General JUCE discussion
1

Given the limited support for MIDI plugins which forces us to release those as normal plugins in certain plugin formats and simultaneously release them as MIDI plugins in other plugin formats, instead of using JucePlugin_IsMidiEffect wouldn’t it make more sense to determine if the plugin is a MIDI plugin inside each plugin format by looking at its category? (and then generate separate VS/XCode projects for those categories?)

For AU, the MIDI plugin categories would be ‘aumi’ or ‘aumu’
For AAX, the recently added AAX_EPlugInCategory_MIDIEffect

To be more specific, for AU I was able to ignore JucePlugin_isMidiEffect with the following change in juce_audio_processors/format_types/juce_AU_Shared.h(524):

static int getBusCountForWrapper (const AudioProcessor& juceFilter, bool isInput)
{
   /*
   #if JucePlugin_IsMidiEffect
    const auto numRequiredBuses = isInput ? 0 : 1;
   #else
    const auto numRequiredBuses = 0;
   #endif
   */
   const auto numRequiredBuses = (
            ('aumi'==JucePlugin_AUMainType)
            && !isInput
            )?1:0;

   return jmax (numRequiredBuses, getBusCount (juceFilter, isInput));
}

Thoughts?

2

What’s the main problem you’re trying to solve? Is it that you want to avoid building the “shared code” portion of the library twice, once for each state of JucePlugin_IsMidiEffect?

3

Hi, thanks for asking. I’m building from the same projucer file an AU Midi plugin (aumi) and a SWGenerator AAX plugin. I was basically suggesting a way to select separately for each plugin format if you want it to be a MIDI plugin. I think this is more natural since the category of the plugin already indicates if it is a MIDI plugin or not.

4

Thanks for the suggestion. We’ve pushed some changes to the plugin wrappers, so that the JucePlugin_IsMidiEffect macro is no longer queried, and other more-specific macros, or AudioProcessor member functions, are used instead.

3 Likes
5

Can we have a warning raised if that macro is still #defined in projects? This way we can declutter them when the JUCE version they are compiled with is updated to the newer version which no longer requires the macro.
I know I have asked the same in the past for other macros, but that would really help to reduce the amount of variables to take into account when investigating a bug, thanks.

2 Likes
6

I did consider this, but I think this would be a breaking change for users. We’ve only stopped querying this define in the plugin wrappers. The definition is still included in Projucer and CMake projects, and may still be queried in user code. Removing the definition would break user code that queries this macro. In particular, the macro is used in template projects generated by the Projucer, so removing the macro would break any project that hasn’t modified the relevant parts of the template.

7

Nice work reuk. Thanks! I think it would be also a good opportunity to add the recently introduced AAX_EPlugInCategory_MIDIEffect AAX category and address the interaction of JucePlugin_IsMidiEffect with the AAX code since paradoxically it has to be set to false for AAX Midi Effects to work (see AAX MIDI FX plugin via CMake detected as Instrument in Pro Tools).

8

Thanks for the suggestion, we’ve added support for the MIDIEffect category here:

2 Likes