It is currently Fri Mar 29, 2024 1:53 am


Arduino-based MIDI

Building organ consoles for use with Hauptwerk, adding MIDI to existing consoles, obtaining parts, ...
  • Author
  • Message
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Arduino-based MIDI

PostThu Jan 19, 2017 7:52 am

I'm new here so be gentle with me :D

Better late than never, I am returning to the wonderful world of organ playing and, my word, hasn't the technology moved on? Except, it seems, in one area: MIDI...

The MIDI specification dates back to the early '80s when 31.25kbit/s was motoring along quite nicely. In my research for likely ways to implement Hauptwerk, I've been surprised to find that it's still in use in its original serial I/O, 5 pin DIN format, pretty well wherever I look. This seems odd, particularly as USB MIDI has been around for the past 18 years or so and is fairly universally adopted elsewhere.

With a background in electronics and computer programming I started thinking about this conundrum and before long I was coding away. The result is a MIDI program running on an Arduino Due that supports up to three 8x8 matrix keyboards, full pedalboard, four swell pedals and 96 stops/pistons. Each component class can have its own separate MIDI channel and everything is sent via a single USB interface to the host computer running Hauptwerk.

All this needed barely a day's worth of coding to get to the stage where it plays nicely with Hauptwerk. That got me wondering why such an obvious solution is, as far as I can tell, not in common use. It is a remarkably low cost way of achieving a full organ's worth of connectivity.

And so, inevitably, some questions:

- Has this sort of thing been done already and I've just not noticed?
- Is there some dastardly down side to this approach that I've not considered?
- Is this an interesting approach that others might like to consider?

John.
Offline
User avatar

engrssc

Member

  • Posts: 7283
  • Joined: Mon Aug 22, 2005 10:12 pm
  • Location: Roscoe, IL, USA

Re: Arduino-based MIDI

PostThu Jan 19, 2017 11:02 am

We are always interested in other ways of doing things with Hauptwerk. Say on

Rgds,
Ed
Offline

jkinkennon

Member

  • Posts: 1208
  • Joined: Thu May 07, 2009 9:43 am
  • Location: Vancouver, WA

Re: Arduino-based MIDI

PostThu Jan 19, 2017 11:55 am

Hi John,
We are in a lonely group of three or so. Check out my work using PIC32s that also uses USB MIDI for the entire console. That's on the web site below. I believe that forum member 'Elia' is doing something similar with the A20 chip running Linux that we may hear about soon. Lot's of folks have tried the Teensy but not for more than a single keyboard or set of pistons to my knowledge. I'm interested to know more as I have a Teensy 3.2 on my desk that I haven't yet found time to try.
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Re: Arduino-based MIDI

PostThu Jan 19, 2017 12:23 pm

Hi Ed, John, thank you both for your replies. A bit more information then...

The Arduino Due is a ARM Cortex-M3 based device that supports around 60 I/O ports, some of which can be analogue, most digital. The processor runs at 84MHz so it is plenty powerful enough and it supports high speed USB via a native USB port direct to chip.

I specify eight digital I/O pins as diode matrix row select outputs and scan them at the rate of one row each millisecond. A complete scan, therefore takes 8ms. For each manual I use another eight input pins for the matrix columns. There are sufficient pins to do this four times - three keyboards and pedalboard. There are 32 matrix positions left over from the pedalboard matrix and a further 8x8 matrix provides another 64 on/off positions, giving 96 on/off switches for pistons, stops, etc. The Due also has 12 analogue I/O pins and I use four of them to provide swell pedal inputs for each manual.

This all seems to work a treat. The processor is fast enough that scanning five matrices is easily completed in well under 1ms (row select time). USB is super fast, adding virtually no delay and because it is a multiplexed packet-based device, multiple MIDI channels can be supported without overhead. The overall latency is thus, near enough, the scanning time for the matrices, i.e. 8ms. I am fairly sure this could be speeded up if needed - I only used 1ms scan rate because that is trivial to code!

Right now I do not have suitable keyboard hardware to test all this in a real world set up. I can test it easily enough with a few wires, switches and pots and that is what I have been doing so far, with Hauptwerk as the host. I can't really see any reason to suppose that it wouldn't work just fine in the real world.

The code is in C and it's pretty simple really. I think the Arduino Due is an ideal platform because of its huge complement of I/O pins.

John.
Offline
User avatar

engrssc

Member

  • Posts: 7283
  • Joined: Mon Aug 22, 2005 10:12 pm
  • Location: Roscoe, IL, USA

