A responsive, fully-featured MIDI controller at an affordable price

Transcription

1 Project Name: 2 Project Description: Team Members: Outside Collaborators: Component Description: Author: A responsive, fully-featured MIDI controller at an affordable price Graham Boylan, Khaled Albaddah, Matthew Wong None MIDI interface drivers and connectivity, microcontroller selection Graham Boylan Submission Date: 11/1/2016

2 2 Page 2 of 8 Overview: With 2, our goal is to design a device that offers a similar feature set to existing devices at a competitive price point, without sacrificing functionality or performance. This means that in addition to offering velocity sensitivity and a practical, easy-to-use layout and form factor, the final product must perform with a minimal amount of operational latency, thus allowing it to be used for composition and performance by amateur and professional musicians alike. Additionally, in order to seamlessly integrate with a user s existing workflow, the device must be compatible with most (if not all) major operating systems and audio workstations. This report will detail the risks involved with the device s MIDI interface and connectivity and will cover the factors involved in choosing the microcontroller which will be used. The two other independent investigations for this project detail the design of the input method allowing for velocity calculation, and the design of the physical layout and the implementation of the velocity calculation algorithm. As a result, this investigation assumes that a button press can be identified and its velocity can be calculated prior to any output being generated over the USB-MIDI interface. The results of this investigation suggest that the final product should implement a USB class-compliant MIDI device on a Teensy development board in order to be maximally compatible with most hardware and software combinations, and should produce no more than 10 milliseconds of delay between any given button press and an output response (with an ideal delay falling below 3 milliseconds).

3 2 Page 3 of 8 Risk Specification: Needs: 1. The device must be compatible with most common music production configurations. 2. The device must be simple for any layperson to install. 3. The device must be compatible with industry standard digital audio workstations. 4. The device must provide MIDI velocity readings. 5. The device must not introduce any noticeable latency. 6. The device must be capable of providing visual feedback to the user. Engineering Specifications: A. The device must implement a USB class-compliant MIDI device. Satisfies needs [1, 2, 3]. B. The device must calculate a velocity result between 0 and 127 for each button press and include the final value in the output MIDI bitstream. Satisfies need [4]. C. The device must produce a response in the output MIDI bitstream within a worst-case delay of 10 milliseconds after a button is pressed. D. The device must receive incoming MIDI messages from the host computer and interpret them to light LEDs located in each button. Analysis: A. Class-compliant devices are natively supported by all major operating systems and audio workstations using built-in drivers. By designing the product as a class-compliant MIDI device, driver compatibility can be ensured across all hardware and software configurations, and user setup is reduced to the process of connecting the device to the computer via USB. B. Velocity is a natively supported parameter in MIDI and is used in many audio workstations to control a variety of settings and options. From a marketing perspective, this feature is necessary in order to compete with available products. From the perspective of the device drivers, this feature does not require any additional overhead to implement and transmit after a button press is detected and a velocity value is calculated, as the resulting value can simply be added into the MIDI output stream. C. Latency is a very important operating specification to minimize in the implementation of this product. The human ear is extremely sensitive to difference in phase and delays between sounds, and if any delay between a button press and the resulting output from a DAW is detected, it may result in an unpleasant user experience. When playing a musical instrument, a user may experience a delay between their action and a resulting sound of roughly 20 milliseconds, and most operating systems are capable of processing and outputting a sound on the order of tens of milliseconds. Thus, if the device is capable of outputting a signal within ten milliseconds of the user s action in the worst case, it will perform similarly to a musical instrument. D. Visual feedback is an important factor in the functionality of a product marketed towards musical performers, but due to the diverse nature of how users configure and interact with their devices, there is no single visual feedback scheme that will appeal to all users. The solution to this problem is to allow the visual feedback elements on the device (in this case LEDs in each button) to be controlled via incoming MIDI messages so that the user can configure their DAW to produce the feedback required for their use case.

