USB MIDI?

Fantastic news. Don’t forget support for Timidity, if possible :)

would the midi that Rick Murray wrote work at the start of this tread???
I have been looking for 32bit midi support/SynthPlus for a long time even sent a few emails to liquid but never had any replies.

would the midi that Rick Murray wrote work at the start of this tread???

Just so we all know where we stand with this:

Bad news

• Does not return time stamps of received MIDI data (USB works differently so such things would only be accurate to a few centiseconds in any case).¹
• Does not support queuing of multiple timed things to transmit. Commands to be sent are sent immediately, timed ones will return a buffer full error.²
• Depending on what you are doing, SysEx ranges from “probably broken” to “not implemented”.¹
• Doesn’t support multiple USB devices at the same time.²
• Probably a bunch of bugs that !Maestro didn’t show up. ;-)
• There is no MIDI playback option (like in the original module), nor is one planned. Such software these days would want to be more compliant than eight voices and WaveSynth-Beep could manage!³
• Does not work with MidiSupport (that I’m aware of?). Couldn’t find a copy online anywhere to work on making it work. If, however, MidiSupport has a veneer to talk to the standard Acorn MIDI module, it might work?

Now for the good news

• I’m (still) here.
• It is kind of hard to develop when the most sophisticated program you have (!Maestro) only uses one SWI. ;-)
• I’m getting sick of running into things that MuseScore does not want to do. Seriously, the notation editor is like !Maestro, only with lots of bells and whistles. I have no doubt that it is a powerful package, but I suspect it is for people who already know what they want to notate. For people writing as they go along, editing stuff earlier in the timeline is……tedious.
  To give a great example – on my blog on Christmas Day is a stop-motion animation with a rather odd musical soundtrack. Writing the music took longer than doing the animation (including all the editing, processing, and making the end credits sequence), and the result is still depressingly far from what I had in my head.
• So it goes without saying – I really really want to get MelIDI working.

;-)

¹ I’m on holiday next week. If I get any respite from acres of mowing, I may look to see if I can get this stuff working. But note – due to technical limitations, time stamps will only be every x centiseconds (currently 5) and two or three commands may have identical time stamps.

² This is something that I want to do, but it’ll probably be a little later on.

³ just for clarification, all of the SWIs/commands for this and song timing are dummy commands for compatibility. This will not be supported. Accordingly, song control and timing messages are always passed to the RX buffer [though I may change this behaviour depending on how it affects things downstream]

Hi Rick:
What (if any) Hardware, Software and/or documentation would help you?
I suspect there are people willing to donate some or all of what you need.

Hi Chris,

I have a Pi, I have a Yamaha keyboard.

I will just wait patiently until MelIDI is available and then I’ll see how far it gets. Having sources will be a great boon as I ought to be able to look to see what the program is trying to do vs what my module thinks is happening.

There just didn’t seem to be a lot of point on doing a lot of work if I had to write my own test programs. If I have misunderstood how something works, this would not show up in a test because I would make the same error there. It would be better to work with a third-party program, especially one with a proven track record on other machines. Does that make sense?

Let’s put it like this. When I’m alone at work, I sometimes hum to myself. I have an idea that I want to write a “four seasons”, but a personal one. How each season makes me feel. I have thought this for a while, which is why I bought myself a keyboard in early 2013, but as nice as MuseScore looks, I just don’t seem to be getting on with it. I’m a beginner at notation, so it can be difficult to think of something and then convert it to notes and breaks. I suspect the sequencer layout of MelIDI will be better for me.
For this reason, there is a definite incentive to work on making this work.

[not to mention, MIDI stuff is a gaping omission in what we can do with RISC OS on these little ARM boards; if I can make one actual contribution (asides from inane forum postings and attempting to blow up Territory ☺), then it can be MIDI support]

Not sure if it helps (only just seen this thread, but perhaps I should have done a year ago /blush) but we have midi support and, I think, the MIDI Support “PRMs” that ESP produced to go with it in stock, as well as soft-synth. I think I have the 32bit version of SoftSynth, but probably not on the “for sale” discs, as I’m not sure it was ever formally released. I have no clue if this is of any help to anyone at this stage (probably not), but I mention it in case it is.