Re: Arduino-based MIDI

PostThu Jan 19, 2017 12:31 pm

Is there a provision for contact (key) bounce which can be an issue? Are any other support chips needed?

Rgds,
Ed
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Re: Arduino-based MIDI

PostThu Jan 19, 2017 12:46 pm

At the moment I have not put any de-bounce logic (hardware or software) in there but I can see it might be necessary. This is something to explore when I have the keyboard hardware to hand.

No other chips are required. Obviously you need the diode matrices but those generally come with the keyboard or if not are easily and cheaply fabricated. Each column input pin needs a 10k pull down resistor but that's about it as far as I can see.

John.
Offline
User avatar

engrssc

Member

  • Posts: 7283
  • Joined: Mon Aug 22, 2005 10:12 pm
  • Location: Roscoe, IL, USA

Re: Arduino-based MIDI

PostThu Jan 19, 2017 12:55 pm

Very logical approach(es). No surprises so far. I'm optometrist (usually). 8) And I like tiny useful things.

Rgds,
Ed
Offline
User avatar

johnh

Member

  • Posts: 699
  • Joined: Sat Mar 15, 2003 6:51 pm
  • Location: Monterey Bay Area of California

Re: Arduino-based MIDI

PostThu Jan 19, 2017 6:31 pm

John L wrote:At the moment I have not put any de-bounce logic (hardware or software) in there but I can see it might be necessary. This is something to explore when I have the keyboard hardware to hand.
.


You'll definitely want debounce functionality. Also, older organ keyboard contacts were designed to switch a fair amount of current at 10 volts and higher. Some folks have found that these contacts do not work well with the low voltages and micro-amp currents of modern circuits.

---john.
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Re: Arduino-based MIDI

PostThu Jan 19, 2017 6:48 pm

johnh wrote:You'll definitely want debounce functionality. Also, older organ keyboard contacts were designed to switch a fair amount of current at 10 volts and higher. Some folks have found that these contacts do not work well with the low voltages and micro-amp currents of modern circuits.

Yes I am sure you're right, although the extent to which debouncing is necessary is very much dependent on the switch technology, as are issues with contact switching voltage/current. The trend towards using hall effect devices is good news in both regards. Something to pick up on later when I have the keyboards but it's quite easy to do in software with the approach I've taken to matrix scanning.

John.
Offline
User avatar

Grant_Youngman

Member

  • Posts: 1203
  • Joined: Sat Jan 20, 2007 6:50 pm
  • Location: Savannah, Ga

Re: Arduino-based MIDI

PostThu Jan 19, 2017 8:24 pm

John L wrote:And so, inevitably, some questions:

- Has this sort of thing been done already and I've just not noticed?


Sort of depends on what you mean by "this sort of thing" As an example, you might check out Midiboutique, such as this controller …http://midiboutique.com/MIDI-encoders/hwce2x

Certainly not the only source, but fairly widely used. While it has the DIN midi out, there are inexpensive products which will convert to USB for computer connection. The midi data rate on a typical organ console is fairly low as data rates go … so USB is useful for convenience, but not necessarily a lot to be gained because of interface speed.

Other approaches, such as velocity sensitive keyboards (Midiworks/Fatar, and others) can also be useful, and will typically have their own midi encoder hardware (with USB midi out). Some HW sample sets support velocity for both key-down and release.

In any case, sounds like an interesting project.
Grant
Offline
User avatar

csw900

Member

  • Posts: 269
  • Joined: Mon Mar 07, 2016 9:40 am
  • Location: UK

Re: Arduino-based MIDI

PostFri Jan 20, 2017 3:41 am

As Grant_Youngman says above, DIN midi is fast enough for organs -- there is no
(lack of) speed issue.

The DIN midi interface has been around for a long time and has stood the test of time
well. It is perfectly adequate for general purpose musical use and is very popular.
The connectors are robust and will withstand misuse.

Not so USB, it is continually changing and is not universally compatible -- even with
itself. There are multiple different connectors and cable length is severely limited to
only a few metres.

However I am all in favour of experimenting with different connection methods and
often a specialised connection method can be better than the standard way of doing
things. This is how progress happens; BUT you need to be the size of Microsoft or Apple
to inflict new standards on the electronics industry.

csw900
Offline
User avatar

NickNelson

Member

  • Posts: 880
  • Joined: Tue Dec 20, 2005 10:31 am
  • Location: Yorkshire, UK

Re: Arduino-based MIDI

PostFri Jan 20, 2017 4:12 am

