MidiMon 1.00, a USB MIDI app

I’m introducing MidiMon 1.00, an app designed to work with Rick Murray & Dave Higton’s USB-MIDI module.

This provides a basic MIDI console monitor, as well as a virtual piano keyboard and the ability to send some common MIDI commands.

Unfortunately, while I wanted to do more with it, in the end I had too much trouble getting my hardware and the module to work together consistently to get it all done, but I’ve cleaned up what I have and put together a release in hopes it might be of use to someone; it’s fully open source, so hopefully it can be scavenged for parts if nothing else. It has some helper modules that may be useful in some other applications.
But if your setup works, it should be at least as functional as that, with the exception of severe limitations with SysEx messages.

If anyone has a working USB MIDI setup on your RISC OS machine, drop me a line and let me know the hardware details, to say I am broke is an understatement but I’d love to revisit this some more later. Please be gentle though, this is my first RISC OS app! Wrapping this up and putting a bow on it will give me a chance to move on to some of the other RISC things I’ve been working on lately, mostly involving Python.

Get it here: https://github.com/laurenrad/MidiMon

with the exception of severe limitations with SysEx messages.

They were pretty much not supported until recently (now supported thanks to Ian).

Try version 0.10: https://heyrick.eu/blog/files/usbmidi010.zip

If anyone has a working USB MIDI setup on your RISC OS machine

Pi 2 (or 3B+), RISC OS 5.2x, my module, Yamaha PSR E-333. Plug’n’play in both directions.

See also https://heyrick.eu/blog/index.php?diary=20230827#simpleseq

Oh! I’m behind on versions once again, I’ll have to check it out 0.10! I need to keep up on your blog. I think it’s more than the module for me though, if I plug the presonus interface i have into my Pi half the time it freezes and a random app crashes, so there are deeper issues there… and the only other thing I have that might work is one of those generic cable ones. Budget and space limitations will probably prevent me from trying different hardware anytime soon but I’ll keep that in mind for the future. If you get a chance let me know if it does the basics with that Yamaha.

is it possible to delete a thread here? I’m not sure this is ready for primetime.

is it possible to delete a thread here?

You can’t. I could, but I don’t see a good enough reason to do so.

half the time it freezes and a random app crashes

Connection stuff was changed quite a bit in recent versions. Shouldn’t have randomly crashed, more likely just fail to detect devices or endpoints. See if the new version is better.

But note that the RISC OS USB stack is kind of fragile – I have a clever keyboard & touchpad combo that works as a keyboard but if I touch the pad, RISC OS immediately freezes.

but I don’t see a good enough reason to do so.

I agree. The original post clearly discusses its limitations, so anybody using it does so with that understanding.

Plus, if we waited for primetime, stuff wouldn’t ever get released. :P

but if I touch the pad, RISC OS immediately freezes

I have a keyboard and mouse shared between the Mac and the Pi, with a diode switch device to select which computer I’m using. They also share a monitor (well, a TV really), with two HDMI inputs I can switch between with the TV remote. Most of the time I can switch back and forth as much as I like, but occasionally when I switch back to the Pi, RISCOS has frozen. It’s not happened since I thought of being very careful not to knock the mouse as I switch, thinking that maybe some mouse communication switched in or out in mid message might be the problem, but I wasn’t aware of having knocked the mouse anyway, it wasn’t very frequent before, and it might just be luck. The Mac has never frozen at all at change-over (it has at other times, but that’s a different, known problem).

But note that the RISC OS USB stack is kind of fragile – I have a clever keyboard & touchpad combo that works as a keyboard but if I touch the pad, RISC OS immediately freezes.

It is also notable that, in my experience, some of these freezes are not real “hanging” crashes but something like busy-waits that never end – until you remove the USB device in question, and RISC OS suddenly starts to work again.

Switching the keyboard and mouse away from the Pi to the Mac, then back to the Pi, didn’t unfreeze the Pi, sadly. Tried that. I don’t have a Break key on the Mac keyboard that I’m using, so I don’t know if even Ctrl-Break would work or not, but possibly not since neither the keyboard nor the mouse seem to do anything at all when the Pi’s frozen. Tried using a keyboard with a Break key for a while, but it didn’t happen while I’d got that keyboard hooked up, and it’s not very good with the Mac so don’t want to keep it on long term.

