BR: MIDI input asserts on Big Sur

Steps to reproduce:

  • Pull latest develop
  • Create a plugin project
  • Enable midi input, synth
  • Press a key
  • jassert
    // the messages that come in here need to be time-stamped correctly - see MidiInput
    // for details of what the number should be.
    jassert (message.getTimeStamp() != 0);
2 Likes

I’m getting that bug too.

I believe it’s related to the new implementation strategies in juce_mac_CoreMidi.mm:

    #if    (defined (MAC_OS_VERSION_11_0) || defined (__IPHONE_14_0))
     #if (MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_VERSION_11_0 || __IPHONE_OS_VERSION_MIN_REQUIRED >= __IPHONE_14_0)
      #define JUCE_HAS_NEW_COREMIDI_API 1
      #define JUCE_HAS_OLD_COREMIDI_API 0
      constexpr auto implementationStrategy = ImplementationStrategy::onlyNew;
     #else
      #define JUCE_HAS_NEW_COREMIDI_API 1
      #define JUCE_HAS_OLD_COREMIDI_API 1
      constexpr auto implementationStrategy = ImplementationStrategy::both;
     #endif
    #else
     #define JUCE_HAS_NEW_COREMIDI_API 0
     #define JUCE_HAS_OLD_COREMIDI_API 1
     constexpr auto implementationStrategy = ImplementationStrategy::onlyOld;
    #endif

Commenting out that whole section and replacing it with:

#define JUCE_HAS_NEW_COREMIDI_API 0
#define JUCE_HAS_OLD_COREMIDI_API 1
constexpr auto implementationStrategy = ImplementationStrategy::onlyOld;

Fixes it for me.

i can’t say for sure (because it looks like these are dynamically defined at build time in a place i can’t easily find) but i think that should be MAC_OS_X_VERSION_11_0 since that’s how the other versions mentioned in the source code are styled, eg MAC_OS_X_VERSION_10_5

edit: or maybe MAC_OS_X_VERSION_11 since that lines up with the version strings here

Bump. Can this be looked it?

Does this fix the issue?

I just wanted to report that this jassert is still being hit on MacOS Catalina.
I’m using the standalone plugin holder and am trying to filter the processBlock midiBuffer for all messages on a single channel only:

    for( auto message : midiMessages )
    {
        auto m = message.getMessage();
        if( m.getChannel() == 1 && !m.isMidiClock())
        {
            DBG("samplePos: " << message.samplePosition << " timestamp: " << m.getTimeStamp() );
            midiChannel1Collector.addMessageToQueue(m);
        }
    }

Every once in a while, I’ll get a message with the timestamp and samplePosition of 0:

samplePos: 53 timestamp: 53
samplePos: 93 timestamp: 93
samplePos: 93 timestamp: 93
samplePos: 93 timestamp: 93
samplePos: 77 timestamp: 77
samplePos: 54 timestamp: 54
samplePos: 5 timestamp: 5
samplePos: 33 timestamp: 33
samplePos: 0 timestamp: 0
JUCE Assertion failure in juce_MidiMessageCollector.cpp:59

A couple of questions:

  1. Is my usage of midiMessageCollector in processBlock an incorrect usage?
  2. If a message in the midiBuffer has a timestamp of 0, doesn’t that mean it lined up exactly with the start of an audio buffer, when it was created, deep in the juce::CoreAudioClasses::CoreAudioInternal code?
1 Like