Some time ago I explored this approach using the earlier Arduino products, but abandoned it due to the difficulties with the USB-MIDI libraries then available (though I understand that these have been considerably improved since). Another issue then was that although one could reconfigure the (single) USB port to work as a MIDI device, the data to and from the main microcontroller was still via a serial connection, albeit at a higher baud rate than standard serial MIDI.

It is certainly encouraging that some of the the newer Arduino products provide a second native USB port which should bypass this potential bottleneck, and I for one certainly applaud any work which expolres the possibilities of exploiting these devices.

There are other considerations though.

Firstly, serial MIDI is extremely robust and reliable, particularly if the data needs to be transmitted over a significant distance. This robustness is at least partly attributable to the relatively slow data rate which in turn potentially introduces latency between the keyboards and sound producing system. Some contributors to the forum (Elia springs to mind) are very concerned with this and have investigated the matter very thoroughly.

The problem is not so much that there may be a fixed delay (all players of real organs have to deal with this) but that the scanning and transmission of the data can introduce random variations in the response time (MIDI jitter) between key press and sound production. In theory, the maximum number of simultaneous MIDI events I could, or at least imagine I would want to, produce is 12 (ten fingers and two feet). There would be an uncertainty of about 1/80 second over when these notes actually sounded. Personally, I don't believe I am able to perceive this let alone be annoyed by it. Others may (and probably will) disagree.

A second issue for me is that while I am also drawn by the idea of keeping all the processing in one place, there is a down side in the amount of wiring it generates. Each manual, needs a minimum of 16 wires from the controller. Generating the MIDI traffic for each manual (and the pedal board) locally needs only two to carry the serial MIDI to the next device. Naturally, 'chaining' several separate MIDI controllers carries an additional time penalty (the incoming traffic to each controller has to be received, parsed, merged and transmitted) but again, I have never found this to be a problem.

I agree with the other posters that some form of debouncing is likely to be needed, here is a post where I describe my approach:

viewtopic.php?f=15&t=13249&p=97822#p97770

Good luck with the development,

Nick
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Re: Arduino-based MIDI

PostFri Jan 20, 2017 7:06 am

Some very interesting in-depth responses, thank you all. To avoid writing a reply of Tolstoyesque proportions, I'll respond to a few key points here and perhaps pick up on others later.

USB vs. DIN MIDI
Not sure I agree about the lack of standardisation in USB connectors. Yes, there are several connector types for the peripheral (B) end - and a good thing too, the earliest connectors are nearly as huge as a standard DIN plug! The host (A) end is always the same standard rectangular connector. USB 2 works up to 5m, which I think is far enough for our VPO application. Most usefully, USB multiplexes multiple data streams and provides power to the peripheral. I tend to the view that for what we are trying to do these are useful attributes. For a pop group prancing around on the stage the DIN would certainly be better.

It was the existence of DIN to USB adapters that got me thinking about this in the first place. It seemed to me that there was no justification for another protocol conversion (keystroke > serial MIDI > USB MIDI) and that it would be better to go straight to USB.

Speed
Is serial MIDI fast enough? I suppose it probably is although the serialisation delay is added to scanning time. In other walks of life I've become accustomed to thinking in terms of around 20ms as being the shortest period that the human ear can discern. If a mighty chord of 12 notes is struck then MIDI serialisation of the Note On messages will be around 12ms and, for my current design the keyboard scan time is 8ms, which, remarkably enough, sums to 20ms. My inclination is that I would quite like to get away from that 12ms of MIDI serialisation time.

Wires
A very good point about the number of wires needed for each approach, especially so for the pedalboard. I suppose that might drive us towards two or perhaps three Arduino Dues, connected via a standard USB hub. The Due only costs about £25 and USB hubs are as cheap as chips, so it is still an extremely low cost solution. Another advantage of USB is that the peripherals are powered via the USB cable, so no additional power wiring.

Debounce
I need to think about this some more. A simple RC circuit would get rid of most of the noise but probably it is better done in software. My sampling method should minimise contact bounce problems but it should be quite easy to add some more code to ensure that the line has stabilised before accepting that a change in state has occurred. Again, using my 20ms discernibility figure as a guide, any state changes that happen for significantly less than that time could be ignored as contact bounce. What is a typical key switch bounce time? I would have guessed <<10ms of state uncertainty.

Enough for now. I'm finding that this an interesting discussion and I am happy to be gaining useful knowledge.

John.
Offline
User avatar

NickNelson

