USB MIDI?

I put up a fresh version of my program on my web site. It now copes with sharps, pauses and different octaves.

A simple string such as ‘cdefgab’ will play those notes. o followed by a number will change the octave. # followed by any note except b+e will play the note sharpened. – will give a pause.

The timings are not great yet, but this version plays a recognisable version of the folk tune Wild Mountain Thyme (Will ye go lassie go).

http://www.lodelane.co.uk/files/playnotes.zip

EDIT: missed out ’files/ from URL. Sorry

It now copes with sharps, pauses and different octaves.

Nice.

The timings are not great yet

You can either work out the BPM you want, and know there are 60 seconds in a minute and 100 system ticks per second…

…or you can “fiddle” until it sounds right. I prefer the latter approach. ;-)

USB transfer failed: IO Error

I started to get this when I was working on my PTP application. It wouldn’t happen consistently, though.

If it helps, EXT#i% returns zero regardless of whether or not any keys have been played. Not that that matters, the keyboard ought to be spitting Active Sense a couple of times per second, so there ought to be data…

That’s what I was talking about further up the thread. Bulk IN transfers have to be requested specifically, unlike interrupt IN transfers which are scheduled automatically. MIDI is bulk. (And if you think the original designers of the USB MIDI spec made a mistake there: I agree with you.) Please take in what that means. You won’t find bytes magically put in the buffer for you; you will have to request a transfer by OS_GBPB.

I have also seen, by using a hardware USB analyser, bulk IN transfers that took place on the USB, but the incoming data were not seen by the RISC OS USB stack. That’s why I stopped work on Bluetooth.

Hi all!

Interesting foray, this. With John looking for his Atari, Rebecca doing the programming thing, and a viable way to get RISC OS and a keyboard talking (if only properly on a Pi at the moment?), I think we can say this idea was mostly successful.
I await the time when Rebecca realises that opening the other endpoint and reading in 4 bytes at a time will show her keyboard spitting lots of data – and if she parses the first byte [hint – blk%?0 will be a 9 for note on; and velocity (blk%?3) will be a zero for note off] to discard all the sensing/status rubbish, she could write a program to record what she plays, and play it back. If she associates each note recorded with a relative time (ie elapsed time since start of recording), playback will be exactly as it was recorded…

As for me; I do not, at this time, plan to do any further work with MIDI. It was more a “can this be done?” weekend project that spun out of control. I might poke around s’more if the quirks are tracked down – John’s 512Mb Pi and the lack of input data on a Beagle xM.

But, fret not! I’ve left you all a little present to enjoy.

It is a hacked version of !Maestro that will play to a MIDI device. Source for the !Maestro application (with the modifications) and the MIDIhack module (uses SWI chunk &16F00 – not registered!) are provided. Feel free to mess with it. Maestro is Castle/ROOL standard licence. MIDIhack will be EUPL but I’ve not bothered with the preamble as it would double the size of the code!
Before anybody asks why on earth I’ve written a module to write bytes to a file, look at Maestro and how it uses Sound_QScheduled – it’s quite clever (I didn’t know RISC OS could do that).
This version of !Maestro uses the device scanning code from miditest so it should auto-detect your keyboard/device. If not, it should start up as a normal non-MIDI version of Maestro.

maestrohack.zip (122K)

For a quick look, or for those without MIDI equipment, here’s a video of it in action. Note, however, that the sound is very low. Mom was listening to the radio in the next room, and the eeePC was on top of the speaker. Oh, and yes, I don’t like bright light… ;-)

youtube:EJ9qUXx6NCQ

One final thing to say: The Fanfare example sounds especially nice. I will leave that for you to discover for yourselves…

Please take in what that means. You won’t find bytes magically put in the buffer for you; you will have to request a transfer by OS_GBPB.

Which leads to the obvious four questions:

• How do I request a transfer. If you mean like OS_GBPB 4, fh%, buf%, 4 ¹ then that fails in exactly the same way.
• If the data is not in the DeviceFS buffer, where is it? The very nature of MIDI means you can’t rely upon there being any data at all.
• Specifying “interrupt” when opening the file handle makes no difference.

But most of all:

• Why does it work as logically expected (zero bytes aside) on the Pi? Isn’t it the same USB stack (with minor difference in the HAL part for differing hardware) talking to the same DeviceFS? Either the HAL implementation is very different (in behaviour too), or something bizarre is going on here.

¹ from memory so might have my parameters mixed up

Hi Rick,

That Maestro hack is really cool. I like your suggestion about recording / playback. I am going to continue to play with the Midi stuff- I had been looking for a project. Hopefully I’ll have fun, learn something and maybe even produce something useful! I won’t be doing much until the weekend though, got three night shifts then four off :)

Of course, I could always take the Midi specs on my laptop.

Cheers.

