Shruthi-1 firmware development

Hi all,

While waiting for some shipments of parts and investigating on the problems some of you had with the kits, I’m doing a bit of coding for a next firmware revision.

DONE:

  • More uses of the CV1…4 inputs. So far they were only accessible through the modulation matrix. I added an option to hardwire CV1 > osc 1 prm / CV2> osc 2 prm / CV3 -> cutoff adjustment in the perspective of building a small expansion board with an expression pedal input and a joystick for VS-style morphing fun. Another option adds support for a 32-pots expansion board with a dedicated pot for each setting on the first 8 pages…
  • Punchier/smoother envelopes. The decay/release are now decomposed into 3 linear phases to give them a more exponential feel.
  • Support for filter-board specific options. At the moment, it’s just a placeholder, but everything is there for adding extra pages for programming the filter boards that will contain more than a VCF/VCA (in preparation of a board with a built-in delay!).
  • Secret “preset” mode. When this mode is enabled, the Shruthi boots on the preset page, and remembers the number of the last visited preset when you power it down. Got this request from two musicians using the synth on stage.

TODO:

  • pots scanning ADC improvements. I’m not sure how well it will go, but the goal is to get stable 8-bits readouts from pots to switch to a 0-255 range for Cutoff and other important parameters: less stepping! I can’t do that at the moment because the 2.5 lowest bits I read from the ADC are trash - so I need to set up a filter with just the right amount of smoothing to make it computationally cheap, reactive, and with only 2 bits of noise.
  • 24 bits phase counting. I’m not sure if I’ll have the computational resources, but if it works, this will allow more subtle beating between the two oscillators.

Definitely excited about the new CV uses! I played with an expression pedal hardwired to cutoff when I was building the filter board and it was awesome! Plus the fact that it was true analog was wonderful, no aliasing whatsoever!

> More uses of the CV1…4 inputs. So far they were only accessible through the modulation matrix. I added an option to hardwire CV1 > osc 1 prm / CV2> osc 2 prm / CV3 -> cutoff adjustment

i’m not sure i understand. this is already possible with the mod matrix. what’s the advantage of this new setting?

The advantage is that you don’t have to program it into all your patches ; and because it’s hardwired it’s a bit more reactive.

oh so then it’s a global setting, not one that is stored with each patch? i guess in that case, personally i prefer the flexibility of the mod matrix. i haven’t done so yet, but i’m planning to add cv in sockets at least for two of those cv inputs on the board to be able to add modulation sources from my eurorack modular synth. those sockets neatly fit into the honeycomb holes in the acrylic enclosure. well, i guess hardwiring filter cutoff mod to one cv in kind of makes sense as that is probably one of the most commonly used modulation destinations. but as for cv1 an cv2 i guess i’ll stick with the mod matrix for more flexibility.

btw, what voltage range do those cv inputs accept? do they work with negative voltages or only positive ones?

They accept only 0 to 5V, with higher and lower voltage potentially damaging the ADC. You need to clamp the signals from your modular, using either a clamp chip like the TL7726 or a Zener, or two Schottky’s.

uh oh, good thing i asked before starting to experiment with this!

unfortunately i’m so electronically illiterate that i have no idea what a “clamp chip” or a zener or a schottky is, and how they are used. maybe if you find the time, you or somebody else in these forums who knows about these things could put up a small tutorial about how to protect these cv inputs? i guess i’ll postpone my own cv experiments till then. :slight_smile:

maybe for the time being, it might be a good idea to add a warning about this in the reference manual?

Just thinking about the poly-chain mode. I think the envelope times need to be longer for poly sounds, up to about 20 seconds for each stage would be ideal, with the edit values scaled so there is more resolution for the shorter times. Is this possible?

I’m not sure people will accept that their patches will sound different after a firmware update.

It would be a bit of trouble for people but I think it would be worth it. I suppose another way would be adding a ‘long envelopes’ mode? They seem pretty short for poly sounds at the moment - I’ll have to measure them. I’ve been meaning to measure how my K-Station does it, they’ve got params from 0-127 and the stages are 20 seconds on that.

Ok I had a look at this. Envelope is 14 bits internally, with integer increments, and is recomputed every ms. Hence, if it were linear, it could last for 16s. It is pseudo-logarithmic so it has a phase where it decays faster. The resulting time is about 8s. I can’t do much without using a fractional increment and that might be too costly.

Thanks for looking into it. How about a slow mode where it updates every 2ms? That would get us to 16s with a logarithmic shape.

The Waldorf Pulse runs on a roughly 2ms update rate, here’s the SOS review where the Waldorf guy is quoted:

'“Digital machines and digitally-controlled analogue synthesizers always suffer from one problem: they are slow at processing modulation, either digital or analogue. On the Pulse, we developed control voltage generators that are really fast. The modulation update is 523 times per second, which means that each modulation gets updated every 1.9mS. This gives you envelopes with analogue feel and digital control.”

The subcircuit in the analog boards which smoothes the control signals expects this signal to be sampled at 1kHz. Otherwise there’ll be more stepping/zipping. I don’t think this is something I want to take the responsibility for experimenting with, but the good news is that there’s not much code to change to divide the refresh rate by 2 and see how it sounds (adding a new menu/page and communicating what it does is the worst part). Happy hacking!

My guess is Render in this bit would need to be called every other time Control is run:

inline void Voice::Control() {
// Update the envelopes.
dead_ = 1;
for (uint8_t i = 0; i < kNumEnvelopes; ++i) {
envelope_[i].Render();
dead_ = dead_ && envelope_[i].dead();
}

It’s a bit beyond me to do this and the interface bit, compiling etc. though! I would be interested to hear what other users think of the envelope times.

Just had a quick look at the SMR4 analysis PDF, very helpful. Would increasing C11 to 68n change the smoothing to about 500Hz? I suppose this could be added on a switch.

The capacitor change is the right one to add more smoothing.

I’ve just measured the decay on the init patch, sustain to zero, decay 127 - I get about 5 or 6 seconds!

Just had more of a fiddle, sometimes I get about 6 seconds and when I set the envelope params to some positive value then reset the envelopes to 0 127 0 127 I get 8 seconds. Might be a bug? I’ve set the Vel->VCA default mod to zero.

I’ve just measured 127 0 0 0, it’s about 5.5s.