Hi > Every app has its own address space. Suppose we have two apps, app1 > and app2. This means that app1 cannot use app2's variables, and vice > versa. If both apps link with libmidi2, they will each have their > own instance of BMidiRoster. This instance is created the first time > you use a midi function. Ok I have understood all what follow but in the BeBook you have written you say :"My guess is that MidiRosterApp is the class that makes the one-and-only BMidiRoster instance. It could be the app that drives the midi=5Fserver, but I haven't checked that out yet." > > Ok i will do that, but as you know MidiFiles can store > > name of the track and other things like that, with the > > implementation of BMidiEvent from Paul that can't be > > stored(with mine that work :-)) > > Why do you need to store track names in BMidiEvent=3F I don't need it but if you want to do an app that need track name you can't use BMidi and other function and you must do all the job yourself and I think the API must do all the job. > > > I have seen that BMidiPort use Midi2 but where BMidi use Midi2 > > BMidi is basically a producer and a consumer rolled into one. Midi2 > provides BMidiConsumer and BMidiProducer objects, and I think BMidi > uses those to receive and send out events. > > > I will try to do BMidiPort. > > Cool. I hope this is possible using the Midi2 API calls. In other > words, without having to access the midi=5Fserver directly. > I will test that. > > > - Finish the MidiPlayer ;-) > > I correct the problem you say me, what are the other problem > > I don't know if there are any other problems. Did you commit your > changes to the cvs=3F Because I would like to try out the latest > version of MidiPlayer. Thanks! Now Yes. A+ Jerome