It saddens me that you failed to prove me wrong. I know you are better than this.
kind regards,
Carey
ET - Carey can speak for me on the subject of you at this point. 
You are just acting out something, not clear what. People do come here for help. Giving you the benefit of the doubt, I can almost see where, if you have been of help to a lot of people and received no thanks for it, that you would now want to punish those who seek help. Kinda twisted, but, eh, I have watched Criminal Minds, I get it.
But moving on, if you can still speak to me directly for a moment, I wanted to say that where you took exception to me copying and pasting a file, MS says this is the better method than dragging and dropping, cutting and pasting, etc. Google it I guess, knowledge is king right? And the bottom line is that Cubase found the file and performed as it should have, listing all the ports. Which is what I needed it to do.
If a poster is not doing anything for the thread just glaze by. You just end up commenting about the poster rather than getting anywhere near a solution.
I repeat. Comedians don’t like being laughed at.
But I have to ask. Who’s a comedian? 
Has anyone tried any other forums to see if anyone there has a solution?
You’ve been here a long time. No joy yet.
Been everywhere tried everything apart from actually getting a MIDI controller that is known to not have any issues and trying that on my system.
I’d like to know what MIDI controllers are not showing this problem.
If it worked, cool. I was going by the instructions from Steiny themselves where they say to Move it. That’s what I do and it’s always worked so… . Also, the ignore port filter file has been superceded by another file. Surprised it worked for you, but the result is the key. 
[quote=“LeVzi”]Been everywhere tried everything quote]
No you haven’t. If you had it would have been working by now. The answer’s been given, but you haven’t bothered to read the article closely to see where you’re going wrong. This issue has been cured WITHOUT FAIL on PC’s. Doesn’t it say something to you that you’re the only one not to be able to solve it? Were it me, I go over the instructions with a fine tooth comb to see what I was missing.
I have been reviewing your posts to try to understand the exact issue you are trying to solve. From being on the forum now for a couple of months, it seems there are two main “issues” with MIDI:
-
From Joel’s thread, users are looking to have the DAW adjust for VSTi latency and place the MIDI to align with the VSTi output.
-
From this thread, independent of VSTi latency, the DAW is not placing the MIDI notes properly to begin with.
Which issue are you trying to solve? From some of your posts, it seems like #1, however then you are talking about using different MIDI controller to solve the issue. I recently purchased the Fireface 800, and my MIDI placement is now tighter than my Firepod. It is approximately 2-3 ms off from the keythump audio placement. And this behavior is the same for any Fireface latency setting.
For #2, how many msec are you off in the MIDI placement with key thump test?
I’m going to post a copy of some info that is interesting. It seems all of the midi timing info I can find via Google is old and I don’t know why this is except maybe a lot of timing issues were resolved as the OS or recording software changed, dunno. What I want to say at this point is that - apparently - I was wrong to use an emulated port with C6.5. And I was also wrong to use the file (port enabler)that I transferred to the Steinberg folder. It would seem this is old hat and not necessary. So I removed the folder, and I am now using a Direct Music port that is non-emulated. ?? Sounds fine to me timing-wise but then so did the emulated port. Here’s the copied info from someone named ‘Richuill’ from Gearsluts. (I also read in SOS that it is wise to adjust your VST instrument to the latency of your ASIO driver, so I did this also. There’s an interesting article there written in 2001 or so, dated stuff again.) At the bottom were listed some devices that work with ‘System Timestamp’ settings or not. My little Uno 1X1 is listed there actually so I may be on the right track. Hope this helps someone.
PC Windows MIDI port configuration and troubleshooting
This article mainly applies to PC Windows systems running Cubase SE/SL/SX 3.0.1 and Nuendo 3.0.1 or higher only but contains general information for all users of previous versions too (e.g. Cubase LE).
General advice for using MIDI on PC Windows systems
These are the basic steps to check when you experience problems with the stability of MIDI communication on your PC system:
• It is recommended to have DirectX9.0c installed! Please update the DirectX version if this is not the case. DirectX9.0c is automatically installed with Windows XP SP2. You can also download the current version separately here.
• If you have persistent timing problems (shifted notes etc.) with native or emulated DirectMusic ports please check the option “Use System Timestamp” provided in the DirectMusic section of the Device Setup dialogue. This option uses another timing reference in your system when enabled.
• The option “Use System Time Stamp” is also available for Windows MIDI ports since Cubase SE 3, SL & SX 3.1 and Nuendo 3.1.
• If you experience trouble while receiving/transmitting SysEx data through native or emulated DirectMusic MIDI ports please check if the Windows MIDI (MME) ports can be of help. To gain access to all available driver architectures please see sections below about the “ignoreportfilter” & “enableemulated” switches.
Further details using MIDI on PC Windows: What´s the issue?
Using MIDI interface port drivers on PCs with Windows XP in conjunction with cutting edge MIDI/Audio sequencer applications like Cubase SL/SX or Nuendo, which mainly rely on Microsoft’s current DirectMusic (as part of DirectX) API for MIDI communication, can sometimes be confusing for the user. This is due to the fact that it is possible for providers of MIDI interface drivers to deliver their drivers in different “flavors”. Modern MIDI interfaces like Steinberg’s MIDEX 3 and MIDEX 8 interfaces are installed with real native DirectMusic drivers whereas it is still quite common for other interfaces to use a predecessor API to provide drivers for the Windows MIDI system. DirectMusic itself has a function to “mirror” these Windows MIDI ports to show up as “emulated DirectMusic” ports. Unfortunately, this can lead to a quite nice array of problems when using an inappropriate port driver architecture:
• Using emulated DirectMusic ports often results in shifted MIDI events while recording (events are recorded too late or too early)
• Sometimes no MIDI events are recorded at all
• Sometimes stuck notes or several events stacked on top of each other are recorded instead of being consecutive
• Generally bad or wacky MIDI timing on playback
• Double or triple recordings of the same MIDI events due to using different driver architectures at the same time
Former versions of Cubase SL/SX and Nuendo (before 3.0.1) used a MIDI port filter to guess the most appropriate MIDI interface port type. The detection often displayed native DirectMusic drivers (if available at all) and the emulated versions of installed Windows MIDI drivers per default. But as most interface drivers are delivered for Windows MIDI only, such interfaces could be only used as emulated DirectMusic drivers with the consequences described above. Intervention from the user was needed to unhide the filtered Windows MIDI ports followed by a necessary re-configuration of the MIDI Setup in the Device Setup dialogue to make sure that no ports are used twice or three times due to the disabled MIDI port filter.
The new MIDI port filter used by Cubase SL/SX & Nuendo 3.0.1
Since the release of Cubase SL/SX & Nuendo 3.0.1 we have changed the filter mechanism to pick the MIDI ports provided by the MIDI port drivers of your Windows system.
From now on the default behavior will be as follows:
• If native DirectMusic drivers are present these ports will be used (e.g. for the MIDEX 3 or MIDEX 8 MIDI interfaces)
• If there are no native DirectMusic drivers available the Windows MIDI (MME) ports will be used instead of emulated DirectMusic ports as it was the case in previous versions
• Emulated DirectMusic ports won’t be used any longer by default!
This should be the most common solution for most setups, especially for users having issues with MIDI problems due to emulated DirectMusic ports in the past.
A manual configuration of MIDI ports should no longer be necessary.
Advice for a proper MIDI port setup
If you have updated from previous versions of Cubase SL/SX or Nuendo to version 3.0.1 please make sure to check the following points:
• If you have used the “ignoreportfilter” file in the past to get your Windows MIDI ports displayed please move this file back into the folder “midi port enabler” inside the program application folder where Cubase or Nuendo has been installed. It is essential to ensure that this file is no longer available in the main folder of the application but in the “midi port enabler” folder only.
• After that please check your MIDI port configuration in the menu >Devices >Device Setup… and look in the section for “DirectMusic”. You should not see emulated ports any longer, instead the application has detected the appropriate MIDI ports dependent from the used architecture of the MIDI port drivers automatically
How to deal with “Pending Connections”
While the improved filter mechanism leads to easier handling and configuration of your MIDI ports it may occur that you see a “Pending Connections” dialog on loading projects saved with versions prior to 3.0.1. This happens when your project file had e.g. emulated DirectMusic MIDI ports assigned to MIDI tracks. As these ports are no longer available per default the application asks you to resolve such connections.
Upon loading such a project the following will happen:
• A ???Pending Connections“ dialog will appear
• This dialog suggests the appropriate Window MIDI ports automatically to resolve pending connections to former emulated DirectMusic ports used
• Accepting this dialog with “OK” loads the project with correctly re-connected MIDI tracks without further intervention by the user. However you can also re-route the ports by yourself if needed.
• The application also saves such re-routings in the “default.xml” file within the preferences of the application to know how to re-route pending MIDI port connections in the future.
Additional possibilities to configure MIDI ports (for troubleshooting only)
It is still possible to use the “ignoreportfilter” file in the same way as prior to Cubase SL/SX & Nuendo 3.0.1. Additionally, there is also a new file called “enableemulated”. These two files are stored inside a folder named “midi port enabler” which can be found inside the Cubase / Nuendo application folder.
This will happen when you use these files:
• “ignoreportfilter” will show you every MIDI port installed on your system independent of the used driver architecture. When you use e.g. a MIDEX 3 or 8 you can use this to get the Windows MIDI ports of the MIDEX displayed inside the application (additionally to the already displayed native DirectMusic ports). Generally speaking, the “ignoreportfilter” disables any filter to hide specific MIDI port architectures.
• “enableemulated” will show you all emulated DirectMusic ports but will not unhide Windows MIDI ports itself. This can be necessary if you have problems with the Windows MIDI ports of your MIDI interface but there are no native DirectMusic ports available for your interface. Fortunately, this situation is happens only in a very rare number of cases.
These files are used as a sort of “switch”. To use these “switches” just move the desired file from the folder “midi port enabler” one level up to the main application folder, e.g. to folder “\program files\steinberg\cubase sx 3\”.
Please note that using these files makes it mandatory to check your MIDI port setup inside the application for redundant MIDI ports (i.e. those that appear twice or even three times). Use menu >Devices >Device Setup… for this. You should not use more than one driver architecture for a specific MIDI device at a time. For example, using the “ignoreportfilter” with a MIDEX 3 or 8 will show you the native DirectMusic ports listed and the Windows MIDI ports at the same time. This means that you will record from two ports at once when your MIDI tracks are set to “All MIDI Inputs”. To solve this, please deactivate the ports either for DirectMusic or Windows MIDI.
May 15, 2004: Technical
PC MIDI Timing and Nuendo
Updated
Users of Steinberg’s Nuendo and Cubase often run into trouble with MIDI timing. I’m not affiliated with Steinberg, but I am a programmer, and I’ve done a lot of experimenting with MIDI timing on the PC. Here is, I hope, the definitive list of problems and workarounds. Note that I talk mostly about Nuendo here, but Nuendo and Cubase SX are the same application under the covers, and everything I write applies to both. The explanations are lengthy, but it’s a complicated topic, where many problems can cause the same system, and I think it’s important to understand the background; if you think I should provide a long and short version of this FAQ, leave a comment to that effect.
- Emulated Ports
By far, the most common cause of MIDI timing problems is using emulated MIDI ports. Once upon a time, there was only one type of MIDI driver, known as Windows MIDI. Later on, Microsoft introduced a new driver type, DirectMusic, which could theoretically offer better timing, but due to some limitations, this was mostly taken advantage of by gaming cards, not pro-audio cards.
To encourage application developers to switch from Windows MIDI to DirectMusic, Windows provides “emulated” DirectMusic ports for all Windows MIDI drivers; as far as the application knows, it’s talking to a genuine DirectMusic driver, with Windows doing the translation under the covers. This means that an application like Nuendo can, in theory, be written solely to the DirectMusic interface, and if your card doesn’t actually support DirectMusic, Windows will cover for it.
The reality is more complicated; sometimes the emulated DirectMusic drivers don’t work at all, or only work in one direction. Sometimes the emulated ports don’t work but the original Windows MIDI ports do. Sometimes the timing is off on one port or the other. Sometimes there are actually both Windows MIDI and genuine DirectMusic drivers for a device. So if there is both a Windows MIDI and DirectMusic version of a port, Nuendo tries to guess which one is the right one, and it filters out the other. Sometimes—usually, in my experience—it guesses wrong, especially where emulated ports are involved. And on some systems, though certainly not all, the emulated ports have timing problems.
(By the way, these two driver types—driver APIs, really—have nothing to do with WDM vs. MME drivers. Those are driver models, and affect how a driver is built, not what API it uses. A WDM driver can be either Windows MIDI or DirectMusic, and I believe the same is true of MME. We don’t care about WDM vs. MME here.)
The fix
Nuendo keeps a zero-length file called ignoreportfilter in the directory C:\Program Files\Steinberg\Nuendo\MIDI Port Enabler. Using Windows Explorer, you can drag this file up one level to the Nuendo directory, restart Nuendo, and you will now see both the emulated and non-emulated ports. In my experience, you nearly always want the non-emulated ports; you should go into Device Setup and set “Show” to “No” for the emulated DirectMusic ports so that you don’t accidentally use them.
This will only solve your problem if yours is a system where the emulated ports have timing issues. On my system, they don’t. - The two-clock problem
All MIDI interfaces on Windows timestamp their data before providing it to the application. This avoids timing problems when the application doesn’t immediately see the incoming notes, perhaps due to higher-priority interrupts, or things chewing up CPU time, or simply a burst of notes too quick for the app to process. The app just looks at the timestamp, does a quick calculation, and poof: instant latency compensation for all MIDI. This has been part of the MIDI driver spec forever.
But Windows provides two different multimedia timers - specifically, one called timeGetTime, or TGT, and one called QueryPerformanceCounter, or QPC. The QPC timer is more precise (although the actual precision is up to the motherboard), and often more accurate, but it’s only available on newer versions of Windows, and there were some motherboards a while back that had major inaccuracies with it, and some current dual-CPU boards still don’t keep the two CPUs in sync.
So drivers, especially Windows MIDI drivers, that descend from older code, or have to work on older OS’s, or that are simply more cautious, are likely to use TGT, which is what Nuendo normally uses; the VST and ASIO specs are based on TGT. Newer drivers, especially those written under DirectMusic, are likely to use QPC. Since the two end up out of sync on most PCs, you’ll end up with timing problems in Nuendo if your MIDI driver uses QPC.
This problem is likely to affect any sequencer, not just Nuendo - although some sequencers might be based around QPC instead of TGT, and thus they’ll have problems with exactly the interfaces that work fine on Nuendo and vice versa. Sonar does have a hidden option that lets you ignore ALL timestamping from the interface, which is fine unless Sonar can’t keep up with the interface, at which point you’ll have really sloppy timing on ANY interface.
The fix
Nuendo and Cubase 2.20 provide an option in the DirectMusic settings called “Use system timestamp”. This tells Nuendo that for MIDI tracks, they should keep track of time using QPC, not TGT. This affects only DirectMusic drivers. That means that if you have a Windows MIDI driver that uses QPC, you’ll have to use the emulated DirectMusic drivers, which is the exact opposite of what is normally recommended! Hopefully future versions will offer this option in both DirectMusic and Windows MIDI flavors. Meanwhile, hopefully your system isn’t one of those that has timing problems on the emulated ports. My system, an Asus P4C800-E, doesn’t, but certainly some do. A future version of MIDITime will test DirectMusic emulated ports as well, so you’ll know exactly what you’re up against.
The test
If you want to be certain that this is the problem you’re having, and help out the user community at the same time, you can download my MIDITime Utility. You take a cable from a MIDI output port to a MIDI input port, and run the utility until your clocks get out of sync; it then tells you which clock is correct, and thus what setting to use. Simple and definitive.
And please, if you run the utility, and your interface isn’t already listed below, e-mail me the results so I can share them! (I’d prefer that you not leave them as comments, so others don’t have to wade through the details.) The utility can take up to an hour to run (it waits that long to decide that your clocks are staying in sync), but more often takes about 5 minutes.
If there are any Windows programmers out there interested in slapping a simple GUI on this app, drop me a line. I never bothered to learn MFC, and with Windows.Forms and .NET coming of age, it’s not really worth it now.
The results
The following MIDI interfaces will work best with the DirectMusic emulated ports and the “Use System Timestamp” option checked:
• Echo Mia
• EMU 1212M
• Frontier Design Dakota
• M-Audio 410 Firewire
• M-Audio Audiophile 2496
• MOTU 828 MKII
• MOTU Express XT
• MOTU MTP-AV
• Steinberg MIDEX-8
• Terratec EWS88MT
• Yamaha SW1000XG
The following MIDI interfaces will work best with the native DirectMusic ports and the “Use System Timestamp” option checked:
• Wami Rack-24
The following MIDI interfaces will work best with the “Use System Timestamp” option unchecked, and (presumably) the non-emulated Windows MIDI ports:
• Aardvark LX6
• Aardvark Q10
• Edirol UMT-880
• Digi 001
• Emagic Unitor8 MK1
• Emagic Unitor8 MK2
• Emagic AMT-8
• M-Audio MIDISport
• RME Digiface
• RME 9632
• Roland SC-8820
• Roland Super MPU-64
• Roland UM-4
The following lucky motherboards have clocks that don’t drift, and so can use any interface with any setting:
• Asus A7V333
• Asus A7N8X-X
• Asus P4D-800D
• Asus P4T-533C
• Asus TUSL2-C - Constrain Latency Compensation
One person has reported that using the Constrain Latency Compensation option—which should, in theory, affect only audio—also improved his MIDI timing. This has not been confirmed by other reports, but it’s certainly easy enough to try. If you find this setting to be helpful, please let me know.
Maybe you explained and I missed it…how are you actually getting MIDI into the PC? USB? Which product/driver?
Rumor has it that only RME has the DirectMusic drivers, but sounds like other products offer this also. Good to know for everyone’s knowledge.
FWIW, some data using the “thump test” from my system, 5 thumps, with the following configuration (44.1K, 256 sample buffer):
a) Yamaha Motif synth audio directly to interface audio in (M-Audio Delta 66 card, housed in an Omni I/O breakout box),
b) Yamaha Motif MIDI via USB MIDI cable to computer USB in (not to the interface), and
c) The microphone transmitting the mechanical thump of when the key is struck.
RESULTS:
-
The microphone thump audio was always printed about 2-4 msec earlier than the audio and the MIDI that travelled from the key through the Motif was.
-
The MIDI note was always printed within 1-2 msec of the audio signal that travelled through the Motif - usually 1-2 msec after, but on one occasion 1 msec before, the Motif-generated audio.
So the MIDI from my synth arrives within 1-2 msec of the audio from my synth, and both arrive 2-4 mseconds after the signal down a mic cable does (the cable that measured the “thump”).
Good Test. I’m going to do the tests again with all three signals from my V-Drums.
I think the question now is, what is an acceptable and non-acceptable msec difference?
Just a related comment, I have been analyzing my V-Drum playing in more detail and it seems that I am playing before the beat (i.e., click). After researching a little more, it is common for many pro drummers to anticipate the beat and play before it. Looks like for some of my songs I am 15 - 20 msec before the beat (on average). Would be interested in hearing some comments on that subject. Maybe it is ok or maybe I need to tighten things up.
Although the Time Stamps in the MIDI stream of the 64bit DirectMusic driver have a resolution of 100 nanosecond, while the Windows MIDI has a timer resolution of one millisecond, I doubt this is the cause of the trouble some people experience with their MIDI placement.
I absolutely do not notice any great differences in playing MIDI through the Windows MIDI port (USB Controller with Generic USB-audio driver) or DirectMusic (RME driver).
Yes, when I test my RME cards, they are absolutely rock solid with an average MIDI send and receive time of 0.90ms over 30000 messages.
But I doubt if these small numbers are noticeable for a mortal keyboardist, given the fact the average human reaction time is somewhere around the 180ms.
Unless you have very old drivers or driver problems, I would not use “Emulated” ports in Windows 7, because they are what the are, emulated.
In other words, the Windows MIDI ports are translated into Direct Music by the OS which usually adds latency.
I would start to just check out the MIDI behaviour of the device with a tool like MIDITest or just record some MIDI data from your out to your in and compare both.
Values like 1/16 or 1/32 too early are subjective. Rather describe it in ms or samples (with samplerate).
Interesting thread (both for the odd comments and the wealth of info posted above). I use the MIDI ports on my RME FF400, which are DirectMusic based, and noticed an improvement in the MIDI timing of my recordings by simply ticking the “Use System Timestamp for ‘DirectMusic’ Inputs” option is the Device Setup window. The timing wasn’t too bad before (slightly ahead though), but now it is spot on. Granted, I didn’t perform any scientific test to measure the timing difference before and after. I simply recorded a major scale with as much precision as I could (w/metronome ON of course) and compared the differences.
Bottom line, if you own an RME FF400 and want to improve the MIDI timing of your recordings then checking the option mentioned above could be the solution for you. YMMV.
I think it’s #2, that the MIDI notes get printed early. And they are out by 1/32th exactly no matter what the tempo (Thump test) when I record a set of MIDI notes, if I group them all up then shift literally 1/32th later, it aligns perfectly (Within human tolerances) on the beat.
Hmmm, interesting. 120 BPM, then 1/32 = 15 msec. 60 BPM, then 1/32 = 30 msec. I have no explanation for the time difference being related to BPM. Just for sanity’s sake, no MIDI Quantization, correct?
FYI, to see the actual msecs, you can zoom in with the cursor and see the actual time in the transport bar.
There will always be some quantisation. If you work it out at default in Cubase prefs the ppqn is set at 4096pulses per quarter note. You could try increasing this and see if that makes any difference to the note placement you’re getting.
Quantise off is what I’d call “incoherent” quantise where the timing could be arbitrary and quantise on is where it should be more coherent.
4096 x 1 bar at 120bpm (ie: two seconds per bar of 4/4) = 8192 pulses per second. ie: 8192ms.
So without making too much of it you could see if that has any bearing on your own calculations. And I hope my math is right.
8192ms is 8.192 seconds!!!
See the math is dodgy. 8192 pulses per 1000ms at 120bpm.
Probably still rump about face somewhere.
But if it’s relevant it should mean changes in timing placement at different bpms.
Yep I can only count three. After that I usually hit something.
The wall!
That’s drummers for you
Just a comment on the ‘thump test’. I don’t see where this is a valid test. Case in point, in the case of my keyboard anyway, the notes don’t even trigger the sound until the key is pressed 1/8" down. So here I would be hearing the click of my finger striking the key and there would be a delay to the note right from the gate.
On the other hand, if I record a track to the click and then double click it into edit land for a look, I can clearly see the midi note and where it sits on the bar line. It should be starting right on the vertical bar line on playback if you are playing right on the beat. And I can do this without a problem.
So the question remains, are all keyboards like my keyboard? Prolly not, maybe not, I dunno. So, considering this, I think that every player has a ‘thing’ that naturally happens, that you sense where your instrument makes a sound, and then you play the instrument to the beat. So looking at the recorded midi note - as it lines up to the beat - seems the best way to determine if your midi send is working properly. THAT SAID — if the player is playing along to the beat and it sounds correct, but yet when examined, the midi note is way off the vertical beat line, then I would agree there is maybe a midi timing issue. As to drummers (or anyone) playing ahead of the beat, well, it happens. It would be a shame to fret over midi timing issues when in fact it is the player, eh?
My .02.