Some general notes to the understanding of the midi manager. The midi manager has the task to intelligently assign applications to destinations.
It is important to understand what it actually does to understand the distinction first, which is expressed through the "MidiClientType" of each client.
APPLICATIONS: An application is a user visible application, that produces or records midi data. It is important for the understanding of an application, that an application actually *wants* to be supplied with data, or wants to get its data played. Thus, adding an application to the midi manager is an implicit request: "go and find a place where to put the events to (or get the events from)".
Examples for applications would be games or midi players.
DESTINATIONS: A destination is a system service that plays or supplies midi data. The characteristic here is that a destination is something that is there if you need it.
Examples for destinations might be might be a hardware device or an emulation of a hardware device (such as a virtual sampler).
So the process is as follows: - destinations register themselves at the midi manager, and provide system services in that way
- when the user starts an application (such as a midi player), the midi manager's task is to assign it to a suitable destination
- the user can interact with the process by changing the way applications are assigned to destinations - the midi manager will try to learn what the user wants, and next time do a better job while assigning
To actually record or play some data, you need to register a client first, and after that, you can add Input or Output "MidiPort"s to your client, so that you can actually send or receive events with them.
|readonly attribute sequence<MidiClientInfo> |
add a client
this creates a new MidiManagerClient
connect two clients
disconnect two clients
|Generated by: stefan@stefan on Sat Feb 24 19:11:36 2001, using kdoc 2.0a47.|