Midi Baud Rate (31250)

[SiriusHardware]

Could we have the Baud rate 31250 added to the serial baud rates already supported by the serial port on the Pi? This would allow MIDI input / output with the addition of a simple opto input / led driver output interface.

Unless I'm out of date I understand that this can only currently be done by including a microcontroller in the interface as a gear-shifter (baud rate converter).

[dom]

I do have a kernel patch that allows arbitrary baud rates - are you able to build your own kernel?

[SiriusHardware]

I do have a kernel patch that allows arbitrary baud rates - are you able to build your own kernel?

No, sadly not, but it would be more generally useful anyway (and an extra string to the Pi's bow, if you'll excuse the clumsy musical analogy) if MIDI baud rate (as a standard selectable rate) were to be included in the standard Pi kernel at some point.

[W. H. Heydt]

Just a couple of quick questions...

Is the midi data rate baud, or bits per second? (They're NOT the same.)

Is the fix to permit arbitrary baud rates or arbitrary bits/sec rate? Isn't the baud rate determined by the actual data comms circuitry, not the sending (or receiving) logical device?

[SiriusHardware]

Just a couple of quick questions...

Is the midi data rate baud, or bits per second? (They're NOT the same.)

Is the fix to permit arbitrary baud rates or arbitrary bits/sec rate? Isn't the baud rate determined by the actual data comms circuitry, not the sending (or receiving) logical device?

From "The Advanced MidI User's Guide" by R.A. Penfold, 1991: 31250 baud. The format is 1 start bit, 8 data, no parity, 1 stop bit.

31250 is a FIXED rate used by the MIDI interface on electronic musical instruments equipped with 'legacy' 5-pin DIN MIDI in/out connections. As to why such an odd speed was chosen, I guess it was because it can be generated exactly by either standalone or built -in microprocessor UARTS when using a crystal with a 'round numbered' frequency, (such as 6.00MHz or 12.00MHz with an 8051-family device for example). Whatever the reason, MIDI devices don't have a choice of data speeds like other serial comms devices do:

MIDI devices can not therefore be set to use a rate that the Pi already has. That is why I have requested that this rate be added to those selectable on / supported by the pi. Dom's patch is not the ideal solution unless of course it becomes standard at some point because any software written to use it can only run on another machine so patched - this is unlikely to encourage the creation / spreading of MIDI software for the pi. Adding MIDI's peculiar baud rate to the standard set on the pi would be a huge step forward in this respect, especially when the hardware side of a MIDI interface is so easy and cheap to make.

The actual (physical) aspects of the comms are as follows:

On the transmit side, the logic-level output from the transmitting device's UART goes to (typically) an open-collector transistor driver, the other side of the output being a resistor-limited power feed from +Ve in the sending device.

On the receive side, an opto-coupler takes in the open-collector drive from the remote device and converts it back to logic level for the input of the UART.

This scheme ensures that the only 'connection' between the two devices is via the light beams inside the optos at each receiving end of the link, and eliminates hum-loops which might arise if there were two separate ground connections between the two items of equipment (one for the audio, and one for the comms data).

HTH

[mahjongg]

I concur, having the MIDI baudrate as a standard setting would be very nice.
The hardware interface is relatively simple to implement, just a few standard optocouplers and some resistors, and a DIN-connector is all.

[plugwash]

Is the midi data rate baud, or bits per second? (They're NOT the same.)

In general communication systems there are three rates to consider.

The baud rate (symbol rate).
The raw bit rate.
The maximum achievable data bit rate.
The actual data rate.

On a simple serial interface the baud rate and the raw bit rate are the same since there is one bit per symbol. The maximum achievable data bit rate is a bit lower because not all bits are data bits. Standard async serial has at least 10 raw bits for every 8 data bits. Further since the link has an idle state the actual data rate may be lower than the maximum acheivable data rate.

Isn't the baud rate determined by the actual data comms circuitry, not the sending (or receiving) logical device?

The baud rate is determined by the clock fed into the serial perhiperal and sometimes other configuration settings of the perhipheral (for example the PICs have a high baud rate setting which allows higher baud rates at the cost of reducing the synchronisation accuracy).

No system i'm aware of can give truly arbitrary baud rates since the multipliers and dividers have a limited selection of ratios. However many allow a far greater range of rates than the conventional PC rates. Furthermore because things are resynchronised every byte the baud rate settings don't have to match exactly, they just have to be close enough that things don't drift out of sync by the end of a byte. In general being within 1% of the nominal baud rate is more than good enough. Therefore if enough points are available the range of nominal bitrates that can be supported becomes effectively continuous.

[mahjongg]

We are talking about a UART setting here, I am aware that baud (signals per seconds) do not always correspond to bits per second, (modems and other communication systems often send several bits per baud) and that a asynchronous connection can have various settings that affect the effective bit rate, but MIDI prescribes the number of start and stop bits etc, and any UART (certainly the one in the PI) sends one bit per baud. So this was actually a quite simple question. No different than asking if 300, 1200, or 4800 baud is possible.

You are right that the baudrate/bitrate doesn't have to be exact, in fact theoretically even a fault of about 3% can still work under otherwise ideal conditions.

[dom]

Could we have the Baud rate 31250 added to the serial baud rates already supported by the serial port on the Pi? This would allow MIDI input / output with the addition of a simple opto input / led driver output interface.

Unless I'm out of date I understand that this can only currently be done by including a microcontroller in the interface as a gear-shifter (baud rate converter).

There is an ugly hack that will probably work.
Get the UART talking at whatever rate it supports (e.g. 38400). The input to the UART is a 3MHz clock. You can vary that clock with the config.txt parameter init_uart_clock.

So, you want to make that 3MHz x 31250 / 38400.

So add to config.txt
init_uart_clock=2441406

and it might do what you want.

[SiriusHardware]

Could we have the Baud rate 31250 added to the serial baud rates already supported by the serial port on the Pi? This would allow MIDI input / output with the addition of a simple opto input / led driver output interface.

Unless I'm out of date I understand that this can only currently be done by including a microcontroller in the interface as a gear-shifter (baud rate converter).

There is an ugly hack that will probably work.
Get the UART talking at whatever rate it supports (e.g. 38400). The input to the UART is a 3MHz clock. You can vary that clock with the config.txt parameter init_uart_clock.

So, you want to make that 3MHz x 31250 / 38400.

So add to config.txt
init_uart_clock=2441406

and it might do what you want.

OK Dom, that sounds somewhat less drastic than having to rebuild the Kernel - I'll knock up the transmitter half of a midi interface and see if I can use Python / Pyserial plus your suggested Bodge to get one of my synths to play a drum track or something - that would be nice from a personal point of view.

However, the original request for official support for 31250 as a supported serial port baudrate still stands, so that every PI produced becomes a potential MIDI machine straight out of the box.

[theandfire]

However, the original request for official support for 31250 as a supported serial port baudrate still stands, so that every PI produced becomes a potential MIDI machine straight out of the box.

+1

[novoline]

+1

[neophytte]

However, the original request for official support for 31250 as a supported serial port baudrate still stands, so that every PI produced becomes a potential MIDI machine straight out of the box.

I'd like to add my vote for this too ...

Cheers

Richard

[David Else]

However, the original request for official support for 31250 as a supported serial port baudrate still stands, so that every PI produced becomes a potential MIDI machine straight out of the box.

YES please! +1

[Bradoshea]

I do have a kernel patch that allows arbitrary baud rates - are you able to build your own kernel?

Hi dom,

Are you still offering the kernel patch? I need to be able to set the baud rate to 1920.

Thanks!

Brad

[SiriusHardware]

I do have a kernel patch that allows arbitrary baud rates - are you able to build your own kernel?

Hi dom,

Are you still offering the kernel patch? I need to be able to set the baud rate to 1920.

Thanks!

Brad

Brad,

Would it not be easier to use the later bodge suggested by Dom further down the thread? Pick a standard baudrate near the one you want and then shift it to 1920 by altering the UART clock setting in config.txt as he suggested. No need to rebuild the Kernel then?

[Bradoshea]

I do have a kernel patch that allows arbitrary baud rates - are you able to build your own kernel?

Hi dom,

Are you still offering the kernel patch? I need to be able to set the baud rate to 1920.

Thanks!

Brad

Brad,

Would it not be easier to use the later bodge suggested by Dom further down the thread? Pick a standard baudrate near the one you want and then shift it to 1920 by altering the UART clock setting in config.txt as he suggested. No need to rebuild the Kernel then?

Hi SiriusHardware,

Thanks for the response! I've tried this, but the clock setting does not seem to affect the baud rate with my setup. As a test, I tried to cut the baud rate in half. This was my setup.
1) added init_uart_clock=1500000 to /boot/config.txt (2012-10-28-wheezy-raspbian)
2) set dev/ttyAMA0 speed to 9600
3) on the receiving end (bus pirate) the speed was set to 4800
4) garbage came through on the bus pirate
5) changed the speed on bus pirate to 9600
6) the correct values came through

