Re: Greetings!

Hi Jerome,

BMidiRoster::Connect() and BMidiRoster::Disconnect()
basically implement BMidiProducer::Connect() and
BMidiProducer::Disconnect(). IIRC, the latter
functions simply call the former.

I don't know what RemoteConnect(), RemoteConnected(),
RemoteDisconnect(), and RemoteDisconnected() did. But
I have a question for you (and this is not meant in a
mean way!): is it really important to know how these
(private) member functions work? It seems to me that
such questions are leading you away from the main task
at hand. Rather than figuring out how each helper
member function works, I would think about the
BMidiRoster from a functional point of view, and
simply write the roster in whatever way you feel
implements that functionality best. In other words:
implement all the public/protected member functions as
close to spec as possible, but feel free to toss the
rest!

So what's the functionality needed here? When we
connect a producer to a consumer, there are several
cases:

* Neither the producer or consumer are local. In this
case, the MIDI server needs to establish the
connection (since only it knows how to access the
objects involved), so we forward our request through
the BMidiRoster to the server, telling it the IDs of
the objects we want to connect. It will do something
like the following:
-- Tell the consumer that it will be receiving MIDI
messages from a producer from another application. A
port is created to handle the connection. (But do we
really need a port for each consumer?)
-- Tell the producer to add a "remote" consumer to its
list of connections, and tell it what port the
consumer may be found at. Now the producer has enough
information to send events directly to the consumer
(i.e. without having to go through the server), which
is good.
-- Assuming everything works, tell any listeners (e.g.
PatchBay) that a connection has occured.

* The producer is local, but the consumer is remote
(or v/v). This, too, can be handled by forwarding the
message via the BMidiRoster to the MIDI server,

* Both the producer and consumer are local. In this
case, we don't need to use IPC; the producer can
simply call the consumer's receive member function
directly! If the objects are registered, the server
will need to know about the connection so that it can
tell any listeners. But the objects don't have to be
registered, in which case the server doesn't even know
about them and can be cut out of the loop altogether.

Also keep in mind ref counting when you're
implementing connections. Ref counting makes sure that
a MIDI object in one application doesn't get destroyed
when objects in other applications depend on it. A
connection will have to adjust ref counts between its
objects accordingly when it is established and broken.
While I'm on that topic, keep in mind that, each time
you obtain a pointer to a MIDI object from the Roster,
the ref count is incremented. This means that you need
to Release() that object when you're done with the
pointer, or that object may not get cleaned up
properly.

A final question for the list: does everyone here have
access to PatchBay, Transposer, and lsmidi? These
should demonstrate how the new MIDI Kit API is
intended to operate. I can send the source code I have
for these if needed.

Hope this helps,
-- O

--- Jerome Leveque <[email protected]> wrote:
> My first questions are :
> What are the difference between
> BMidiRoster::Connect(..) and BMidiRoster::Connected
> (...) or other function with Remote in the name of
> the function?
> 
> Did class derived from BMidiEndPoint just call class
> function with the same name of 
> BMidiRoster.


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com