> I'm absolutely not agree with you. how is it possible > to integrate Midi2 in BMidi class? According to the BeBook, BMidi does the following things: - Connection functions - "Spray" functions - "MIDI hook" functions (NoteOn, etc.) But we also know that BMidiProducer from the midi2 kit does: - Connection functions - "Spray" functions And BMidiConsumer from the midi2 kit does: - "MIDI hook" functions (NoteOn, etc.) If you _don't_ implement BMidi using a BMidiProducer and a BMidiConsumer, then you will be _unnecessarily_ _duplicating_ functionality! After all, a BMidi object is simply the combination of a producer and a consumer... so why not use BMidiProducer to play the part of the producer, and BMidiConsumer to play the part of the consumer? Actually, you have already done that in BMidiPort. If you look in the BeBook, you will see that BMidiPort extends from BMidi. So the BMidiProducer and BMidiConsumer objects that you put into BMidiPort _really_ belong in BMidi instead! When you wrote BMidiPort, you already did half the work necessary for BMidi. If that is not enough reason, let me add another: interoperability. If midi1 and midi2 both have their own, incompatible way of sending and receiving MIDI events, then you can have endpoints "stealing" events from each other. I don't have to tell you that is bad. > What else don't work in the current implementation of BMidi? The current implementation of BMidi was not made using the classes from libmidi2, and therefore it is useless to us. I am not saying that the code is wrong or that it doesn't work (although that probably is a fair assumption to make), just that we cannot use it. There is one exception: the "Performance functions", i.e. Start(), Stop(), Run(), KeepRunning(). These functions control the thread that processes incoming events and sends out new events, if I am not mistaken. The classes from midi2 do not do this, so this is the only part that is unique to BMidi. -- Matthijs