Member

  • Posts: 880
  • Joined: Tue Dec 20, 2005 10:31 am
  • Location: Yorkshire, UK

Re: Arduino-based MIDI

PostFri Jan 20, 2017 8:33 am

John L wrote:What is a typical key switch bounce time? I would have guessed <<10ms of state uncertainty.


From my experiments this can vary a lot.

For magnetically actuated reed switches (in my view the best choice for pedal boards) - about 2mS

For microswitches (another possibility for pedalboards, but I don't like the 'ticking' on a manual - about 2mS

Optical approaches typically don't have any bounce at all, but there may be issues around the sensor rise and fall times, particularly if these are arranged in a matrix configuration.

Hall effect switches typically don't have any bounce at all, but there may be issues with excessive hysteresis.

Conductive rubber membrane switches, in so far as my investigation based on a sample of 1 revealed, also don't bounce at all, when new at least, but do exhibit a ramping effect which may introduce delays on slow presses.

I would think that for the reasonably standard kind of keyboards switches based on lengths of bent wire 10mS would be a reasonable estimate for a well designed contact assembly in good condition, though I have not sytematically investigated this.

For the bent wire approach with as bad a design as I could contrive, it was not difficult to obtain bounce times up to 25mS.

On the matter of pedal boards, it's worth bearing in mind that nothing much happens quickly down there. A Due might only cost £25, but I would regard that as about £15 too much for a pedalboard encoder. For an integrated scheme such as the one you are proposing I would be inclined to use something like one of my ATMega8 based encoders (32 pedals, 4 expression inputs, 16 pistons) and send the serial MIDI to the Due where it could be merged in with the rest of the MIDI traffic (assuming the Due provides access to a USART of some kind). Note that since the data is not being sent to a standard MIDI-in port the baud rate could be much higher than for serial MIDI.

Nick
Offline

John L

Member

  • Posts: 46
  • Joined: Wed Jan 18, 2017 8:33 am
  • Location: Cumbria UK

Re: Arduino-based MIDI

PostFri Jan 20, 2017 10:03 am

Some very interesting points, thank you Nick.

De-bouncing
I think your figures are about what I was expecting. Let's look in more detail at what I have already coded. Each matrix row is enabled for 1ms and in that time the eight columns are scanned sequentially. Now this code is pretty quick and the actual pin read part probably takes no more that a microsecond or two. After that there is processing work to be done. On a whim I decided to run the scan as fast as it'll go and it turns out that a complete scan takes 320 microseconds (us) so each key is read and processed in just 5us! I must confess that that is considerably faster than I had imagined it would be.

Anyway, for the purposes of this treatise, we can suppose that the period of time that each column input pin is actually being sampled is in the microsecond region. It therefore doesn't matter much if there is contact bounce - unless the bounce pulse rate is in the nanoseconds region. At the instant that the key is sampled it is either on or off and subsequent processing works on that value.

The next problem is whether a note might be rapidly turned on/off because on one scan the input is high and, due to contact bounce, the next is low. At my standard scan rate that would mean that the contact had bounced from 0 to 1 or vice versa in 8ms or less. I think no-one is ever likely to play a note for only 8ms, so it is a simple matter to see how many scans ago the last state change occurred and if less than some threshold, to ignore that state change.

Using your figures and my suggestion that 20ms is a discernible time, seems to suggest that 16ms (i.e. two scans) might be a sensible threshold. Note particularly that this does not add to latency: if the note state hasn't changed in the last 16ms then it will change immediately (and then another 16ms timer starts). I can't see much wrong with this Baldrickesque cunning plan but I'd love to hear what you think.

An alternative scanning technique
As the standard scan for the entire keyboard is 8ms, a single note can have up to 125us processing time and in that time one could do multiple pin reads, taking the average to get the most likely true value. This approach is also quite easy to code and would have the benefit that the risk of missing a change in state, because the contact happened to bounce just at the instant of scanning, would be substantially reduced.

Slave MIDI encoders
I like your idea of a lower cost MIDI encoder for the pedals et al. This would be very easy to do as the Due has four UARTS in addition to the programming and native USB ports. These UARTS can certainly run at 115.2k baud, perhaps faster, so serialisation delays would be negligible. There is processing overhead in the Due and the UART support libraries are not particularly renowned for their speed but as you say, traffic volumes are low, so unlikely to be a problem. Something else to think about in due (sorry!) course.

John.
Next

Return to DIY organ consoles / MIDI

Who is online

Users browsing this forum: No registered users and 4 guests