[Fixed] Creating a multi-midi VST for use in Live


#1

Hi, is the configuration specified anywhere that is needed to be able to create a VST for use in Live that can provide inputs on the 16 MIDI channels required for routing in Live?

thx


VST2.4 problem, MIDI channels not visible in Ableton
#2

Hi. anyone any ideas on this? thx


#3

can one of the Juce devs comment on this pls?


#4

Hi @leehu, sorry none of us JUCE devs understand live midi routing enough to understand what you mean. Can you elaborate?

Fabian


#5

Hi, ah - ok. sure - see attached.

In Live, each MIDI track can only send MIDI on a single channel (effectively channel 1), but when routing MIDI from a track and sending it to a track with a VST on it (in this case an instance of Drumazon) some VSTs give multiple routings so that you can target an individual MIDI channel, as shown by the 16 entries here.

When I create a VST I only get a single entry so can’t route MIDI notes to a specific channel for processing… So, basically wondering how to create multiple inputs…

thx


#6

hi, any thoughts on if this can be achieved? thx


#7

This can be easily fixed by responding to the effGetNumMidiInputChannels, effGetNumMidiOutputChannels opcodes. Here is a patch:

diff --git a/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp b/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
index 4008c45..b77bd45 100644
--- a/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
+++ b/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
@@ -1168,6 +1168,8 @@ public:
			 case plugInOpcodeGetSpeakerArrangement:       return handleGetSpeakerConfiguration (args);
			 case plugInOpcodeSetNumberOfSamplesToProcess: return handleSetNumberOfSamplesToProcess (args);
			 case plugInOpcodeSetSampleFloatType:          return handleSetSampleFloatType (args);
+            case pluginOpcodeGetNumMidiInputChannels:     return handleGetNumMidiInputChannels();
+            case pluginOpcodeGetNumMidiOutputChannels:    return handleGetNumMidiOutputChannels();
			 default:                                      return 0;
		 }
	 }
@@ -2007,6 +2009,24 @@ private:
		 return 0;
	 }

+    pointer_sized_int handleGetNumMidiInputChannels()
+    {
+       #if JucePlugin_WantsMidiInput || JucePlugin_IsMidiEffect
+        return 16;
+       #else
+        return 0;
+       #endif
+    }
+
+    pointer_sized_int handleGetNumMidiOutputChannels()
+    {
+       #if JucePlugin_ProducesMidiOutput || JucePlugin_IsMidiEffect
+        return 16;
+       #else
+        return 0;
+       #endif
+    }
+
	 //==============================================================================
	 JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (JuceVSTWrapper)
 };
diff --git a/modules/juce_audio_processors/format_types/juce_VSTInterface.h b/modules/juce_audio_processors/format_types/juce_VSTInterface.h
index fc10105..90b8628 100644
--- a/modules/juce_audio_processors/format_types/juce_VSTInterface.h
+++ b/modules/juce_audio_processors/format_types/juce_VSTInterface.h
@@ -141,6 +141,8 @@ enum VstHostToPlugInOpcodes
	 plugInOpcodeStopProcess,
	 plugInOpcodeSetNumberOfSamplesToProcess,
	 plugInOpcodeSetSampleFloatType = plugInOpcodeSetNumberOfSamplesToProcess + 4,
+    pluginOpcodeGetNumMidiInputChannels,
+    pluginOpcodeGetNumMidiOutputChannels,
	 plugInOpcodeMaximum = plugInOpcodeSetSampleFloatType
 };

Are there any reasons why I should not apply this patch to develop? Could this break anybodys plug-in?


#8

Hi. thanks… I wouldn’t have thought so if no-one has previously brought it up. I’m just trying to think though whether these are circumstance where people wouldn’t want to give the option and so forcing it to 16 might be overkill? In this instance, I need the ability to target individual channels as I’m routing MIDI through but this won’t be the case for most plugins… Maybe it should be an override?


#9

tested the patch and it works fine. thx


#10

any update on whether this is going into the code?


#11

It’s on our todo list!


#12

OK I’ve pushed this change now to develop as it is in line with what VST3 has been doing for a while anyway.


#13

great, thanks!