Most of the time I can switch back and forth as much as I like, but occasionally when I switch back to the Pi, RISCOS has frozen.

I see this too, occasionally. But similar to what Steffen said, it can easily be solved by disconnecting the USB connector and connect it back again. Or is it really RISC OS that is frozen, and not just the keyboard/mouse?

I didn’t think to try unplugging anything, thinking that switching the diode switch away from the Pi would be effectively the same thing. If it happens again, I’ll try unplugging things and plugging them back in.

Most of the time I can switch back and forth as much as I like, but occasionally when I switch back to the Pi, RISCOS has frozen.

This sounds like a problem I had on my ARMX6. I was (and still am) using a VGA 4-port KVM, and switching would randomly freeze the aRMX6, and more repeayedly freeze it if I moved the mouse while it was settling.

Adding a USB3 externally powered switch between the KVM and the ARMX6 cured it. This in spite of the power draw of the KVM being less than 50mA – well below the amount the USB ports on the ARMX6 should have been capable of.

Well…

This is going well.

1. Go to the site on my phone to pick up the download zip link (https://github.com/laurenrad/MidiMon/archive/refs/heads/main.zip) because stupid GitHub doesn’t think mobile browsers can download stuff like that. What is this, 2010?
2. Open the archive. Swear in four different languages ¹ at seeing that the files have been bodged into name/ext format and all filetypes thrown away (some retained as /xxx extensions).
3. Sort out the mess, swearing in two more languages ².
4. Build the two modules to test the building works. Groan at seeing it’s the stupid shared MakeFiles, so I have no idea how to tell it to not squeeze things. That crap made sense when loading files off floppy. Now? Well, I don’t feel that it makes any damn difference to a file that’s smaller than a couple of megabytes.
5. Unsqueeze the modules by hand. Because I’m the kind of freak that likes looking at the code in Zap.
6. Build the app. It fails. No perl.
7. Remember that Perl is buried somewhere in the DDE. Find it, run the app.
8. Build the app. This time it makes it in an “Install” directory within the AcornC/C++.
9. Run it. Instant crash – no MIDI module loaded. !Run ought to check that, but since that file is being built programatically… ;)
10. Finally!

Right…

• Reading the docs, yes, there were problems getting the MIDI module to connect to some devices. In certain cases, whether or not it worked depended on whether the device was connected before or after the module was started. Hopefully most of this has been fixed.

• It receives data from my keyboard, and displays the manufacturer name (in place of the product name). So far so good.

• What does “Test” in the monitor menu do? For me, it crashes.

• Might be better to change the “Fake Fast Clock” option (which is not really necessary now it can actually do proper millisecond timestamping) with an option to enable/disable the slow interface mode. Which I notice you’re using.

• The piano works as well, but I find the Octave confusing, having octave 0 be middle C, and it’s plus or minus from there. Perhaps it might be better to annotate it as C0, C1, C2, etc and have it default to C4?

• The pitch bend doesn’t seem to work correctly. Well, it sort of bends the pitch slightly, except for the topmost position where it is not bent. The lower half… seems to sometimes bend down slightly, sometimes not.
  At max bend up, I ought to be able to bend a C to a D (or two semitones), and at max bend down I ought to be able to bend a C to an A#. Basically just pick any key, and go two keys up or down. That’s the range pitch bend ought to cover.
  Are you correctly calculating the value to send?

• Controller 64 value 64 adds sustain, as expected.

• Well done having a menu listing all the program change voices. I have a list of voices in my sequencer and, yeah, it was a bit of a pain in the arse to type all that stuff in. ;)
  For the future, maybe an option to send bank select messages before the program change? That’s how one accesses the additional XG voices. I think Roland’s method is similar.

• I don’t think Tune Request actually does anything on digital devices, as their timing is derived from megahertz crystals. It was more important back in the old days with analogue parts that could ‘drift’.

• A useful addition might be a Misc option for forcing all notes off. The little program I threw together to do this stepped through each channel, using MIDI_SetTxChannel to select it, then MIDI_TxAllNotesOff to say “shaddup!”.

