Tagged: raspberrypi
Building Keykit on Raspberry Pi
[KeyKit](http://nonsuch.com/keykit/] is an interesting programming environment for midi music, combining graphical and programmatic control. The interface is extensible. Best of all, it was written before 2000, so it doesn't require a beasty machine.
There was no pre-built package for the raspberry pi, so I thought I'd have a go myself. I haven't done much compiling from sources since my early days using Linux.
I'm running the standard Raspbian distro.
Registering at the download site allows downloading the source. I was just interested in the alsa version-- haven't tried the raw midi version at all.
Extracting the zip creates a keykit77b folder, but running make installlinuxalsa fails with different errors. There is a useful readme_linux.txt file, but it didn't solve my immediate problems. Here's what I did to get it working:
- chmod u+x to src/rmcr (this is just making the dos line endings into unix ones)
- byacc (Berkley yacc) is included as a binary under byacc/ -- this won't work, neither will the dos version, obviously.So we need to use a proper version of byacc.
- sudo apt-get install byacc
- cd byacc/
- mv byacc byaccbroken
- ln /usr/bin/byacc byacc
- We also need some missing header files
- sudo apt-get install libasound2-dev
- sudo apt-get install libX11-dev
- Running make will fail because it can't fint ytab.c or ytab.h
- byacc is creating y.tab.c and y.tab.h, so just mv the files
- cd src
- mv y.tab.c y_tab.c
- mv y.tab.h y_tab.h
- first I tried to change the src/makefile to use the right names, but this seems to be recreated after each make attempt, so it's easier to just rename the files, and rerun make
It then compiles successfully-- though it doesn't create files in /usr/local/bin like the documentation says, the files are created in key77b/bin. The program runs under x, so startx if it's not running already.
The key77b/doc file has tutorials, as well as other documentation-- the multiport one was useful.
Initially I the program was seg faulting whenever i tried to get some sound. This turns out to have been an issue with my midi port setup. This is probably properly handled by creating a keylocal.k file but I haven't got that far yet. Adding the Port Enabler tool to the window, and using it to enable midi input and output prevented further segmentation faults.
To actually get midi doing something required I use the alsa tools to map keykit's ports to the system's midi ports.
I had an old Edirol UM-1 USB-midi cable which I plugged into the usb hub connected to the pi. With keykit running and the midi ports enabled, from a console command line
aconnect -i
lists the midi inputs
aconnect -o
lists the midi outputs
Both the UM-1 and keykit showed up, with a major/minor number.
aconnect 128:1 20:0
connects the midi in on keykit to the midi out of the UM-1. At this point I could connect my iphone (through yet another midi interface) and run Midi Monitor and see events generated by keykit's Mouse Matrix tool. Running BS-16i on the iphone let me hear stuff. BS-16i has a General Midi soundfont; very handy.
Using aplay midifile from the console was very handy getting this working.
aplaymidi -p20:0 filename
Once that was working, I connected the midi cable from the UM-1's output to my MeeBlip synthesiser, switched it to receive on channel 1, and spent a fun few hours playing with keykit.
Keykit's documents say it only works for external midi; but I imagine since they were written, the state of soft synths has advanced considerably; since the connection is handled by alsa, I don't see why it won't work.
Resources
- At the Sounding Edge: Introducing KeyKit is a Linux Journal article from 2005
Tags: raspberrypi, synth
Date created: 2013-04-28
My O/S boots instantly
...but it just turns an LED on.
I've spent a few hours this afternoon on Baking Pi excercise OK1 for the Raspberry Pi.
The OK1 exercise results in an SD card with your own 'operating system' on it. In this case, it just turns on the OK LED on the rpi board, then goes into a busy loop.
The program is tiny (ignoring all the lines preceded by semicolons, they're just my comments):
.section .init
.globl _start
_start:
ldr r0,=0x20200000
;loads r0 with base address for GPIO
;GPIO has 52 pins only a few are avaialbe to us
;each pin gets 3 bits to determine what its doing
;so each group of 10 needs 30bits, or 4 bytes
;GPIO register is 6*4-24bytes total
mov r1,#1
lsl r1,#18
;load r1 with 1<<18,
;the address for the function select for pin 16
;(bits 18-20 of this bank of 10)
;the data here is 001, which sets the pin for output
;(000 is input, other values mean other things)
;unclear to me if loading this value affects the other pins?
;are we setting all other pins in this bank to input?
str r1,[r0,#4]
;put r1 into address r0+4,
;addressing the 2nd group of 10 GPIO pins
;pin 16 now ready for output
mov r1,#1
lsl r1,#16
;indicate which pin we're addressing, pin 16
;so this is a bitfield? can control many pins at once?
str r1,[r0,#40]
;r0+40 is address for turn pin (the data given) off,
loop$:
b loop$ ;loop forever
His instructions are clear; setting up the mac with the gnu toolchain was quick, and using his template file to create the assembler main.s was straightforward. All that could be done in about 15mins; the other hours I've spent are in trying to understand what's happening, flipping over the reference manual, following up on Wikipedia.
Most of that time was spent trying to work out what's going on with the GPIO register; the base address, the offset to target the relevant pin (the one wired to the OK led), the data that gets put into the offset to set it to output mode, then sending the index of the pin to the address for setting pins off (thereby turning the LED on).
There's a bit of jumping around between decimal and hex and binary, which is confusing. And because we're dealing with the CPU, the distinction between address and data is not completely clear. That is, the data in this register is the address for that operation, and populating that address with this data actually does something-- changes a pin state, lights an LED.
It's so easy to learn things as needed now -- when I was first learning about computers in the 70s, it was pretty impossible.
Some interesting things:
- kernel.img is 32 bytes
- the rpi needs a fat32 sd card with 4 files
- start.elf (which is the GPU image, a 2Mb binary blob)
- bootcode.bin, the 2nd stage bootloader
- kernel.img, the program that gets run
- config.txt, for options passed to kernel.img
- kernel.list and kernel.map generated by the compiler show your program and how it's laid out in memory
I remember reading about the MITS Altair and the IMSAI 8080 in Popular Electronics in the mid 70s.
They were the first hobbyist computers, programmed by flicking switches on the front panel. No long term storage, tiny memory, and I/O limited to buttons and LEDs. From this limited start people would interface with keyboards and screens, write drivers for paper tape or cassette storage, and the basic assemblers and editors to increase capability enough to do the next round of pulling themselves up by their bootstraps.
The rpi is a completely different beast of course, with built in USB, HDMI, Ethernet-- many layers of complexity on top of the core CPU; none of which I have a clue how to access. Yet.
Now to make the LED blink.
Tags: raspberrypi
