ProxMidi

Software Design & Implementation    top

QTouch implementation

As mentioned above, every sensor requires two port pins for implementation. In this project, we use a 3x4 keypad for selecting the MIDI patches and patterns, one wheel for controlling the tempo and one slider for controlling the volume of the MIDI. Since each sensor needs to two channels to operate, the keypad requires 24 port pins and each of the Rotor and Slider require 6 port pins. µCA is used to implement the touch sensing of the keypad and µCB is used to implement the proximity sensing of rotor and slider.

The basic implementation of keypad and rotor/slider is similar. We used the QTouch library functions to initialize the sensors, set the detection parameters and measure data.  System initialization includes setting the system clock, disabling the JTAG pins and disabling the pull-ups (using assembly or using the fuses). In this case, we used assembly language programming. The system clock is set to run at half the external crystal oscillator frequency i.e at 8MHz.  The function init_system() does this task.

The touch measurements have to be made periodically for which we used a timer ISR executing at 50 milliseconds. Every 50 milliseconds, a flag is set indicating that it is time to measure touch. The timer initialization is done using init_timer_isr() function. After the timer and system are initialized, the touch sensors need to be configured. For this, the studio masks indicating the connections to Port pins are set up using the QTouch Studio Pin Configuration Wizard.  The sensors are set up as keys or rotors or sliders as desired using the config_sensors(). This function uses the QTouch predefined public functions :

1)    qt_enable_key (channel_t channel, aks_group_t aks_group, threshold_t detect_threshold, hysteresis_t detect_hyseteresis)

2)    qt_enable_rotor (channel_t from_channel, channel_t to_channel, aks_group_t aks_group, threshold_t detect_threshold, hysteresis_t detect_hyseteresis, resolution_t angle_resolution,uint8_t angle_hysteresis)

3)    qt_enable_slider (channel_t from_channel, channel_t to_channel, aks_group_t aks_group, threshold_t detect_threshold,hysteresis_t detect_hyseteresis,resolution_t position_resolution, uint8_t position_hysteresis)

The default values we chose were 2 counts for the detect_threshold with a hysteresis of 6.25% and zero position/angle hysteresis. The position resolution is selected to be 8-bits and hence the sensor changes value from 0 to 255. The parameters recalibration delay, drift values also have to be set. This is done in function qt_set_parameters(). In this case we set the sensors to have no recalibration process.

Each time the user wants to scan the sensors and check if they are in detect, the user has to use the function touch_measure() which calls the QTouch library data structure qt_measure_sensors which updates the status flags indicating whether there has been a change in the signal level levels of any sensor, if the sensor requires to be checked repeatedly etc. The user uses these status flags for further implementation. In this case, if the QT_LIB_BURST_AGAIN flag is set to 1, then the qt_measure_sensors is called again to update the flags. This process continues till the burst again flag is reset. The function touch_measure() is called inside an infinite loop to continuously scan the sensors.

After this point, we define 2 macros to detect the key touch or proximity sensing of rotor/slider.

Keypad Implementation(µcA):

We used all pins of Port A,B and 4 pins each of Port C and D for 12 channels corresponding to 12 keys.  Each sensor is labeled by the SENSOR_NUMBER from 0-11. In order to check which key has been pressed, we use the macro GET_SENSOR_STATE(SENSOR_NUMBER) as :

#define GET_SENSOR_STATE(SENSOR_NUMBER) qt_measure_data.qt_touch_status.sensor_states[(SENSOR_NUMBER/8)] & (1 << (SENSOR_NUMBER % 8))

where qt_measure_data is a QTouch Library defined data structure that has three fields – channel_signals[], reference_signals[] and qt_touch_status[]. For a key press, we only need to detect if the status has changed from 0 [No detect] to 1[Detect]. Hence, the above macro accomplishes the task of checking if a particular sensor/key has been touched. A number of ‘if’ statements checking the status of each of the sensors are written and corresponding sensor number transmitted to the MIDI control MCU through a serial UART.

In order to ensure that sensor number is not transmitted repeatedly when a user holds down one key for a long time, we check if the previous key press was the same as the current. We transmit data only when it is not the same. In order to account for pressing the same key twice, for example – 1;1, we check if at any point none of the sensors are in detect. In this case, the SENSOR NUMBER is reset and multiple presses of a single key can be effectively detected.

Rotor/Slider Implementation (µcB)

We used Port A and B for 6 channels required by one wheel and one slider. The wheel controls the tempo and slider controls the volume of the MIDI. In addition to detecting which sensor value has changed using GET_SENSOR_STATE(SENSOR NUMBER), we have to get the position/angle of the user’s hand on the proximity sensor. This is achieved using another macro defined as follows :

#define GET_ROTOR_SLIDER_POSITION(ROTOR_SLIDER_NUMBER) qt_measure_data.qt_touch_status.rotor_slider_values[ROTOR_SLIDER_NUMBER]

As mentioned above, in addition to sensor_states[], the data structure qt_touch_status has another field called rotor_slider_values[ROTOR_SLIDER_NUMBER]. This returns the position/angle of the detection on the slider/rotor respectively. The rotor_slider_number is initialized depending on the order in which the rotor and slider were defined.

In order to transmit this data from the rotor and slider to the MIDI MCU, we send alternating tempo and volume values at regular intervals of 1 second in order to not overflow the receive buffer of the MIDI control MCU. For the MIDI control MCU to detect from which sensor the value came from i.e, whether it was volume or tempo change, in addition to the raw values we transmit an ID indicating whether the data that follows is a tempo variable or a volume variable. These IDs can be defined by the user to any values they desire.

MIDI Generation (µcC)

