Item — HN Reader

"No CPU involved" is not strictly true, as the CPU is doing the LFO. You can observe this by, for example, rapidly moving the data slider and noticing that the LFO slows down.

I considered doing a super-accurate "dirty" mode but ultimately decided against, as most of these changes would make it sound worse. One important subtlety is that after the DAC (which is just sample-and-hold) there's a Sallen-Key low-pass filter tuned at about 16kHZ, to round off the worst of the DAC artifacts. Many digital replicas (my own included) miss this, which gives a harsh brittleness to the sound.

I know dexed added multiple bit depths (this work was done after mine, and I haven't followed their fork carefully). I don't know about the other aspects of the signal chain though.

I get where you are coming from, though, and think it would be a good project for a super-dedicated contributor.

3 comments

Thank you! Didn't knew that about LFO. And I just found your wiki page [1], it's very informative. So I would like direct any curious reader there :)

[1] https://github.com/google/music-synthesizer-for-android/blob...

>One important subtlety is that after the DAC (which is just sample-and-hold) there's a Sallen-Key low-pass filter tuned at about 16kHZ,

You mean IC54 and IC56? I noticed them on the circuit but didn't know it was tuned SO LOW! Wasn't the sample rate over 50KHz for each voice? 16Khz looks overkill for such sample rate. I know this is a time-division-multiplexed DAC so pehaps the time division multiplexing generates even more artifacts of their own?

I would love to see a circuit that replaces the whole DAC section with 16 separate DACs that then mix their sound on the analog domain...

I recall seeing a comparison of DX7 vs dexed patches on Youtube that mostly found audible differences in envelope lengths, not timbre. That seems like something more straightforward to fix, though there's always the potential for a caveat like it being tied to the original hardware sample rate.