MidiMon 1.00, a USB MIDI app

Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC1E01B4, pc = 00008BCC: registers at 0001C640

That address looks suspiciously like it’ll be in BASIC with registers in application workspace.

You might need to recompile the module with debugging options to see what’s going on.

That said, getting Rhapsody to crash messily isn’t hard. The best way I knew my MIDI export was good was when Rhapsody didn’t keel over stone dead.

Can Rhapsody cope with the number of available MIDI devices changing on the fly? It wasn’t part of the original spec due to being a hardware upgrade, but with USB things can come and go…

If no devices are connected at startup

I’ve cold started and loaded the module with my keyboard powered up so many times now…

Test version 2 of !RunImage to download, save the previous one :-)
This works for StepTime and for semiRealTime, to be confirmed.
For RealTime it should work but not yet flexitime.

Interesting the franglaise in the comments. ;)

Step time works – it seems to behave in a manner not unlike my sequencer.

Semi real time… it captures notes but it makes numerous mistakes. If I hold down a note, it seems to frequently insert a shorter note followed by a break. I notice, by the way, that it doesn’t capture expressions (key velocity or the sustain pedal).

Real time misses a lot, but there’s work to do as it can only capture about fifty notes before bombing out with a No room for function/procedure call. I think there’s some unholy nesting going on there that’s slaughtering BASIC’s stack.

The missing notes is an odd one, but the good news is that if you ignore the notation errors, the timing now more or less matches what was entered (I mean, it takes the same perceptual duration, I didn’t check it with a stopwatch!).

For information, the !Midiphile (ESP) application allows you to see if the MIDI file contains SysEx data.

Oh, I didn’t know about that.

Later: So much for 26/32 neutral, needs Aemulor. ;) Still, it allowed me to fix a couple of minor bugs in the MIDI export.

I found the culprit…
Two days ago, I tested my Roland expander output, so I connected a midi cable to out and since then as soon as I turn on the devices I receive a message “Active sensing (0xFE)”.

I don’t know who fills the buffers but it’s not the MIDI module because it’s not running.I don’t think I have a module or application that requires the handler service?
On the other hand, when it is launched it is a disaster (in fact it also happens with other versions).

I don’t know if there is a way around this problem with the MIDI module, I will already see if I can stop the flow of Active sensitive from the Roland

Rhapsody: Have you tested the !Runimage test version of 09/11/2023?
Normally there are additional corrections and better entry of notes (Step-Time and Semi-Real-time).
I continue to improve.

Real time misses a lot, but there’s work to do as it can only capture about fifty notes before bombing out with a No room for function/procedure call. I think there’s some unholy nesting going on there that’s slaughtering BASIC’s stack.

ESP: I bought a 32 bit version in 2007 which works without Aemulator. From what I understand, ESP software is now freeware,ROOL takes care of it but unfortunately they don’t have the sources…
To distribute?
Note: for the module it is with !MIDIMole from ESP + MIDI driver (Peter) that I could see the “ActiveSensing” arriving.

I will already see if I can stop the flow of Active sensitive from the Roland

I don’t think that’s the problem unless it’s causing the expander to do something weird.

My keyboard sends Active Sense every 200ms (I don’t think this can be turned off) and clock ticks every ~28ms (can be turned off by selecting external timing mode).
In its default state, my keyboard is very chatty, and the module copes.

If it is causing problems for Rhapsody, you are nuking all the buffers before accepting input, right? ;)

Ahem, I know it actually doesn’t – start Rhapsody, press a bunch of keys (on the piano) and then click the icon to turn on the recording mode and watch as lots of notes suddenly appear.

What is the actual order of DeviceFS activities at system shutdown?

My MIDI module throws a spurious “Device not found” error on shutdown, so it seems to me that by the time I’m getting the ability to close handles, the device has gone.

Should I, perhaps, be keeping an eye on devices other than MIDI – for example USB – and if that goes away first then just flag the handles as invalid and ignore the shutdown requests?

