Re: Virtual source/destination conventions
Re: Virtual source/destination conventions
- Subject: Re: Virtual source/destination conventions
- From: Thomas Hudson <email@hidden>
- Date: Mon, 26 Nov 2001 09:23:14 -0800
I've got the same problem. Ultimately it would be nice if Apple
supplied an application to manage connections and all other
apps just created endpoints with no UI to do connections.
Perhaps a new message could be added to the MIDINotifyProc to
tell an app to connect an endpoint to another. What I'm doing
currently is every app has a combobox to specify a source as input,
and I have a separate app that connects to hardware destinations and
allows the user to specify sources to route to those destinations.
One other problem I've encountered is that if an application
isn't aware of what is connected to its sources, it needs to
use MIDIReceived to send messages to all connected endpoints.
MIDIReceived doesn't allow advance scheduling of events like
MIDISend does, so you end up having to do some things yourself
(Hey, I'm lazy and want to go ahead and queue the NoteOff when I
generate the NoteOn). It would be nice to either provide a
MIDISendToAll to allow prescheduled events to all connected ports,
or some way for an app to get a list of ports connected to a source,
so that it could use MIDISend to each.
Thomas
On Sunday, November 25, 2001, at 11:33 PM, Kurt Revis wrote:
I'm currently talking to another developer. I have an app which
listens to MIDI messages; he has an app which sends them. The question
is: how do we get our apps to talk to each other?
Currently, it seems that my listener app *must* provide the user with a
list of sources to listen to. After all, some of them may be MIDI ports
on external hardware, and there is no other way to hook them up to my
app. And this will also let me see any virtual sources which may exist.
Similarly, the sender app *must* provide the user with a list of
destinations to send to. (Again: some of them may be external MIDI
ports, and there's no other way to hook them up.) And it will also be
able to send to any virtual destinations on the same machine.
But if we both do that, neither app will provide any virtual endpoints,
and we'll have no way to communicate. So the alternatives are:
1) Both apps should provide virtual endpoints.
This is the most flexible solution. I think, however, that it leads to
a confusing UI. Every MIDI app must then give the option of choosing
sources/dests from a list, AND the option of being a virtual endpoint.
I really don't know how to explain this to a user in a coherent way,
especially since there will then be two different ways of getting two
apps to talk to each other, each equally valid. Setting up a MIDI
network is already confusing enough as it is.
2) Only one app should provide a virtual endpoint.
Then we just need to make a convention for which it should be...
senders, or receivers. We'd just need a benevolent dictator to flip a
coin and make a decision :)
Are there any limitations with this approach that I'm not thinking of?
It does complicate things for one of the apps. I think it is somewhat
easier to be a virtual destination than to be a virtual source.
3) Neither app should provide a virtual endpoint.
Instead, we could have another app provide both sources and
destinations, acting as a virtual "adaptor" in between. I think this
is basically how the IAC buses in OMS worked (someone correct me if I'm
wrong).
This will work, and is sort of conceptually elegant, although it will
be less efficient than providing a direct virtual connection. As a
user, though, I don't much like the idea of having to run and keep
track of another app. (The adaptor could run as a faceless process,
though, with just a configuration app to set it up.)
I think the most important thing is that there should be a convention
that all apps implement. Otherwise all three of these possibilities
are going to happen simultaneously, which maximizes total confusion.
Anybody have thoughts on this? Especially you Apple guys--surely this
question has come up before! (I'm sure someone (ahem) remembers how
this evolved in OMS...)
--
Kurt Revis
email@hidden
_______________________________________________
coreaudio-api mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/coreaudio-api