I also need to test Anthem under aemulor!

Hi Andrew,

I had messed with Aemulor and Anthem a bit..sadly it crashed..but I cannot tell you what my version was, nor what crashed?

It certainly loaded to the iconbar…but this was back in november ~ish.

I was also using the software synth package I have…again can’t remember it’s name, but I think I got it from you.

Kind regards
Michael

Hi Andrew i have been trying to get a copy of the 32 bit version midi support & soft synth can you contact me on email if i can get a copy from you??
Regards
Rob Andrews

Hi Rick, thanks for giving me a kick last September to take this up again!

Regarding your limitations:

• Does not return time stamps of received MIDI data (USB works differently so such things would only be accurate to a few centiseconds in any case).

MelIDI does use this for real-time recording. A (very) few centiseconds is probably acceptable

• Does not support queuing of multiple timed things to transmit. Commands to be sent are sent immediately, timed ones will return a buffer full error.

MelIDI uses either callbacks or 100Hz interrupt to playback. It does not use timed commands

• Depending on what you are doing, SysEx ranges from “probably broken” to “not implemented”.

MelIDI expects to be able to send and receive SysEx, but if you don’t try to use SysEx it probably won’t particular care.

• Doesn’t support multiple USB devices at the same time.

That would be easier with MIDISupport

• There is no MIDI playback option (like in the original module), nor is one planned. Such software these days would want to be more compliant than eight voices and WaveSynth-Beep could manage!

No need to worry about that. The original MIDI module (as on AKA16) mixed up the backend device driver with frontend MIDI SWIs. MIDISupport separates out the frontend (MIDI_RxCommand, etc.) from the bankend hardware while allow routing between the front- and back-end channels. MelIDI (the program) doesn’t use any MIDI_* SWIs. MelIDIUtils (the module that provides the smart bits) comes in two versions: MIDISupport and legacy.

• Does not work with MidiSupport (that I’m aware of?). Couldn’t find a copy online anywhere to work on making it work. If, however, MidiSupport has a veneer to talk to the standard Acorn MIDI module, it might work?

It’s sort of the other way round, MIDISupport comes with a frontend-only MIDI module. I have 32-bit versions of MIDISupport and MIDI, but I need to check on my ability to distribute them.

As an aside, MelIDI used to support sample playback through the 8-bit system (had its own playback module that could load raw samples on-demands as required by a song) as well as using AudioManager (?). I never got my head round SharedSound. The sample code was always commented out when building releases I think, so it would be good to resurrect this stuff. I loved the AudioManager API, but my understanding is that Computer Concepts lost the source, so it was never 32-bitted and also it remained commercial. Is that right?

@ Andrew:

we have midi support […] in stock

Isn’t that supposed to be Chris’ line? ;-)

My keyboard uses the standard MIDI device interface, it was a plug’n’play exercise on the Windows box, and I imagine Linux would be similar. So I set about seeing if I could make it the same with RISC OS.

but I mention it in case it is.

What do you mean by “MIDI support”, exactly?
Can a person connect a USB keyboard to their machine and have it work with your software?
This page → http://www.somascape.org/riscos/midi/msfs.html describes the MIDISupport stuff, and there’s a long list of supported hardware under “Use”, but no mention of USB.
That said – the page says “All MIDI data transfers will be possible via the MIDI Support module, however, full support is also provided for the original Acorn MIDI module Tx and Rx SWIs.” so you may be able to patch in my module. It is designed to try to look and feel just like the Acorn original (only talking to USB devices).
I don’t have MIDISupport (yet?) so it’s all hypothetical.

@ Stephen:

MelIDI does use this for real-time recording. A (very) few centiseconds is probably acceptable

