[openbeos-midi] Re: Midi2 todo List

  • From: "Matthijs Hollemans" <matthijs@xxxxxxxxxxxxxxxxxxx>
  • To: <openbeos-midi@xxxxxxxxxxxxx>
  • Date: Wed, 13 Nov 2002 18:04:04 +0100

Hi Jerome,

> There is a lot of things I can't understood especially
> on protected memory for example an app do that

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.

App1 does this:

> endpt1 = new MyMidiEndpoint("test");

The BMidiRoster from app1 sends a message to the midi_server that
says: "This application has created a new endpoint". The midi_server
responds with: "OK, the new endpoint will use ID 14." This
information is stored inside the new MyMidiEndpoint instance.

> endpt1->Register();

The BMidiRoster sends a message to the midi_server that says: "The
endpoint with ID 14 is now visible to other applications".

App2 does this:

> endpt2 = BMidiRoster::NextEndpoint(14);

The BMidiRoster from app2 sends a message to the midi_server that
says: "hey, can you tell me if there is an endpoint with ID 14?".
The midi_server responds with: "Sure, this is a remote endpoint
(published by app1) and it communicates at port 1234 (or whatever).
The endpoint's name is 'test' ".

Now the BMidiRoster from app2 makes a new BMidiEndpoint object and
returns it. This new object represents endpoint 14, but does not own
it. Because endpoint 14 lives in app1, our object is called a
"proxy". So how can app2 talk to the endpoint from app1? Through
this proxy object...

These are the applications and the objects they contain:

    midi_server
        endpoint 14

    app1
        BMidiRoster
        MyMidiEndpoint - owns endpoint 14

    app2
        BMidiRoster
        BMidiEndpoint - proxy for endpoint 14

Note: the protocol is a little different than that, but this should
give you a general idea of what is going on between midi_server and
libmidi2.

> I see too in BMidiEndpoint.h that the operator is
> redefined can you explain me what that do

It makes a copy of the BMidiEndpoint. So you can do this:

BMidiEndpoint* endpt1 = ...;
BMidiEndpoint* endpt2;
endpt2 = *endpt1;

Now endpt2 is a copy of endpt1. But don't worry about this. The
operator= is private, and we do _not_ have to implement it
ourselves. Anything that is private we can change (except virtual
functions).

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

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

> > -    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? Because I would like to try out the latest
version of MidiPlayer. Thanks!

--
Matthijs



Other related posts: