Quoting Jerome Leveque: > how is decided the id of the BMidiEndPoint? Hum, a always increasing global next_midi_endpoint_id count somewhere in the midi_server (where should live the midi endpoints *roster*)? > Now question about Register an Unregister > I think for this 2 functions that publish device in /dev/midi/ for other > app can talk > together but the question is how create and read/write with the new > *entry*? Hum, no, I think these two methods are to start and stop being a alive BMidiEndpoint in the midi_server endpoints roster. Again, it's only my guest, but I think that at start up midi_server instantiate a internal class of a BMidiEndpoint (both producer and consumer) for each /dev/midi/* entry succesfully opened and add them to his endpoints roster. That's for the *real* midi endpoints (or ports, as they were named before in old midi kit). The [Un]Register() methods allow any instance of a BMidiEndpoint living outside the midi_server, like a software midi synth or a userland midi driver (like the USB midi device driver on BeBits), to be added/removed dynamicly from the midi_server endpoints roster. That's the great addition of MidiKit2 : all apps can publish and share their own midi endpoints (consumer, producer or both). The midi_server and his /dev/midi/* endpoints do it himself, but he's not the only one that could do it anymore... My bet is that BMidiEndpoint::[Un]Register() in turn call the BMidiRoster::[Un]Register(this);. I bet that the tricky part of the midikit2 is in BMidiRoster and the protocol it use to talk with the midi_server. The hard part of the midi_kit (2 only?) would be the midi_server, no? Or did I miss something here? Did someone run a "nm midi_server" to get some hint on how this server works (and his internal design), yet?. -Philippe, always a "how works MidiKit2" guesser ;-)