That’s what I figured, so it is something I want to get working. I found an archive with some software for a MIDI device made by “The Serial Port”. No idea what the device is, Google didn’t help as those words aren’t exactly unique (!) and original MIDI is a serial protocol, you can see where this is leading… however it has a simple BASIC record/playback program and some saved tunes that I can use to test these aspects of the module.

It does not use timed commands

;-) Maestro uses QSound’s secret “call a SWI instead” feature. Part of me wonders if that was only added so Maestro would actually work in a co-operative environment on an 8MHz machine. <giggle>

MelIDI expects to be able to send and receive SysEx, but if you don’t try to use SysEx it probably won’t particular care.

I think I’ll need to implement it, it looks as if my keyboard spits out a load of custom stuff when you send it a reset command.

Doesn’t support multiple USB devices at the same time.
That would be easier with MIDISupport

I have an interesting question for all interested parties. Traditionally MIDI has been an all or nothing sort of deal. You either had it, or you did not.
This has changed. There have been small modifications to the MIDI SWIs and behaviour due to the fact that MIDI itself can come and go arbitrarily. I mean, you couldn’t unplug a MIDI podule while the machine was running. You can unplug USB devices, and the device is not only the keyboard but is also the MIDI interface. [my module will keep going, but attempts to read/write will throw up errors with a new error code] I wonder how existing software will cope with this change?

MelIDIUtils (the module that provides the smart bits) comes in two versions: MIDISupport and legacy.

Legacy works with the original-style module?

so it would be good to resurrect this stuff.

This looks interesting: http://sourceforge.net/apps/trac/fluidsynth/wiki/SoundFont
[not fluidsynth, the “SoundFont”]

(apologies for the thread hijack!)

Michael – Did you get my email last month? Please drop me a line!

How bizarre.

I have a simple MIDI player that attempts to play the “2001” theme (not Strauss but sounds like it is). The MIDI dump looks correct, but it appears to leave dangling notes, and for some reason TxAllNotesOff does not work.

[…time passes…]

Okay. The music starts up by defining a voice and setting sustain on:

{ 12, 192, 72, 0 }   ; select voice #72 (clarinet)
{ 11, 176, 64, 127 } ; sustain on
{  9,  90, 48, 64 }  ; note #48 on mid
{  9,  90, 36, 64 }  ; note #36 on mid
{  9,  90, 60, 64 }  ; note #60 on mid
{  9,  90, 60, 0 }   ; note #60 off
{  9,  90, 67, 64 }  ; note #67 on mid
{  9,  90, 67, 0 }   ; note #67 off
{  9,  90, 72, 64 }  ; note #72 on mid
{  9,  90, 72, 0 }   ; note #72 off
{  9,  90, 48, 0 }   ; note #48 off
{  9,  90, 36, 0 }   ; note #36 off

At this point, there should be silence. There isn’t. It seems as if when sustain is switched on for the clarinet voice, the voice does not switch off when instructed, so eventually all the notes pile up on top of each other.
SYS "MIDI_TxAllNotesOff" does not work.
What works is to send this afterwards:

{ 11, 176, 64, 0 } ; sustain off

Surely this cannot be “correct” behaviour?

PS: Discard the first digit and any unnecessary trailing null bytes to convert to old-school MIDI.

You seem to have infinite sustain.

You seem to have infinite sustain.

My first thought. Isn’t there supposed to be a small decay so the level drops slowly?

The origin of sustain was the damper pedal of a piano. Take the dampers off, and the note, once struck, will die away exponentially. We mustn’t confuse sustain with reverberation, for example.

You can’t do that with a clarinet. You can only sustain a note by continuing to blow it. As such, the note doesn’t die away until the player runs out of breath. And there are circular breathing techniques that remove the short term limit imposed by lung capacity.

So I think it’s working correctly.

So I think it’s working correctly.

Including ignoring explicit note off commands¹ and the all-notes-off command?

¹ It seems like one or two notes can be turned off. More (exact conditions currently unknown) and the off will be ignored leading to a sort of clarinet white noise. While sustain with clarinet is “unusual”, this sounds like a bug…

Including ignoring explicit note off commands

