Greg Crain wrote: > I started writing the module ages ago. I recently revisited it, and > have it compiling. I am going to work on debugging it this weekend on my AWE64. That would be a great news ! > There's still a few things that I am not 100% sure about. The undocumented workarounds flag in the generic=5Fmpu401=5Fmodule create=5Fdevice() call, maybe=3F :-\ > It's probably only days away from getting it to work with one card, > but if threes two or more cards in a system, I'm not sure how the > module is supposed to work. > Is the module copied for each sound card, or is the module only > loaded once and all cards share it=3F > I'm not that familiar how modules are used. Kernel modules are load on demand, and when more than one driver or other module call get=5Fmodule() on it, he's shared between us, yes. However, each generic=5Fmpu401=5Fmodule "client" should call create=5Fdevice() first, and pass in void **out=5Fstorage argument a place to keep an "handle" to client specific data. That way the MPU401 module attach, with client help, each specific module "client" (aka sound card driver) data... > Is the midi=5Fparser even used=3F Good question! I guess his purpose is to help midi driver coders to implement in their driver a read() hook that return full, valid, MIDI event bytes, as the midi=5Fserver expect to get at least one event per read() call. > Also- is there anyone on this list that has an SBLive and midi > interface that wants to test a midi port driver=3F Well, me. But I would have reconnect my MIDI keyboard to the sound card... > I was also working on an add-on driver for the SBLive. For the > SBLive I was talking right to the midi server, so what I learned is almost a cut-n-> paste to the module. Looks interesting! -Philippe -- Fortune Cookie Says: The Briggs/Chase Law of Program Development: To determine how long it will take to write and debug a program, take your best estimate, multiply that by two, add one, and convert to the next higher units.