Online Documentation - Statistics - FAQ - Plugin Parts (All, Dependencies) - Class hierarchy
New in Version 22.2 22.3 22.4 22.5 23.0 23.1 23.2 23.3 23.4 23.5 24.0 24.1
The list of the topics, classes, interfaces, controls, modules, global methods by category, global methods by name, screenshots, licenses and examples.
Platforms to show: All Mac Windows Linux Cross-Platform
Super class: MidiObjectMBS
Type | Topic | Plugin | Version | macOS | Windows | Linux | iOS | Targets |
class | MIDI | MBS MacCF Plugin | 3.1 | ✅ Yes | ❌ No | ❌ No | ✅ Yes | All |
Only make one instance of this class in your application.
From Apple's documentation:
History:
Apple's MIDI Manager (ca. 1990) had a simple model of the world. There were application and driver clients, which had MIDI in/out ports, which could be interconnected in arbitrary ways. This model failed to provide a way for applications to make reasonable assumptions about how to make bi-directional connections to a MIDI device. MIDI Manager also had limitations on the number of ports per client, and became very unwieldy with the advent of large studios and multi-port MIDI interfaces such as the MIDI Time Piece and Studio 5.
Opcode's OMS (1991) addressed some of the shortcomings of MIDI Manager. There was the concept of a studio setup document, where drivers detected their devices, and the user could define the characteristics of additional devices connected to the MIDI ports. Applications could view the studio both as a collection of MIDI source and destination "nodes", but also as a collection of devices. OMS collected information about, and made available to its clients, useful characteristics of the devices in the studio, such as their system-exclusive IDs, MIDI channels on which they were listening, which were controllers (as opposed to simple tone generators), etc.
API Overview:
This design expands slightly on OMS's device/node hierarchy, inspired by the USB MIDI spec.
Drivers own and control devices, e.g. USB interfaces, PCI cards, etc. A device is defined as a physical object that would be represented by a single icon if there were a graphical view of the studio.
Devices may have multiple logically distinct sub-components, e.g. a MIDI synthesizer and a pair of MIDI ports, both addressable via a USB port. These are called Entities.
Entities have any number of Endpoints, sources and destinations of 16-channel MIDI streams. By grouping a device's endpoints into entities, the system has enough information for an application to make reasonable assumptions about how to communicate in a bi-directional manner with each entity, as is necessary in MIDI librarian applications.
Third-party services like FreeMIDI or OMS can collect and report interesting properties of a device by attaching those properties to the devices' entities -- CoreMIDI provides a central database, but no user interfaces.. It's worth noting that some device characteristics are dynamic (e.g. MIDI receive channel and system-exclusive ID's), or a matter of user preference (choice of icon, whether the device should appear in lists of possible controllers), while other properties are static and could be looked up in a database, using the device's manufacturer and model names as a key.
Persistent configurations / Device Information:
There are a number of reasons why CoreMIDI has a persistent state.
Endpoints must have persistent ID's. When a user assigns events in a sequencing application to an endpoint, the application needs a way to retain a permanent reference to the selected endpoint. A brute-force method of generating a persistent ID would be to combine the driver name, device name, entity name, and endpoint type and index into a string, but this is not very | friendly to clients even if the system provides services to generate and decode these strings. |
Some drivers will need to store configuration information about the devices they control. For example, the driver for a standard MIDI interface on a serial port needs to remember which external clocking speed to use (this is | a simple, slightly obscure, but hardly unique example). The Alesis QS7 is capable of communicating at a variety of speeds, so its driver needs to remember the correct speed. |
Moreover, since a driver knows exactly what device it is communicating with, it is capable of supplying information to the system about the | characteristics of the device, such as its system-exclusive ID, whether it | is General MIDI or DLS-compatible, etc. |
But unlike OMS, the system is able to begin functioning immediately, using only the MIDI devices/endpoints detected by the drivers, without | forcing the user to go through a somewhat lengthy and confusing intial configuration process. Definition of external MIDI devices can be a completely optional step, only made possible when a client application requests that they be added to the configuration. |
Constant | Value | Description |
---|---|---|
kMIDIIDNotUnique | -10843 |
One of the type constants for a MIDI error.
Attempt to set a non-unique kMIDIPropertyUniqueID on an object. |
kMIDIInvalidClient | -10830 |
One of the type constants for a MIDI error.
An invalid MIDIClientRef was passed. |
kMIDIInvalidPort | -10831 |
One of the type constants for a MIDI error.
An invalid MIDIPortRef was passed. |
kMIDIInvalidUniqueID | 0 | A constant for an invalid unique ID. |
kMIDIMessageSendErr | -10838 |
One of the type constants for a MIDI error.
Communication with MIDIServer failed. |
kMIDIMsgIOError | 7 |
One of the type constants for a MIDI Notification.
A driver I/O error occurred. |
kMIDIMsgObjectAdded | 2 |
One of the type constants for a MIDI Notification.
A device, entity or endpoint was added. |
kMIDIMsgObjectRemoved | 3 |
One of the type constants for a MIDI Notification.
A device, entity or endpoint was removed. |
kMIDIMsgPropertyChanged | 4 |
One of the type constants for a MIDI Notification.
An object's property was changed. |
kMIDIMsgSerialPortOwnerChanged | 6 |
One of the type constants for a MIDI Notification.
A persistent MIDI Thru connection was created or destroyed. No data. New for CoreMIDI 1.3. |
kMIDIMsgSetupChanged | 1 |
One of the type constants for a MIDI Notification.
Some aspect of the current MIDISetup has changed. No data. Should ignore this message if messages 2-6 are handled. |
kMIDIMsgThruConnectionsChanged | 5 |
One of the type constants for a MIDI Notification.
A persistent MIDI Thru connection was created or destroyed. No data. New for CoreMIDI 1.3. |
kMIDINoConnection | -10833 |
One of the type constants for a MIDI error.
Attempt to close a non-existant connection. |
kMIDINoCurrentSetup | -10837 |
One of the type constants for a MIDI error.
Internal error; there is no current MIDI setup object. |
kMIDIObjectNotFound | -10842 |
One of the type constants for a MIDI error.
The requested object does not exist. |
kMIDIServerStartErr | -10839 |
One of the type constants for a MIDI error.
Unable to start MIDIServer. |
kMIDISetupFormatErr | -10840 |
One of the type constants for a MIDI error.
Unable to read the saved state. |
kMIDIUnknownEndpoint | -10834 |
One of the type constants for a MIDI error.
An invalid MIDIEndpointRef was passed. |
kMIDIUnknownProperty | -10835 |
One of the type constants for a MIDI error.
Attempt to query a property not set on the object. |
kMIDIWrongEndpointType | -10832 |
One of the type constants for a MIDI error.
A source endpoint was passed to a function expecting a destination, or vice versa. |
kMIDIWrongPropertyType | -10836 |
One of the type constants for a MIDI error.
Attempt to set a property with a value not of the correct type. |
kMIDIWrongThread | -10841 |
One of the type constants for a MIDI error.
A driver is calling a non-I/O function in the server from a thread other than the server's main thread. |
This class has no sub classes.
The items on this page are in the following plugins: MBS MacCF Plugin.
MFPMediaPlayerMBS - MidiDeviceMBS