80s electric piano up-cycling with Pianoteq!

Cool project. Nice audio solution (cheap USB DAC to amplifier).

Would be interested in hearing more details about how you setup the Odroid XU4 to work with Pianoteq. Especially assigning the 4 high performance cores to Pianoteq and 4 low performance cores to the OS. Also what Pianoteq Performance Index number are you getting?

wow, i can't understand all the details, but sounds amazing.

i do find it funny, in a friendly way, that a genius like you couldn't figure out how to post images here.

use the BBCode help.

you can host your images here:  https://imgbb.com/

steve200

Oh, my setup is totally stable. The custom kernel throttles very conservatively and I am using a high surface area passive heatsink. In fact, mostly taking the slower cores out of the equation allows me to run at 2GHz without throttling.

I only mentioned additional optimisations because I want the system to run as cool as possible.

1.9 GHz is in fact my first throttling step. So the system will go there automatically if it reaches 90°C, which it so far never has.

Thanks for the pointer to the thread! It's very useful to see how others have dealt with the cooling issue.

Andreas

So finally a few images with further detail:

The final result looks like the original CLP300 and preserved all the user control features:

Inside a few things have changed. You can see the power supply board on the left and my own board arrangement on the right replacing the original mainboard. The dampening wool has been added behind the case speakers to reduce cavity resonances and acoustic short circuits in the low frequencies.

Now for comparison the original 80s mainboard with discrete Logic ICs and proprietary Yamaha CPUs next to my replacement. I've covered the area of the original mainboard with a hard-foam board that carries the different components now.

Up close, you can see the PSU and speaker amplifier to the left and the odroid on the far right. In between are the three custom boards I have added. The biggest board in the centre is the key scanning circuit. It acquires the state of the keyboard at a rate of 30kHz which is 30 times faster than most commercial key scanners. That means the key velocities can be determined much more accurately and the fastest keystroke is also much faster allowing for a better dynamic range of the keystrokes. I am tracking note-on and note-off velocities as well. The Teensy on the top right converts the timing information to MIDI with high resolution velocity and sends it to the Odroid using a USB link. The velocity data is actually calculated based on the true key velocity without any form of additional modifications. This is exactly what Pianoteq requires to calculate the physical model, so no additional calibration is needed for a great translation of the action.

A better view of the boards with some of the cables removed. The top left board interfaces with the damper and sustain pedals and sends the data to the teensy. It also takes the audio signal from the usb-cable interface and prepares it for the amplifier. The relay on the board turns audio output on when Pianoteq is fully loaded. In the middle of the board there is an audio line driver that is supposed to deliver balanced line out to the connectors on the back of the case. This section is not yet fully working and the line out connections are still missing. On the back panel there is an ethernet connection that links to the odroid, so that it can be accessed from outside without opening the case.

As I wrote above somewhere, it takes about 20 seconds from power-on to being playable. The longest time is spent in loading the kernel modules. It should be possible to change the kernel configuration to remove all irrelevant bits and pieces and include the important things statically and reduce the boot time significantly. I have not had the time to really approach this, as there are some issues with compiling kernels for the Odroid. Compilation may fail and it's hard to track down the options that cause it. So creating a working kernel configuration that also includes the realtime preempt patch takes a significant amount of trial & error.

What are you planning to use the sensors for?

Andreas

That doesn't sound feasible. Apart from the much slower reaction time of a Hall sensor and the much less precise switching position, you would not be able to use a diode matrix for scanning. Instead, you would have to scan all the key sensors directly. I don't think there's a microcontroller with this many inputs. And multiplexing is probably much too slow.

So what are you trying to achieve? Switches work very well if done correctly. What kind of advantage do you think you get from using Hall sensors?

Andreas