Search:
Submit Search


Arduino-based MIDI

Building organ consoles for use with Hauptwerk, adding MIDI to existing consoles, obtaining parts, ...

Re: Arduino-based MIDI

Postby NickNelson » Fri Jan 20, 2017 1:12 pm

John L wrote:... 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.


Like this you mean

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

Nick
User avatar
NickNelson
Member
 
Posts: 719
Joined: Tue Dec 20, 2005 11:31 am
Location: Leeds, UK

Re: Arduino-based MIDI

Postby brooke.benfield » Fri Jan 20, 2017 2:06 pm

John L wrote: USB 2 works up to 5m, which I think is far enough for our VPO application.


My DIN MIDI cables are 60' long.....

How about Ethernet vs. USB?
Brooke Benfield
Organist, Gethsemane Lutheran Church
Portland OR
brooke.benfield
Member
 
Posts: 125
Joined: Fri Apr 10, 2009 11:38 am
Location: Oregon City

Re: Arduino-based MIDI

Postby jkinkennon » Sat Jan 21, 2017 3:53 am

It seems that no one is taking the entire chain of system latencies into account. Let's look at a fairly normal old fashioned MIDI configuration compared to a single board console USB-MIDI solution.

Both systems will have similar scan times. Let's go with 1ms as my encoder can easily scan 512 contacts or even a 32x32 matrix in 1ms or less. I don't imagine the typical single keyboard with a smaller MCU would be much faster. Then we add perhaps 2ms of debounce time -- this is a subject that would need it's own thread. We are at 3ms delay. This is roughly 10 bits (8 + start and stop bits) x 3 bytes divided into 31.25k which means we need about 1ms to transmit each note on or off.

With 10 keys the traditional MIDI implementation sends them out in a row giving a "jitter" or spread of about 10ms. So the individual notes are now delayed between 4ms (3 + 1ms transmit) and a high of 14ms. The USB-MIDI device sends all the notes in a tiny fraction of a ms so it's safe to say that all 10 notes are delayed 3ms with NO spread greater than a millisecond. Let's say 3 to 4ms.

Let's say we have three keyboards and pedals with no other pistons or stops or expression information clogging the traditional MIDI connection. These four MIDI sources are frequently daisy chained with each hop adding at least another 1ms. We are at 6 to 16ms spread if we assume an average of two daisy chain transitions for each note. These delays don't exist with USB-MIDI.

