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 here.

	MidiTest 4.6
See the version history to learn what's new.

 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 (http://8portse.earthvegaconnection.com) 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 important.



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.



If you are interested in the latest status, read the following thread on the Cubase forum: http://forum.cubase.net/forum/Forum2/HTML/063927.html



You can read some additional information about DirectMusic and MME here.

 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:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{6994AD04-93EF-11D0-A3CC-00A0C9223196}\##?#USB#VID_0A4E&PID_1101#4&A1B1B45&0&2#{6994ad04-93ef-11d0-a3cc-00a0c9223196}


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 ports.