• I can’t comment on Song Select. My keyboard specifically doesn’t support that.

• I noticed when fiddling:
  [System Exclusive] 43 10
Unknown command
Unknown command
[System Exclusive End]
  It isn’t immediately clear to me if this is failing to interpret the SysEx (I wouldn’t waste your time, there’s a LOAD of proprietary junk in there) or if it’s trying to treat the SysEx data as MIDI bytes? Might be worth just outputting SysEx: xx xx xx (<— the bytes) until the SysEx end is received.
  But, I know the older module didn’t really do anything useful with SysEx, so… ;-)

• When you’re using the hotkeys to play the piano, you’re grabbing keys that don’t belong to you and not swallowing the keys. So I’m actually sort of playing music as I write this, depending on which letters I’m typing. depending depending… I quite like how that sounds. Actually, it’s more like deendng as p and i don’t sound.
  Sorry, this actually amuses me. It’s like a sort of synesthesia ³.

• If the keyboard is switched off and back on again (the module will assign it the same device ID) but the program refuses to recognise it until the module has been RMReInit’d.

Anyway – some problems, but on the whole I think it’s a very useful test utility to ensure that a MIDI device is correctly working with RISC OS. It’s much friendlier than that crappy test program I threw together.

Let me know when you have an updated version to play with (preferably a prebuilt app!).

PS: Is it wise/safe to call Wimp_SendMessage from a module (not a task) while in a Service Call handler? You’ll be in SVC/IRQ mode and RISC OS is probably “busy” so…?

¹ Merde! Mierda! Scheiße! (and you can guess the English one)

² Paska! Cachu!

³ Given that texture is an important part of my food (I’m happy eating plain pasta tossed in a little butter or oil provided there are multiple sorts of pasta to provide varied textures), plus different tastes have colours associated with them (and whether or not I like something depends upon the colour as well as the taste perception, well, for me the colour is part of the taste perception)… yeah, I think I have some sensory miswiring. Did I mention that I’m a really picky eater?

A quick program I threw together to test pitch bending (make sure it isn’t my module screwing up!).

SYS "MIDI_SetTxChannel", 1
SYS "MIDI_TxNoteOn", 60, 80
FOR l% = 1 TO 20 : WAIT : NEXT
SYS "MIDI_TxPitchWheel", &3FFF
FOR l% = 1 TO 20 : WAIT : NEXT
SYS "MIDI_TxPitchWheel", 0
FOR l% = 1 TO 20 : WAIT : NEXT
SYS "MIDI_TxPitchWheel", &2000

MUST reset the pitch wheel to &2000 at the end, or the bending will ‘stick’.

Anyway, this has the same effect as pressing C, D, A#, C.

[hmm, only two notes – is there a way in MIDI to slide a large range of notes, like you can with many string instruments?]

is there a way in MIDI to slide a large range of notes

Sussed it.

Here’s an extreme example…

REM Channel 1
SYS "MIDI_SetTxChannel", 1

REM Yamaha XG - switch to Er hu
SYS "MIDI_TxControlChange", 0, 0
SYS "MIDI_TxControlChange", 32, 115
SYS "MIDI_TxProgramChange", 111

REM For non XG, you could use this for a cello:
REM SYS "MIDI_TxProgramChange", 43

REM Select RPN &0000 -> pitch wheel adjustment
SYS "MIDI_TxControlChange", &64, &00
SYS "MIDI_TxControlChange", &65, &00
REM Select 24 semitones (or two whole octaves)
SYS "MIDI_TxControlChange", &06, &18
SYS "MIDI_TxControlChange", &26, &00
REM End RPN adjustment
SYS "MIDI_TxControlChange", &64, &7F
SYS "MIDI_TxControlChange", &65, &7F

REM Slide from C4 to C6!
SYS "MIDI_TxNoteOn", 60, 80
FOR l% = &2000 TO &3FFF STEP 64
  SYS "MIDI_TxPitchWheel", l%
  WAIT
NEXT
REM Slide from C6 down to C2
FOR l% = &3FFF TO &1 STEP -128
  SYS "MIDI_TxPitchWheel", l%
  WAIT
