Show a warning when loading a snapshot with missing hardware

[BenMcLean]

Is your feature request related to a problem? Please describe.
If Zynthian isn't detecting the hardware devices I expect it to, then this is a big problem and I need to know it when the snapshot loads!

Describe the solution you'd like
When a snapshot loads but some hardware devices referenced by the snapshot as MIDI inputs or outputs are missing, then a warning popup should be displayed in the UI saying what devices are missing, with options to cancel loading, continue xor try reloading the snapshot again after the user makes sure everything's turned on, plugged in and ready.

"Abort", "Retry", "Ignore" would be fine things for buttons on the warning popup to say -- but just defaulting to "Ignore" like Zynthian currently does without warning me is bad behavior from my perspective.

There could be just one warning for all missing devices or alternatively, if multiple devices are missing, then a series of the warnings to show one for each missing device. If there's multiple warnings then there needs to be a fourth "Ignore All" option. Either way, it needs to say the name of the missing device. (optionally, it could also include which chain was referencing it)

I've been calling this a "warning popup" but I don't know if the right word would be "popup" or "modal" or "screen" or some other UI term I can't think of at the moment. Please substitute whatever term is appropriate. I'm not entirely sure what should happen if other buttons are pressed (like "Chain" to go to another screen) while the warning is being shown -- should it dismiss the warning or should Zynthian ignore other buttons until the warning is dealt with? I'm inclined towards the latter but there might be reasons why it should dismiss the warning or something else should happen instead. There's definitely some room to clarify and idiot-proof this feature.

In summary, when there's missing hardware then that failure shouldn't be ignored by default. Instead, that's a good crash / error / exception we want to catch, as long as it's handled gracefully.

Describe alternatives you've considered
Maybe a way to turn the warning off for people who don't want it -- although I'd expect that everybody who uses external MIDI gear would probably want to know about missing gear every time it's missing.

Additional context
Kind of important that I can know my MIDI controller is actually controlling something! I'd see this as a critical feature for making the Zynthian dependable as a MIDI host/router for live performance with external gear.

[riban-bw]

I started to look at this but soon hit a problem. It could be quite challenging to identify what are the required devices, e.g. I may have some MIDI devices plugged in when I save the snapshot / ZS3 but they may not be important, e.g. the master keyboard in my home studio which I would not take to a gig. Instead, at the gig I might use a more portable device. I may be happy to use any MIDI keyboard that is available at a venue and just pack the Zynthian.

To consider this enhancement we need to better understand the rules of how to detect what is required for a particulary patch.

[BenMcLean]

It could be quite challenging to identify what are the required devices

The rule which immediately occurs to me is: Any device that's actually selected by one or more chains for MIDI input or output is required. Any device that's not, isn't required. Seems to have no ambiguity.

I may have some MIDI devices plugged in when I save the snapshot / ZS3 but they may not be important

It seems to me personally like it would make sense to disconnect or disable any optional device before saving the snapshot in such a case but there might be a better solution. In any case, missing devices you don't need would be what the "Ignore All" option is for.

[BenMcLean]

Also, I have been considering the best wording to submit another issue along the lines of saying that I'd like to make it so that any newly plugged in device doesn't get selected as input or output for any chain. When I first plug it in then it should be doing nothing until I add it to a chain. That would be the workflow which would make sense to me because the way it works now is that new devices seem to get added to every chain, which means that I have to go turning them off for every chain except the one they're for any time I plug in a new device.

But I'm not sure what I just said completely makes sense or is the best way to express it.

[BenMcLean]

The rule which immediately occurs to me is: Any device that's actually selected by one or more chains for MIDI input or output is required. Any device that's not, isn't required. Seems to have no ambiguity.

On second thought, a new menu could be made which attaches a status to connected devices as required or optional. What I really want to avoid is the situation where I think my setup is ready to play but it's actually not ready.

[riban-bw]

The oram branch includes the enhancements to MIDI devices. The MIDI input/output views show only the devices that are currently attached (updated at 2s intervals). I think this is similar to the "menu" suggested in the previous post. I feel there would be more detrimental impact on more users to implement this kind of warning system than there would be benefit so I am sorry to have to reject this request.

[BenMcLean]

Could this sort of feature be made in a plugin? Like a MIDI chain which shows warnings for any device that's not found when it starts up?