Since PCs don't have MIDI ports the traditional connection will go through an audio interface or a dedicated MIDI interface. A 2ms delay in an audio interface is a virtual certainty so we are at 8 to 18ms. There is a typical 1ms granularity to a PC's reading of USB ports I believe (correct me if I'm wrong). That would mean 9 to 19ms for the traditional MIDI and 4 to 5ms for USB-MIDI.

Assuming a perfect immediate output from HW we then are left with the audio interface latency plus the distance from the speaker to the listener, especially to the organist if it's straight latency with or without the 10ms spread between notes. Let's assume a distance of 10 feet. Sure, some speakers are much closer, but others in a sanctuary may be much further away. Sound travels at roughly one foot ever millisecond (1100 ft/sec). If we are using a safe 10ms delay in the audio interface (512 samples) then we can add 10ms to the previous numbers plus 10ms for the speaker distance.

Now we are looking at 29 to 39ms for the old MIDI and 24 to 25ms for USB-MIDI. We are at the point where it would be wise to look for places to trim down. Can this system sound OK. I suspect it may. Just don't add one dirty expression pedal to the mix. Or any buffer issues. Or any outbound traffic to control stops as these signals might busy up the ideal figures for transit time through a daily chained device.

I'm well aware that the audio latency could usually be set to a 5ms delay. If your speakers are right on top of the organ then that's also a huge improvement for latency -- perhaps not for the sound though. So USB-MIDI doesn't fix everything, but it should be our preferred interface if the choice is possible. Avoiding daisy chaining and using a MIDI merger is also a great upgrade.

For those needing cable length, ethernet is a great solution. Perhaps not this week, but the next time they buy an interface. I'm seeing the AVB standards showing up on some of the ARM MCUs, believe it or not, so this is the emerging standard so far as I can see.
jkinkennon
Member
 
Posts: 855
Joined: Thu May 07, 2009 10:43 am
Location: Vancouver, WA

Re: Arduino-based MIDI

Postby John L » Sat Jan 21, 2017 5:35 am

Interesting post John, thanks.

I have had a weather eye on overall system latency all along but some of these things can't be changed (speed of sound, for example) and others are outside the scope of the Arduino USB MIDI interface. However, as you have shown clearly, MIDI is responsible for a high proportion of the end-to-end latency but, crucially, most of the variability.

USB MIDI certainly reduces that variability considerably, partly because of the negligible serialisation delays and partly because there are fewer steps along the way from key depression to sound arriving at the ear.

I will admit that I didn't really start the Arduino MIDI project with latency at the core of its rationale. More, it was out of mild frustration with reverting to 1980s technology in a system that could never have existed in that era due to its computing and memory requirements. It seemed to me that USB would be a better interface but was quite surprised to see very few stand-alone USB MIDI encoders out there. I've been programming stuff on Arduino for years and when I discovered the Arduino MIDI library, suddenly I had a project on my hands!

Ethernet-based MIDI is an interesting thought and I should look into that as well, albeit USB is perfect for my needs. Oddly, latency could still be something of an issue, if TCP/IP is used as the transport, because of the handshaking protocol. TCP/IP is not very good at moving very small amounts of data as the protocol overhead is large relative to payload and handshaking is slow. Concatenating multiple notes from a chord into a single packet would probably be unsatisfactory. So that leaves UDP, which certainly should be quick enough,as it is a broadcast protocol that does not use handshaking, albeit there is still a considerable protocol overhead. Something to look at some time, as Arduino also supports Ethernet.
John L
Member
 
Posts: 18
Joined: Wed Jan 18, 2017 9:33 am
Location: Cumbria UK

Re: Arduino-based MIDI

Postby engrssc » Sat Jan 21, 2017 7:45 am

A minor insert here, the spec for transmitting MIDI over fiber boasts a range of 10K feet.

Bit Error Rate 1 x 10E-9 (worse case)
Bandwidth DC to 1.0 Mb/s
(includes 31.2kKbaud)
Rise & Fall time Less then 100 nanoseconds

Rgds,
Ed
User avatar
engrssc
Member
 
Posts: 5114
Joined: Mon Aug 22, 2005 11:12 pm
Location: Roscoe, IL, USA

Re: Arduino-based MIDI

Postby jkinkennon » Sat Jan 21, 2017 2:05 pm

When we installed the console for St. Barnabas Episcopal there were two connections, AC power and a single USB cable. The MOTU 24o interface didn't have a MIDI jack had we needed one. Simplicity is a beautiful thing.

With a large console and 100 stop tabs it would take 1/10 of a second to send the MIDI signals if one had to clear a huge registration. There would be another 1/10 of a second transmitting all the new stop tab status back to the computer. We haven't even touched on the subject of keeping a number of number of LCD displays updated. The Hauptwerk log will show a surprising amount of MIDI traffic that has nothing to do with keystrokes when outbound stop data and status info is enabled for complex consoles.

With AVB (Audio Video Bridging) on ethernet the latency is sub-millisecond and better than USB if I recall correctly. Devices that include a MIDI port, say ten years from now, will be doing so only for compatibility with vintage equipment.
jkinkennon
Member
 
Posts: 855
Joined: Thu May 07, 2009 10:43 am
Location: Vancouver, WA

Re: Arduino-based MIDI

Postby johnh » Sat Jan 21, 2017 4:40 pm

jkinkennon wrote: This is roughly 10 bits (8 + start and stop bits) x 3 bytes divided into 31.25k which means we need about 1ms to transmit each note on or off.


Your figures are already 30% too high. Once a Note-On has been sent (3 bytes) the next Note-On only requires 2 bytes (running status). And the Note-Off (actually using Note-On with Velocity = 0) also only reuquires 2 bytes.

---john.
User avatar
johnh
Member
 
Posts: 688
Joined: Sat Mar 15, 2003 7:51 pm
Location: Monterey Bay Area of California

Re: Arduino-based MIDI

Postby NickNelson » Sat Jan 21, 2017 4:52 pm

johnh wrote:Your figures are already 30% too high. Once a Note-On has been sent (3 bytes) the next Note-On only requires 2 bytes (running status). And the Note-Off (actually using Note-On with Velocity = 0) also only reuquires 2 bytes.


But only when they are on the same MIDI channel. It's pretty common to be playing on two different manuals
when this generally won't be the case.

Nick
User avatar
NickNelson
Member
 
Posts: 719
Joined: Tue Dec 20, 2005 11:31 am
Location: Leeds, UK

Re: Arduino-based MIDI

Postby johnh » Sat Jan 21, 2017 5:02 pm

So perhaps not 30% but not as bad as assumed.

Perhaps implementing a USB composite device where each MIDI channel shows up as a separate device to the OS. Different overhead for sure but but maybe the tradeoff works out better...
User avatar
johnh
Member
 
Posts: 688
Joined: Sat Mar 15, 2003 7:51 pm
Location: Monterey Bay Area of California

Re: Arduino-based MIDI

Postby jkinkennon » Sat Jan 21, 2017 6:02 pm

Running status is optional and sometimes used. If we were to throw real world situations at our hypothetical examples the situation gets much worse, not better. Don't assume, just for starters, that keyboards send and scan at the same time. Hopefully most do these days as hopefully no-one is still bit-banging MIDI transmissions, but you would need to do some testing to be certain. I'll put a scope on my Roland keyboard in a moment and see how it does using the traditional MIDI connections. Just for grins.

EDIT: I just got a best case spread (jitter?) of 27ms for my Roland and a worst case of 33ms to send 10 notes via a Scarlett 18i20 interface. I didn't have a ready way to get the delay, but clearly the variation between notes was about three times worse than my generous guesses. So I'm more comfortable than ever with what I am saying. I could easily rig something to trigger a scope from a key press and get the delay to an actual audio signal, but I'll leave that one alone unless we still aren't convinced of the need for a better MIDI transport. In the past I have put ten or more notes into the same millisecond when using my USB-MIDI encoder.
jkinkennon
Member
 
Posts: 855
Joined: Thu May 07, 2009 10:43 am
Location: Vancouver, WA

Re: Arduino-based MIDI

Postby engrssc » Sat Jan 21, 2017 9:59 pm

Very interesting discussion 8) Thanks to the contributors. Please continue.

