This is awesome. Has anyone attempted to upgrade Shruthi to a more modern CPU and higher resolution code? I’d love to have a new control board for mine (all 7 of them!) which didn’t have so much aliasing at higher octaves and not so much steppiness when tweaking the filters. Unfortunately, I don’t know the first thing about coding or PCB design…
Have you tried the YAM firmware by @Bjarne ? It at least includes a PolyBLEP implementation of the basic oscillators which should sound less aliased than the original bandlimited implementation. But of course the ATMega is fairly limited as the audio output is just a PWM signal.
This just got me thinking: A STM32 Ambika voicecard firmware could potentially also be ported to a new Shruthi Control Board, as the two are very similar obviously, maybe by utilizing the oscillator code from Plaits.
That brings up the question: for these new voicecards/control boards, how backwards-compatible are they supposed to be in regards to oscillator types, modulations etc? When does the shruthiness stop and the shruthi-filter-compatibleness start?
I do use YAM, but I never used the original firmware so I don’t know the difference in SQ. If someone made an upgrade all I really care about is compatibility with the filter boards and the enclosure. I wouldn’t care about 1:1 patch compatibility.
I’ve been thinking along the same lines. I think my ideal would be a polyphonic Shruthi approach: a monolithic/centralized sound generation to allow for more straightforward firmware improvements combined with swappable filter boards. Obviously this is a big step away from the Ambika approach with voice cards and would also require a much more powerful CPU and lots of DAC’s.
I’ve no plans to make it backwards compatible (as in plug in and go) but I am reusing the structures to communicate the parameters…
(I’m also actively thinking about fx…)
Kinda like a modular diy novation peak.
I might make a prototype in the future with just some HW upgrades
- Graphic LCD with a 1602 form factor for more…graphics
- STM32F405 (FPU!)
- WM8731 with optional audio input wiring for maximum flexibility via the jumpers next to the socket
The control layout should be compatible with the Shruthi for ecosystem-reasons.
Please no TI’s PCM* line has so much better parts.
Even better, I don’t have experience with any of them specifically. Would PWM with an F4 be enough for CV signals? I assume the carrier and resolution could be high enough with such high clock rates.
I would not recommend PWM in a project that aims to get things done right
I know talk is cheap, but if someone really does take the time to design a new Shruthi PCB with a modern CPU and revamp the code to improve the resolution of the oscillators, filter controls, CV scanning, etc, you can count me in for ~$30 per PCB. I feel like there’s still a lot of hidden potential in these little synths that’s being held back by the slow CPU.
You might want to read this thread in full to see the history of the ‘better CPU’ idea.
I originally posted there but Emilie split my post and the subsequent posts into this Shruthi thread I was hoping that revamping Shruthi might be significantly easier than Ambika but it seems like it’s much more difficult than “insert faster CPU” and “update a small part of the code to do higher resolution calculations”.
Yes it makes sense to put Shruthi stuff in a seperate thread. Just the reasons why we still dont see any working Shruthis and Ambikas with 'better CPU’s can be found there
Would you mind sharing what to look for? When comparing the WM8731 to fit example the PCM3060 (seems to be the most suited for this), I see very similar SNR specs and support for 24-bits (the WM even supports 32bits?).
On the interface side, both talk I2S and are configurable via SPI, so no difference there. The PCM is less “bloated” on the analog side as it does not have the MIC/Headphone pins which we don’t care about anyways. The only advantage I see is that the PCM can get its system clock from the MCU while the WM relies on a crystal.
Build the circuit, measure the performances yourself
Why would you want ADCs for a Shruthi control board? There is no path to route audio from the filter board to the control board, so you’ll make something incompatible with the existing filter boards!
Most (all?) filterboards have the volume-potentiometer headers next to the input and output jacks. My idea was to optionally include a way to get the input signal to the input jack into the control board into Input 1 and then the filtered output from the filter board to Input 2 (via header). Output 1 of the Codec should go to the Filter OSC input, and Output 2 goes to the output header of the filter board.
This would allow for digital effects processing of the filtered signal and also audio input into the controller board, for example for sampling or whatever one might want to implement.
So, a couple of days ago, this arrived:
because I had it on hand, my first design used an F722, but I switched to F405 for now.
- PCM3060 codec
output works already
- AD5676 for CVs
- microSD-card slot
normal size didn’t fit unfortunately
- bodge-wires™ for the first prototype
- 5V compatible LCD interface
same as with the original board, including level-shifting
The LEDs, Switches, output expansion, Codec and DAC are tested to be working, next up are midi and the LCD. I hope I’ll find the time to port over the YAM-Shruthi code then, and after that (try to) improve it from the bottom-up, although a big improvement will already come from the increase sample rate. But obviously, the resolution of the Shruthi Oscillators is only 8-bits. The Codec has 24!
You’d better port Plaits’ code to it