MidiInput problem on windows 7



MidiInput keep reporting null pointer when inside a plugin.
While the same code works on mac, and works inside the demo application on the PC. But not inside a plugin either RTAS (Protools) or VST (I only tested Reaper)…
Though midi devices are ‘seen’ and I can properly populate a stringArray with MidiInput::getDevices () …

While I was scratching my head to find why my plugin do not work, I trimmed down things and tested this little code in JuceDemo plugin without sucess :

[code]MidiInputCallback * callback;
MidiInput * input;
input = MidiInput::openDevice(0,callback);

if (input != nullptr) {
gainLabel.setText(“It works !”,false);
gainLabel.setText(“Do not work !”,false);

I’ve been several hours on this, (remember no debug protools on the PC …) installing hosts, drivers, building the picky RTAS and launching protools etc…
For now I’m back to xcode !

Any idea ?
This is with windows 7 64 bits, on bootcamp (and parallels).
Protools 8.04
Latest ‘module’ tip.



If the host already has your midi device open, a lot of drivers will fail to open a second handle on it.



But it fail on ALL midi drivers I have in the computer…
I’ve tried in both bootcamp win7 and parallels win XP.
There’s 2 in the mbox pro, and 2 virtual midi drivers.

I can’t believe there’s no way to do a synth VI on windows ?



Then perhaps the host has all your midi drivers already open…? I can’t think of any other reason why it’d fail except that something else is holding onto the driver. Why not try putting your code into an app rather than a plugin and see if that works?


FWIW, Pro Tools seems to open each and every available input drivers, even if not instructed to do so. And since most Windows driver are not multi-client contrary to Mac ones, then this could explain the whole thing.

BTW, it’s indeed possible to launch PT with a debugger, at least with version 9. You need to use the debug edition of Pro Tools, and you may have to remove some Digidesign drivers (some drivers check for a debugger instance and kill the whole process when they detect one)
Since you can use PT9 with built-in audio, you can surely debug if you remove all of the Digidesign drivers.

To override PT9 debugger detection, you may (or must, I just don’t remember right now) have to launch PT then attach to, instead of merely debugging PT.



I’m very new to JUCE and C++ programming, but I think I’ve got a similar problem.

I’ve created a MainComponent with the Jucer and created a new Audio Plugin with the Introjucer. This works fine, in my DAW (Cubase, Windows 7), the MainComponent window opens correctly. The plugin should accept Midi (JucePlugin_WantsMidiInput flag is set).
I want my plugin to be controlled by a external hardware midi controller, so I’ve created an instance of MidiInput in the private declarations of MainComponent.h and MainComponent inherits ‘handleIncomingMidiMessage’ to create a listener.

class MainComponent  : public Component,
                       public SliderListener,
                       public ButtonListener,
	               public MidiInputCallback
    MainComponent ();

    //[UserMethods]     -- You can add your own custom methods in this section.
	void handleIncomingMidiMessage (MidiInput* source, const MidiMessage& message);


        //[UserVariables]   -- You can add your own custom variables in this section. 
	MidiInput* midiInput;


At this point, the plugin still works.
Next, I start the MidiInput in the constructor of MainComponent.cpp and I stop it in the destructor:

MainComponent::MainComponent () :
        //[Constructor] You can add your own custom stuff here..

	// Open a midi input:
	midiInput = MidiInput::openDevice(MidiInput::getDefaultDeviceIndex(),this);
	if(midiInput) midiInput->start();


    //[Destructor_pre]. You can add your own custom destruction code here..



    //[Destructor]. You can add your own custom destruction code here..


// This function is called, every time a midi-event is sent from the controller:
void MainComponent::handleIncomingMidiMessage (MidiInput* source, const MidiMessage& message)
	if(message.getControllerNumber() == 9)
		// ensure Thread-safeness. Not sure if this is correct, but seems to work:
		const MessageManagerLock mmLock;
	if(message.getControllerNumber() == 4)
		const MessageManagerLock mmLock;
		wah_button->setToggleState(message.getControllerValue(), true);

And now the plugin can’t be opened in the host anymore. I’ve tried this exactly in the same way in a standalone application, and it works perfect.



Thanks for the explanation rbocquier.
But would be sad news.

Does this mean MidiInput is useless inside a plugin on the PC ?
Anybody succeed using it inside a plugin ?