NEXT
REM And now back up to C4
FOR l% = 0 TO &2000 STEP 64
  SYS "MIDI_TxPitchWheel", l%
  WAIT
NEXT

REM End this note now
SYS "MIDI_TxNoteOn", 60, 0

The piano works as well, but I find the Octave confusing, having octave 0 be middle C, and it’s plus or minus from there. Perhaps it might be better to annotate it as C0, C1, C2, etc and have it default to C4?

I had to look it up, but it does seem to be generally accepted that middle C is referred to as C4.

Yes, the notes are tagged with an octave number (according to a full size 88 key piano) in “Scientific Notation”.
In this case, middle C is the fourth one along, hence C4 (or correctly, C₄).

The only time you should see negative octaves is if you have a piano with more than 88 keys (rare, but they do exist).

To start with, thank you for taking a look Rick, I have to admit I wasn’t expecting much interest or attention which is why I threw it out as-is when I got a bit frustrated with trying to work around the hardware issues and wanted to move on without abandoning it. I’ll try to examine all this, but to answer a couple things real quick:

- There is a binary build on the releases section of the Github repository, but I may want to see if I can make that a bit more visible. Especially since I left the debug flag in the Makefile in my haste.

What does “Test” in the monitor menu do? For me, it crashes.

It shouldn’t be there. I meant to have it hidden if debug was off or just remove it from the resource file, but again, I did it in a rush. I’ll make sure to deal with that.

The piano works as well, but I find the Octave confusing, having octave 0 be middle C, and it’s plus or minus from there. Perhaps it might be better to annotate it as C0, C1, C2, etc and have it default to C4?

I was attempting to mimic the behavior of some of the hardware I have, which has the octave as an offset from the middle octave which isn’t rigidly defined but C4 is a common option for middle C as Dave mentioned. I may see if I can make it more clear in the future, but I’ll have to think more about this one.

I don’t think Tune Request actually does anything on digital devices, as their timing is derived from megahertz crystals. It was more important back in the old days with analogue parts that could ‘drift’.

Indeed not likely to be useful but I just threw it in because it didn’t cost any extra to add.

A useful addition might be a Misc option for forcing all notes off. The little program I threw together to do this stepped through each channel, using MIDI_SetTxChannel to select it, then MIDI_TxAllNotesOff to say “shaddup!”.

I think I intended to add this to the Panic function but didn’t quite get to it.

It isn’t immediately clear to me if this is failing to interpret the SysEx (I wouldn’t waste your time, there’s a LOAD of proprietary junk in there) or if it’s trying to treat the SysEx data as MIDI bytes?

Correct, the parsing right now is very stupid and only designed to handle fixed-size commands. I wanted to fix this but I couldn’t get the hardware working long enough to test things (the condition deteriorated over the course of development where when I started it usually worked and when I ended it didn’t at all), so I left it where it was where it could at least handle everything else.

When you’re using the hotkeys to play the piano, you’re grabbing keys that don’t belong to you and not swallowing the keys. So I’m actually sort of playing music as I write this, depending on which letters I’m typing. depending depending… I quite like how that sounds. Actually, it’s more like deendng as p and i don’t sound.

In order to get key up events working (and this was needed to have the thing at all), I did something a bit nonstandard, so while it should honor the caret if hotkeys are disabled, otherwise this is the intended behavior for now. But I am curious if there is a better way to get key up events.

PS: Is it wise/safe to call Wimp_SendMessage from a module (not a task) while in a Service Call handler? You’ll be in SVC/IRQ mode and RISC OS is probably “busy” so…

As has been pointed out to me, absolutely not. I’m not very bright.

thank you for taking a look Rick

You’re welcome.

I wasn’t expecting much interest or attention

It has the potential to be a useful test tool.

There is a binary build on the releases section of the Github repository

Oh? I didn’t spot that.

I meant to have it hidden if debug was off or just remove it from the resource file

Ah, it doesn’t crash. It adds a dummy entry to the scroll list, and then calls exit(). ;)

which has the octave as an offset from the middle octave which isn’t rigidly defined

