[Bug]: Regression of #812, assertion failure in MidiMessageCollector for MIDI effects

[DaAwesomeP]

Detailed steps on how to reproduce the bug

If you set the following for a plugin:

NEEDS_MIDI_INPUT TRUE
NEEDS_MIDI_OUTPUT TRUE
IS_MIDI_EFFECT TRUE

Then play a MIDI note to an enabled input and you will see:

JUCE Assertion failure in juce_MidiMessageCollector.cpp:66

I have only tested running the plugin in standalone mode on JUCE develop c786e61. This appears to be a regression of #812.

This line is here:

JUCE/modules/juce_audio_devices/midi_io/juce_MidiMessageCollector.cpp

Lines 61 to 67 in c786e61

	void MidiMessageCollector::addMessageToQueue (const MidiMessage& message)
	{
	const ScopedLock sl (midiCallbackLock);
	#if JUCE_DEBUG
	jassert (hasCalledReset); // you need to call reset() to set the correct sample rate before using this object
	#endif

What is the expected behaviour?

Should not error when inputting MIDI notes to a MIDI effect plugin running in standalone mode.

Operating systems

Linux

What versions of the operating systems?

openSUSE Leap 15.6, Linux 6.13.6-lp156.4.g495d82a-default

Architectures

x86_64

Stacktrace

Plug-in formats (if applicable)

Standalone

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• I agree to follow the Code of Conduct

[reuk]

I'm unable to reproduce the reported behaviour on Fedora 42 or macOS.

MidiMessageCollector::reset is normally called from AudioProcessorPlayer::audioDeviceAboutToStart. The assertion you're seeing would imply that this function is never called, which might indicate that there's no suitable audio device on your system. On my Fedora machine, AudioDeviceManager::createAudioDeviceTypes adds the ALSA audio device type. I recommend putting a breakpoint in this function and ensuring that at least one AudioIODeviceType is returned by this function. You should also check that the createDevice call (e.g. ALSAAudioIODeviceType::createDevice) succeeds.

Note that standalone MIDI effects still need an audio callback in order to function. MIDI events are delivered to the AudioProcessor via the processBlock function, and use sample positions within each block of audio to timestamp the MIDI events. If you're trying to write a standalone app (not a plugin) that only processes MIDI and doesn't deal with audio at all, then you could consider moving away from AudioProcessor. Check the MidiDemo for an example of a standalone app that processes MIDI events. Otherwise, if you're trying to support plugin formats as well as standalone, then the standalone will need an audio device to function.

[reuk]

I've investigated a bit more: I managed to trigger the assertion, but only by changing the stored ~/.config/MIDILogger.settings to clear both the input and output device names. In this case, the AudioDeviceManager will avoid opening any audio device, instead of respecting the default channel counts requested by the standalone.

Adding the following snippet in AudioDeviceManager::initialiseFromXML() just before the line starting setup.bufferSize = xml.getIntAttribute (... seems to resolve the issue for me. Please could you try making the same modification and check whether it fixes the issue for you?

const auto deviceNameMissing = (numInputChansNeeded  > 0 && setup.inputDeviceName .isEmpty())
                            || (numOutputChansNeeded > 0 && setup.outputDeviceName.isEmpty());

if (selectDefaultDeviceOnFailure && deviceNameMissing)
    insertDefaultDeviceNames (setup);

Note that this change is just forcing the AudioDeviceManager to pick appropriate default devices in the case that the stored settings don't contain appropriate devices. If the system itself doesn't have any suitable input/output audio devices, then this change won't resolve the issue you were seeing.