“Device not found” happens on 2 occasions 1 a DeviceCall when the device doesn’t exist and the other an attempt to deregister a device which doesn’t exist. I had a similar problem but I deregister devices you don’t. You have to ask why some code is taking any notice of errors returned when deregistering – there’s nothing you can do about it.

I suppose in your case the error is related to the the usb device which is deregistered when it disappears. The only difference I can see between your code and mine regarding usb is I close the files as early as possible – in the service call handler and you close files as late as possible in a callback. Maybe you haven’t closed the file before usb deregisters and that causes a problem at the fileswitch level who knows.

Does a rmreinit devicefs make the error happen?

Hi,
Glad to follow the discussion on USB, it’s essential for our boards

If it is causing problems for Rhapsody, you are nuking all the buffers before accepting input, right? ;)

Module’s Midi_init does it?
Rhapsody could do this when starting captures. I already restart Fastclock to be in phase with Beat which is reset to 0. This is what allows for better synchronization when starting notes.

Unfortunately I have problems with my keyboard…difficult to initiate reception. I run a simple test to check, but it works after resetting the keyboard multiple times.

I noticed in source code, that the Peter module wakes up the buffer every ms, and it works better.

I use version 0.11 of Rick’s module.

I’m making progress entering notes in rhythm using the keyboard in Rhapsody:-)

@Jean-Michel
I had a similar problem with a Keystation32, having to unplug/plug a few times, so I had a look at what it was doing on the PC using Wireshark.
I found that after enumeration the host (PC) sends about 16 “URB_Bulk in” request packets to the device (Keystation32). Sometimes one is returned to the host by the Keystation and is a packet with zero data.
Colin said a while back on this thread that a zero length packet could cause the packet request mechanism that we use to stall.

If the device returns 0 bytes RXDataPresent will not be called. so the whole process stops.

This might be why we have to unplug/plug the keyboard a few times before it works.
My solution of sending a wakeup call every ms is probably a bit of an overkill but it did solve the problem.

@Peter
It’s good to have someone who has the same configuration and thanks to the forum for being able to discuss it.

I found that after enumeration the host (PC) sends about 16 “URB_Bulk in” request packets to the device (Keystation32). Sometimes one is returned to the host by the Keystation and is a packet with zero data.

Colin said a while back on this thread that a zero length packet could cause the packet request mechanism that we use to stall.

Is this a problem with the USB (on RISC OS) or the module?

What’s strange is that the problem with Rick’s module has become recurring.
I use the same USB port configuration every time.
With USBInfo I reset the device or the Hub to get a “wake-up”.

I will perhaps work on the buffers again (Colin had already helped me).

About MidiSupport, I tested !SysExy, !MidiMole they appear in the routing, but the results are not the same as with the ESP version. For example MidiMole only displays reset systems.

The other ESP tool is MidiSpy which is very practical for viewing all the MIDI channels of a device

The module issues a wakeup when it connects to the input endpoint, and also after dealing with the buffer in the upcall.

Perhaps you could iterate the available devices and issue wakeups for them in irq_handler() to happen every time Timer1 fires. See if that makes any difference…?

@Rick
Thanks for the info, the wakeups seem effective (Peter module), but this does not explain the behavior of the keyboard, it is a solution.

Rhapsody investigations:
Timer 1, I think it is also used by Fastclock?
From Acorn_MIDI UserGuide:

User timer The User Timer (IOC timer 1) is used by the Fast Clock. This means that other software cannot use this timer while in Fast Clock timing mode, or the Fast Clock will not work correctly.

However it seems to work well with the modules.

FastClock is not related to Tempo, Beat and Beats, I’m testing a solution to keep them in phases.

Timer 1, I think it is also used by Fastclock?

Yes, the Fast Clock is updated by hooking into the equivalent of Timer1 on the modern machines.
It’s what the IRQ handler is for.

FastClock is not related to Tempo, Beat and Beats