This leads me to believe that init_uart_clock is being ignored. Does anyone have any tips?

Much appreciated!

[dom]

What does:

Code: Select all

vcgencmd measure_clock uart

report with and without the init_uart_clock.

[Bradoshea]

with init_uart_clock set to 1500000:
pi@raspberrypi ~ $ vcgencmd measure_clock uart
frequency(22)=1500000

with init_uart_clock commented out and a reboot:
pi@raspberrypi ~ $ vcgencmd measure_clock uart
frequency(22)=3000000

From these values, it looks like it should be working. Anything else you can think of? Do I need to rebuild the Kernel? I've seen mixed statements on various forums/blogs.

[dom]

Can you try adding:

Code: Select all

bcm2708.uart_clock=3000000

to cmdline.txt and

Code: Select all

init_uart_clock set=1500000

to config.txt

[Bradoshea]

that was it! Thank you dom and SiriusHardware!

[SiriusHardware]

that was it! Thank you dom and SiriusHardware!

All Dom and none of me, I assure you. I just remembered his wise advice.

I'm still hoping that 31250 (for Midi) can be added to the standard selectable serial baud rates on the Pi to simplify the creation / use of MIDI software, but in the meantime has anyone tried any of the USB to 5-DIN midi interfaces originally for PC? Any luck with those?