Rgds,
Ed
User avatar
engrssc
Member
 
Posts: 5114
Joined: Mon Aug 22, 2005 11:12 pm
Location: Roscoe, IL, USA

Re: Arduino-based MIDI

Postby organtechnology » Sun Jan 22, 2017 12:36 am

Hi Guys,

Here is my 2 centavos worth.

In this process of getting from the keyboard switches to the encoder, there is also the issue of getting from 64 switch closures to the 8x8 matrix (4x8 matrix for the 32 note pedal board) and the getting 96 piston, toe studs and switches in a console, which do not usually come matrixed, to be MIDI fied. These need auxilliary circuitry to do this that are usually external to the encoder itself.

Not all keyboards are 8x8. We have used the Highly Liquid CPU on many of our re-purposed keyboards such as the Allen 6x11 matrix boards and the Rodgers 4x16 keyboards but it was also useful as a 24 input non matrix switch encoder. Since the Highly Liquid CPU production has ceased, we are happy to know that John Kinkennon has a pic module which can be used with the Allen keyboards but we would still like to have something like the inexpensive HL-CPU. The point is keyboards come in a variety of matrices. 4x12, (Yamaha), 6x11 (Allen), 4x16, (Rodgers), 2x (8x8), (Fatar) but I do not know of a keyboard with an 8x8 non-velocity matrix.

In addition, when each keyboard has it own encoder and DIN MIDI output, it is fairly easy to 'merge' these into one USB connection for the computer. The best way to do this is with a multi port merger which gives one MIDI channel per MIDI port with each MIDI input signal given a port number. Serial merging (daisy chaining) the keyboards which puts all the data on one 32kHz port has shown issues. The result is sometimes too much data for the port and over runs occur. A single encoder with all the data on one MIDI port would seem to suffer from the same problem as a serially merged set of keyboards and encoders.

