Class MIDIDriverInterface


  • public final class MIDIDriverInterface
    extends org.moe.natj.c.StructObject
    • Constructor Detail

      • MIDIDriverInterface

        public MIDIDriverInterface()
      • MIDIDriverInterface

        protected MIDIDriverInterface​(org.moe.natj.general.Pointer peer)
    • Method Detail

      • _reserved

        public org.moe.natj.general.ptr.VoidPtr _reserved()
      • set_reserved

        public void set_reserved​(org.moe.natj.general.ptr.VoidPtr value)
      • FindDevices

        public MIDIDriverInterface.Function_FindDevices FindDevices()
        [@fn] FindDevices This is only called for version 1 drivers. The server is requesting that the driver detect the devices which are present. For each device present, the driver should create a MIDIDeviceRef with entities, using MIDIDeviceCreate and MIDIDeviceAddEntity, and add the device to the supplied MIDIDeviceListRef, using MIDIDeviceListAddDevice. The driver should not retain any references to the created devices and entities.
      • setFindDevices

        public void setFindDevices​(MIDIDriverInterface.Function_FindDevices value)
        [@fn] FindDevices This is only called for version 1 drivers. The server is requesting that the driver detect the devices which are present. For each device present, the driver should create a MIDIDeviceRef with entities, using MIDIDeviceCreate and MIDIDeviceAddEntity, and add the device to the supplied MIDIDeviceListRef, using MIDIDeviceListAddDevice. The driver should not retain any references to the created devices and entities.
      • Start

        public MIDIDriverInterface.Function_Start Start()
        [@fn] Start The server is telling the driver to begin MIDI I/O. The provided device list contains the devices which were previously located by FindDevices (in the case of a version 1 driver), or the devices which are owned by this driver and are currently in the current MIDISetup (for version 2 drivers). The provided devices may or may not still be present. A version 1 driver should attempt to use as many of the devices as are actually present. A version 2 driver may make calls such as MIDISetupAddDevice, MIDIDeviceAddEntity, MIDIDeviceRemoveEntity to dynamically modify the system's current state. For devices in the provided device list which are not present, the driver should set their kMIDIPropertyOffline property to 1. A version 2 driver may also set up notifications when the IORegistry changes, to detect connection and disconnection of devices it wishes to control. At these times also, the driver may change the devices' kMIDIPropertyOffline, and dynamically modify the system's current state to reflect the devices which are present. When passing a CFRunLoopRef to IOKit for notification purposes, the driver must use the server's main runloop, which is obtained with CFRunLoopGetCurrent(). The driver will probably want to iterate through the destination endpoints and assign their driver refCons, so as to identify multiple destinations when Send() is called. The provided device list remains owned by the system and can be assumed to contain only devices owned by this driver. The driver may retain references to the devices in this list and any it creates while running.
      • setStart

        public void setStart​(MIDIDriverInterface.Function_Start value)
        [@fn] Start The server is telling the driver to begin MIDI I/O. The provided device list contains the devices which were previously located by FindDevices (in the case of a version 1 driver), or the devices which are owned by this driver and are currently in the current MIDISetup (for version 2 drivers). The provided devices may or may not still be present. A version 1 driver should attempt to use as many of the devices as are actually present. A version 2 driver may make calls such as MIDISetupAddDevice, MIDIDeviceAddEntity, MIDIDeviceRemoveEntity to dynamically modify the system's current state. For devices in the provided device list which are not present, the driver should set their kMIDIPropertyOffline property to 1. A version 2 driver may also set up notifications when the IORegistry changes, to detect connection and disconnection of devices it wishes to control. At these times also, the driver may change the devices' kMIDIPropertyOffline, and dynamically modify the system's current state to reflect the devices which are present. When passing a CFRunLoopRef to IOKit for notification purposes, the driver must use the server's main runloop, which is obtained with CFRunLoopGetCurrent(). The driver will probably want to iterate through the destination endpoints and assign their driver refCons, so as to identify multiple destinations when Send() is called. The provided device list remains owned by the system and can be assumed to contain only devices owned by this driver. The driver may retain references to the devices in this list and any it creates while running.
      • Stop

        public MIDIDriverInterface.Function_Stop Stop()
        [@fn] Stop The server is telling the driver to terminate MIDI I/O. All I/O operations that were begun in Start, or as a result of a subsequent IOKit notification, should be terminated.
      • setStop

        public void setStop​(MIDIDriverInterface.Function_Stop value)
        [@fn] Stop The server is telling the driver to terminate MIDI I/O. All I/O operations that were begun in Start, or as a result of a subsequent IOKit notification, should be terminated.
      • setSend

        public void setSend​(MIDIDriverInterface.Function_Send value)
        [@fn] Send Send a MIDIPacketList to the destination endpoint whose refCons are being passed as arguments.
      • EnableSource

        public MIDIDriverInterface.Function_EnableSource EnableSource()
        [@fn] EnableSource A client has opened or closed a connection, and now the server is telling the driver that input from a particular source either does or does not have any listeners in the system. The driver may use this information to decide whether to pass messages from the source to the server, and it may even be able to tell the source hardware not to generate incoming MIDI I/O for that source.
      • setEnableSource

        public void setEnableSource​(MIDIDriverInterface.Function_EnableSource value)
        [@fn] EnableSource A client has opened or closed a connection, and now the server is telling the driver that input from a particular source either does or does not have any listeners in the system. The driver may use this information to decide whether to pass messages from the source to the server, and it may even be able to tell the source hardware not to generate incoming MIDI I/O for that source.
      • Flush

        public MIDIDriverInterface.Function_Flush Flush()
        [@fn] Flush Only for version 2 drivers (new for CoreMIDI 1.1). Drivers which support schedule-ahead, when receiving this message, should unschedule all pending output to the specified destination. If the destination is null/0, the driver should unschedule all pending output to all destinations.
      • setFlush

        public void setFlush​(MIDIDriverInterface.Function_Flush value)
        [@fn] Flush Only for version 2 drivers (new for CoreMIDI 1.1). Drivers which support schedule-ahead, when receiving this message, should unschedule all pending output to the specified destination. If the destination is null/0, the driver should unschedule all pending output to all destinations.
      • Monitor

        public MIDIDriverInterface.Function_Monitor Monitor()
        [@fn] Monitor Only for version 2 drivers (new for CoreMIDI 1.1). Some specialized drivers (e.g. a MIDI monitor display) may wish to intercept and look at all outgoing MIDI messages. After a driver calls MIDIDriverEnableMonitoring(true) on itself, this function is called with the outgoing MIDI packets for all destinations in the system. The Monitor function cannot rely on the MIDI events arriving in order, due to MIDIServer's schedule-ahead facilities.
      • setMonitor

        public void setMonitor​(MIDIDriverInterface.Function_Monitor value)
        [@fn] Monitor Only for version 2 drivers (new for CoreMIDI 1.1). Some specialized drivers (e.g. a MIDI monitor display) may wish to intercept and look at all outgoing MIDI messages. After a driver calls MIDIDriverEnableMonitoring(true) on itself, this function is called with the outgoing MIDI packets for all destinations in the system. The Monitor function cannot rely on the MIDI events arriving in order, due to MIDIServer's schedule-ahead facilities.
      • SendPackets

        public MIDIDriverInterface.Function_SendPackets SendPackets()
        [@fn] SendPackets Only for provisional drivers. Send a MIDIEventList to the destination endpoint whose refCons are being passed as arguments.
      • setSendPackets

        public void setSendPackets​(MIDIDriverInterface.Function_SendPackets value)
        [@fn] SendPackets Only for provisional drivers. Send a MIDIEventList to the destination endpoint whose refCons are being passed as arguments.
      • MonitorEvents

        public MIDIDriverInterface.Function_MonitorEvents MonitorEvents()
        [@fn] MonitorEvents Only for provisional drivers. Same as Monitor but uses MIDEventList, whose protocol may vary from MIDI 1.0.
      • setMonitorEvents

        public void setMonitorEvents​(MIDIDriverInterface.Function_MonitorEvents value)
        [@fn] MonitorEvents Only for provisional drivers. Same as Monitor but uses MIDEventList, whose protocol may vary from MIDI 1.0.