USB MIDI?
Rebecca (1663) 107 posts |
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 |
Rick Murray (539) 13872 posts |
Nice.
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. ;-) |
Dave Higton (1515) 3555 posts |
I started to get this when I was working on my PTP application. It wouldn’t happen consistently, though.
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. |
Rick Murray (539) 13872 posts |
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. 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 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… ;-) One final thing to say: The Fanfare example sounds especially nice. I will leave that for you to discover for yourselves… |
Rick Murray (539) 13872 posts |
Which leads to the obvious four questions:
But most of all:
1 from memory so might have my parameters mixed up |
Rebecca (1663) 107 posts |
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. |
john evans (1898) 63 posts |
Hi Rebecca. I’m getting a 404 when I try to download your updated file. Have you moved it by chance? |
Rick Murray (539) 13872 posts |
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: Description/reference to General Midi level 1: What your keyboard transmits/understands is described (very briefly!) here: The USBMIDI spec fills in the blanks between the USB side and the pure MIDI: Good luck! |
Dave Higton (1515) 3555 posts |
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. |
john evans (1898) 63 posts |
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.” |
Rick Murray (539) 13872 posts |
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 1 with respect to systems like MIDI, or the Pi implementation is sufficiently lackadaisical that it actually works. 1 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? |
Dave Higton (1515) 3555 posts |
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. |
Rick Murray (539) 13872 posts |
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…
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? |
Dave Higton (1515) 3555 posts |
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. |
Rick Murray (539) 13872 posts |
(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. |
Dave Higton (1515) 3555 posts |
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. |
Rick Murray (539) 13872 posts |
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:
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. |
Rick Murray (539) 13872 posts |
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. |
Ronald May (387) 407 posts |
Regarding MIDI stuff on the Raspberry Pi, someone has found shortcomings with USBMidi on another platform. Hopefully this can be done using the RISC OS HAL (or whatever) one day. |
Craig Lynch (1859) 33 posts |
Having been lurking on this post for a while; I figured I’d give this a whirl with my Electone – in a word, awesome 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… |
Rick Murray (539) 13872 posts |
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. But… wow… let me just back up and listen to that again! |
Ronald May (387) 407 posts |
@Rick |
Craig Lynch (1859) 33 posts |
@Rick Craig |
Rebecca (1663) 107 posts |
Sorry John, I botched the URL. The file is at: http://www.lodelane.co.uk/files/playnotes.zip I had not looked since Tuesday.. |
nemo (145) 2579 posts |
I imagine Maestro is belting out all the notes at 127 velocity, no? |