An encoder as has been described which output the keyboards, switches and particularly the expression pedal MIDI data on its own port would be able to utilize more of the USB bandwidth by putting multiple parallel streams of MIDI data into the computer at USB speeds similarly to the way an 8 port MIDI merger works.

YMMV, Thanks for listening.

Thomas
Complete VPO systems powered by Hauptwerk™. Real Wood Consoles, PC or MAC Computer Sound Modules, Audio for Home or Church.
info (at) organtechnology.com http://www.organtechnology.com

Authorized Hauptwerk Dealer; Milan Digital Audio Dealer..
User avatar
organtechnology
Member
 
Posts: 1621
Joined: Sun Aug 02, 2009 5:58 pm
Location: DFW, TX USA

Re: Arduino-based MIDI

Postby engrssc » Sun Jan 22, 2017 3:41 am

How much of a difference in the final take is using a USB 2.0 port as compared to a USB 3.0 port in the cases mentioned above?

Rgds,
Ed
User avatar
engrssc
Member
 
Posts: 5114
Joined: Mon Aug 22, 2005 11:12 pm
Location: Roscoe, IL, USA

Re: Arduino-based MIDI

Postby John L » Sun Jan 22, 2017 5:39 am

Thanks for all the comments guys. Picking up on a few points...

I just got a best case spread (jitter?) of 27ms for my Roland and a worst case of 33ms to send 10 notes...

Using my rule of thumb, 20ms minimum perception time, that is unacceptable. And it's unnecessary as the technology has been around for a decade or more to do better. I think your point is very well made! I should also say that in any complex system where there are several sources of an unwanted effect that occur in series, the engineering solution is to attack the principal cause first. I think you've demonstrated clearly that MIDI delay is a, if not the, first order contributor to overall system delay.

Not all keyboards are 8x8

The beauty of doing this in something like an Arduino (or indeed any other software driven interface) is that it is quite straightforward to adapt for different matrix layouts. 8x8 is rather convenient and uses the fewest I/O pins (16 for one keyboard, 24 for two, etc.). If the keyboard doesn't have a matrix then it is relatively simple to make one with a bunch of cheap diodes on a piece of Veroboard.

...when each keyboard has it own encoder and DIN MIDI output, it is fairly easy to 'merge' these into one USB connection for the computer

Yes, it is. Aesthetically this is not pleasing to me as an engineer because there are two serial conversion processes - firstly to DIN MIDI and then to USB. Whether or not it causes problems, there is no need for this any more. Daisy chaining must, surely, be a no-no?

...particularly the expression pedal MIDI data...

I understand the issue with expression pedals causing floods of MIDI traffic but this is just poor design if it is allowed to happen. My approach is to sample the analogue input every 50ms (could probably be increased to 100ms) and send any update to the MIDI channel at that time. This means that at most there can be 20 (10) expression pedal updates per second which is perfectly fit for purpose.

I'm impressed with the level of interest and quality of debate on this! Thanks to all.
John L
Member
 
Posts: 18
Joined: Wed Jan 18, 2017 9:33 am
Location: Cumbria UK

Re: Arduino-based MIDI

Postby NickNelson » Sun Jan 22, 2017 6:14 am

John L wrote:I understand the issue with expression pedals causing floods of MIDI traffic but this is just poor design if it is allowed to happen. My approach is to sample the analogue input every 50ms (could probably be increased to 100ms) and send any update to the MIDI channel at that time. This means that at most there can be 20 (10) expression pedal updates per second which is perfectly fit for purpose.


Yes, that rate is around what I use. I suspect though, that a worse design error is rounding the ADC result to 7 bits before checking whether it has changed (thus requiring a new value to be transmitted).

Nick
User avatar
NickNelson
Member
 
Posts: 719
Joined: Tue Dec 20, 2005 11:31 am
Location: Leeds, UK

PreviousNext

Return to DIY organ consoles / MIDI

Who is online

Users browsing this forum: No registered users and 3 guests