Hi Rebecca.

I’m getting a 404 when I try to download your updated file. Have you moved it by chance?

Rebecca,

I have three nights next week (two days 10am→5.45pm then three 9pm→4.30am). Yuck. But I’m covering for somebody. Afterwards, thanks to time owing, I have three weeks off! Yay! I plan to do as little as possible. ;-)

I’m glad you like the Maestro hack. I might remake the video for my blog with the Fanfare – oh, and crank the sound up a bit! I’ll be happy to help you if I can, assuming others don’t reply first, that is.

Having fun is the main point, isn’t it? I’m sure you can imagine the size of the smile on my face when I clicked “Play” in Maestro and the keyboard began playing. Oh yes. Like a Cheshire.

There is no official released MIDI spec (you have to ‘buy’ it) though there are some useful references online. Here’s a detailed guide to plain MIDI:
http://home.roadrunner.com/~jgglatt/tech/midispec.htm

Description/reference to General Midi level 1:
http://www.jososoft.dk/yamaha/pdf/gmlev1.pdf

What your keyboard transmits/understands is described (very briefly!) here:
http://download.yamaha.com/api/asset/file/?language=en&site=my.yamaha.com&asset_id=46415

The USBMIDI spec fills in the blanks between the USB side and the pure MIDI:
http://www.usb.org/developers/devclass_docs/midi10.pdf

Good luck!

Specifying “interrupt” when opening the file handle makes no difference.

The device’s endpoint is bulk. You shouldn’t be able to open it as interrupt at all – the attempt ought to generate an error. I know it doesn’t, but you’re trying to do something that is fundamentally wrong, so, as to how it will behave: you’re on your own.

You don’t get to choose the type of an endpoint. That’s baked into the device.

Bulk IN transfers have to be requested specifically, unlike interrupt IN transfers which are scheduled automatically. MIDI is bulk. (And if you think the original designers of the USB MIDI spec made a mistake there: I agree with you.)

This article appears to support that point of view:

http://www.rme-audio.de/english/techinfo/lola_usbkills.htm

“Instead of the bulk transfer mode the interrupt transfer mode seems to be more suitable for MIDI interfaces. Although there is no support for high data rates (nevertheless fully sufficient for MIDI), it offers better timing control of the data transfer (whereas the bulk transfer mode is specified for data which are ‘not time critical’….) Using this mode no problem occurred anymore.”

I know it doesn’t, but you’re trying to do something that is fundamentally wrong,

Opening it and letting the device/stack use defaults does not work. Opening it as interrupt does not work. Using OS_GBPB 4 does not work. I can send data to the output endpoint on Pi and Beagle. Attempting to read anything from the input endpoint on the Beagle does not work. The only thing I can surmise is that the USB driver Beagle is either fundamentally broken ¹ with respect to systems like MIDI, or the Pi implementation is sufficiently lackadaisical that it actually works.
At any rate, I’ll look forward to trying David’s USB to see if that can do the job…

¹ I feel I can look at RISC OS here as the spec wouldn’t have got off the ground if it “didn’t work” on all the other platforms! There must be some point where the hardware says to RISC OS “hey, there’s some data here”, right?

There must be some point where the hardware says to RISC OS “hey, there’s some data here”, right?

For bulk IN endpoints, that point is when the application programme has asked for some.

When the stream model was adopted for RISC OS, the only devices supported were keyboards and mice (interrupt transfers, i.. the OS schedules them automatically) and mass storage. A stream model suits mass storage very well. There cannot be any data on offer except those you’ve asked for – you know exactly how many, and it’s a causal system.

If you don’t know how many bytes are coming in – and that number may be zero for long periods of time – a blocking and/or padded stream model is a programmer’s nightmare.

For bulk IN endpoints, that point is when the application programme has asked for some.

Is this how RISC OS works, or how USB works? I really can’t see the point of an interface with irregular externally-sourced input being set up as a “request some data” model. That seems akin to ringing the doorbell without bothering to look to see if the lights are on…

padded stream model is a programmer’s nightmare.

Thinking about it, it would seem that this is the difference between the Pi and the Beagle. It looks like the Beagle does not work as a stream with padded null bytes. [since OS_GBPB fails on read, it looks like it may be broken?]

Question is – is this a conscious decision made in the HAL and can it be altered, or is this something to do with the hardware?

since OS_GBPB fails on read, it looks like it may be broken?

I use OS_GBPB to read bulk IN for my Bluetooth experimental app. It works on the RPi.

I don’t know what this means; whether you’ve got an error in your code, or whether there is an inconsistency in what happens when RISC OS runs.

I use OS_GBPB to read bulk IN for my Bluetooth experimental app. It works on the RPi.

(my highlight)

That is exactly what I am saying. Reading (BGET or GBPB) works on the Pi but does not work on the Beagle.

