Build the "REMI" (mk1)
A DIY Project by M.J. Bauer
This web post describes the design and construction of the "first generation" REMI - mk1.
The REMI is an "electronic wind instrument" (EWI) using a fingering scheme based on the traditional recorder, simplified a little to make it easier to learn to play. The concept is based loosely on existing commercial EWI's using touch-sensitive pads for the “keys” to select the pitch of notes. A breath pressure sensor allows notes to be articulated by blowing into a mouth-piece.
A REMI setup typically consists of
two main parts for self-contained operation:
The synth module allows the REMI to be played "stand-alone", without needing an external MIDI sound module or computer. Sockets are provided for audio output to an amplifier and/or headphones. The built-in synthesizer is capable of producing a variety of instrument sounds. However, it is optimised for wind instrument sounds. For example, it can sound like a recorder, flute, clarinet, oboe, jazz organ, pipe organ, or whatever. The sound quality and pitch accuracy are more than adequate for serious musical performance.
The synth module also provides MIDI IN and MIDI OUT sockets (5-pin DIN) for connection to a MIDI synthesizer or sound module, or to a personal computer via a low-cost MIDI/USB adapter.
Two "octave pads" on the underside of the hand-piece extend the range of pitch of the instrument to four octaves. (By contrast, it is difficult to obtain more than two octaves from a real recorder.) Further, the 4-octave range can be "shifted" (transposed) up or down the scale any number of semitones by setting a "pitch offset" parameter in the software.
A modulation lever (or force sensor) operated by the RH thumb can be fitted to control a selected sound parameter, for example, pitch bend, vibrato depth, timbre, etc. If not assigned to pitch bend, the modulation lever can be configured as a MIDI "effect controller" to send periodic MIDI Control Change messages.
A button on the under-side of the handset, operated in conjunction with the touch-pads, selects one of eight instrument "Presets". The selected Preset determines various instrument and MIDI configuration parameters. For example, a Preset sound is chosen from a collection of pre-defined synth patches built into the micro-controller firmware. The Preset also selects one of a group of MIDI "programs" (instrument voices) for use with an external MIDI sound module.
The cost of parts to build a REMI is much less than a commercial EWI.
The 'MIDI OUT' (transmit) command set includes: Program (voice) selection, Note-On/Velocity, Note-Off, Channel After-touch (pressure), Expression or Channel Volume, Pitch Bend, Control Change (effect modulation), All Sound Off and System Reset. The REMI can be set up to use any one of the 16 basic MIDI channels.
In normal note trigger mode, the REMI will send a Note-On/Velocity command when the breath pressure exceeds a preset threshold. A corresponding Note-Off command will be sent when the breath pressure drops below the "note-off pressure level". After a new note is initiated, a change in fingering pattern will cause another Note-On/Velocity command to be transmitted without first sending a Note-Off. If the external MIDI sound module is set to Mono mode, this should cause the module to produce a different note, i.e. to change pitch, without "re-attacking" the amplitude envelope. The musical term for this is "Legato".
While there is no note being played, the PRESET button may be pressed in conjunction with a touch-pad to select one of a number of instrument "Presets". A MIDI "Program Change" command will be transmitted. The Program Number sent depends on the user-defined Preset configuration.
In addition, pressing the PRESET button while none of the touch-pads is touched will cause the REMI to transmit a MIDI "All Sound Off" command followed by a "Controller Reset" command.
Provision of a 'MIDI IN' connector allows the built-in synthesizer to be played by any MIDI controller, for example, a keyboard or another EWI with a standard MIDI output. Using a low-cost MIDI-USB adapter, the REMI synth can also be controlled by a computer running music software, for example, a MIDI sequencer.
REMI's built-in sound synth is implemented largely in software, requiring minimal circuitry outside of the MCU chip - just a low-pass filter in the audio output circuit. To generate audio tones, REMI uses a dual "wave-table oscillator" algorithm offering a variety of waveforms which can range from simple to rich and complex sounds, some resembling acoustic instruments.
A PIC32MX processor clocked at 80MHz allows a sample rate of 40kHz with 11-bit precision of PWM audio output. Internal DSP computations use 32-bit fixed-point arithmetic resulting in high quality sound.
For clarity, the diagram omits the LFO, envelope shapers and PWM-controlled audio attenuator.
The synth model comprises a pair of wave-table oscillators which can use independent wave-tables. The two oscillator outputs are fed into a "mixer" which scales and adds the two signals in a variable ratio. The mix ratio can be fixed, or it can be varied in time as the note progresses. The mixer has its own dedicated envelope shaper to control the oscillator mix ratio. This capability is used to implement "waveform morphing", a technique used to vary the harmonic content of the sound with time. Waveform morphing can be used to realise a range of effects, beyond what is possible to achieve with filtering techniques.
The pitch of the secondary oscillator can be "detuned", i.e. increased or decreased relative to the primary oscillator. The "detune" factor is a patch parameter having units of "cents", so that the detune resolution is 1/100th of a semitone. If the detune factor is a fraction of a semitone, typically in the range 3 to 30 cents, and both oscillators are driven from wave-tables with similar harmonic content, the resulting effect is known as "Voix Celeste" (heavenly voice). This effect greatly enriches the soundscape possibilities of the synthesizer.
In addition to the two wave-table oscillators, a low-frequency oscillator (LFO) is provided. The LFO can be used to modulate the audio oscillator frequency to implement vibrato, or the LFO can be used to modulate the oscillator mix ratio. In the latter case, the mixer envelope output level determines the modulation depth.
An external analog filter of some sort is necessary to remove the 40kHz carrier frequency from the PWM audio output signal. The recommended filter is a 3rd-order low-pass circuit with a roll-off slope of -18dB per octave. The corner frequency is variable over a three decade range (10Hz ~ 10kHz) by means of a PWM signal generated by the MCU. The filter can be made to track the pitch of the primary oscillator, or it can be set to a fixed frequency. A simpler 3rd-order fixed-frequency (10kHz) low-pass filter may be substituted if desired to reduce construction effort, with very little sacrifice of the synth capabilities.
The amplitude (loudness) of the note-in-progress can be varied with time in a variety of ways depending on the instrument patch. A five-segment envelope shaper provides the classic "attack, peak-hold, decay, sustain, release" (AHDSR) amplitude profile. In addition to the envelope shaper, amplitude can be controlled by the breath pressure sensor, or by the modulation lever, or by MIDI IN Control Change messages.
The firmware includes several "pre-defined" synth patches providing a good variety of instrument sounds. Any pre-defined patch may be assigned to any of the Presets via the user interface (GUI or CLI).
How the Synthesizer is Patched
The REMI synth can be programmed (patched) by the user to create a new sound, without needing to modify and re-compile the firmware. Instead of using knobs and switches like a "real" synthesizer, however, the REMI synth is patched by means of a set of numeric parameters... (see table below). A CLI command "patch" is provided for the purpose of setting patch parameter values. A user-created patch can be saved in non-volatile memory (EEPROM) for later recall. The stored "user patch" may also be assigned to any of the instrument Presets.
Table 1: REMI Synth Patch Parameters
Two patch parameters specify which wave-tables out of a large selection will be used by the synth oscillators. The assigned wave-tables determine the waveforms and hence the harmonic content of the oscillator outputs. The "user patch" can specify any pre-compiled wave-table (stored in MCU program memory) or it can specify a "user wavetable" which, as the name suggests, may be created by the user. A CLI command "wav" is provided for this purpose. The "user wavetable" is also stored in non-volatile memory for later recall.
REMI makers who are prepared to re-compile the firmware can add their own patches and wave-tables, limited only by the amount of MCU flash program memory. CLI commands "patch" and "wav" include options to dump patch parameters and wave-table data (resp.) as C source code definitions.
Sample sound clips made with the REMI synthesizerNo post-processing effects were used in the recordings, except for a small amount of "concert hall" reverb to create a stereophonic image. More sample sound clips and a better quality demo video will be posted later!
REMI fingering is based on a traditional wind instrument, the descant recorder, with simplifications. The scheme uses eight touch-pads on the upper surface, i.e. one pad (hole) fewer than the recorder. Three pads are operated by fingers on the left hand while five pads are operated by fingers on the right hand. The fourth and fifth RH pads (RH4 and RH5) are both operated by the little finger.
Two pads on the underside of the handset operated by the left-hand thumb select one of three ranges of notes, each range being two octaves. The octave pads are located so that one or other or both pads together can be touched. When both octave pads are touched, the "middle" note range is selected (normally C4 to C6). By moving the thumb to the upper or lower pad, the range of notes is shifted up or down by one octave, respectively. The octave pads extend the overall range to four octaves.
Referring to the “Bauer EWI Fingering Chart” below, it can be seen that the fingering combinations cover two octaves, without changing the octave selection by the LH thumb. Selection of notes in the first octave of each range follows quite closely the fingering patterns of the recorder, including C" (Alt.) above the low C'. Contrary to the recorder, however, the second octave simply repeats the fingering pattern of the first octave, with the top pad (LH1) released, up to G". Above high G", the fingering gets a bit weird, but not as weird as a real recorder.
Alternative fingering schemes may be implemented by modifying the firmware, of course.
If two or more pads marked with a diamond symbol (◊) are touched, the effect is the same as if any one of the pads is touched, i.e. the note is flattened by one semitone.
The little finger on the right hand can select either pad RH4 or RH5, which are close together.
Pads RH4 and RH5 are located so that both can be touched at once by the fourth finger, but this fingering oddity is needed only for selection of the alternate B note in each octave.The alternate C" is designed to maintain semblance to recorder fingering in the first octave.
Controller Module Design & Construction
Following is a description of the author's prototype PIC32 controller module (rev.A) which was built around a PIC32-MX460 development board, made by Olimex, plus an extension board implementing the handset interface, MIDI output driver and audio signal conditioning circuitry. The prototype incorporated a front-panel user interface consisting of a low-cost monochrome graphic LCD screen and 16-button keypad.
fully-optioned build includes front-panel user-interface (LCD
screen and keypad), classic MIDI IN and MIDI OUT connectors (5-pin DIN)
and synthesizer audio circuitry.
The firmware includes a command-line user interface (CLI), accessible via the "RS-232" serial port provided on the MCU board. The CLI was originally intended mainly for firmware development, diagnostic and testing purposes, but the CLI now provides equivalent functions for all operations performed by the front-panel UI -- and much more. You'll need a USB/Serial adapter cable (~ $10) and a PC terminal emulator application (e.g. 'PuTTY').
The LCD panel and keypad are optional. The REMI can be operated using just the console CLI. This is like the "Command Prompt" in Windows, or the "Console Terminal" in Linux. User interaction is all text-based. The REMI CLI has commands to do everything, e.g. test, set up configuration options, set up instrument Preset parameters, synth patch operations, wave-table selection and creation, etc, etc.
In contrast, the front-panel UI can perform only a subset of the CLI functions - it's main purpose is to change the instrument 'Preset' parameters, for example to select the synthesizer "patch" (and/or MIDI voice for external synth) assigned to each Preset. It is convenient to be able to do this without the need to connect a computer.
The LCD module chosen for the mk1 prototype used an ST7920 display controller chip with a monochrome back-lit graphic LCD screen of 128 x 64 pixels. In hindsight, this was a poor choice, because the ST7920 data write operation is very slow in graphics mode. Also, with the ST7920 chip, the VDD supply voltage must be dropped to about 4.5V to ensure logic-level compatibility with the PIC32 I/O signals (3.3V).
In future firmware revisions, it is planned to support LCD modules using the KS0107/KS0108 controller chipset. This is the preferred option, because the KS0107/08 MCU interface is much faster than the ST7920. Moreover, the KS0108 MCU interface signals are TTL-compatible, which means that the LCD module can be powered directly from the 5V supply rail.
A suitable LCD panel is available from Sparkfun. Equivalent modules are available at low cost from online suppliers, e.g. Ali-Express. This type of LCD module is also available with smaller overall dimensions and a smaller dot pitch (~0.4mm). There are many variants of the connector pinout, different chip-select polarity, etc, so be sure to observe the datasheet of the display module you decide to use.
The mk1 prototype (pictured above) used a 16-button numeric keypad wired in a 4x4 matrix, interfaced to the micro-controller using just four wires. This scheme works by using ADC voltage readings to determine the row and column addresses of a key when pressed, in similar manner to reading a resistive touch-screen. It is planned to replace the 4x4 keypad with a set of 6 push-buttons in the mk2 design, because the keypad looks a bit clunky and takes up a lot of space on the front panel. In any case, numeric data entry is rarely needed. A screen allowing the user to enter numbers (up to 5 digits) using just 6 buttons can be realised.
The handset does not have a micro-controller built in. The 10 touch-pads are wired to a NXP MPR121 capacitive touch sensor breakout board from SparkFun, interfaced directly to the PIC32 MCU in the controller module via an I2C serial bus. The handset is connected to the controller module via a 6-wire cable (including +5V DC power, 2-wire I2C bus and 2 analog sensor signals). The cable length should not exceed two metres.
The prototype handset was made from two pieces of PVC plastic cut from a scrap of drain pipe, 110mm outside diameter, 3mm wall thickness. A suitable scrap may be found perhaps on a building site. The curved surface makes the plastic covers very rigid and strong. The upper piece has 3 wooden "ribs" (8~12mm thick) glued to it, allowing the bottom cover to be attached with self-tapping screws. Side strips of fibre laminate or timber veneer may be glued to the ribs. The plastic surfaces were not painted, but rubbed with fine abrasive cloth (P400) to give a smooth matte finish. The result is a very "retro" (1950's) look and feel. For a more modern look, the plastic covers may be spray-painted and the side strips made from brushed aluminium.
The touch-pads are self-tapping screws with a broad flat head, cadmium-plated (I think). These are inserted through holes in the handset playing surface, fastened on the inside with aluminium retainers (~9mm square). Machine screws with hex nuts would be better if you can find a variety with a broad flat head, plated with a corrosion-resistant metal. Solder lugs are fitted under the retainers (nuts) for wiring to the MPR121 board. A drill template and cross-section drawing are available for download -- see links at bottom of page.
The mouth-piece is carved out of soft-wood with a 6mm hole drilled through the middle. It should be coated with a water-based sealer* to prevent moisture absorption in the wood. The nylon tubing is inserted into the 6mm hole, all the way through to the tip, and held in place with a water-based sealer. The mouth-piece is attached to the upper plastic cover with 4 self-tappers, so that it is easily removeable.
*Warning: Do not use a paint or laquer with oil-based solvent on the mouthpiece, for 3 reasons... (1) it tastes terrible, (2) it could cause a health hazard, and (3) the vapours given off by the solvent could damage the Fluoro-silicone membrane in the pressure sensor. Recommended coatings for the mouthpiece are water-based polyurethane, PVA wood-working glue (dries clear), or some other safe product used to paint wooden toys.
Pitch-Bend / Modulation Lever
A Modulation Lever mechanism may be fitted on the handset, located so that it can be operated by the right-hand thumb, or it may be omitted altogether. Makers with adequate workshop skills and plenty of spare time may opt for a DIY solution to build a suitable lever mechanism. The technique I decided on was to use an optical position sensor. A shutter or vane moving between a LED and a photo-cell gives a variable output voltage.
The simplest option is to use a force-sensitive resistor (FSR-402). This will give a uni-polar output, which is not ideal for a Pitch Bend controller, but quite satisfactory as an "Effect Controller" (e.g. vibrato depth). The FSR can be mounted behind a round cutout in the bottom cover of the handset. A round rubber pad, about 10mm diameter, 4mm thick, may be stuck onto the FSR for use as an actuator. These are available from hardware stores.
Pressure Sensor “plumbing”
Tubing and other bits and pieces needed to make the airways inside the handset may be sourced from the garden irrigation section of your local hardware store. The prototype handsets (pictured) used clear nylon tubing (3mm ID, approx 5.5mm OD) for the internal airways linking the mouth-piece, pressure sensor IC and the "drain tube”. The T-joiner needed the barbs cut off to fit the 3mm tubing.
The sensor air inlet barb is slightly less than 3mm in diameter, which is a wee bit too small to make a good seal with the 3mm ID nylon tube. An easy solution is to fit a short bit of 2.5mm (nominal diameter) heat-shrink tubing over the barb, shrink it with a hot air blower or whatever (taking care not to melt the sensor!), then fit the 3mm nylon tube over it.
A drain tube is recommended because moisture condensation occurs inside the airways and it is probably sensible to provide an exit for the moisture. Also, the drain tube allows air-flow, which is preferable to a sealed system for playability. However, the exit air flow needs to be restricted somewhat to produce a sufficient range of pressure inside the sensor. This can be achieved by fitting into the drain-tube a small plug with a 2mm hole through it, perhaps cut from a bit of plastic insulation sleeving if you can find some of suitable size (3mm OD, 2mm ID). The best place to fit the restrictor is close to the T-joiner, to minimise moisture condensation.
It is also recommended to mount the pressure sensor above the T-joiner, i.e. close to the mouthpiece, to prevent moisture from accumulating in the sensor, as shown in the picture above.
This firmware release (v1.4)
is designed to support the 'mk1' prototype hardware configuration, the
handset of which uses the MPR121 touch sensor device with I2C
connection to the controller module. As such, this firmware version
will not work with the proposed REMI mk2 hardware configuration. The mk1 firmware is available to download (link below) for anyone interested in this implementation.
Last revised: 19-OCT-2018