[openbeos-midi] Re: Midi2 todo List

  • From: "Jerome LEVEQUE" <jerl1@xxxxxxx>
  • To: openbeos-midi@xxxxxxxxxxxxx
  • Date: Wed, 13 Nov 2002 20:30:41 PST (-0800)


> 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 

> > 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.


Other related posts: