-
Notifications
You must be signed in to change notification settings - Fork 9
Overview
The Native Instrument hardware controllers system supports the use of multiple different hardware controllers on multiple instances of different software.
The software architecture is divided into three main parts:
- A kernel-space driver
- A user-space daemon (NIHardwareAgent)
- Client instances (e.g. standalone applications, plugins, the Controller Editor...)
Both the kernel driver and the user-space daemon are really thin wrappers to the real hardware, which supports the multiplexing of different hardware connected to the computer to different client instances.
As I will show later, the clients have practically complete control over the hardware itself my main point of focus has been investigating the connection between the user-space daemon and the clients.
The Maschine hardware (I'm not sure about other kind of devices) supports a so called "Midi mode" in which the controller sends standard MIDI note on/of and CC messages to the MIDI subsystem of the operating system (CoreMidi, a part of CoreAudio on OS X).
It is worth noting that this mode is not implemented using the usb-midi protocol from the hardware controller, like it is on other kind of controllers, but even in this mode the hardware communicates with a custom protocol.
This is the "point-of-contact" of the hardware and the software subsystems.
I didn't investigate this module in detail, but on an high-level perspective its only competences are related to the USB housekeeping such as connection/disconnection notifications, firmware uploading, and exposing the hardware interface as soon as possible, and with as few data conversions as possible to the user-space daemon.
It is now worth noting that the controller hardware does not implement any standard USB protocol, like HID or USB-MIDI, not even if the hardware is in "Midi Mode", so a kernel driver is really necessary.
On OS X, it is not possible to have user-land USB drivers if memory mapped IO to the device is required, so it is plausible to think that the kernel driver exists only for this reason, as the entire architecture seems to be pushing as much competencies as possible to the user-land.
This is the main actor in the communication of with the hardware devices: alongside its other competencies, the agent is the only process talking directly to the USB devices using IOKit, all other applications that access the hardware, must do so using this daemon.
The agent role is that of a middle-man between all the devices connected to the USB bus, and all other processes that wants to access the controller hardware.
Since there can be more hardware controllers connected, and there can be multiple instances of the controlled software, one of the agent's role is to keep track of which controller is connected to which client.
On the Maschine hardware, you can access a menu to choose which different instance you want that controller to connect to: the Agent is responsible to intercept the SHIFT+INSTANCE key-presses on the hardware and present the menu.
Another responsibility of the agent, is to implement the Midi Control mode, and rely the midi input from/output to the hardware physical midi ports.
Client softwares are the most user-facing parts of the system, on both the computer user interface and the controller hardware.
Native Instruments ships two clients with their products, the instrument itself, in various versions, and a Controller Editor, with which an user can modify the mapping of the Midi Mode of the controller.
Clients, after requesting a connection to the agent, and after being "focused" on the hardware controller, have a complete raw access to the device, with the only exception that the agent will hijack the SHIFT+CONTROL and SHIFT+INSTANCE key-presses to implement the midi mode and the instance selection menu.