What happens when you have a piano’s sustain pedal down and you release the key?

You may wish to consider whether using sustain on a clarinet makes logical sense.

What happens if you use sostenuto (66) instead of sustain (64)?

Is it possible to communicate with a USB device that has no endpoints?

My MIDI device has an audio interface with contains an IN and an OUT endpoint, but I see there is another device listed that appears to an endpoint-less “Control” device, as described here → https://www.riscosopen.org/forum/forums/5/topics/1982#posts-23914

It seems as if AudioControl devices are supposed to have an endpoint of 0 (or be an interrupt device?) but this appears to be neither.

Is there a way of receiving data from this, at all?

The device has an audio control interface (0.0 class 1.1:0) and a midi interface (1.0 class 1.3:0) with a midi in and out endpoint. The listing on your reference doesn’t show the audio control features. You just read from the IN endpoint and write to the OUT endpoint – similar to serial programming.

You just read from the IN endpoint and write to the OUT endpoint – similar to serial programming.

That is what I am doing, however this leads on to the main question. I can write data significantly faster than the generic MIDI serial speed, and these cheap interfaces are barely MIDI compliant, never mind having anything that resembles a useful buffer size.
So how, if I just read and write, will I be able to determine if the buffer has filled up? Is it not possible for the device to signal “hold off for a moment, I’m busy”? By using a ’scope and hammering data to the device, it appears as if it can cope with five Note On events, anything more would result in data loss → http://www.heyrick.co.uk/blog/index.php?diary=20141122

My current method of dealing with this is an ugly (!) delay loop, to waste around 1ms per command. Some day I’ll use the HAL timer, but that will ‘cost’ anything between 1ms and 2ms per command (I’d need to wait for a new ms value, then wait until it changes again to be certain to delay at least 1ms). Some form of signalling would be better. You know, like CTS/RTS on old fashioned serial ports.

I assume you are talking about the buffer on the device. Only automatic handshaking by the device would work – by the time you get the buffer full info you will already have sent more data. If it does handshaking – which I think is doubtful for a real time device – it will use the standard control endpoint.

Surprised that a 32byte endpoint can’t handle more than 16 bytes.

Only automatic handshaking by the device would work

Which it doesn’t appear to do, or if it does, it does in a non-standard sort of way.

Surprised that a 32byte endpoint can’t handle more than 16 bytes.

The internet is full of horror stories of cheap MIDI interfaces. Just because it says it has X bytes doesn’t mean it really does.

Let’s see:

1. Notes getting lost (possibly the same problem as here)
2. Hell to send data to the host computer as some seem to want to prefix any MIDI data received with the &90 byte which messes up reception on the USB end.
3. You’ll crash and burn if you think you’ll get SysEx data through it.
4. Running status? Yeah… right.
5. Latency – expect at least half a second (or more!) between keypress and anything being sent to the host.

And that’s not even discussing the hardware “issues” (eccentric non-compliant wiring, total lack of opto-isolator…).

The important part is hidden beneath one of those black blobs (second picture http://www.heyrick.co.uk/blog/index.php?diary=20141119 ), I wonder if it is some sort of PIC running a serial port at one end and a USB interface at the other, and “just enough” software that it works for playing notes on a keyboard, if not so much else?

ref article:

Range, apparently up to 10km
Depends upon terrain – expect a hundred or so metres in a city, to a long way in the country.

It’s been a few years so it may not be the same model and we had a base station in the mix but Admiral Hardy¹, Greenwich to Docklands Arena (gone, just north of where Crossharbour station is now)

¹ We were stewarding at the GBBF during the build days and nipped out for lunch, OK we nipped out a fair way… 2km :)

A quick google of midi tells me that midi runs at 31.25kb/s. As USB 1 transfers in millisec chunks it has to handle a transfer of 32 bytes (the maxpacket size) doesn’t it? It has to have more than a 16byte buffer.

Have you tried the device on a pc to see if it works?

If you have, have you tried using snoopy on the pc to see how the device is initialised/used – I’m assuming you have no documentation for the device.