New life old synthesizer. Part 1

A few years ago, my old Yamaha PSR-GX76 synthesizer died the death of the brave. This happened due to the fact that I mistakenly connected a 24 V power supply to it instead of the 12 V. In this mode, the synthesizer heroically worked for several minutes, after which there was a bunch, accompanied by audiovisual special effects and a specific smell, and the synthesizer no longer turned on . Since then, he has been gathering dust in a box and waiting for his time, which has finally arrived for him. In several articles I will tell you how the movement proceeded from the idea of ​​breathing new life into it before realizing and demonstrating the results obtained.

Autopsy

A typical synthesizer consists of several main parts: a sound generator module (usually containing the sound generator chip itself and a memory with instrument samples), an audio amplifier module, and a module that scans the keyboard matrix of the synthesizer.

Audio amplifier module (combined with power supply)

Sound generator module (memory is visible, the sound generator itself is on the reverse side)

An autopsy revealed that a power supply voltage regulator, responsible for applying voltage to the sound generator chips and the keyboard matrix scanner, tore into pieces on my synthesizer. Alas, replacing the stabilizer with a new one did not bring results. Further analysis showed that both microcircuits, apparently, no longer function: there are correct reset signals and a clock generator, however, no signs of life on the part of the microcircuits are observed. Since these chips were manufactured specifically for the synthesizer by Yamaha, it was not possible to replace them with new ones, especially since the model is already old. And then the idea occurred to me instead of repairing the old sound generator module, throwing it out and making my own, fully and completely customizable, with Linux and Wi-Fi.

Choosing a platform - the basis for a new synthesizer

Having caught fire with this idea, I began to select a platform on the basis of which a new “brain” of a synthesizer will be created. I started searching with relatively simple debugging boards on the STM32, since the initial idea was to implement from scratch the firmware that implements the synthesis of sounds. The selection criterion was the presence of at least several tens of megabytes of memory, a slot for an SD card, audio output and the ability to connect an LCD display. Then there was an idea to use something more powerful, and I remembered about the Raspberry Pi lying around idle. But in the end it didn’t come up for several reasons: the inability to connect an LCD display without dancing with a tambourine out of the box, the lack of a sufficient number of GPIO pins, a relatively low processor frequency. But by that time, I already realized that I had to move in the direction of Linux, because quite a lot of software synthesizers had already been written for it, and in particular, LinuxSampler and FluidSynth that particularly interested me. Therefore, I continued the search, having already discarded the “low-power” motherboards on the STM32, and after several hours of continuous searches, I found HIS, and I realized that this was what was needed. So, the EmbedSky E8 miniPC mini-computer, complete with a 4.3-inch resistive touch-sensitive LCD display, was chosen and acquired as a platform in China.


Its technical characteristics are presented in the table, the issue price is $ 48:

Dimensions	100x65x20 mm (excluding connectors)
CPU	Samsung S5PV210 Cortex-A8 (1 GHz)
RAM	512 MB *
EMMC Flash Memory	4 GB
USB ports	4 USB 2.0 ports, 1 OTG USB port
Audio	Input / output up to 48 kHz, WM8960
HDMI	HDMI 1.3 1080p @ 30 FPS
Ethernet	100 Mbit
Serial port	3 ports 3.3V, one port with standard RS232 levels
Clock	Real time clock support (plus battery)
Memory card	SD card interface
Buttons	2 programmable buttons
Camera	Special port for connecting a video camera
LEDs	4 programmable LEDs
Irda	Built-in IR receiver
Display	40-pin FPC for connecting LCD (resistive and capacitive screen support)
50 pin connector	17 GPIO lines, 4-channel ADC, SPI, 2 PWM, optional SD interface

* - the amount of memory available in the system with a standard core is about 390 MB (this restriction was later removed - details in the next article).
')
I must say, I was pleasantly impressed by the volume of documentation that comes on two DVDs with a mini-computer: there is a complete circuit diagram on the discs, documentation for each chip used, including full processor documentation, a user manual (in Chinese, but everything is clear) various instructions (for example, on installing Ubuntu and even on developing with Qt). In addition, there are source codes for the Linux kernel 3.0.8, the source code for the Android system, some software from EmbedSky, GCC 4.4.3, the source code for Qt and many more interesting things. On the board, two operating systems are preinstalled at once - Linux and Android 4.0.4, the choice of which one to load is through the U-Boot bootloader. Android was ruthlessly demolished by me, and all the eMMC flash memory available was used under simple Linux.