I wasted time last night looking at the USB source to see if I could spot any differences. I gave up as the code is so different it’s like comparing a Datsun with a Ferrari. Both are cars, but…..

I have a ghost of an idea in my head. Something to look at tonight. Won’t fix it, but might give a pointer.

Reading (BGET or GBPB) works on the Pi but does not work on the Beagle.

Sorry, I missed that.

I’ve used OS_GBPB to read bulk IN on the BeagleBoard and Iyonix in my PTP app. It works in some cases, but not others. Worst of all, it appears to be inconsistent. It hasn’t worked for Bluetooth, although there’s only one message involved – there pretty much has to be a sequence of commands and responses, so it’s difficult to get over that hurdle.

Clearly USB bulk IN must work at some level on the BB; that’s how mass storage communicates. That indicates not merely that it works, but that it works reliably.

I’ve remarked before that I wonder if there’s a difference calling from application space or user mode as against calling from system space or system mode.

It works in some cases, but not others.

I give up with USBMIDI on the Beagle. I tried a variety of things, and it just didn’t want to work. But I re-recorded the keyboard-playing-from-Maestro; that worked without a hitch. <shrug>

I guess for the Beagle, I’ll just wait ’til DavidS stuff is ready.

Oh, and for what it is worth:

You shouldn’t be able to open it as interrupt at all – the attempt ought to generate an error. I know it doesn’t, but you’re trying to do something that is fundamentally wrong, so, as to how it will behave: you’re on your own.

Not 100% correct. “Interrupt” mode is a misnomer, it is really “polled” mode; and some lesser USBMIDI devices are Low Speed Bulk devices, which is an “illegal” combination in the USB spec. A version of Linux for some sort of AVR device worked around this problem by ignoring what the endpoint says and treating all Bulk Low Speed devices as interrupt/polled.

Maybe the guys who wrote the USBMIDI spec got confused by the stupidity of referring to that polled mode of USB as “interrupt”? Certainly, it is nothing like I expected going by the name. So instead they chose a mode where data must be transferred in complete packets (ie n bytes at a time on a system where not a lot of data is to be transfered and this not-much data ought to be transferred fairly concurrently with activity as plain MIDI doesn’t support advance scheduling), plus you should request data you are expecting (which is useless when you don’t know how much data there is) and it’s a mode that older low speed devices just cannot validly support (although a number appear to). In other words, I think we need a slow hand clap for USBMIDI! Yay.

Updated to have better sound and be playing Fanfare. Recorded with a Sony Xperia U mobile phone, audio tweaked with Nero WaveEditor. Available in HD for those with fancy hardware.

Regarding MIDI stuff on the Raspberry Pi, someone has found shortcomings with USBMidi on another platform.
http://raspberrypisynthesizer.blogspot.co.nz/2012/10/the-problem-with-usb-midi.html
But I think of more importance is the simple MIDI hardware interface possible using the serial port because of the speed being programmable.
http://www.siliconstuff.com/2012/08/serial-port-midi-on-raspberry-pi.html

Hopefully this can be done using the RISC OS HAL (or whatever) one day.

Having been lurking on this post for a while; I figured I’d give this a whirl with my Electone – in a word, awesome

http://youtu.be/f3BNw5CYwm0

EGAD! – Apologies, its rather loud. Turn the volume down if you don’t want to shake the neighbourhood with it.

If you want to hear more, add comments to the video and I’ll record a few more…

Yup, that’s pretty awesome. The loudness just makes it more so, it is almost like the intro to a gothic rock power ballad played like that.
What instrumentation are you using? It isn’t a straight piano, it sounds a little too harsh (harpsichord?) along with what sounds like string backing. I think my Yamaha can do stuff like that, but I’ve not really played with those settings much.

But… wow… let me just back up and listen to that again!

@Rick
I dont have USBMidi, but in the past I have sent a midi file to a sound module with a serial connection using the Devices string for serial.
I am wondering if there is much in your code that would stop in%=Devices# (or out%)
from working?
This is for Iyonix that has serial port support, rather than Raspberry Pi.
I almost bought a cheap usb>midi adapter, but one report says they are dodgy, and it wouldn’t
help to bring weird problems. OTOH they are only $7.
cheers

@Rick
I had the top stave played in the upper with piano, strings and a Violin for a lead.
I had the bottom stave played by the lower and pedals with piano and a organ bass, set quite low on those.
The ShostF7 demo really shows the channel splits and sounds like a piano with orchestral accompaniment.
I’m glad you liked the arrangement :)

Craig

Sorry John, I botched the URL. The file is at:

http://www.lodelane.co.uk/files/playnotes.zip

I had not looked since Tuesday..

It isn’t a straight piano, it sounds a little too harsh

I imagine Maestro is belting out all the notes at 127 velocity, no?