MIDI over IP Flaky AF

Gig Performer on Mac OS X
1

People use MIDI over IP on the Mac to an iPad live, but I can’t get through a single song on my system. Very frustrating!

My System:

  • M1 MacBook Pro with Ventura 1.3.4.
  • A StayGo hub/desktop-extender with an Ethernet Port. The Mac Power Supply plugs into the StayGo, and it connects to the Mac with USB-C.
  • Network cable to an Ethernet Hub, then another cable to…
  • Belkin Ethernet Adapter (which also gets power via lighting from an iPad charger with USB-C) to…
  • iPad Pro (1st gen) with the latest firmware, running…
  • MobileSheets

I can get the system running, flip pages and change songs from either MobileSheets or GigPerformer.

But after about a minute, the iPad drops from the Audio-MIDI Setup directory, gets disconnected and page turns no longer work. Note that the IP addresses for both Mac and iPad are set manually, and Wi-Fi is disabled on both machines. 192.168.2.21 for the Mac (2 = 2nd network; 21 = 1st Mac.) 192.168.2.31 for the iPad (2 = 2nd network; 31 = 1st iPad.)

When the iPad drops from the directory, I can still ping the iPad from the Mac successfully.

If I restart MobileSheets, sometimes the iPad comes back into the directory, but it doesn’t get connected automatically. I need to restore it manually.

If the iPad is missing from the directory for an extended time Audio-Midi Setup will throw an error. What’s worse is that GigPerformer can hang when this happens. Today, I was playing a song on keyboard, it stopped playing with a hung note. Panic and Audio Engine reset did not fix it. Gig Performer showed “Connection Error 1-2-3-4-5-6-7-8-9”

I can still ping the iPad after all of that. But as I recall, I have to reboot the system to get Gig Performer to work well again.

It’s possible that my Ethernet connection has dropouts. I will try different cables, etc. Even so, I’m surprised that it would crash so badly. Before networking MIDI, GP was rock solid, like running for weeks on end.

On the iPad/MobileSheets side, it would be good if it were to send an occasional “I’m still here” signal, rather than just establish things when the app starts. There’s something about restarting MobileSheets that resets the name in the directory from my iPad’s Bonjour Name, “Jon’s iPad(2)” to the generic “iPad”. The iPad device gets lost, but reappears when I restart the app.

On the Gig Performer side, It shouldn’t hang if there are problems on the network. If a MIDI or USB MIDI device disappears, the program keeps ticking, but when a MIDI-over-IP device goes away, bad things seem to happen.

For testing, I recommend manually disconnecting and reconnecting an Ethernet cable and see what happens. I’m guessing that my hardware connection is intermittent, but I would hope that it would just cause a temporary loss of page turning that would be restored. It shouldn’t be forever broken or cause crashes.

I’ll go back to Wi-Fi for now, which ironically seemed more robust than my network hardware.

[Sorry for the negative report. I’ll keep trying things on my end.]

2

Some updates:

  • I didn’t need to reboot to get GP working again. I just needed to restart the program. However, even though I show the Network Connection in Audio-MIDI Setup again, page turns don’t work. I would need to reboot to get that going again.
  • The iPad is running iOS 16.6.1. I changed its name in Setup | General | About, but when I run MobileSheets, it first shows up as “Jons iPad”, but then gets overwritten with “iPad.” I’m not sure if this conflict is part of the problem or not. It could be that the identity of my iPad changes occasionally, causing connection losses.

I’ll keep trying things to get more details.

3

More data…

  • I got another crash with GP and the Connection Error 1-2-3… and a hung note.

  • I renamed my iPad to “iPad”, so it would align with what MobileSheets seems to rename it.

  • I rebooted everything, launched MobileSheets, but not GP. “iPad” shows up in the directory, and I connect it. But after a minute or so, it disappears from the directory, and after a short time, it becomes disconnected as well. When I restart MobileSheets, it comes back temporarily, but disappears again.

  • I disconnected my wired network and enabled Wi-Fi on both devices. Launching MobileSheets again adds “iPad” to the directory, and I can connect it, but only temporarily. It seems that the problem isn’t limited to my wired network.

