Matthijs wrote: > Jerome wrote: > > For the class BMidiPort I think that just a class that > > translate BMidi data to BMidiEndpoint data. The hardware > > midi port are created by the midi_server as BMidiProducer > > or BMidiConsumer, and BMidiPort just send or receive data. > > A BMidiPort represents a hardware MIDI port. It has several > functions for finding out which hardware ports are available: > CountDevices(), GetDeviceName(), Open(). How does BMidiPort know > which hardware ports there are? Does it look through /dev/midi? > Or does it let the midi_server do that? Most probably the BMidiPort is responsable for scan all /dev/midi/* it can support. And the midi_server, thru an internal MidiPort objects, open each and publish them as a BMidiEndpoint (consumer & producer) ... However, looking at midi_server internals, it seems he's watching /dev/midi/* tree, so maybe since Midi2 the BMidiPort class don't scan devices itself anymore but rely on midi_server to do it. > What should happen if you > Open() a port, say /dev/midi/sblive? As the midi_server should have already open /dev/midi/sblive it at his startup, I'll bet you will get a "Busy" error on a BMidiPort::Open("/dev/midi/sblive"); > The BMidiPort now has to ask > the midi_server for the producer and consumers for that port, but > how does it do that? Does it simply loop through all endpoints and > compare their names? These are the issues we should think about ;-) Well, I guess yes. A quick search at BMidiEndpoint::Name() until it match device_path passed to BMidiPort::Open(device_path). -Philippe