YAM - alternative Shruthi-1 firmware


EDIT: This initial description is outdated. Instead, see “README on Github”:https://github.com/bjoeri/shruthi-1 for latest changes.There you can also find the complete source code and “YAM builds”:https://github.com/bjoeri/shruthi-1/tree/master/yam_firmware_builds . The Ambika version of YAM can be found “here”:http://mutable-instruments.net/forum/discussion/7717/yam-alternative-ambika-firmware#Item_7 .

I’ve been fiddling with some minor Shruthi-1 firmware modifications and I thought I’d share it in case anyone is interested. Use it “as is” if you like, but you’re on your own :slight_smile:

The source is available “as is” on Github and contains the following changes compared to the official firmware:

  • Duo mode voice allocation reverted to 0.96 behaviour (only because I personally like it better)
  • ‘triangle’ oscillator is no longer band-limited. This is done to reduce memory footprint of the firmware for hacking. Also, the triangle wave is folded (instead of clipped) upon modulation, resulting in a one octave higher note at max modulation.
  • ‘qpwm’ oscillator added - It’s very similar to the quad saw implementation in ‘pad’. Note that the modulation parameter affect both detuning of the four pwm oscillators and the pulse width simultaneously.
  • ‘fmfb’ oscillator added - It’s basically the same as the original FM oscillator, but with added feedback modulation for modulation values above 64. At moderate modulation there’s added ‘grit’. At high modulation values there is some crazy digital distortion (that I deliberately left in).
  • EDIT: ‘pbpwm’ and ‘pbsaw’ oscillators added - polyblep implementations of saw and pwm heavily inspired by Oliviers prototype implementation for SMT, but more hardwired and less generic (no polyblep for sync etc) to fit into Shruthi constraints.

I believe patches made with the official firwmare should be reasonably compatible (except for the changes explicitly mentioned above), but again I won’t give any guarantees. Since I added the new algorithms between ‘vowel’ and the final wavetables, patches using the latter will probably have to be manually edited to correct the wavetable selection.

Happy new year!

shruthi1_YAM0.05.zip (393.7 KB)


I’ll need to give this a try. :slight_smile: qpwm sounds very interesting.

@audiohoarder Great! It’s nothing revolutionary but it’s sure fun to make your own hacks for this beauty

Just a bump to mention that I’ve now added PolyBLEP Saw and PWM oscillators. The implementation is heavily inspired by Oliviers experimental implementation for SMT available on GitHub, but it cruder, more hard-wired, and less generic (doesn’t handle sync etc). I haven’t done much testing, but I already like how the PolyBLEP PWM has less aliasing than the naive PWM, and yet more edge than the square based on bandlimited saw waves.

1 Like

Bringing polyBlep to the Shruthi is cool!

In which way is it crude? I never thought about putting this in the Shruthi (the division scared me), but now that I can think of ways of avoiding the division by precomputing 65536/(phase_increment >> 16) or the like, it seems doable to make it work without too many approximations. This would save quite a few bytes of flash :slight_smile:

1 Like

@pichenettes Thanks! Yes I struggled quite a bit with getting the division working in fixed point and without wasting too much flash memory. You’re right that it’s not crude given that both the Blep and the division tables use only 256 bytes of flash. Maybe it could make it to the official firmware some day :slight_smile:

Edit: Note I’ve already sacrificed band limited triangle for space (I personally don’t think it makes much difference for useful notes) :confused:

Edit2: I’ve focused on max backwards compatibility with the official firmware. If you consider replacing the original band limited saw and square altogether you would of course save plenty of bytes :slight_smile:

1 Like

Here’s three audio snippets that compare the polyblep pwm (1) with the original pwm (2 not band-limited at all) and the original square (3). All with a pwm paramter of 10.

I will now stop spamming the forum for a while :wink:


Please, keep on spamming. It’s interesting reading!

Ok :slight_smile: Here goes:

I don’t want to sound arrogant, but I actually like the polyblep saw and pwm varities better than the original firmware’s saw, square and pwm oscillators. And as Olivier suggest, they could even replace the original versions. Resulting in (potentially) better fidelity and more space for other stuff (since the corresponding bandlimited tables could be eliminated).

However, since there are qualitative differences, old patches wouldn’t sound the same. For example, the polyblep pwm is much more edgy and consistent in level than the original square (approximated by dual saws), so the level of this oscillator would have to be lowered a little to approximate original patches (for example the original 3 Moonrise, 4 Basic, 5 Virgin patches etc).

Personally, I’d be fine with dropping “square” for the new polyblep implementation, but since the original bandlimited saw is high pass filtered to approximate “juno” synths I think it should be left in.

Edit: deleted preliminary firmware file

1 Like

Can I let you in on a secret? I never use the regular square for PWM because of the volume drop after position 0.

I’ll definitely try uploading this firmware today. :slight_smile:

Well, the original bandlimited pwm (square with parameter > 0) is produced by adding two bandlimited saw waves, where one is inverted and shifted according to the pwm parameter. My conclusion is that the loudness drop is simply due to less headroom and fidelity in this procedure, or possibly that the bandlimited saw high pass filtering gives this effect. I may be rambling.

Getting an edgier but still reasonably antialiased PWM was my drive for this. I think it worked out better than I expected, and the new Saw and other possibilities are great bonuses. :slight_smile:

1 Like

Yeah, I just tried it out. Your pbpwm wave is something that had been missing from the Shruthi! :slight_smile: I also like the fmfb mode and the qpwm, but the poly blep oscillators really steal the show!

For people who want more “analogue” sounds, both of you pb waves are perfect. I just layered them with my BS2 for a quick test, and they beefed up the BS2 oscillators instead of the other way around! :open_mouth:

Overall, this is a very welcome addition worth its own separate firmware number. If you have plans to poly blep anything else go for it!

I’d be glad if some of these additions made it to the official firmware. I guess it depends what the community and Olivier think. I wanted to contribute a little to the Shruthiverse. (If only it was as easy to update the Ambika firmware via midi…)

I wouldn’t mind if these replaced the original saw/square.

1 Like

@pichenettes You’re more daring than me :slight_smile:
(I think the original saw still has its virtues in terms of ‘character’ and compatibility)

@pichenettes But I take your comment as a testament of the quality. Big thanks!

I haven’t listened to the audio clips (and I wouldn’t trust mp3), but I’m confident that a smart polyblep implementation can outperform the original code - so if you didn’t make any mistake and did not cut too many corners, it should be fine. I did the exact same thing as you did for Yarns and Tides.

1 Like

I think I cut just the right amount of corners - the truth is out there :slight_smile:

Yeah, the original saw has a wave shaping option while the new pbsaw doesn’t, but that can be solved by reverting to the older firmware. :slight_smile:

@audiohoarder True - I even forgot about that