It should be noted that initially the board is configured to work with a capacitive screen. In order to switch it to the resistive interface, it is necessary to solder two jumpers on the back side of the board near the LCD connector. Actually, this was the first thing I did with the board after checking its efficiency. Then it turned out that the Linux image wired in eMMC is also configured to use a capacitive sensor by default. He killed a few hours, digging into the Qt and Tslib configs, but in the end, the touch still worked as expected.

Qt version 4.5 comes with the board - a rather old version. I love everything new, so I decided to compile the latest version 5 for ARM Qt, and because I didn’t really want to spend much time on development, I decided that I would write everything in Python, so I needed also the PyQt5 library. The Samsung S5PV210 processor has a built-in 3D accelerator with support for OpenGL ES 2.0, but unfortunately, Samsung provides drivers for OpenGL only for the Android OS, so I could not use Qt 5 with support for OpenGL ES (I tried to copy the necessary DLL from the Android image, but one from libraries had a dependency on libhardware.so and beyond to infinity), so I settled on LinuxFB as a platform for displaying graphics. With Qt compilation 5, no special problems arose, for the basis I took the config for Raspberry Pi and cut out everything related to OpenGL ES. Then I compiled Python 2.7.6 using the instructions from here .

When building for ARM library PyQt5, a problem arose - it turned out that the library has a dependency on OpenGL headers even if Qt was compiled without OpenGL support. I had to patch the library so as to remove the dependency. The corresponding patch was published on the PyQt mailing list . The ability to build without OpenGL will also be added to upstream soon. After assembling PyQt5, I successfully tested on the device examples from the Qt delivery, ported to Python and distributed as part of PyQt.

My GUI to LinuxSampler and FluidSynth, written in PyQt5

This was followed by cross-compiling LinuxSampler and its dependencies: libaudiofile , libfftw , libgig , libsndfile , libsamplerate . An interesting feature was found in libsndfile , named in the code of the library “Ultimate sanity check” - assert that the type off_t has a size of 8 bytes. In my case, this was not the case. Fortunately, simply deleting this “sanity check” completely solved the problem. I wonder why she does this check at runtime, and does not stop at the configure stage — it won't work anyway, why compile it?

Additionally, JACK was compiled as a sound output driver for LinuxSampler. It took the arm-timestamp.patch and atomic.patch from here . I also compiled with such flags for GCC to enable support for NEON extensions for ARM: -march=armv7-a -mtune=cortex-a8 -mfpu=neon -ffast-math -funsafe-math-optimizations -O3 .

At this stage, I had JACK and LinuxSampler, through which I could play MIDI files using the jack-smf-player. Together with the graphical interface (see above), there was written a Python module for working with LinuxSampler using the LSCP protocol, as well as using SWIG generated a binding for libgig , which allows you to download GIG files, and, in particular, find out what tools are inside They could be selected from the list in the Qt interface. Toward the end of the project, these developments, as well as all the original source associated with the project, will be uploaded to GitHub for everyone.

In the next article I will tell:

• How does the keyboard matrix synthesizer
• How I changed the burnt keyboard MK scanner on ATmega, about the firmware directly from the board, and how the microcontroller communicates with LinuxSampler
• How I did a core with stock-based Realtime Preemption support and how many problems encountered were solved
• How did the communication with the technical support company EmbedSky Tech
• How did you manage to reduce the latency of the sound when you press the keys on the synthesizer from several tens to several milliseconds?

All the manipulations described in this and the next article with minor differences can also be done using other suitable ARM platforms, including the Raspberry Pi, to make your own universal synthesizer from an old MIDI keyboard. The advantages of the latter include the presence of more powerful hardware FPU and the ability to build Qt 5 with support for OpenGL ES 2.0.

Next article >>