My conclusions are:

  1. GP should be more robust when Network MIDI connections fail.
  2. On my iPad Pro (1st gen) with iOS 16.6.1, MobileSheets forces the name to be “iPad”.
  3. The MobileSheets MIDI service comes and goes on my iPad.
  4. The situation can cause a “Connection Lost” error in Audio MIDI Setup, which brings us back to Conclusion #1.

I’ll try ForScore to see how it behaves.

4

I tried ForScore. It uses the Bonjour name that I set on the iPad (Settings | General | About), and it is stable. The problem seems to be with MobileSheets on my version of the iPad and iOS.

So, for now I’ll use ForScore. But I’d prefer to use MobileSheets for its page indexing using the Pitch Bend message.

Also, we will see how stable ForScore is over time. I’ve just done a quick test, but I haven’t seen it drop once. Fortunately, MobileSheets fails quickly, which isn’t good for performing, but is helpful when troubleshooting. :slight_smile:

5

Mac is not my territory, so forgive me if I’m asking stupid questions: Is GP just sending midi messages using a midi port, or is GP directly using a network connection like OSC? When GP is just sending messages using a midi port, then there’s not too much GP can control about that: it calls the api of the os for doing midi, and there the responsibility of GP stops.

Just think out (too?) loud…

When I read what you wrote, it feels more like a bonjour issue, but most probably I’m out of my depth here

6

Thanks Frank,

It’s just a MIDI port, but it’s over IP as setup by MacOS. In the PC world, it’s more like RTP-MIDI.

So far, ForScore has been solid, so the cause of the instability has been MobileSheets. My guess is that my older iPad Pro has an older version of iOS that is only updated for security issues, and Mobile Sheets was developed using a newer version. ForScore was developed long ago, so it is happy with my olde iPad. :slight_smile:

Something seems to be different about this Network MIDI failure, compared to USB MIDI devices. GP seems to be very tolerant of MIDI configuration changes on the Mac, but this Connection Lost thing upends it.

7

GP has no idea that the connection is a network connection, it is just using the standard CoreMIDI API

2 Likes
8

In that case, Apple should make it more robust. :slight_smile:

1 Like
9

Is Ethernet needed because of cable distance?
I have a USB-C iPad Air and can just use the USB-C connection to my MacBook Pro to pass Midi. The iPad can be in airplane mode. This is using the IDAM mode, where you connect to the iPad from the Audio MIDI Setup app (which adds the ‘iPad’ Midi Port to GP).

10

Well, I use mobilesheets (used to use forscore) with a Mac and I have never had a problem. Maybe you have a connectivity issue.

I use a decent router connected to my Mac via Ethernet and my iPads (one for sheet music and one is running Lemur using OSC) and it has been flawless for many years.

11

JonFair,

I tried to look into the issue with the MIDI network session being renamed to just “iPad” after the initial connection occurs. It’s a mystery to me - I’m using the most simple approach possible. I just enabled the default MIDINetworkSession, indicate that anyone can connect, and then everything after that point is transparent to me. Much like dhj said, network connections are treated identically to USB connections - they are just input and output ports, and the implementation details are abstracted away by Apple with their framework. I do support a direct network connection option in MobileSheets - things get more complicated with that, but that’s generally not needed if the device supports rtpMIDI, and that is a direct connection to a specific IP/port, which is a little different from how rtpMIDI/bonjour works. As far as why forScore works differently, I’m assuming that forScore uses a completely different approach to this, as they added MIDI support before iPadOS 13, so they are probably using coreMIDI to set up a completely separate session from the default session, and this must be why the session name doesn’t change after connecting. forScore also lets you connect to existing sessions created on other machines - that’s not really something I currently support (I will have to investigate it). I experimented with trying to set up a different host with a specific name, but could not get it to change the behavior, so there is most likely something I’m missing (the documentation for coreMIDI is incredibly sparse and lacking).