And does anyone know of a lightweight Cubase 1 / Cubase 2- alike MIDI-only sequencer which is nimble enough to run on the Pi? I mean one with no audio support at all - I'm only interested in recording in from / playing back out to MIDI.

I recently tried a Windows Midi-only fork (from the Linux version) of 'RoseGarden' but my 900Mhz Athlon, 1GB Win XP PC struggles, graphically, to run it - Midi playback stalls each time the cursor line runs off the current page onto the next.

Because of this, I have tended to assume that Rosegarden (Linux) will not run too well on the Pi,

I've still got a real (8Mhz!) Atari ST which runs its native version of Cubase 2 very smoothly indeed, but the Atari, Its dedicated 'hi res' mono monitor and its clunky hard drive are quite bulky things to have lying around just in case I want to use them. It would be nice to be able to get something similar running on the Pi.

[gritz]

@SiriusHardware : Atari ST! I wonder how many of those are still being used? Rock-solid timing...

I suppose there's no reason why a class compliant USB-MIDI interface won't work (you may have to do the "force USB 1.1 speed" hack to mitigate the dropped packets problem though). I do however feel that the combination of USB interface and whatever MIDI editor you may be lucky enough to find may scoff considerable CPU overhead before you've even sequenced a note - and might possibly offer less than stellar latency performance anyway.

If I absolutely had to try this I might be tempted to go the route of RISCOS + GPIO MIDI interfacing. This assumes that old RISCOS sequencing software is still available and can be made to run on the Pi port. If this (admittedly far fetched) suggestion doesn't fill you with dread then it may be worth putting out some feelers in the RISCOS part of this forum. Sorry I can't be more (or indeed much) help.

[SiriusHardware]

@SiriusHardware : Atari ST! I wonder how many of those are still being used? Rock-solid timing...

If I absolutely had to try this I might be tempted to go the route of RISCOS + GPIO MIDI interfacing. This assumes that old RISCOS sequencing software is still available and can be made to run on the Pi port. If this (admittedly far fetched) suggestion doesn't fill you with dread then it may be worth putting out some feelers in the RISCOS part of this forum. Sorry I can't be more (or indeed much) help.

I still have virtually every computer I ever bought in the 70s - late eighties, with the exception of the Amiga which I sold while it was still a mainstream machine. I have never (yet) found anything better than the ST + Cubase 2 to use as a pure MIDI sequencer, so it is still in use to this day. I have a spare PSU for it carefully mothballed as well.

Apparently the RiscOS port of the ST emulator 'Hatari' runs at full ST speed on Pi RiscOS, considerably faster than the Linux version under Pi Linux distros. Hatari even supports Midi... On PCs, where it probably transcodes ST MIDI activity to the MPU401 or Soundblaster MIDI hardware ports on I/O 330.

Unfortunately that interface does not exist on the PI, so it would need some tinkering to get Hatari under RiscOS to offer to use the Pi's UART as a midi interface...and even then, it might still be necessary to bodge the UART config as discussed earlier, to obtain the right serial data speed.

I never used the Archimedes series myself (I was a committed 68000 man by then) and so I've never heard of any established MIDI sequencer programs for that platform.

[JimT]

I'd also like to add a vote for supporting Midi's 31250 baud rate. Has anyone gotten a USB/Midi interface to work on the Pi?