Hi there! It's been a while, but I have always looked through the other mails coming into my mailbox and allthough I had no idea how I could help the others guys at all, I found the topics to be very interesting and informative. Well, the last time I asked you guys for help, I was about to create a virtual MIDI driver, to create a software that can manipulate midi data. After some explanation from you guys, I had to realize, that my programming skill level wasn't yet sufficient enough to get it done. With the help of Tobias Erichsen and his amazing Virtual Midi Driver and SDK however, I managed to get what I was looking for. However the solution had a few "performance issues" which were quite depressing as my software had to be very time critical. In the mean time I experimented a bit with easier USB-Drivers and learned alot about the whole Windows Drivers concept. Mainly because I'm interested to learn more about drivers, and secondly because I want to see whether I can tweak the performance a bit myself, I want to have another go at programming a Virtual MIDI driver. Now here's my current knowledge: - I'm pretty certain that the driver will need to make use of Kernel Streaming to get the performance I need. - From the MSDN Documentation, the most suitable approach seems to be a WDM driver that makes use of the PortCls Driver and the DMUS Minidriver, as the normal Midi Minidriver lacks support of some Midi features and it says in the FMSynth Sample: "// N.B.!!! // THIS DATA SINK ASSUMES THAT DATA COMES IN ONE MESSAGE AT A TIME!!! // IF LENGTH IS MORE THAN THREE BYTES, SUCH AS SYSEX OR MULTIPLE MIDI // MESSAGES, ALL THE DATA IS DROPPED UNCEREMONIOUSLY ON THE FLOOR!!! // ALSO DOES NOT PLAY WELL WITH RUNNING STATUS!!! // // CLEARLY, THIS MINIPORT HAS SOME "ISSUES"." Which doesn't sound that promissing to me.. - The way I understand the adapter driver is that it builds a connection between portcls and the minidriver that supports the wanted feature (in my case DMUS MIDI). - In the Adapter Driver Sample, the miniport is created and bound to a portcls port using the "ntStatus = PcNewMiniport(&miniport,MiniportClassId);" function, which accesses a standard minidriver inside portcls. - I now believe that if I want to send virtual generated midi data into the stream, that I need to adapt the DMUSUart Sample so it will fit my needs and then create my own instance of my modified miniport and bind that. So my first question to you guys would be to verify the above stated assumptions, just to make sure i'm on the right path here. The second question has to to with the Midi stream. Looking through the Samples for the MPU401, I seem to find only code that writes outgoing data TO the MPU401, but no code that reads MIDI data from the MPU401 and writes it in the midi stream to the application that uses midiIn etc. Or am I looking in the completely wrong section? I appreciate any comments and ideas ;) Greetz RF