Sort of. RISC OS supports some of this itself in the sound system (hence TEMPO, BEAT, BEATS, etc being keywords in BASIC), and it’s also a way of synchronising MIDI devices. Typically one device would be the clock (internal timing) and the others respond to it (external timing).

The reason that I say “sort of” is because the beat timing comes from somewhere. That where? The PRM says:

And the centisecond clock is derived from a high speed clock, just like (or maybe the same as) the Fast Clock. ;)

There’s a relationship, though with Fast Clock you can get better accuracy than is possible with centiseconds.
In my scheduler in SimpleSeq, I calculate the timing for each column of music using a float, and rounding to nearest centisecond. This permits me to use the monotonic clock as a timing source, with minimal jitter (+/- half a centisecond) without suffering accumulated errors if I worked it out using integers.

Hey, did you notice https://gitlab.riscosopen.org/RiscOS/Sources/Audio/MIDI/MIDIPlay ?

@Jean-Michel

Do you have a specific Windows driver for Keystation32?

No it’s Midi Class Compliant so uses the built in Windows driver. Both Ricks and my module can only connect to class compliant devices so anything that works with them won’t need a special driver on Windows.

Is this a problem with the USB (on RISC OS) or the module?

I don’t think it’s a problem with Risc OS USB, and the Keystation works reliably on Windows so I doubt there’s a problem with that either. More likely just a situation that we have to deal with.

My problem is that the Keystation is the only commercial midi device I have that is USB and Class Compliant. The other devices I have are either not class compliant or have DIN connections. I have a couple of USB to DIN adapters but they are home made and are class compliant but composite devices with streaming audio and midi interfaces. They work fine on Windows streaming 44.1k audio in both directions at the same time as playing Midi files through them
I made sure they worked with my module but because the midi interface is interface 3, they won’t work with Ricks module. And that brings me to my other problem.

I would have a go at trying the extra wakup’s myself in Rick’s code as I have the same Keystation, but
I only have GCC so a simple tweek to Ricks code is not so easy. I tried to recompile it a while ago and failed miserably.

As for the ESP tools,

For example MidiMole only displays reset systems.

What do you mean by “reset systems” ?.
The problem is that your version of MidiSupport is newer than the version I based my effort on. Mixing bits of your ESP system and mine may well have issues. I’m surprised you’ve done as well as you have. Must have spent a bit of time on it, Thanks.

@Rick

Hey, did you notice… (MIDIPlay)

This is ESP’s player module. It refuses to play about 10% of my midi files (about 100 ish). Sometimes the failure locks the machine. I looked at the source a while ago but decided it would be easier to give my player a MIDIPlay swi interface than to port all the assembler to GCC, and then try to fix it!
So I made my player a replacement and it’s now the player in (my) Midi Support.

Incidentally Rick, all I was going to try in your code a while ago (when I failed miserably) was to remember the interface number when searching for devices and then specify it in the call to OS_Find, so it would connect to composite devices. i.e. my dodgy home made beasties. But no matter, not important.

@Rick
I have tried to group the information, and I hope not to make any mistakes in their interpretation.

the beat timing comes from somewhere. That where?

From Acorn MIDI user guide:

NOTE: The types of time-stamp are related to the different time periods, or beats, used. For the purposes of this guide, a sound system beat, as defined in the RISC OS User Guide, is referred to as a microbeat, in order to distinguish it from a MIDI beat.
One MIDI beat is equal to 16 microbeats, when microbeats govern the timing of MIDI beats.

Tempo is not just for the basic, it is the system tempo of the sound module. By default it is in centiseconds. It was adjusted to play the tempo score with Rhapsody.

In addition, it is necessary to make the distinction when it comes to Real Time messages. (Not used by Rhapsody). In this case the TxCommands would be transmitted with a Fastclock Timing in ms and we would use MidiStart/Stop

And the centisecond clock is derived from a high speed clock, just like (or maybe the same as) the Fast Clock. ;)

