Virtual source/destination conventions
Virtual source/destination conventions
- Subject: Virtual source/destination conventions
- From: Kurt Revis <email@hidden>
- Date: Sun, 25 Nov 2001 23:33:46 -0800
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