> I tried to compile a program with Class BMidi, BMidiText, > BMidiStore from libMidi.so (Be) and I put libMidi2.so into > the trash that compile and that run normally, then I think > LibMidi2 is not used with that class. For BMidiText and BMidiStore you may be right, but I cannot imagine that BMidi is not implemented using the classes from libmidi2. By the way, how can your app even run if libmidi2.so is not available? libmidi.so links against libmidi2, so when you load libmidi into memory the OS should also load libmidi2... Unless I don't understand how ELF loaders work. > 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? What should happen if you Open() a port, say /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 ;-) -- Matthijs