[openbeos-midi] Re: Other question on BMidiEndPoint

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 ;-)

Other related posts: