Which waveforms/features are you ready to say goodbye to?

30716 bytes of the 30720 available bytes of the ATMega328p are used, so there’s not much room for the addition of new features… Of course, I can give yet another chance at squeezing things here and there (everytime I start the game I end up finding something to squeeze, but at the end I believe there’s nothing more to gain), but larger cuts could be taken into the code size to pack more features (eg, a full sequencer, an even better MIDI implementation…). Things that could go away:

  • The “blit” oscillator waveform + a new algorithm for PWM (at the moment, PWM is derived from blit)
  • The “sweep” oscillator waveform
  • The wavetable/drone oscillator

I’m not necessarily talking about doing this on the main firmware. But if you want a customized firmware with a new feature, something will have to go away. Also, don’t hesitate to mention other features - though getting the right feel for what takes space and what doesn’t is not always easy for non-programmers…


Blit and sweep yeah and CZ perhaps?, if you can CCise all control Cauze i’ve got a lot of bug with nrpn/live (certainly due to myself…)…And if you give us all control by CC no more need of preset lol :smiley: … Is there a way to have a distortion fx easily for u without eating too much bytes?

I don’t know about which features could be lost but having a go at cutting code size is one of the things I’m planning on when I can get a kit running. I might not be able to do much (it’s looking quite tight already, from what I’ve seen of it) but another pair of eyes on the code can’t be a bad thing. I’ve written modular soft-synths before that had to run on quite limited platforms (not quite THIS limited, but I like a challenge!) so it might help.

One thing I have wondered - I don’t know much about the ATMega328p, but would it be possible/feasible in the Shruti-1 design to upgrade the chip, or add memory (either to the 30KB for the program or the 2K of RAM)? I know there are other options to explore first, and you definitely won’t want to change the setup of the kits you send out, I just thought it might be a fun project for someone in the future - double the power and then see what crazy stuff you can do with it :slight_smile:

CZ doesn’t use much, only 118 bytes. Also, I would never, ever let it go :smiley: In fact I can tell you there’ll be more CZ-like weirdness in my next synth :smiley:

The NRPN implementation is directly poking bytes in the data structure holding the patch data (you can think of the parameter number of an address, and the parameter value as the byte to write there) - that’s why it can create bugs when not used correctly (think of it as digital circuit bending). I’ll try to find a way of CC-izing everything without too much pain, for example by reusing the parameter range data from the editor, so everything is in 0-127 and is mapped to the right thing…

Regarding distortion, I think there’s already a lot to explore with the 1^2 setting. Something less destructive (like a soft fuzz) would take 280 bytes - just a lookup table mapping an 8-bit value to an 8-bit value ; holding the waveshapping curve.

If I had to choose I’d say blit then sweep…the wavetabe osc…Never! But I might change my mind after playing around with it.

features (non programmer so they may be impossible):

note latch function (maybe a long press like the test note)
envelope A D S and R as mod destinations
cycle option on one or both adsr envelopes (looping envelopes…yay!)


I don’t remember having been tight on RAM, so program memory is the biggest barrier here. AVR microcontrollers have a Harvard architecture - the code runs straight from flash, so you can’t “load” code from an external source - unless what you’re running is not code but bytecode (I’ve seen a project where they do that… load 1k blocks from a SD card and run it through a VM stored on the main 30k - out of question here).

Of course, you can redesign the board to house a bigger AVR, like the ATMega644p (64k of flash) or ATMega1284p (128k of flash), though they are more massive ; or put 2 AVR there - one for the oscillators/control signals, and one running the MIDI and user interface stuff. I am not a big fan of multi-chips designs, though, because it suddenly make firmware updating and hacking more tedious…

@11hz Robot. Excellent ideas! The implementation of the envelopes would need a couple of changes to allow modulation of the time (at the moment, slopes are computed at the beginning of a stage, they would have to be recomputed dynamically/tracked). Cycling option is super fun - I would do that in relationship with the LFOs (when a LFO resets to 0, retrigger the envelope to the attack stage).

i personally would prefer different oscillator modes over e.g. an on-board midi sequencer.
cycle mode for adsr is awesome of course.

One thing I like doing with cycling amp envelops is: with the sustain level at 0, set the attack and decay times kind of fast to create a percussive kind of shape then modulate the release time (noise is a good mod source for this) so that the hits repeat at unpredictable times (modulated release time makes the envelop cycle at different rates). Sometimes I’ll also modulate the decay time a little to get hits of slightly different durations. If the cycling is based on the lfo frequency then I’d want to add LFO frequency as a mod destination to the list of possible future features. Hell the more mod source and destinations the better. Does modulation options take up alot of…whatever it is that is limited…bytes of the ATMega328p I guess it is? (I got to learn more about this programming stuff, I think this project may make me want to do that)

I was checking out a demo video of the minicommand and the time it takes to load firmware on that thing is just a few seconds. Loading firmware is almost like loading a patch it is so fast. So I’m wondering how long does it take for shruti to receive the firmware via midi?

about one min to upload the firmware via midi.

I suspect it’s because my firmware always end up being 30720 bytes large :smiley:

I can’t wait to get into this (I’ll be done soldering by tomorrow); I second 11hz Robot’s point about LFO speed being a modulation destination.
By the way, currently, what is maximum speed of the LFO?

Also, the more mod destinations, the better. I agree.

I’m sure after I play with it for a few hours, I’ll be able to contribute some ideas.

The control signals are refreshed at 1kHz, and since the LFO waveforms are not band-limited, the fastest frequency is kept way below Nyquist, at 100 Hz. It won’t certainly give you FM or anything “precise”, but I can do a decent job in the “destruction” department:

Just letting you know that I wouldn’t miss the “drone” or “blit” waveforms if they were replaced by other waveforms or features.
Drone is nice, but it doesn’t have as much character as the other waves.

I like sweep a lot; actually, I like wavetables in general. It’s just that the drone one is perhaps too smooth for my taste and the filter smooths it out even more.