Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Virtual source/destination conventions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Virtual source/destination conventions

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



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.