Due to the frequency requirement of a transfer speed of 31.25 kilohertz, an ISR is utilized on  µcC to raise and lower output pin C0 in order to transfer data to the MIDI receiver. Since µcC is clocked at 16 Megahertz, a prescaler value of 8 lowers the clock to 2 Megahertz. An overflow counter OCR2A is set to 63, further dividing the clock of the ISR so that every 64 counter increments the MIDI handling code is run, which works out to be exactly at the rate of 31.25 kilohertz, satisfying the 1% accuracy requirement of the MIDI protocol.

Microcontroller inter communication protocol

Since communication is performed via USART, a protocol was developed to allow for the the MIDI generating µcC to receive ID and value packets from the sensor micro controllers. The protocol requires messages to be in a two byte format. The first byte is the ID of the sensor which has made a measurement.

The proximity sensors periodically send their IDs and values via USART1 to ucC while the touch sensors record presses, sending messages over USART0. Each USART is configured at a baud rate of 9600, with 8 bit length, one stop bit and no parity bit. The two byte messages required µcC to keep track of whether or not a given byte should be interpreted as an ID or a Value, which is accomplished by state machine logic.  The first received byte is interpreted as an ID, whose value is recorded. The next byte corresponds to the value , after which an action can be taken if a valid ID has been recorded.  The parameters modified by the sensor messages in turn modify the messages outputted by the MIDI sequencer.

Note Generation

As the ProxiMIDI controller generates music, a scheme was designed to periodically send MIDI messages to a synthesizer in order to produce music. This was accomplished by creating patterns stored on µcC, which are sampled at rate controlled by tempo and whose values are used to send MIDI messages corresponding to the raising or lowering of notes. Tempo is controlled by modifying a software defined counter which controller the sampling function. Lowering the counter value causes the function to be run more often, increasing the tempo.

Sound generation

To generate the patterns of MIDI notes for musical composition, the arrays are read at a rate controlled by the tempo set by the circular proximity sensor. It samples the arrays which contain quarter note values and turns the notes on if they are valid notes. A sustain value is used to signify that a value should not be turned off a half or whole note, which prevents the controller from turning the note off at the beginning of the next sampling of the arrays. Channels 1 and 3 are composed of chords, which are sampled three at a time. The MIDION messages are sent using the volume parameter set by the proximity slider. Each time a patch change request is received from the sensors, ProxMIDI sends a patch change message to switch to a new instrument. This scheme allows for pattern changes and various instrument combinations.

Patch Selection

Patches were able to be changed by receiving button presses corresponding to a desired patch change and using a circular buffer of the instuments listed above to send PATCHCHANGE messages to the MIDI synthesizer.

Conclusions

Expectations Met / Not Met

The project met most of the expectations and design parameters.

Some of the difficulties encountered dealt with the sensitivity of proximity system to individual charged bodies. Some of the students wearing silk/wool garments were statically charged. This lead to unexpected behavior from the proximity system - including random increase and decrease in reading and proximity sensing ranges, but for 90% of the cases, the sensor worked perfectly fine.

The software is designed to calibrate on startup and expects the user to not be around when starting up. The calibration takes place one to two seconds after starting up. If the user is present during calibration, the electric field generated by the user is taken as the default measurement - or the baseline. Any future readings are compared with this baseline to determine if a touch has been detected or not, resulting in false readings.

Presence of any current carrying conductor also has similar effects on the proximity sensor - placing a switching LED or a USART cable near a proximity sensor causes it to record absurd values - possibly due to the electric field generated by the switching currents in the wire.

Conformed Standards

ProxiMidi conforms to the GM Midi 1.0 standard, being tested on a laptop computer using a EMU XMIDI USB MIDI interface and a standard electronic keyboard which accepts MIDI inputs. Both were able to receive commands to start and stop notes as well as changing patches on multiple channels.

We are not aware of any standards regarding capacitive and proximity sensing, but since it follows the standard Atmel ® QTouch protocol, it should conform to any standards included in the protocol.

Ethical Considerations

The project is safe to use, it runs on a transformer based power supply (typically 9 Volts) and further drops it to 5 Volts before powering the microcontrollers and the test circuits.

No part of this system is hazardous to touch. We have electrically insulated the entire project to avoid any electrostatic discharge from the user on to the board.

The system does generate a minor EMI (Electro Magnetic Interference) due to the charging - discharging of the capacitor, but its range is limited and effect negligible. On the other hand, the system is very sensitive to EMI, and does generate false readings in presence of strong EMI. We used decoupling capacitors at various locations to reduce the effect of EMI on sensor measurements.

Intellectual Property Considerations and Legal Considerations

QTouch and QMatrix:

The QTouch and QMatrix brands are owned by Atmel, and the code generated by the code composer studio uses Atmel’s proprietary technology. Users are allowed to use the code without any warranties. Atmel requires the copyright notice to not be removed from the code, which we followed.

MIDI legal considerations:

The MIDI protocol is freely available on the internet as it is a a communications standard. MIDI technology was standardized by a panel of music industry representatives, and is maintained by the MIDI Manufacturers Association (MMA).

We did not violate any intellectual property rights in developing this project. All specifications for the project were designed and implemented by us. We wrote most of the code, with no violation of any patents.  We referred to Prof. Bruce’s code on UART initialization and functionality to implement the serial communication between the 3 microcontrollers used.  We used the GCC QTouch library and API  to implement capacitive sensing.  Portions of the ISR which serialized MIDI data from the Glove Midi Controller project were used to sent messages to the audio device. The simplicity of operations allowed for us to make improvements on the design and create more complex musical patterns. We do not plan to get patents for this project as there a number of QTOUCH based devices in the market today.