No, some parts of music aren’t rigidly defined, thanks to hundreds and hundreds of years of evolution.
However, to set middle C to be the first octave is eccentric to the point of being obtuse. These days, it pretty much counts according to a standard 88 key piano, and counts up. There’s some disagreement over whether middle C is C3, C4, or C5, but the closest thing there is to an actual “standard” is variously known as Scientific Notation, International Pitch Notation (IPN), and American Standard Pitch Notation (ASPN) – and in SN/IPN/ASPN, middle C is always C₄.

For completeness, I think this pretty much covers it:

(Textile completely lost its marbles over this table, so I had to rewrite it as an actual HTML table… :/ )

As you can see, the Helmholtz and English rapidly devolve into nonsense with all of that punctuation. I mean, “c''''”? Really?

To be fair – the reason Helmholtz/old English/old French (etc) use similar methods as Helmholtz designed this system in the middle of the 19th century, basing it upon Baroque organ tablature, which itself came from the Renaissance…

Technically there are more – MIDI note 0 would be C_-1, 108 would be C₈, and 120 would be C₉ but these are far out of the range of normal pianos. Hell, even my electric piano has so much interference in the playback that SYS "MIDI_TxNoteOn", 0, 80 is read by my phone as being A#₁ (and out of tune) rather than C_-1 (and my stand-alone tuner just about manages a standard piano and simply won’t go down that low).

That being said, C₀ is 16.something Hz, and the notation begins there as the average person isn’t actually able to distinguish frequencies less than ~20Hz as individual pitches. So while C_-1 technically exists, it’s usefulness (and the ability of hardware to actually reproduce it) is rather limited.

But I am curious if there is a better way to get key up events.

I think the appallingly naff keyboard handling has been visited numerous times in the history of RISC OS. There’s nemo’s DeepKeys module, Ovation(Pro) ships with a helper module that’s aimed at working out which keys were actually pressed. I’m sure somebody somewhere has wanted to know when a key was released without continually polling for it. So.. yeah…

I’m not very bright.

RISC OS is a bit fragile in places. ;)

As has been pointed out to me, absolutely not.

The way I’d handle this is to pop the key press/release into a buffer (make the buffer suitably large that you can handle multiple key actions). If you terminate the buffer with a null word, you can then simply give the buffer address to the Wimp to treat as a poll word. If nothing happened, the first word will be the null terminator so the Wimp won’t do anything.
If something happened, the first word will be the key code/action/whatever (non-null) so the Wimp will poll you with Pollword non-zero (reason #13), helpfully with the address as !0 of the poll block, so you just read the key events until you get to a null word which means you’re done. Tell the module you’re done so it can poke a null into the start and reset whatever pointers are necessary internally.

I notice your NoteOff comment says that for reasons you don’t recall, you actually use NoteOn with a velocity of zero.
Don’t sweat it. My keyboard does the exact same thing.

There’s actually a reason for this – and why the MIDI spec supports both methods – in the old days of serial MIDI there was a thing called “running status” where you’d send a “Note On” command, followed by a note, and another, and more notes. Because MIDI commands have the high bit set, and parameters don’t, it is easy to tell that “Note On” followed by eight bytes with bit 7 clear would actually be four individual Note On requests. For the first, the Note On was specified, but for the remainder, it was assumed. Thus effectively saving the time necessary to send one byte for every note. It adds up.
By having a velocity of zero mean Note Off, it became possible to construct fairly complex sequences using running status. Many notes could be turned on and off as the data was received, and it had a higher throughput as, effectively, you gained a note for every two sent (thanks to not needing to keep sending the Note On).

Obviously this falls apart a little when one interface is talking to multiple channels, so these always need to be specified; but even so – depending upon the music – running status could save time. So Note On 0 is equal to a Note Off.

the condition deteriorated over the course of development

I think you mentioned having a cheap MIDI interface?

If it’s a QinHeng CH345, be aware that there are some notable bugs:

• It screws up SysEx messages – every other packet has the wrong index number (it seems to stuff CIN15 into things). If you’re aware of this and know it’s a CH345, it can be worked around by bodging the data and not blindly assuming the CIN15 is correct.
• It completely messes up running status. This is insurmountable.
• It has a worrying tendancy to simply lose data if too many notes arrive at once. MIDI suggests that resource limited devices ought to support at least 128 bytes (and SysEx packets shouldn’t be more than that unless it is known the receiver can cope. Well, uh, I think the CH345 would struggle to cope with eight bytes, never mind a hundred and twenty eight.

There’s a reason why the flag in my device array (in the MIDI module source) is called “craphardware”.

Interesting – up and down output of the keyboard ‘down’ key so you could time the length of Morse code Dit’s/Dar’s.

Also a way of getting Morse output from a Morse key connected to serial port or a USB/serial port?

(Textile completely lost its marbles over this table, so I had to rewrite it as an actual HTML table… :/ )

Hey you and me both, Textile has been driving me up the wall.

So not saying you’re wrong about the octave thing, but thinking back through my process, I remember why I did it this way: this is exactly how my old Midiman Oxygen 8 behaves; it’s a two octave controller and it starts with the lowest key’s octave on a “center” value it calls “0”, and there are two buttons to shift down to -4, or up to +4. So, that’s my excuse. I also believe this is a fairly common way for smaller controllers to operate, and that was the intended skeuomorphism behind it (that and the Casio VL-Tone VL-1 inspiration to make the simple button keys look as decent as I could). It should be able to make all valid MIDI notes at any rate I believe, which is the main intention since it’s not going to be useful for performance; it’s to let you send test messages encompassing as much of the MIDI spec as possible, whether they’re useful or not.

I notice your NoteOff comment says that for reasons you don’t recall, you actually use NoteOn with a velocity of zero.

I went back to this comment and to clarify, it can actually do note off both ways with a choice, but what the comment was referring to is that I had some trouble or confusion or something with the MIDI_TXNoteOff SWI and ended up constructing the note off myself with MIDI_TxCommand. Might look at it later, but…

… You’re right about the KeyUp thing, but I went back to it last night and realized I don’t have the Wimp maneuvering down enough to know how to solve it. So I’m putting this one on the shelf for just a few while I do another project that will help me learn what I need to put out a fix, unless someone wants to contribute one.

Oh also:

If it’s a QinHeng CH345, be aware that there are some notable bugs:

I have one of those AND a presonus one that are both wonky for different reasons, but anecdotally, when I broke out the new version of USB-MIDI the other day it seemed to behave, so it’s worth another look. But yeah, I’m aware of the limitations with that one.

Hey you and me both, Textile has been driving me up the wall.

Not withstanding the habit of the forum setup overall making a dog’s breakfast of the user input, it might be helpful if the "See also the Textile reference here actually pointed to a live link of helpful info – like

https://textile-lang.com/ 

So not saying you’re wrong about the octave thing

Yeah, best not to argue with the conventions of the professional musicians (western world set) when they’ve been using those conventions for many generations.

Edited round the link because textile…

I tweeked my MIDI Support system to provide !MidiMon with the responses it
needs and it all seems to work fine, although I haven’t quite figured out
what’s up with the pitch wheel.
My only comment is that I think it would be nice if the monitor window
displayed the channel number with each message.

Midi Support might help with testing as you can create loop backs without
any extra hardware and connect it back to back with my monitor program
(which I have renamed MidiSMon to avoid problems – S for Support).
If you’re interested, it now supports serial ports as well as USB and
is available here

As Midi Support and Ricks USB Midi both use the same Acorn Midi SWI’s
it’s an either/or situation. Both cannot be loaded at the same time.

although I haven’t quite figured out what’s up with the pitch wheel.

How is it not working?

it would be nice if the monitor window displayed the channel number with each message.

Yup, that’s a good idea.

Both cannot be loaded at the same time.

That’s probably just as well. Multiple things trying to control the same hardware doesn’t tend to end up in a good place.

as you can create loop backs without any extra hardware

In my experience, the main problems aren’t so much the drivers, it’s getting the hardware doing what is expected.

although I haven’t quite figured out what’s up with the pitch wheel.

How is it not working?

In my experience, the main problems aren’t so much the drivers, it’s getting the hardware doing what is expected.

Too many unknowns when you’re trying to sort out your own code. That’s the nice thing about using a UART instead of USB. You can loop back tx to rx directly on the Pi expansion header without any additional hardware. The pins are next to one another as well.