Having said all that, the name really doesn’t matter in the slightest. Once you connect to the session, it should just work from that point on. I set up the following test:

  1. I ran rtpMIDI on Windows to connect to the network session
  2. I used sendMIDI to send pitch bend messages to MobileSheets running on my iPad Pro (gen 2)
  3. I ran a little test program that triggers sendMIDI in a loop

I let that run for 30 minutes, and the network connection was completely solid the entire time. I’m not seeing any issues at all, so I have no idea why you are seeing such different behavior with your setup. I also haven’t heard from any other users encountering problems with the MIDI over WiFi functionality. I know this doesn’t help you, and I wish I had more answers, but without having access to your environment and devices, I can’t really explain what’s going on. I can repeat these tests on my Mac Mini if needed, but I don’t think the end result would be any different.

Mike

12

It’s definitely odd behavior on my system. No idea why. It was a bit more stable when I first started using it a week ago or so over Wi-Fi, but not fully stable. When I went to a wired network and disabled Wi-Fi that the failure occurred more quickly.

I’ve also tried a free MIDI keyboard app on the iPad, and it behaves as expected with the correct name, but it might have been developed earlier as well.

Another odd thing is that the announcement of the iPad to the Mac from MobileSheets has been sluggish. When setting up a Session from scratch on the Mac and starting MobileSheets, “iPad” did not show up quickly in the directory. I would generally need to add a connection to the IP address of the iPad manually. I would then connect it, but it would generally fail. But eventually, “iPad” would show up in the directory. I could then delete my manual connection to the device. I believe that with ForScore and the keyboard app, it would appear in the directory on the Mac quickly, but I’m not 100% sure.

When the device would show up in the directory with MobileSheets running on the iPad, I would generally see “Jon’s iPad” at first, but then it would be renamed “iPad”. I would then get many unpredictable results, such as “iPad” still showing as connection, even though it might disappear in the directory. Restarting MobileSheets might yield “Jon’s iPad” then “iPad” in the directory, and the Connection might disappear.

It all feels like something is fighting itself, leading to the instability.

I don’t have any developers tools for the Mac. I might be able to hook up WireShark or something to monitor the IP traffic, though I am no expert, and sifting the useful information from the other traffic takes skill.

If you can think of any test that I could do, please let me know. I could shoot a video of the situation, but I don’t know that it would help. It’s as I describe, with the name reluctant to show up, when it does, it changes, and after a short period, it disappears. There’s no clear cause and effect.

I wonder if anybody else with an original iPad Pro and iOS 16.6.1, or similar, is having this issue.

13

Sorry for the delay in my response JonFair - I monitor the Zubersoft forums pretty closely, but I forgot to check this thread to see if you had responded. I do think you are right that it does seem like there is something fighting itself, sort of like the code may be constantly adding/removing MIDI ports if they are being reported as found/lost. I wanted to mention that I set up an empty application, initialized the MIDI network session (using CoreMIDI directly), and saw the same behavior where the session started out with my tablet’s name, then switched back to just “iPad”. I’m going to run some more tests with this though to see if I can gather any more information.

Feel free to contact me at mike@zubersoft.com if you want to continue this conversation. I’ll definitely be happy to share information with you if I discover anything new, and I’d like to try to think of more tests/workarounds for you, as I’d like to get this working reliably on your device. We can also experiment with some TestFlight builds (if you are interested) to see if we can figure out any patterns for when it works or doesn’t work.

Mike

14

I wanted to leave one more comment. I’m noticing that if you load MobileSheets and switch apps, that the MIDI network session is still active in the background. The same is true if you do this with forScore. So if you have multiple apps all running in the background that all use MIDI, I have no idea if this can cause conflicts with the default MIDI network session. If you haven’t done so yet, it would be good to verify that you’ve force closed all apps other than MobileSheets when running your tests just to confirm that there are no conflicts between apps. This may have no impact at all on the problems you are seeing (I’ve certainly never had to do this while testing), but I just wanted to rule it out as a potential problem.

Mike