Yes, may be ms will become standard with RISC OS, even for null events? The centisecond was when the processor was at 8MHz…

There’s a relationship, though with Fast Clock you can get better accuracy than is possible with centiseconds.

Rhapsody uses microbeat (see Acorn note above), I don’t think FastClock was available at that time. This is not a problem, but the timestamp with the modules is in ms and continuous, but the microbeat is reset to 0 for each capture. so this must be taken into account. The FastClock swi allows you to restart the Fastclock counting. The result is correct. So if I’m not mistaken it’s FastClock which is in the RxCommand?

@Rick/Peter

Hey, did you notice https://gitlab.riscosopen.org/RiscOS/Sources/Audio/MIDI/MIDIPlay ?

Rool recovered the ESP software, unfortunately with few sources. Recently they made two ESP programs available in /downloads/common/Hardisc4:

!Player et !RealTime (sound effect)

These two programs in Basic have been revised and work very well. To test.

@Peter
I had no problem with my old version, but for clarification, all the ESP software I own date from 2007.

The version of the ESP MIDI Module is 5.0 and should have reached a certain level. I had no trouble testing the ESP version of MidiSupport, I just added your MIDIUSb driver and MTimer module.

I started wanting to build a driver for MidiSupport, but yours works, mine remained in embryonic form…

If I have time I will test the Serial driver with my ARMX6. I found an adapter with a DB15 containing the hardware, it must have been for Windows. I have another expander to run at the same time.

I have a couple of USB to DIN adapters but they are home made and are class compliant but composite devices with streaming audio and midi interfaces. They work fine on Windows streaming 44.1k audio in both directions at the same time as playing Midi files through them

I use a Steinberg UR22MKII USB to DIN conversion no problem and for audio streaming I can record (waw format) the output of the expander while Rhapsody is performing with my ARMX6.

With Colin Granville’s software !Isocplayer, I can listen to it again. I also use !DigitalCd or !ProSound for editing.

Been prepping my next release on this to be done shortly, but in the meantime, anyone know how to get a hold of Peter? You there? I think I’ve found a little bug in MidiSupport while tweaking MidiMon for it.

Specifically, MIDI_InqBufferSize seems to have an off-by-one where it reports 2044 when clear, despite the Rx buffer size being 2048 as standard.

Specifically, there is a line:

r->r[0] = (RXBUFF_SIZE-1 - used) * sizeof(unsigned int); // return number of BYTES free

Where I believe the “-1” is unnecessary and results in it reporting 1 less byte free than actually exists. Correct me if I’m wrong.

Correct me if I’m wrong.

One less word. ;)

Thanks for rummaging, things like this help improve the software for everybody else. 👍

Are you sure that it really is an error? In a circular buffer, either you have a flag to denote the difference between completely full and empty, or you leave one item unfilled.

I haven’t looked at the code, so this is a suggestion to check, not a statement that it is wrong.

Hm, good point Dave. I’ll have to check later. I haven’t ever been right about a single thing in my life, so I’d be surprised if I’d started now.

I haven’t ever been right about a single thing in my life

Well, either that’s right, in which case it’s wrong, or it’s just wrong.

Sorry for flippancy, I’ll get me coat.

Right, I’m awake now, I think.

I believe the “-1” is unnecessary

I get most confused with things like this and usually resort to testing with a buffer size less than ten so I can use my fingers. I thought it did need the -1 for the reason Dave said but I also could be wrong so I will check.

Lauren, if you need to wake me up in the future my email should be in one of the readme files.

Oop, so it is, I thought I looked for that email but I must not have looked very hard.

For what it’s worth, that calculation isn’t used anywhere except the return value of the SWI, so changing it shouldn’t impact anything, but the only reason I was interested was trying to determine if the buffer was full, but that turned out not to be important for my needs anyway.

And now, I get to feel awkward about bumping this thread up, because I’m about to open a new one for the next version…