4 2 Page 4 of 8 Risk Investigation: Existing systems which contribute to the latency of the device include the physical button construction, the layout of the components within the controller, and the velocity calculation algorithms. Depending on the components selected to comprise each button on the device, a single button press may span from a few hundred microseconds to a few milliseconds, which adds to the latency experienced by the user. Additionally, any propagation delays through the controller s circuit boards and multiplexing components as well as the time required to calculate the velocity of a button press once it is detected contribute to the end-user delay, though these delays are unlikely to exceed a few hundred microseconds in total. Once a MIDI signal has been received by the host computer, the delays incurred may vary. Differences in host hardware performance, running software, audio buffer settings, and available resources can all impact the delay inherent in producing sound thus it is imperative for device-side latency to be optimized wherever possible in order to avoid adding unnecessary delay. As a result, the most heavily weighted factor in determining microcontroller selection for this product was the availability of reliable USB or MIDI support and documentation. For this product, three microcontrollers were considered based on their USB connectivity, support for MIDI over USB, and similar numbers of available GPIO connections: the NXP Freedom development board series, the Arduino Mega, and the PJRC Teensy The following table lists the properties evaluated for each board and the decided best option for each property: Teensy Arduino Mega NXP Freedom Best Option Clock Rate 16 MHz 16 MHz 48+ MHz NXP Freedom USB-MIDI Support 1 st -party packages 3 rd -party opensource packages Manual implementation of MIDI protocol and USB HID protocols Teensy or Arduino Mega USB-MIDI Documentation Heavilydocumented by 1 st - party Some documentation with packages Some 1-st party documentation Teensy Form Factor 0.7x2.0 inches 2.11x4.01 inches 2.08x3.19 inches Teensy While the NXP development boards offer higher clock rates than the Teensy and Arduino options, they come at the cost of requiring manual implementation for all of the lowest-level USB interconnectivity and MIDI protocols. By contrast, the Arduino Mega supports USB-MIDI via free and open-source software packages, and the Teensy is supported by native, vendor-developed and documented packages with compatibility for the same IDE as the Arduino. The Teensy s improved documentation, software support options, and vastly smaller form factor make it the clear choice for this product. In addition, if a higher clock rate is required in the final project, the Teensy can be replaced with a Teensy 3.5 (using the same 120MHz Cortex M4F found on some NXP Freedom boards) with no code changes required and with only a minimal increase in size.

5 2 Page 5 of 8 Risk Mitigation Design: The Teensy s native MIDI support provides high-throughput, low-latency interfaces for both transmission and reception of MIDI data over USB, and minimizes or eliminates all of the identified risks involved with this component of the product. With minimal code, the Teensy can be configured as an HID enumerating as a USB-MIDI class-compliant device which will be automatically detected and enabled by the host computer s operating system (meets specification A). These libraries support velocity sensitivity natively, allowing for integration of a velocitycalculation algorithm seamlessly into the MIDI transmission code (meets specification B). Additionally, Teensy s MIDI support is robust and low-latency, with high throughput allowances under normal operation as a MIDI device, the Teensy will buffer outgoing MIDI messages for up to 1 millisecond, or until 16 MIDI messages have been buffered, at which point the pending signals will be released as a single USB packet. If faster performance is required, the buffer can be flushed manually at any point, at the cost of requiring more USB bandwidth and reducing throughput perpacket (satisfies specification C). Finally, the Teensy is capable of being configured for simultaneous transmission and reception of MIDI messages via USB thus allowing it to receive MIDI signals and control the visual feedback components without any additional hardware or software overhead (satisfies specification D). The Teensy is also free to use in any products commercial or noncommercial post-purchase. The following block diagram shows the flow of data from a button press through the Teensy to the host computer and DAW:

6 2 Page 6 of 8 Similarly, the following block diagram shows the flow of data from the DAW through the Teensy, and out to the button LEDs:

7 2 Page 7 of 8 The following flowchart provides an overview of the MIDI transmission and reception code which will run on the Teensy:

8 2 Page 8 of 8 Parts List: Note: The Teensy listed has already been ordered and received. Component SKU/Description Cost per Item Expense Availability Teensy ATMEL-based 8-bit, 16MHz microprocessor and development board. $24.95 $24.95 ~1 week Testing Strategy: MIDI functionality can be tested by programming the Teensy to enumerate over USB as a MIDI class compliant device and then send a simple sequence of MIDI note messages. Compatibility can be tested by connecting the Teensy to computers running various combinations of operating systems and DAWs. This functionality will have been tested and refined if necessary over the next two weeks. Latency can be tested by programming the Teensy to enumerate over USB as a MIDI class compliant device and echo any MIDI message sent to it. Using a DAW, a message will be sent to the Teensy and the response will be recorded. The time differential between the initial message and the response represents the round trip time required to receive and decode a MIDI message, then encode and transmit a new MIDI message. This test can be repeated with multiple DAWs and operating systems. The latency will be tested initially within the next two weeks, and can be repeated over the course of the development cycle to ensure consistent functionality. Uncertainties: The two uncertainties identified with the selection of the Teensy for this product are the number of available GPIO pins and the clock speed. However, should problems arise relating to either a lack of available pins or a clock speed which is too low, they can both be mitigated by upgrading to a Teensy 3.5 development board, which offers 18 additional GPIO pins and an upgrade to a 32-bit 120MHz Cortex-M4 processor over the Teensy s 16MHz 8-bit AVR processor. Appendices: Teensy index: Teensy USB MIDI Interface Overview: MIDI Message Protocol Overview: USB Implementers Forum MIDI Class Definition: