MidiInput problem on windows 7

Audio Plugins
1

Hello,

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);
}
else
gainLabel.setText(“Do not work !”,false);
}[/code]

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.

Salvator

2

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

3

Hello,

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 ?

Salvator

4

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?

5

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.

6

Hi,

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
{
public:
    //==============================================================================
    MainComponent ();
    ~MainComponent();

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

[...]

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

[...]
};

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();

    //[/Constructor]
}

MainComponent::~MainComponent()
{
    //[Destructor_pre]. You can add your own custom destruction code here..
    //[/Destructor_pre]

[...]

	midiInput->stop();
	deleteAndZero(midiInput);

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

[...]

// 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;
		wah_slider->setValue(message.getControllerValue());
	}
	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.

7

Hello,

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 ?

Salvator