MidiTest now comes in two flavours: 32 bit and 64 bit. There should be no
difference between the two, except that one of them runs native on a 64 bit OS (and
not at all on 32 bit). Also I fixed some bugs, justifying a new version number.
Why 4.12 and not 4.10 you ask? Just because I can!
August 15th 2010
MIDITEST UPDATE 4.9
More than three years without an update! To make up for it I bumped
the version by three points. Seriously. Development has continued but when
you have a day job there is never enough time. Nevertheless, enjoy this new version!
I must confess that I haven't been updating my comparative overview
anymore. To all the people that sent in results, my apologies. I just don't have the time
to add them. Also with all the options you can now set comparisons are a bit apples and oranges.
February 7th 2007
MIDITEST UPDATE 4.6
There were still a few problems left. Some small, some possibly important.
This is the best MidiTest yet.
January 29th 2006
BUG FIX RELEASE 4.4
Fixed a few bugs. One new option added. You can now specify if MidiTest should use the timestamps
given to MIDI input by the operating system. See the release history for
January 15th 2006
VERSION 4.2 RELEASED
A new version, offering minor bug fixes and cosmetic changes. Internally
the program has been redone completely. It now implements the Unified MIDI Model, my personal
invention. It encompasses all Windows MIDI handling methods and unifies them into one programming model.
November 16th 2005
MIDITEST ON SOUND ON SOUND DVD
MidiTest features on the Sound On Sound magazine's November edition cover DVD.
Sound On Sound is in my opinion the best magazine on music recording around. I am very
happy that SOS supports MidiTest!
November 9th 2005
FRESH VERSION 4.0
Only just recovered from the previous update, here is yet again a new
major update. And a nice one it is!
I completely reworked the entire application. Fixing things that didn't work
as they should, adding things that were missing. A whole list of changes.
See the entire list here
Be sure not to miss out on all the good stuff and download your copy of MidiTest 4.0 today!
September 25th 2005
MIDI DEVELOPER INFO
I added some important technical information for MIDI developers.
Read it here.
September 15th 2005
NEW VERSION 3.1
Good news! I decided to bump the version number from 2 to 3 to celebrate
a major break-through. I finally solved the DirectMusic versus system-exclusive
dilemma. I discovered a new way to access DirectMusic MIDI drivers, bypassing
DirectMusic altogether and thereby getting rid of this vexating problem.
For me this is the final proof that it is a bug in DirectX.
MidiTest now features a special 'Direct Mode' to access MIDI devices with
DirectMusic capable drivers. There should be no problems transferring large
system exclusive messages in this mode. Note that it will only work with
real DirectMusic drivers.
I think it is perfectly possible to incorporate this new access method in DirectMusic
capable applications (I am talking Cubase SX and Nuendo here). Finally it is
possible to have the benefits of DirectMusic without the drawbacks! And the best
thing is that it no longer requires the MIDI device drivers to be modified nor that we have
to wait for Microsoft to fix the bug in DirectX (it has been there for almost
10 years now, folks!).
By the way, Steinberg have updated their drivers for the Midex3 and Midex8 to solve
the system-exclusive problems with DirectMusic. I am very happy to say that they did
a good job. The drivers work. Whether they used the same approach as I did for the
8 Port SE and
Midi Translator PC
drivers I cannot say because they have not asked me for help. I have been approached
by Eckhard Doll, a Steinberg employee, asking for my opinion about this DirectMusic
trouble, which I was happy to give. I offered my help but apparently the developers
prefered to sort it out themselves. And they did, which is good. Yet I cannot help to
wonder whether they perhaps used a certain little program in the process.
February 10th 2005
NEW VERSION 2.10
This new version of MidiTest features the option to generate a logfile.
This can be useful for troubleshooting.
August 26th 2004
MIDEX, CUBASE SX AND SYSEX
Read all about the work-around I discovered to get system-exclusive working
with Cubase SX. It's all here.
August 21st 2004
STEINBERG DEVELOPERS DEFY LAWS OF PHYSICS
Having just received my Midex3 MIDI interface (after waiting for two months), I was
of course anxious to put it through MidiTest. However the results were a bit strange. They seemed
to be all wrong, something I had seen in earlier test reports of Midex devices sent to me by users of
MidiTest and which had puzzled me for a long time. I had to find out what this was all about and this was my chance.
After some investigations I made a remarkable discovery. Steinberg developers had found a way to bypass
one of the fundamental aspects of reality, the cornerstone of the thinking system we call 'logic'
even. In the new Steinberg universe information can arrive before having been sent, reactions can precede
the actions that caused them. My modest powers of reasoning were barely capable of coping with the
mind-boggling consequences of this scientific breakthrough, let alone that I could have foreseen it
when writing the MidiTest program.
To mend the errors of my ways I had to create a new version of MidiTest (hence the new version 2.9, hereby officially declared). It required me to invent the totally new
concept of 'anti-time' or 'negative time' just to make it all line up again. I will make a feeble attempt
to explain this concept that my own brain can hardly grasp.
In anti-time, causes are preceded by consequences. In a way we could say that anti-time flows backwards if we
see ordinary time as flowing forward. Within the context of MidiTest, anti-time means that a MIDI message
arrives at the input BEFORE it has been sent out through the output. This is exactly what Steinberg developers
have accomplished with the driver for the Midex (was it genius, madness or both at the same time, who is to say?).
Anti-time is indicated by putting a negative sign before the measurement. To put it in common language one could
say that a negative time value indicates the amount of time event B occured BEFORE event A that caused it. It is
a bit hard at first but after a while you get used to it.
The good thing is that it is still possible to do the statistical calculations that MidiTest requires, even though
negative and positive time values may be mixed in one test run. By the way, all the genius of Steinberg developers
couldn't prevent the Midex from appearing at the lower ranking positions of my comparative overview.
But rumour has it that Einstein also got low grades in school.
July 23th 2004
NEW VERSION 2.8
The new version of MidiTest adds information about operating system,
processor and processor speed and MIDI driver (driver version) to the
This extra information will also be used in the overview of tested devices.
See the overview here.
June 23rd 2004
NEW VERSION 2.6
Yet another version of the best (only) MIDI testing tool. A few bugs
have been fixed plus a brand new test report, revealing more facts about your
MIDI interface's performance.
MidiTest is a small utility that will test the speed and functioning of a
MIDI hardware device.
It's use is quite simple. You need a MIDI device that has at least one input and
one output. Connect the output to the input using a standard MIDI cable. Start
MidiTest. Select the output and the input with the drop-down lists. Click the
button marked 'Test' and the testing begins.
The application will start transmitting MIDI messages through the output. If all
is well the data will be received again through the input. The application
measures the time it takes for the MIDI data to travel through the hardware
and presents this data in a nice overview. The data can then be saved to a
text file for future reference.
Send in your results so I can add them to the reference database. You can see the list
Added option to continue testing on errors in asynchronous mode.
Enabling or disabling logfile now works without restarting the program.
System exclusive is now displayed in detail view as well.
Fixed bugs in detail view.
Added option to do iterative test by ctrl clicking test button.
Fixed issue with negative send times.
Added an asynchronous test mode, as opposed to the existing synchronous mode.
Fixed a bug where MidiTest would crash if no realtime messages were selected.
Many improvements in MIDI handling and statistic calculations.
Improvements to the random message generator. All MIDI channels are used now. Also it
seemed that only the first test run was truely random, next runs would always use the same
data. This is fixed.
Fixed a bug where changes to MIDI event type selection were only recognized
after the application was restarted.
Fixed a bug where system exclusive transfers would always fail in MME mode
if mixed with realtime events.
Corrected the tab order of controls, which was a little peculiar
Added option to use timestamp. By default MidiTest used the timestamp
of DirectMusic MIDI drivers, but not of MME MIDI drivers. You can now
tell MidiTest specifically to use or not use the timestamp offered by the operating
system. Depending on your hardware this can increase or decrease the timing accuracy.
Fixed a bug in closing of MME MIDI ports that could cause MidiTest to lock up
Fixed a bug where sysex size would sometimes be much larger than specified
because it was not read from the edit box properly.
API is now selected using a drop down list
Preload can now only be set when DirectMusic API is selected
DirectMusic direct mode is now called 'Kernel Streaming'
Added 'advanced' test mode which alternates batches of short MIDI messages
with system exclusive messages of varying sizes
Test run can now be canceled
MidiTest remembers settings across test sessions
Improved progress information
System exclusive messages of any size can now be specified. Size
does not have to be a multiple of 4 anymore.
MidiTest remembers settings across test sessions
Fixed some issues with MME testing
Fixed some issues with DirectMusic testing
Fixed memory leaks
Added 'direct mode' for accessing DirectMusic capable MIDI device drivers
Log file now contains information about types of MIDI messages
Fixed a bug where large sysex transmissions would fail in MME mode
Added option to generate a log file
Modifications to enable testing of Midex devices
Test report now includes information about operating system, processor and MIDI device driver
A unique file name, based on system date and time, is generated every time a test report is saved
Testing now starts off with a few test messages to stabilize the ports (some hardware showed bad measurements on first messages)
Invalid timestamps are now reported as errors in the test report (DirectMusic only)
Fixed rounding erros in calculation of jitter
Added new quick jump buttons along with an 'about' button
Added fancy splash screen with interesting information about myself
Measurements are now split into per message statistics and per byte statistics
Detail view now shows measured time per message and per byte
Added calculation of jitter
Fixed bug where sometimes an invalid message was generated by the random message generator. This
would result in MidiTest reporting that no data was received and showing an empty string
as the last sent message.
Fixed bug where measurements where not put into the right range when testing with MME
Fixed bug where program crashed if hide detail was unchecked when no tests had been done
It is now possible to select the types of messages to participate in the test
Messages are now randomly generated
Fixed a problem with sysex testing under MME. Larger messages would always time out
It is now possible to set zero size for messages and sysex
Improved reporting of test results
Added ability to choose between using either DirectMusic or MME for MIDI testing.
DirectMusic and MME are two different ways to handle MIDI on the Windows platform.
Test report modified to reflect new options
Fixed a bug with enumeration of ports that could crash the application if there were
too many devices.
First publicly released version
DirectMusic And System Exclusive
While I was working on MidiTest I became aware that there seems to be a problem
between system exclusive and DirectMusic. Many people will experience this if they
run MidiTest in DirectMusic mode. The transfer of system exclusive messages larger than
a few hundred bytes will fail in almost all cases.
This puzzled me for a long time and I spent quite a lot of time investigating this problem.
My final conclusion was that the problem is caused partly by the way DirectMusic handles
sytem exclusive and partly by the way most drivers of MIDI equipment are structured.
For my own driver for the 8 Port SE
I was able to resolve the problem by completely restructuring the driver. The 8 Port SE is now
capable of transferring system exclusive messages of any size errorfree when using DirectMusic.
From results I have seen of tests with other MIDI devices I believe that the 8 Port SE is quite
unique in that capability.
To most users this will not be of much importance. The majority of MIDI applications use MME
for MIDI processing. The problem does not exist with MME. If you are a user of Cubase SX however,
and you rely on system exclusive for communication with hardware equipment, then this does become
Ever since the release of Cubase SX, users have indeed complained about problems
with system exclusive. To me it became apparent that the problems I perceived with
system exclusive and DirectMusic were directly related to the problems between
Cubase SX and system exclusive. When Cubase SX succeeded Cubase VST as the new
top-of-the-bill sequencer from Steinberg, it's internal audio engine had been completely
reworked. As part of this restructuring the MIDI engine had also changed from MME to DirectMusic.
That's when the trouble started.
At this point I'd like to stress that I am not saying that I think the decision to change from
MME to DirectMusic was wrong. DirectMusic has a lot of good things that can lead to better MIDI
applications. I think that is certainly worth keeping. On the other hand I would very much like
to see the system exclusive problems fixed. Even though many people will never use and never need to
use system exclusive in their life, there are still a large number of people that rely on it.
I have been trying to raise awareness of this situation by posting on the Cubase support forum.
The way I see it Cubase SX users are the largest group of people that will benefit
from this problem being fixed. It seems that Steinberg themselves are now finally
taking steps to at least investigate the system exclusive problems. Let's hope that
this will lead to a solution in the near future. I myself have more than once offered
my assistance as I think that the solution I implemented for the 8 Port SE driver will
work for other devices as well.
You can read some additional information about DirectMusic and MME here.
Cubases SX And System Exclusive
Recently I made a discovery that changed my view on the system exclusive problem
that exists with Cubase SX. Up till now I believed that Cubase SX only used DirectMusic to handle
MIDI. I was wrong. That is not the complete story. Cubase SX can and does use BOTH DirectMusic and MME to handle
MIDI. I started to suspect that this was the case some time ago and only just a couple of days ago
I took the time to test my suspicions when I received my Midex3.
As soon as I had confirmed my suspicions that both MME as well as DirectMusic were used (by trial and error as Steinberg does not
provide this information), I realized that this also meant that it should be possible to solve the system
exclusive problems with Cubase SX. I still am 100 percent sure that DirectMusic and system exclusive is an impossible
combination, due to faulty drivers (my own drivers for the 8 Port SE
and the Midi Translator PC work, but as far as I know they are the only ones).
But system exclusive never was a problem with MME and there is no reason why that would have changed.
The only thing we have to do is force Cubase to use MME and not DirectMusic. How can this be done?
If you start Cubase and open the Device Setup dialog you see a list of devices on the left hand side. Among those, one
is called DirectMusic and one is called Windows MIDI. The rule I discovered is that if you pick a port from
the DirectMusic list it will be addressed using the DirectMusic API and if you pick a port from the Windows MIDI
list it will be addressed using the MME API. This sounds simple. But Cubase has laid a few obstacles on the road.
The first obstacle is that Cubase doesn't really want you to use the Windows MIDI ports. By default
they are hidden. The Windows MIDI list is empty. This can be circumvented by using the 'ignoreportfilter'
file. By moving this from the directory 'MIDI Port Enabler' to the application directory you disable the
hiding of ports. Once you have done this you will see that MIDI ports appear either three times or two times.
This depends on whether the driver for the MIDI device is a true DirectMusic driver or a standard
WDM driver. If the driver is a true DirectMusic driver, all ports will appear three times. If it's a WDM driver
(or an even older type of driver), all ports will appear two times.
Of the two sets of DirectMusic ports at least one set has the word 'emulated' behind the port name. So if you
your device has a standard WDM driver, all the DirectMusic ports have 'emulated' behind their name (a great way to tell whether
the driver is a true DirectMusic driver). Emulated ports are still addressed using the DirectMusic
API so for system exclusive they are not suited.
So if we have a true DirectMusic driver we have to determine which port is the Windows MIDI port
and which is the DirectMusic port. Unfortunately their names are not very helpful. They
both have the same name. However it is possible to change the names of the port. If you add for
instance the letters 'WM' to the port names of the Windows MIDI ports you will be able to distinguish
them from the DirectMusic ports.
For the lazy Cubaser: I found that the Windows MIDI ports always appear at the bottom of the port selection
list when you choose a port for a MIDI track. I don't know for sure whether this is always the case but I
think it is. It is probably safe to distinguish the two types of ports by that method as well.
CAUTION: One thing you must never do when you have deactivated the ignore port filter is select 'All MIDI inputs' for
a MIDI track. It will cause doubling of the MIDI information because it will arrive through two versions of the same port.
The issue described in the section below has been fixed in Cubase SX version 2.2 (thanks
Jay Levitt for bringing this to my attention. Read his informative page on MIDI issues with
Cubase SX). The ignore port filter
now also works for the Midex. It may still be fun to read though.
Ok. We have taken the first hurdle. But for Midex users a new one is appearing. Believe it or not
the ignore port filter does NOT work for the Midex. Isn't that funny? Not really.
The good news is there is a little trick to outwit the Steinberg developers and make the Windows MIDI
version of the Midex ports appear. The filter that hides the Windows MIDI versions of the Midex ports is rather simplistic. It looks
at the name of the port and if that starts with 'Midex' it is hidden. What we need to do is change the name of the port
and the filter will no longer recognize it as being a Midex port and it will become visible.
Unfortunately in this case it is not enough to change the name of the port within Cubase. We have to change the
name of the port as it appears to the system. This is not easy but it can be done. Of course it would be
a much better idea if this silly restriction would be removed from Cubase all together.
How are we going to change the name of the Midex port(s)? The only way I know of is to make some changes to
the Windows registry. This can potentially damage your system so if you plan to do this you will do so at your own risk
(this is to protect myself from law suits, if you are an experienced registry hacker the risks are
actually small). For safety it is advisable to make a backup of the registry before you start fiddling with it.
The registry key we are looking for is:
The part behind 'USB' will actually be different on your system. It contains a hardware ID followed by a unique identifier.
The hardware ID is VID_0A4E&PID_1101 if you have a Midex3 or VID_0A4E&PID_1100 if you
have a Midex8. The hardware ID is used by the Windows Plug and Play system to determine which driver to install
for a device.
The unique identifier is exactly what it's name suggests; it is unique. It will never be the same
on two systems (at least the changes that it would are very small). The unique identifier is used to distinguish
the Midex's that might be installed on your system (it is possible to install more than one on a system).
Because the unique identifier is not known beforehand you have to do a little searching to find
the exact key.
Once you have found the key and you open it, you will see a list of subkeys named '#MIDEX31', '#MIDEX32' or '#MIDEX81', '#MIDEX82'.
This depends on whether you have a Midex3 or a Midex8. Open one of these subkeys and you will see that it has
yet another subkey named 'Device Parameters'. One of the values under this subkey has the name 'FriendlyName'.
That is the one we're looking for. This value should be changed to something else, for instance 'Bratwurst' or anything
else you might like. Be careful to change the VALUE not the name of the value. That should stay 'FriendlyName'.
Make sure you also keep the port number or you will get confused which port is which. Rename all the
ports you plan to use for system exclusive. For the Midex3 you will only need to rename the first port
because there is only one input and this workaround is only needed for inputs (DirectMusic ports can send system
exclusive but not receive it).
There is one more problem with the renaming of the ports. Every time the Midex is restarted it will change the
names back to the way they were. This means that after a reboot you will have to do the renaming again. This is a pain
and I hope that Steinberg can release a quick bug fix to remove the Midex restriction of the ignore port filter so it will no longer
be necessary to change the port names.
One way to make the renaming of the ports easier is to export the registry settings to a 'reg' file once
you have changed the port names. A 'reg' file you can activate by double clicking it. It will then automatically
change the registry values for you.
So now we have our Windows MIDI version of the Midex port available and we can test if system exclusive recordings
really work now. Oh wait, there is yet another problem. I found that I could not record MIDI through the Windows MIDI
port unless I disabled the DirectMusic version of that same port. You can do this from the Device setup dialog.
Go to the DirectMusic port list. The rightmost column has the header 'Show'. Set this value to 'No' for the port
you want to use as Windows MIDI port. Also set this value to 'No' for the emulated version of the same port.
Now we can finally do a test to see if it works.
I used the following test setup to verify that system exclusive recordings were now succesful. I used
a (free) application called Midi-Ox (www.midiox.com). I have a Midex3
so I also used that. I connected output1 with input1 by means of a standard MIDI cable. I started Midi-Ox
and opened Midex output1 with it (only open the output, otherwise Midi-OX will start to feedback). I fired up Cubase SX
and created a MIDI track. The input of the MIDI track I set to the Windows MIDI version of the Midex
input1, now going under a fresh new name. The output of the MIDI track I set to 'Not Connected', the channel
I set to 'Any'.
I opened up Midi-Ox's sysex dialog and loaded this system exclusive file. I set
the MIDI track in Cubase to recording and started recording. I switched to Midi-Ox and told it to start sending
the sysex file. After it had finished I switched back to Cubase and stopped the recording. I now had a recording of the
system exclusive file that had gone from output1 through a MIDI cable to input1. I exported the system exclusive
data to a sysex file and did a binary compare of both files. The files were exactly the same.
For anyone who still has doubts about whether DirectMusic and system exclusive work together: do the exact same
experiment but this time use the DirectMusic port to record the sysex data. I can guarantee that you will not succeed
in getting the sysex recorded without errors (unless you have an 8 Port SE
or a Midi Translator PC together with the DirectMusic
driver that was developed by me.
I hope that everyone realizes that what I describe here is a work-around. It is not an ideal solution and I only
recommend to use it if you want to be able to record system exclusive. I am still unsure whether the Windows MIDI
ports and DirectMusic ports can be mixed (used at the same time) without causing new problems. I also believe
that if your MIDI device has a true DirectMusic driver it is much better to use the (non-emulated) DirectMusic