Sculpt-O-Sound presents: Decode-O-Matic
Summary / TL;DR
Decode-O-Matic is a diagnostic tool that you can use to check midi signals. Sometimes a synth may not respond to a midi signal you are sending to it and you want to find out why that is the case. In actual practise being able to see whether any midi signal is sent to the device at all often solves most problems. Furthermore, being able to see the channel number of the midi signal the synth is receiving will often help to remedy the remaining problems. Only in more difficult cases it may be necessary to have a look at the midi data itself.
Decode-O-Matic consist of 2 parts, a decoder and a viewer.
The decoder part is connected as a pass through between the synth and the midi interface. It is powered via USB.
It will show whether any midi data is received and it will show the data’s channel.
A second device is a midi viewer which can be connected via USB to a computer.
The computer can read the midi data received via a com port (windows) or tty (linux) or serial device (OSX) via free software like PuTTy or minicom. On linux you can also cat or tail -f or use less -f to see the data. For this to work you need to set the baud rate of the tty like so (assuming the viewer is on ttyUSB1):
stty -F /dev/ttyUSB1 115200
less -f /dev/ttyUSB1
To view the data it may be necessary to add a Carriage Return to every line.
In PuttY tick configuration → Terminal → ‘Implicit CR in every LF’
Using putty, the output might look like this:
Note: the data is transfered not as a stream but as blocks of data.
In the picture NF is Note Off, NO is Note On.
The viewer device is not needed to use the decoder device.
The decoder could have been used to show the data on a computer. However, I chose to implement the viewer as a second device so that I did not have to move my computer to the non responding synth to be able to display the decoder’s information. By making this a wireless device, the synth and decoder can be interconnected independently from the viewer and the computer. And since some of my synths are USB-powered, there is always a USB-power supply near by to power the decoder. The viewer can easily be powered by my computer.
Both devices are based on a Wemos D1 R1 (which contains an ESP 8266 device) but the code can easily be ported to any other ESP based wifi device. I did not have any other reason for using a wemos than that I had a few of those laying around.
The two devices are interconnected wirelessly via ESP_NOW and form a small private network. They do not require any WiFi router or similar to be around. Nor do they need internet access. The decoder however will need to know the mac address of the viewer. In de code you need to fill the broadcastAddress with the proper address.
broadcastAddress = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
This is a schematic of the decoder and the viewer. The decoder has some LEDs attached to it and a midi in (plus opto coupler) and midi thru connector. The viewer (top right corner) consists of only a Wemos, one LED and a resistor.
The decoder shows midi channel information using 10 LEDs. LED0 … LED7 are used to show activity on channels 1 to 8. Whenever a midi sgnal is decoded, the correspondng channel LED lights up fo a few seconds, so that you can clearly see that there was a signal for that channel. LED8 shows the raw midi data straight from the opto coupler so it flashes very rapidly. For channel 9 to 16 again LED 1 to 8 light up with LED9 signalling that the data is sent using the upper midi channels (+8).
I used a LED-filament I bought via aliexpress which runs on 2.9 Volts and glued it to the inside of the decoder box for some extra FX. Its flashes in the same fashion as LED8 and lights up the embossed text (particularly the O in Decode-O-Matic) on the 3D printed case.
Note: I used a Wemos D1 R1 development board and found that the silk screen shows a lot of GPIO-pins which it turns out are not all usable. Quite a few IO-pins are interconnected so are in fact ONE gpio but have multiple names. E.g. D7 and D11 are interconnected. The same goes for D6 and D12 and D5 and D13.
To make things more complicated, if you use the arduino IDE to program the device (or use the arduino framework in platformio) then you will find that the name you use in the code does not correspond to the silkscreen. E.g. D4 is not output D4 but it is D9 while D9 is connected to output D3. It took me a while to decode this mess, and I wrote it all down in this table:
// i.e. <name of pin(s) on silkscreen of wemos pcb>
D9 // 1 i.e. D3.
D8 // 0 i.e. D10.
D7 // 13 i.e. D7 == D11.
D6 // 12 i.e. D6 == D12.
D5 // 14 i.e. D5 == D13 == blue SCK LED.
D4 // 4 i.e. D9.
D3 // 5 i.e. D8.
D2 // 16 i.e. D14.
D1 // 1 i.e. D15.
D0 // 3 i.e. D2.
A0 // no responding pin found
Luckily this left me with just enough IO-pins for the decoder without having to add additional decoding circuitry. I built the decoder circuit on a perf board, and used pin headers to connect it to the wemos.
Note: this picture shows an early version of the decoder part.
I used Dupont cables to connect the LEDs because this seemed convenient, but as the cables I have are very stiff, they tended to break quickly while building the device.
The receiver is a very simple device. It consists of another Wemos, an LED and a resistor.
I have uploaded the code, schematic and STL-files to my github.