MidiMon update: 1.50

Hi all, I’ve put together a new release of MidiMon, the USB-enabled MIDI utility, and it’s up on GitHub:

https://github.com/laurenrad/MidiMon/releases/tag/v1.50

I’ve taken various feedback into account from the previous release¹, and highlights include:

• Support for Pete’s Midi Support module (http://www.forever.onmypc.net/)
• A lot of bugfixes, including a helper module that hopefully behaves itself and does everything legally now.
• Multi-device support should now be working (should be able to send and receive on 4 devices)
• Pretty drastically reworked the monitor, it’s still very simple and unpolished, but less so than before. Additionally, it still doesn’t have full SysEx support, but sending it SysEx shouldn’t kill it anymore either.
• A Panic/All notes off feature, albeit a hasty one I didn’t test much.

If you get a chance to test it and have any additional notes, let me know, although I’ll be working on other projects for a bit. Thanks!

¹ Previous thread here

Hiya!

• Is werr() the correct way to end a program if there is a problem during start-up? I ask this as I tried running your program before I had loaded the MIDI module and it, obviously, said that it couldn’t continue in the absence of a MIDI module. Fair enough.
  What was weirder though was the dialogue that told me that had two buttons: Postmortem and Cancel…

• When I turn my keyboard off, I see “A MIDI error has occurred”. Maybe a way to trap that to know that the device is no longer active? After all, it hasn’t been disconnected exactly, so… ;)

• When I start the program, it does not display any active sensing or clock messages (there are MANY). I did manage to get it to show these by lots of fiddling, but I can’t work out what I did having restarted the program.

Oh, it looks like a recent(ish?) change to the MIDI module has broken something. Turning the keyboard on and off four times has it registered as one device and four ports. That’s wrong. It should be reusing the port that the VID/PID was previously associated with.

• What do you mean by “USB-MIDI will return errors in R0 and R1 here but that can’t be relied on at the moment if multiple modules are to be supported.” ?
  The code for both SetTxChannel and TxNoteOn only write the result to ir->r[0] (sets R0 on the way out). R1 isn’t touched.

• The Github links to v0.08 on my blog, so I’ve added a note at the top of that blog entry telling people to look at the column on the right for the latest version. That’s probably the simplest way given it’s a moving target.

• On-screen keyboard and pitch bend works. I see the panic goes and turns off all of the notes one by one. :-) It’s a bit naff there doesn’t seem to be a “shut the hell up will you?” command.

All in all, nice work.

Is werr() the correct way to end a program if there is a problem during start-up?

Correct? Nope. Easy? Very. Postmortem is what you’d expect, and provided by werr (of RISC_OSLib) with any “fatal” error. What I should have done though is flag it and go to cleanup. Shouldn’t be a massively big deal though, at the moment from what I can think of. Something to consider for next time.

When I turn my keyboard off, I see “A MIDI error has occurred”. Maybe a way to trap that to know that the device is no longer active? After all, it hasn’t been disconnected exactly, so… ;)

SO… and this isn’t exclusive to yours, but something I meant to bring up in the last post, but I’m not getting MIDI_DeviceConnectedEvent or MIDI_DeviceDisconnectedEvent from either module, nor the module initialise/dying service calls. All I get is, from yours, MIDI_ErrorEvent when I disconnect a device and nothing from the other one. What’s worse, I currently have no reliable way to differentiate between the two modules if you were to change these, as Peter put compatibility stubs in for any USB-MIDI specific calls before I put this release together¹. So these are some things that may have to worked out somehow going forward… it would be really nice to know when things are getting plugged/unplugged, but I couldn’t work it out at the moment.

What do you mean by “USB-MIDI will return errors in R0 and R1 here but that can’t be relied on at the moment if multiple modules are to be supported.” ?

According to the 0.09 documentation, MIDI_TxNoteOn will return -1 in R1 on exit if an error occurred. I haven’t tested this, the note was just reminding myself other modules didn’t support it.

The Github links to v0.08 on my blog

Oops, sorry about that, thank you for the redirection link.

All in all, nice work.

Thank you!

¹ Maybe there could be a new SWI that identifies your module with a description of “Please nobody else implement this???” Or maybe there already is one I could use, but I didn’t find one right away. It does attempt to detect anything conforming to what’s documented in Acorn MIDI guide and work with it, but for obvious reasons I haven’t tested this.

Correct? Nope. Easy? Very.

;) Good answer.

but I’m not getting MIDI_DeviceConnectedEvent or MIDI_DeviceDisconnectedEvent from either module

Strange.

Device callback handler →

• close endpoints
• clear descriptor
• set all ports lasterror to ‘X’
• issue SERVICE_MIDI_USBDISCONNECTED (not official!)
• issue EVENT_DEVICEDISCONNECTED
• issue EVENT_BACKGROUNDERROR

Is there some sort of restriction on calling GenerateEvent twice in a row?

nor the module initialise/dying service calls.

You should be. As the module starts up, it issues service call &58 reason 0.
As the module shuts down, it issues service call &58 reason 1.
It also (unofficially) issues service call &58 reason 11 when a USB device is disconnected.
It was supposed to (unofficially) issue reason 10 when one was disconnected, but it looks as if the various rewrites of this code have lost that along the way.

What’s worse, I currently have no reliable way to differentiate between the two modules if you were to change these

Parse the module help string? Mine says “USB MIDI” after the date. It may say some other stuff (like it currently says “USB MIDI [test build 3/d]”) but the “USB MIDI” part will always be there as it differentiates it from the Acorn MIDI.

According to the 0.09 documentation

Fair enough. ;)

MIDI_TxNoteOn will return -1 in R1 on exit if an error occurred.

It doesn’t, that’s a typo in the doc. :( If the device is invalid, it’s R0 that’s set to -1 as the following description says. Sorry.

Maybe there could be a new SWI that identifies your module

Okay, MIDI_USBInfo does the following:

• R0 = 0 → return generic information on the module (actually returns valid info in R0-R7 even though only R0 and R1 are documented)
• R0 > 0 → return info on the port (shifted by one because we’re counting from 1, not 0)

How about adding this:

• R0 = -1 → Return a module ID word in R0 (for mine, it’ll be 0×6B636952 (“Rick”)). Sets R1 to 0.

This way, if Peter adds his chosen ID word, then it’ll be possible to easily tell them apart.
Why setting R1 to zero? To allow for something meaningful in the future.

I won’t be releasing an updated module just yet. I’ve discovered an issue (thanks to testing your program) in that it seems as if when the device is turned off and on again, it gets assigned the same device ID, but a new port is created for it. This difference cropped up when the concept of devices and ports was split apart (as modern MIDI devices can support multiple ports and cables on one device).
But the problem is, if I turn my keyboard on and off a bunch of times, I get a bunch of phantom ports and only one actually works.

I’ve sent an email to Ian to notify him about this problem. I don’t want to fiddle with that part of the code as none of my devices support this level of complexity, but I think some of his do – so I don’t want to unknowingly break anything.

He also provided a fix for the “Device not found” (moving when the handles are closed) so if that has been annoying you at shutdown, there’s a fix on the way. ;)