It is currently Fri Mar 29, 2024 4:38 am


DIY MIDI encoder: survey about hardware/software features

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

elia

Member

  • Posts: 125
  • Joined: Mon Oct 27, 2008 1:11 pm
  • Location: Italy , Padova

DIY MIDI encoder: survey about hardware/software features

PostSun Jul 20, 2014 4:14 am

... I know that these things will create more complications than benefits to many people and only a few people will be interested. In any case, the question has a cultural value ...

This topic represents the other side of the topic "MIDI latency/jitter performance" at http://forum.hauptwerk.com/viewtopic.php?f=3&t=13199 .
In the case mentioned we have talked about the problems associated with MIDI interfaces for windows, osx and linux. We observed several cases of extreme performance that no one would believe possible.

In this case we want to address the problem on the other side: the console MIDI encoder. This case is less problematic because there is no interference of complex operating systems. There are only microcontrollers that do one job and do it well with the physical limits of the historical MIDI standard.

I briefly recall the MIDI standard dates back to 1983 and that the serial transport layer network has a theoretical latency of 1ms to MIDI event (note-on). However it may happen that the final latency/jitter that comes to Hauptwerk is also 10 times higher mainly because of the MIDI interfaces connected to the computer. How kindly reminds Martin ( http://forum.hauptwerk.com/viewtopic.php?f=3&t=13184 ), the Hauptwerk MIDI processing has no time limits(nonasecond) ... In practice, the major limitation is the operating system (especially Windows), the quality of the MIDI driver, the physical MIDI transport layer and obviously the raw keyboard quality.

It's been more than 30 years but no manufacturer is sensitive to this issue of the MIDI performance. Obviously we're talking about keyboards performance. The fingers and arms can stress significantly the traditional MIDI encoder: for example, a cluster trill between blacks and white keys played with the arms on coupled keyboards...a torture test!

My speech, however, does not want to just be tied to performance. There are also other aspects:
- Lower costs
- Greater integration
- Greater flexibility, scalability
- Higher performance
- Flexible software implementation
.

Basically I wanted to know if there may be an interest of the DIY users. The solution is based on an PCI(e) Digital I/O board to be installed on your PC or MAC, or a more traditional standalone solution where the console has its own encoder card based on Digital I/O PCI(e) board and communicates with the PC through a low-latency channel: ethernet, thunderbolt, ...

The Digital I/O board are typically used in industrial automation. Basically even the worst cards can do the job well. Market has produced an infinite number of models. You can also find a used electronic card for a few tens of dollars ...:

- Acces PCI http://www.accesio.com/go.cgi?p=../pci/pci_dio_120.html
- ADlink PCI http://www.adlinktech.com/PD/web/PD_detail.php?s&pid=1174
- ADlink PCI_Express http://www.adlinktech.com/PD/web/PD_detail.php?pid=890
- Sealevel PCI http://www.sealevel.com/store/i-o/digital-i-o/pci/8009-pci-96-channel-ttl-digital-interface.html


Anyone wishing to adopt this solution may choose between 2 options:
- "Insert the card into the console" instead of the traditional MIDI encoder with a fast PC communication channel, for example ethernet.

- Insert the card into the PC / MAC to the fullest possible integration. You do not need a Mac Pro to use a PCIe board (http://www.sonnettech.com/product/thunderbolt/index.html ).
.


I await your feedback and/or functional suggestions.
Thanks
Elia
Offline
User avatar

polikimre

Member

  • Posts: 676
  • Joined: Tue Sep 12, 2006 7:39 pm
  • Location: USA, NC, Cary

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 7:28 am

So, if I understand it right, the suggestion is to use a general purpose IO board to read the state of the switches in the console and then generate MIDI events inside the PC and just send them over the internal bus to HW?
Offline
User avatar

elia

Member

  • Posts: 125
  • Joined: Mon Oct 27, 2008 1:11 pm
  • Location: Italy , Padova

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 8:42 am

Exactly, this is one of 2 ways. The other is the standalone mode with a fast channel of communication between the console and PC. The speech can be extended to the pedalboard and all other MIDI hardware (including analog).
However, it is easier said than done but you can use a lot of work already done in a driver-less mode for easy portability and code reuse.
The wiring is typically a diode matrix 8x8 but nobody forbids to use an input for each key...
Elia
Offline

steve till

Member

  • Posts: 350
  • Joined: Sat Aug 23, 2008 11:11 pm
  • Location: oregon usa

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 9:14 am

I too am interested in such things.
Especially an encoder for the console that speaks to the PC via ethernet.
Current gigabit ethernet is way faster than midi.
Time for midi to die.
Offline

jkinkennon

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 9:31 am

I've previously raised the issue of MIDI timing problems and referred to Colin Pykett's article from 2012, http://www.pykett.org.uk/picscannermidi.htm. I would like to see a test of how the newer USB keyboards perform, either the Classic models or more generic MIDI (over USB) controllers compared with the older traditional serial interface models.

The PCIe approach holds a lot of potential but would require a software layer to do the conversion to MIDI. Seems we need to make some kind of differentiation here between MIDI coding and traditional and newer transport options. There's some useful testing ahead for anyone willing to put forth the effort. I commend elia for his work to date.
Offline
User avatar

organtechnology

Member

  • Posts: 1886
  • Joined: Sun Aug 02, 2009 4:58 pm
  • Location: DFW, TX USA

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 10:09 am

While it would seem that a faster communications channel would indeed shorten the latency between key press and sound, there are other considerations of the human-operating-a-mechanical-switch that may also limit the speed of conversion to whatever digital protocol (read MIDI) is used. The most obvious of these is key bounce. Many consumer keyboards have encoding which goes straight to the internal synthesizer and MIDI is generated from this data afterwards. In this case, the key de-bounce character and the hardware/software elimination of this issue is a significant portion of the latency; particularly as the latency of the calculation is shortened through computing power. But in reality, what is the length of the latency in a direct electric action pipe organ control system? What is the lower limit which we seek to obtain? What is attainable?

Thomas
Complete Hauptwerk™ systems using real wood consoles, PC Sound Engines, Dante Audio for Home or Church. info (at) organtechnology.com http://www.organtechnology.com
Authorized Hauptwerk; Milan Digital Audio and Lavender Audio reseller.
USA and Canada shipments only.
Offline
User avatar

NickNelson

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 12:07 pm

organtechnology wrote:But in reality, what is the length of the latency in a direct electric action pipe organ control system? What is the lower limit which we seek to obtain? What is attainable?


I think Thomas is right about this, practically speaking one would need to balance what could be done to reduce the theoretical benefits of reducing latency/jitter against the cost and complexity of doing so.

I for one, wouldn't want to replace a demonstrably very reliable scanning matrix encoder based system capable of, say, 10mS overall resolution, costing about $20 to build, and requiring only three wires to connect it to the computer with a much more expensive and complex system unless I was certain that it would address a real (rather than theoretical) performance problem.

I think it would be possible to reduce the timing errors in a conventional matrix scanning system considerably.

Strategies for this would include reducing the scan interval (but this would most likely mean that mechanical switching couldn't be used due to the bounce issues Thomas also mentions), doubling the number of keys simultaneously examined to 16, implementing running status (though I can't imagine that the current encoders don't already) and, probably, using USB rather than serial MIDI as the interface protocol.

On this last point I'd also be interested in how USB MIDI compares with serial MIDI in terms of timing inaccuracies.

I think there are probably dozens (possibly many more) of very talented, skilful and experienced organists who use serial MIDI interfaces to HW in their performance and who contribute to the forum. I don't recall any of them complaining that the interface is limiting them artistically (though I accept that it could be argued that they just don't realise it).

Nick
Offline
User avatar

NickNelson

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 12:13 pm

NickNelson wrote:I for one, wouldn't want to replace a demonstrably very reliable scanning matrix encoder based system capable of, say, 10mS overall resolution, costing about $20 to build, and requiring only three wires to connect it to the computer with a much more expensive and complex system unless I was certain that it would address a real (rather than theoretical) performance problem.


Ideally, It would be great if someone could build a console with as near perfect overall timing accuracy as possible, and also fitted with a conventional encoding system, and have a good organist compare (blind) the two playing experiences.

Nick
Offline

jkinkennon

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 2:07 pm

A couple of years ago I wrote about playing handfuls of notes at a time in order to stress an encoder. At that time, using MIDI over USB, I was able to get eight or more notes to clock within the same millisecond if I recall correctly. I'll try the test again and see if I can repeat that. With USB there is an extra data byte added which results in four-byte packets so I'm not sure that running status would make much of a performance difference. I recall someone's rule of thumb that USB 2.0 was at least a couple of hundred times faster that the old serial rate.

I'd agree as well that if everything comes in under 10 or 20 ms it's likely that no one will hear the difference. It's the extreme cases where the debouncing isn't efficient, multiple encoders are daisy chained, and audio latency is poor that everything combines to make a system feel sluggish. Speaker distance adds to the overall problem at about 1 ms per foot. Fortunately, putting aside theater organ percussion, most organ tones are not terribly percussive which helps mask any skewing and delay.

On a related matter, I've experimented with shorter attack (noteOn) debouncing with a normal more relaxed release. The results have been promising with my keyboards. I'm trying to take advantage of the fact that open contacts don't accidentally close, though they may bounce, whereas it's easier to get an accidental opening of the switch contacts as the contacts wipe together.
Offline
User avatar

elia

Member

  • Posts: 125
  • Joined: Mon Oct 27, 2008 1:11 pm
  • Location: Italy , Padova

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 3:29 pm

Thank you all. I understand and agree with all the doubts expressed. I have to keep myself neutral. I have to offer only a technical possibility. It is up to the end user decide what to do. It will not always make sense to go too far but having the opportunity to do so can improve life in certain favorable situations. So many little details make the difference if they are all together in harmony. In the worst case it will not hurt anyone and will remove any skeptical doubt.
But that's not all, the system is dynamic and programmable. Based on the dynamic measurement of the background noise (bouncing, 1-bit digital conversion, general hardware noise) can go time down in a meaningful way (for example, 3 times the bounce) and highlight the abnormal condition of excessive noise. The mechanisms do not last forever. Knowing the reliability of the keyboard and the system is not a trivial thing.

The 61-key keyboards are typically constructed with a matrix of 8x8 16pin or a dual matrix 8x8 24pin (key velocity). The circuit is minimal: the track on the printed circuit, a diode and a switch button (or two switches for key velocity keyboards). From the electrical point of view it is difficult to tell if a Fatar keyboard is better than a consumer keyboard. The only important element is the Contact Rubber Strips that probably is a standardized component.
Obviously this is the first physical limit and surely the minimum response time will be at least double or triple the time to bounce. Inside the keyboard M-Audio Keystation 61es is a microcontroller Winbond W78E052C (http://www.keil.com/dd/docs/datashts/nuvoton/w78e052c.pdf) with a clock of 16MHz and with a double matrix of 8x8 24pin (16 inputs and 8 outputs). In the specific case the latency of the USB interface is lower than MIDI. This fact means that only USB comes first but does not change the time between an event and the next. Of course you could do better as you said but the encoder simply does not ... Just measure the arrival time of the same event that comes from the MIDI bus and USB bus simultaneously.
If you press several keys simultaneously on the keyboard M-Audio Keystation 61es you can see the distribution in time and understand what's really going on. Let's say generously that between one event and the next one goes a little more than 1 ms.
This means that an encoder in parallel reading of each individual key (without the matrix) as a minimum can read all the 61 keys in 1ms. But even with a better matrix scan you can do better.


As Nick says, a test would be important to understand what do you think the organist.
If the organist does not notice a difference then there is no need to create so many complications but unfortunately until now no one has ever been able to do it!

I ask if jkinkennon may further specify the details of the case observed (8 note-on in 1 ms on USB bus).

I am now developing the system and when it's done I will offer a demo usable so you can evaluate the results and decide accordingly.

That is why I asked what you want. This will be useful when you try for yourself ...
Elia
Offline

jkinkennon

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostSun Jul 20, 2014 6:46 pm

Concerning my groups of notes inside a 1 ms window it's important to note that my DIY encoder is not velocity sensitive and is not burdened with the need to measure the interval between successive contact closures for each note. What I have done is play a group of ten notes on an old Allen keyboard with leaf style (relay style) contacts. I monitor the results with MIDI-OX on Windows 7 and check the timestamps of the logged results. I took a look at the MIDI-OX web site this afternoon to be sure that the timestamp they post is the one retrieved from the Windows kernel. The encoder does four 11x6 or 8x8 matrix manuals.

I frequently manage to get all ten notes in one millisecond, sometimes six or eight notes with the rest removed a millisecond or two from the others. I think this demonstrates that the notes are not skewed, but I do not have an indication of the overall time through the encoder and the operating system. It would be easy enough to do a loopback and get a round trip time to and from the encoder over USB and perhaps to try different traffic levels. That would be a cool break from rewiring a three manual Allen 675-TH console that's out in the garage.

There's an interesting phenomenon going on and I would solicit anyone's thoughts. If I run Reaper even with all MIDI input seemingly disabled, I see 1 ms gaps between all my notes. If I shut down Reaper then MIDI-OX again displays the tight clusters. Any thoughts? On my Mac I am using a utility called MidiMonitor and getting strange results at this time so will investigate that as well.
Offline
User avatar

NickNelson

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostMon Jul 21, 2014 1:20 am

jkinkennon wrote:On a related matter, I've experimented with shorter attack (noteOn) debouncing with a normal more relaxed release. The results have been promising with my keyboards. I'm trying to take advantage of the fact that open contacts don't accidentally close, though they may bounce, whereas it's easier to get an accidental opening of the switch contacts as the contacts wipe together.


This is how I am dealing with debouncing at the moment:

"For each key, an 8 bit register is maintained in which the present and previous states of the pin are stored, the number of consecutive scans (up to 32) which have returned the same result, and the current reported state (ie whether the last MIDI message sent for this pin was a note-on or a note-off.

If a key has been in the same state for at least n (n=0 to 32) scans, the key is flagged as ‘stable’. Immediately any change is detected from its previously stable state the appropriate MIDI message is sent and the counter reset. Any further MIDI messages are prevented until the key is flagged as ‘stable’ again.

This seems to me to combine the desirable fast response to a key press (or release) with good security against false re-triggering.

Accordingly, the scan interval in the current encoders has been reduced to 2mS. Note that a de-bounce value of 0 means that the result from every scan will be sent immediately. This might be appropriate for sensors which don’t bounce and have a reasonable amount of hysteresis (eg Hall effect sensors). A bounce number of 32 means that the pin must be detected as remaining in the new state for over 60mS before its regarded as stable and therefore ‘allowed’ to change. For most types of contacts in clean condition values of 2-10 ought to be fine."

More details of my encoder design were posted here:
viewtopic.php?f=15&t=12849&p=94757#p94757

Nick
Offline
User avatar

elia

Member

  • Posts: 125
  • Joined: Mon Oct 27, 2008 1:11 pm
  • Location: Italy , Padova

Re: DIY MIDI encoder: survey about hardware/software feature

PostMon Jul 21, 2014 6:25 am

Hello jkinkennon,
to understand where is the problem we need to reduce the variables to a minimum. I understand that you have a DIY USB MIDI class compliant encoder. Windows does not have a good management of the MIDI events especially if you use the class-compliant MIDI default driver. Use OSX and even Linux (for example ubuntustudio) with kmidimon utility. Compare the results and you'll get the answer on the goodness of your encoder (I hope it's good). You must have at least one certainty. If you then want to give us some details of your encoder then we will understand better.

At this point in order to proceed in a more scientific manner, you must provide credible data or verifiable data. It could also be that this project becomes collaborative.
So I thank Nick for having made ​​a significant contribution in this regard. Unfortunately, very few people will be able to follow a hard road to do while insert a PCI card into your PC and do some simple wiring will be much easier for anyone especially if you have to just do the tests. Who plays the organ can not deal with all these details. If it becomes "easy" can do it by myself.

I also wanted to thank Nick for the work he has done and for the direct experience of the problem.
For my purposes I will use the instruments oversized (PCI and fast CPU) in order to have no impediment: as temporal resolution and as 1-bit DSP processing. There is a difference between a 10MHz microcontroller and a 1000MHz x86 processor...for example if you wanted to use a sampling time of 1 microsecond together with a DSP digital processing and a probabilistic processing. The best electronic cards have a frequency of 20 MHz Sample Rate. Some also have hysteresis on inputs, functionality COS (Change of State) via Interrupt ... Below I point to a general bibliography for the study.

In my discussion "MIDI latency / jitter performance" I used a software tool for measuring the loopback time MIDI distribution : https://github.com/raboof/alsa-midi-latency-test .
To be sure of the results I had to disable all energy saving BIOS/UEFI/CPU and use a realtime kernel. Allow active only 1 CPU core as if it were a microcontroller can help in some cases. it is sufficient to compare the results to make inferences. In this way you have a measuring instrument "professional" (remember that also measured the temporal noise of the PC). Basically just install linux Debian, a kernel-rt and you're at a good point ...
Soon I will insert a new version of the alsa-midi-latency-test software to customize the view of the measures which is now limited to 0.1ms. However, all samples are made with a nanosecond clock time!

The c code (alsa-midi-latency-test.c) is really bare-bones and can be used to do many things, even the pseudo-MIDI encoders we're talking as if we had a microcontroller...

In this way you know that the data I posted (on Asrock Z87 Extreme4) are not the result of my invention.

The Digital I/O Handbook - A Practical Guide to Industrial Input and Output Applications
http://www.sealevel.com/store/ref101-the-digital-i-o-handbook-a-practical-guide-to-industrial-input-and-output-applications.html
A Guide to Debouncing, or, How to Debounce a Contact in Two Easy Pages
http://www.ganssle.com/debouncing.htm
Ultimate contact debouncer
http://edn.com/design/components-and-packaging/4327390/Ultimate-contact-debouncer
Contact-debouncing algorithm emulates Schmitt trigger
http://edn.com/design/analog/4324067/Contact-debouncing-algorithm-emulates-Schmitt-trigger
Key Matrix
http://saroselectronics.com/key-matrix/
My favorite software debouncers
http://embedded.com/electronics-blogs/break-points/4024981/My-favorite-software-debouncers
De-bouncing circuits
http://www.ikalogic.com/de-bouncing-circuits/
Bit banging a contact closure input
http://embedded.com/electronics-blogs/embedded-round-table/4422830/Bit-banging-a-contact-closure-input
Using Push Buttons with PIC microcontrollers and Microchip MPLAB C18 example
http://www.mcuexamples.com/push-buttons-and-switch-debouncing-with-PIC.php
The secret life of switches
http://www.embedded.com/electronics-blogs/break-points/4024944/The-secret-life-of-switches
Solving Switch Bounce Problems
http://www.embedded.com/electronics-blogs/break-points/4024956/Solving-Switch-Bounce-Problems
How to make a keyboard - the matrix
http://blog.komar.be/how-to-make-a-keyboard-the-matrix/
Examining switch-debounce circuits
http://edn.com/design/analog/4345320/Examining-switch-debounce-circuits
Elia
Offline
User avatar

NickNelson

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostMon Jul 21, 2014 2:28 pm

elia wrote:The 61-key keyboards are typically constructed with a matrix of 8x8 16pin or a dual matrix 8x8 24pin (key velocity). The circuit is minimal: the track on the printed circuit, a diode and a switch button (or two switches for key velocity keyboards). From the electrical point of view it is difficult to tell if a Fatar keyboard is better than a consumer keyboard. The only important element is the Contact Rubber Strips that probably is a standardized component.
Obviously this is the first physical limit and surely the minimum response time will be at least double or triple the time to bounce.


Interestingly, I took one of these (M-Audio Keystation 61es) apart a couple of years ago. The contacts don't actually bounce at all.

Here are the results for fast (as hard as I could put the key down) , 'normal' and slow (ridiculously so) presses (top row) and releases.

Image

I've reduced the resolution of the image to make it easier to post, but it shows that for the fast and normal key presses and the fast release the complete transition takes less than 50uS. The normal and slow release times are about 1mS and the slow press takes about 2mS.

It's worth noting that the 'slow' timings were the result of my trying very hard to extend the transition times. In these cases the whole key travel took about three seconds. I can't imagine anyone actually playing like that.

There were some limitations to this experiment: The keyboard was virtually unused (and still is) and only one key was tried (bottom c). The experiment didn't use the supplied m-audio encoder, the switch-diode circuit was simply fed with 5V via a 39k resistor. I don't know whether the characteristics would vary between keys, though I suspect not. I think it likely that the characteristics might well change with use over time but I'm not in a position to verify or quantify this.

Nick
Last edited by NickNelson on Mon Feb 18, 2019 8:15 am, edited 2 times in total.
Offline

jkinkennon

Member

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

Re: DIY MIDI encoder: survey about hardware/software feature

PostMon Jul 21, 2014 4:09 pm

I did a quick test of the time it takes to transmit 20 keys via USB without including any debounce time. I get 1.2 ms to send 20 keys on the Mac mini monitoring with MIDI-Connections. I tried some round trip tests which were slower, about 4 to 5 messages each millisecond, presumably because the encoder is not set up to be particularly efficient at reading the incoming status and LCD display information.

So this is in line with what I was seeing on Windows and is about 20 times faster than standard MIDI transmission. It's important to note that the limitation here is not USB speed itself but the particular encoder implementation.

Nick, I liked that last post. I tried to do a velocity sensitive encoder a few years ago and never got to the point of getting satisfactory results.
Next

Return to DIY organ consoles / MIDI

Who is online

Users browsing this forum: No registered users and 5 guests

cron