Midi Input Enabled by default


#1

The AudioDeviceManager seems to be made so a new midi input will be set by default to Deactivated.
We experience too many customers not understanding why their device does not respond.
Is there a way to have any Midi device plugged in for the first time interacting with our application by default?
Thank you


#2

Would it be an option to react as ChangeListener and simply iterate over the available devices and switch them on?

I think that is easier than somebody who wants the current behaviour and needs to figure out which device just became online and deactivate it…

Haven’t tested it though…


Auto select MIDI
#3

If I understand what you mean, that is not an option. We want the Midi input the user already deactivated, to remain deactivated.
Juce does not allow to know if a device is plugged in for the first time or not.


#4

I see. In this case it makes sense if you store the information about deactivated yourself in the ApplicationProperties::getUserSettings(), this way the user decision would be persistent with the next run.
That way you can check when the setup changes and adapt the status using the properties, choosing on as default.

Otherwise if the connection is interrupted and comes back, the device would turn on magically…

Would that be an option?


#5

thank you. I was thinking the same right now :slight_smile: that should work.


#6

Here is the practical issue. The number one technical support issue we are having is users connecting their MIDI keyboard and it not working. Yes it’s in all of the documentation and Readme, but users don’t read. So we spend most of our days telling people to select the MIDI

Programs like Logic and other DAWS just select all ports, so that when you plugin your device, it just works. We wanted a way to do the same.


#7

I agree on all points! It makes perfect sense to assume, if a user connects a device, that he wants to use it. The only problem I see is, if a user has the option to turn the device off, it shouldn’t come back on just by unplugging and plugging it in, since that can happen accidentally, and you just got another support case.

I was just trying this, but I realised, that a MidiDevice coming available doesn’t trigger a sendChangedMessage on the deviceManager, unfortunately (on OSX anyway). Is there any signal to listen for, if a midi device is plugged in?

Here is what I tried:

// private member:
ValueTree midiDevices = ValurTree ("MidiInputs");

MainComponent::MainComponent()
{
    // [...]
    midiDevices = ValueTree ("MidiDevices");
    updateMidiDevices();
    deviceManager.addChangeListener (this);
}

void MainComponent::changeListenerCallback (ChangeBroadcaster* sender)
{
    if (sender == &deviceManager)
        updateMidiDevices();
}

void MainComponent::setMidiInputEnabled (const String &midiInputDeviceName, bool enabled)
{
    midiDevices.setProperty (midiInputDeviceName, enabled, nullptr);
    updateMidiDevices();
}

// can be private
void MainComponent::updateMidiDevices ()
{
    for (auto& midi : MidiInput::getDevices()) {
        // getProperty gets true as default answer, if the device was not specifically turned on or off
        deviceManager.setMidiInputEnabled (midi, midiDevices.getProperty (midi, true));
    }
}

#8

Many of the JUCE demos along with the Standalone Plugin Window use Timers to check when Midi devices come and go. So this could be an option. But let’s see what we can add to make this easier…


#9

Cool, I was thinking of that too, but I was not sure, how expensive that polling would be.
When I reached the CoreAudio level I left it there… But it doesn’t need to check too often anyway, each 1 to 5 seconds would be enough IMHO…


#10

We do not want a user who deselected a device to see it enabled next time it is plugged in, though. We still have to create a list of disabled device and save it, on top of the new device detection work you did.