[wdmaudiodev] Re: AW: Re: Generic Virtual MIDI-driver...
- From: stevejet@xxxxxxxxxxxx
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Fri, 27 Mar 2009 16:52:53 -0400
Hi Tobias,
I can't comment much until others have responded regarding your dynamic
requirements; my only experience is with static ports.
I didn't need a topology driver. In fact I didn't even need any nodes, only
pins.
Regards,
Steve.
-----Original Message-----
From: Tobias Erichsen <erichsen@xxxxxxxxxxxxx>
To: wdmaudiodev@xxxxxxxxxxxxx
Sent: Fri, 27 Mar 2009 17:27
Subject: [wdmaudiodev] AW: Re: Generic Virtual MIDI-driver...
Hi everyone,
I also hope that some of the experts chime in.
Especially some feedback from the MS-guys who are here
on this list would be appreciated. Not to say
that I wouldn't appreciate your feedback as well
:-)
I'm currently working on a small stub-driver that is based
on MPU-401, DMusUART (and some hints from
DDKSynth & MSVAD) and I intend to add to this driver
until my mission is fulfilled ;-)
I'm creating my INF-file by taking hints from the MSVAD-inf
and some other INFs I found for MIDI-drivers
on the net...
I have a couple of questions concerning my
quest:
1. Is it possible to write such a driver & the
corresponding INF-file that installs, but initially does not
register any subdevices? What would I need to specify
in the INF-file to get this going?
2. Do I need a topology for this kind of driver - I think I
read somew
here that for simple MIDI-drivers
a topology would not be necessary.
3. As I intend to have "real" dynamic sub-devices, I cannot
specify any friendly-names within the
INF-file, as I don't have any information about what those
would be when the port is added later on.
How would I go about implementing this?
4. If I understand the documenation correctly the custom KS
properties reference existing
sub-devices. As I intend to create those subdevices
dynamically, I would figure that I
would need to go the way as to implement custom IOCTLs
& hooking the appropriate
functions & structures in the driver-entry (hen &
egg problem) - is this assessment correct?
=C
2�
That is all for now, but I will probably have many more
questions on my way...
Best regards,
Tobias
PS.: I hope I don't stress too many peoples nerves too
much, but like I wrote I'm a newbie
concerning the KS-driver-implementation and this stuff is
not for the faint-at-heart...
Von: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] Im Auftrag von
stevejet@xxxxxxxxxxxx
Gesendet: Montag, 23. März 2009
18:13
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev]
Re: Generic Virtual MIDI-driver...
Hello Tobias,
I have
just written a driver similar to this to replace the earlier one I
20mentioned
in my post of March 2nd.
The driver provides 1 MIDI input port (omni)
and 2 MIDI output ports (32 channels) for the sequencer. My DXi host feeds
the
input port and renders the output ports using buffers written and read using
METHOD_BUFFERED IOCTLs.
I hope that you get help from the experts, but
if not, I'll do what I can.
Regards,
Steve.
-----Original Message-----
From: Tobias Erichsen
<erichsen@xxxxxxxxxxxxx>
To: wdmaudiodev@xxxxxxxxxxxxx
Sent: Mon,
23 Mar 2009 12:25
Subject: [wdmaudiodev] Generic Virtual
MIDI-driver...
Hi everyone,
like I wrote in my last mail from Friday I would highly welcome a
c
omplete MIDI-driver-
sample that implements the following functionality:
- Software-only (like MSVAD)
- Private interface for applications (either by custom KS properties or
private IOCTLs)
- Dynamically creatable/destroyable MIDI-ports with freely configurable
friendly-name
without the need for any reboots
- the created MIDI-Port is accessible to all kinds of standard
application through
the standard interfaces like "old-school" MME API, DirectX...
- The "backend" / "virtual-hardware" side of the MIDI-port is
implemented by the application
(if someone needs some clarification on how this would work, I can
provide with a more
thor
ough description)
This kind of driver would allow for all kind of cool functionality:
- DAW-applications could create MIDI-ports on demand to interface to
other stand-alone
applications for MIDI-message-exchange
- Special-operation MIDI-port(s) can be created by just writing a simple
user-space application
or service. Making a multitude of functions possible like:
- MIDI-over-NET tunneling
- MIDI-patchbays
- MIDI-filters
Apart from the "real-world" uses, the driver-writer-community has some
benefits as well
- For many applications the need of writing a driver would be eliminated
totally!
- Serve as a blueprint for othe
r driver-writers on how to implement this
functionality
- Functionality that has not been that well documented (like dynmaic
creation of ports,
dynamic friendly-names etc.) can be deduced rather easily by browsing
this sample.
It would by highly convenient if such driver could be incorporated into
the standard-shipment
of the next Windows OS version.
In the last couple of years (and especially in the last months) a large
number of companies &
individuals have asked many times for information about writing drivers
which each implement
some of the functionality I have sketched out above - having a generic
driver which implem
ents
the sum of all those request would really bring forward the
DAW-community (both on the developer
& on the user side)
I would be willing to start up such an endeavor but I must admit that
apart from having written
several device-drivers (in other areas) already, I have no intimate
knowledge about the imple-
mentation of the kernel-streaming-mechanisms on the driver side - so any
help from other
interested parties would be highly welcome. Especially the area of
private-interfaces and
dynamic creation/destruction of ports with a free friendlyname is
something that is still
a closed book to me...
I have thought abo
ut a driver that would be called VMIDI.SYS
implementing the functionality
described above and also having a matching DLL: VMIDI.DLL which creates
an easy to use user-
space DLL for applications to interface to this driver in a
standard-way.
So any feedback on this subject is highly welcome (hopefully some of the
folks who have
asked for such stuff in the past are still monitoring this mailing-list
to get feedback
if this contemplated driver would implement most/all of what they were
trying to achieve :-)
Best regards,
Tobias
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
0A
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