Never really knowing whether the devices you think are connected are actually connected is a pretty major issue. I'm not even sure how anyone could work around this without some kind of change from how Zynthian currently works. Sure, it might not matter much in your home studio because you can just do another take after you disconnect and reconnect your devices and check whether all your chains still have the right devices selected, but it sure would matter if you tried to use the Zynthian to route MIDI traffic in a live performance in front of an audience!

Imagine that you're in front of people, ready to play. So, you load the snapshot for the song and everybody else starts playing (guitar, bass, drums) but for you, the keyboardist who depended on Zynthian, no sound comes out because the Zynthian doesn't recognize your keyboard.

I'm not saying it has to be the exact solution of showing warnings as popups/modals which I suggested because this might be resolved other ways I haven't thought of. There could be some better design than my idea. But the underlying issue of knowing when snapshots fail to establish the expected MIDI signal connections when they load has to be dealt with somehow to make the Zynthian usable for live performance.

[BenMcLean]

Here's another idea: when the snapshot menu loads, color any snapshots that call for devices that aren't currently connected/available with red, while snapshots which are ready to load because they have all their devices connected would be colored green. That way, the status of the devices in the snapshot would be known before it even loads. I didn't consider this before because it could potentially make the menu load slow, since the menu would need to investigate the contents of each snapshot, which could get really expensive when there's a high number of snapshots. The code for this would also need good exception handling so that an invalid snapshot wouldn't crash the program.

If multi-threading is available in this context, maybe the evaluation of each snapshot could be done in a second thread, where they'd all start out as white, but would get colored in as the second thread gets done evaluating them. That way, the UI wouldn't get blocked while the evaluation goes on. It would also start over when it gets done in case the devices available have changed and just keep running as long as that menu's open.

A downside of this approach would be how we aren't able to see which devices are missing for each snapshot. Based on seeing the red color, we'd know something's wrong, but not what specifically, making problems more difficult to diagnose. Maybe this could be addressed with an additional feature to assist with diagnosing hardware connectivity problems.

Also, any time we use color to indicate any information ever in any context always makes that feature useless to people who are color-blind, so that's an accessibility issue for this idea. Maybe some kind of symbol could be displayed in addition to the color in order to address that.

[BenMcLean]

I'd really appreciate an indication, when you have time to consider it, of whether this alternative design could work, whether you have any better ideas or improvements on the idea, whether it's something you'd consider making or, if not, whether it's something you'd consider accepting if I made it and sent in a PR.

The possibility of the Zynthian falsely indicating that everything's fine when actually devices are missing during a live performance seems really bad to me. I don't think I could deal with the anxiety of such a critical unknown like that when playing live.

[BenMcLean]

@riban-bw It doesn't necessarily have to follow my exact design suggestions but without some way to address the underlying problem of missing hardware, I don't see how the Zynthian could ever be relied on for live performance. You can't pause and test it before every song: when playing live, you have to just move on. Any test would need to be automatic.

[riban-bw]

Have you an example of any other kit that provides this kind of check? An actual bit of hardware that somehow knows what devices you want to use at your next gig and warns you if it detects any misconfiguration in the expected rig? I am struggling to find a similar use case implemented in other equipment. Most devices I have seen or used depend on the user to configure, e.g. plug together, and to test that configuration. It is worth understanding the real (pragmatic) issue you want resolving because it seems like this issue stemmed from faulty equipment or overloading devices. I have never experienced a problem where my connected outboard devices have not performed as expected after I have plugged the system together and performed some simple tests, like one would during a soundcheck.

[BenMcLean]

I'm wanting the Zynthian to send program changes / patches to the Yamaha Reface keyboards, and since they don't have screens on them, there's no way to tell whether the patches have really been sent and received.

So what I'm thinking would happen is that I'd load a snapshot on the Zynthian that's designed to send out patches for the next song, then we'd start playing the next song, only to discover that the patches didn't actually send. The snapshot might have been set to send a patch to device "yamaha DX (1)" on channel 4 and it would fail to be received because the Zynthian named the DX I plugged in as "yamaha DX (2)" or some other stupid thing where the physical connections are fine but the software's screwed up.

[riban-bw]

I still don't know of any device that will check your connections for you. You can configure Zynthian so that it can use physical port mapping to ensure the devices plugged into ports will behave consistently between restarts, something few (if any) other devices do. It would really help if you showed us another device that does the magic you desire.

[BenMcLean]

I do seem to recall FL Studio doing something like this but I'll have to experiment to see.