MIDI on RISC OS/BeagleBoard?
Terje Slettebø (285) 275 posts |
Hi all. Following my question about printing on the BeagleBoard, does anybody have any experience with using MIDI on RISC OS (or knows about anybody who has)? I know that there’s been add-on MIDI boards for earlier Acorn models, such as RiscPC, which they have been working to update to work for the Iyonix, which is one option for those models. Another option, for any model with USB support is a USB to MIDI adapter. I’ve got a synth, and I’ve got such an adapter (with driver software only for Windows, of course), and I’d liked to be able to use it for the BeagleBoard… :) I would be prepared to write the driver software, myself, should that be needed. In that case, I guess studying the USB stack would be one obvious way forward with that? In that case, does anyone got a pointer to the most relevant documentation? It seems the forum search doesn’t work, or only works sometimes, as searching for “USB” gives no hits… Also, doing a site search didn’t give any obvious hits, either. Regards, Terje |
James Peacock (318) 129 posts |
There is some background and documentation on MIDI in RISC OS here: http://www.somascape.org/ |
Terje Slettebø (285) 275 posts |
Thanks, James. Yes, there’s quite a lot of information, there, and I’ve come across that page earlier, too. Also, I’ve spent several hours now reading about and testing various sound software, and I haven’t found a single sequencer application that is BeagleBoard compatible, for one thing (and possibly not Iyonix compatible), so the currently existing software and information could need some updating… The source code for StudioSound is available, so that might be possible to update to be 32-bit compatible. What I’ve found of MIDI software, for example MIDISupport, all of it seems to be based on working with MIDI expansion cards, not USB MIDI interfaces. |
James Peacock (318) 129 posts |
It looks like the idea would be to create a MIDISupport driver which talks USB instead of talking to a podule or whatever. There is a specification here. I guess you would have to talk with the current owners whoever they are. |
Terje Slettebø (285) 275 posts |
Yes, that’s what I’ve come to, as well… There was a connection to this with my “Understanding the RISC OS architecture” posting, as well: In order to write such a driver, I would first need to learn how it all fits together, and with your generous help, I’ve got a pretty clear picture about it – for the very first time! I’ve had RISC OS computers since the first Archimedes appeared, the Archimedes 310 (and before that, my involvement with Acorn goes all the way back to the BBC Micro), but up until now, I’ve mostly been concerned about application programming. However, I’ve always been interested in learning how things work, especially for a well-designed system like RISC OS (I’ve never had the same attraction to going deep into Windows or Linux), and in particular with the opening of the RISC OS source, where you can really get to the bottom of things… Additionally, it gives a joy to be able to help oneself… I’ve got several USB devices that I’d liked to be able to use with a RISC OS-based system:
With your generous help in helping me understand the RISC OS hardware interface, I now understand roughly how the existing hardware gets interfaced with RISC OS, as well as at where in the system functionality for new devices could go. I realise now that all of these three should be possible to treat in the same way: Making a USB driver for each, which works with USBDriver, possibly registering itself as a device driver with its DeviceFS interface. |
Dave Higton (281) 668 posts |
I’ve got a graphics tablet too (Nisis). I wrote an application driver for it in BASIC, but of course that’s of little use – if any application single-tasks, the pointer ceases to move. How does one write a USB driver that runs in the background under interrupts? |
James Peacock (318) 129 posts |
If you need it to be that low level, then EtherUSB’s method is probably worth a look: find the DeviceFS buffers and talk to those rather than using the standard IO SWIs. For each pipe, enable UpCalls on the buffers to detect buffers filling and emptying. Call the USB device directly to initiate reads. Use the BufferManager’s service routine to read and write data to the pipes. I’m currently updating EtherUSB to try and improve its performance and hopefully to remove some hacks which shouldn’t be necessary after recent additions to the USB API. There is stuff in there which needs improvement, but it demonstrates the general idea. |
Terje Slettebø (285) 275 posts |
I just wanted to add that today, I tested my Wacom CTE-640 A5 graphics tablet, and to my delight, it worked out of the box. :) Is there code in RISC OS for general “pointing devices” like this, or might it be that it simply behaves like a mouse to the operating system? Naturally, there are features, like pressure sensitivity and extra buttons, that doesn’t work, not at least because there’s no API for this in RISC OS (that I know of), but as a mouse replacement, it works perfectly… :) I’ve tested it in a variety of applications, including ProArtisan 24, ArtWorks and Photodesk. Finally, would-be artists aren’t confined to using Painter on a PC… :) I’ve updated the hardware compatibility page with this. |
Wouter Rademaker (458) 197 posts |
|
Trevor Johnson (329) 1645 posts |
This Audio code on Beagleboard |
Terje Slettebø (285) 275 posts |
Hi Trevor. Thanks for the link. Using the BeagleBoard to create a synth sounds like an interesting project… :) |
Andrew Rawnsley (492) 1445 posts |
Cough, erm, I think it is actually us (R-Comp). Well, technically it was ESP (Andy Pierson) who we worked with a fair bit (eg. PC Sound Pro), and sold his various MIDI products etc. We still have stock of many. However, I think MIDI stuff should be open, not closed, so if anyone would find any of the documentation helpful, please let me know. There was a big guide on using MidiSupport, SharedSound and MIDI in general that was produced around 1998 IIRC. |
Trevor Johnson (329) 1645 posts |
Hi Terje. Yes, indeed. You don’t happen to play the trumpet, do you? Off topic: I wonder whether the 2012 Wakefield show and ACCU conference will have compatible dates in 2012. This could be useful for overseas C programmers with an interest in RISC OS, such as yourself! Cheers :-) |
Terje Slettebø (285) 275 posts |
Ha-ha, no, but I have a synth at home that I’ve been meaning to learn to play… :)
Well, that should be easy enough to find out… :) The ACCU conference is at April 25-28, 2012. The 2012 Wakefield Show is, uhm, not yet scheduled, it seems. :) |
Nat Fowler (1676) 6 posts |
Hi, I’m resurrecting this thread to know if you ever got a usb-to-midi box working with RISC OS? |
Rick Murray (539) 13840 posts |
Any pointers to where I might find this? |
Steve Pampling (1551) 8170 posts |
It’s not this is it: |
nemo (145) 2546 posts |
BTW I found my Acorn MIDI podule manual (which refers at length to Arthur, to place it in context). It documents the MIDI module SWIs. I didn’t dig out the podule itself as I now recall it worked in an A5000 but not in a RiscPC (and the manual should have been the clue). But I can do some digging if you still need it. |
Rick Murray (539) 13840 posts |
Steve: I think so, thanks for the link.
I have a copy from ChrisWhy – I think it is late enough to talk about RISC OS instead of Arthur, but it’s still ages old. It is enough to get started with, though.
You might have the original version of the firmware – does your guide cover SWI MIDI_FastClock?
Wasn’t the MIDI podule massive? I never played with the user I/O (mine doesn’t have MIDI onboard) on the RiscPC because it wouldn’t physically fit. I did, however, have some fun installing it into my A5000 and running the HCR EPROM programmer ROM within !65Host to talk to the 1MHz bus. Sadly it was still ridiculously slow, not at programming (that was quite fast) but at loading and saving. It was like it used some horribly slow code to byte-get/byte-put and actually took longer to do that than to burn the EPROM! If the podule fit, maybe there was some interrupt code or somesuch that was incompatible; those bits changed in RISC OS 3.5 (re. OS_ClaimProcessorVector etc).
I sent a mail to Liquid Silicon via their form. No reply as yet. It looks like MelIDI might be “dead”? Let’s put it like this – if you happen to be rummaging in the same box in the attic that your podule is in and you have enough time/inclination to extract the module, then go for it. Otherwise, no worries… |
Steve Pampling (1551) 8170 posts |
Oh, |