Ambika with a better CPU?

Just my two cents as someone who has spent too many hours over the past two months working on the Ambika codebase: it is very difficult to maintain. I mean this with no disrespect to Emilie, who has done incredible things with such constrained hardware architecture, and without her work none of us would be here.

I have been working on getting the firmware to compile with recent versions of G++, to refactor and fix up parts of the code to remove many compiler warnings and even just to make the code more readable to those who aren’t intimately familiar with the whole structure of the firmware. Even though I was trying to be very careful, I introduced several bugs which took literal days of full on debugging to pinpoint, given that there is no effective way to debug this system in a debugger.

As I have posted in another thread, I think I have reached o a point of having no obvious bugs or glitches in the patches, and I know the codebase quite well now. But there is still quite a bit of work to be done before I would say the code would be easy to maintain and extend.

If you are still interested in working on the code after hearing this, then I’m of course happy to talk more if you have any questions. It would actually be nice if we could unify some of the more popular forks of Ambika and also make it easier to make future customisations. I have also been considering whether it would be viable to port the Ambika synth code to an STMF4 chip / discovery board, and reimplementing the filters digitally, just for fun… but that might be later in the year.

Just a side note, I was actually able to reduce the size of the controller firmware by a reasonable amount, just by my refactoring, possibly in combination with adding some extra compile options.

Frankly, I’m surprised why nobody has designed an STM32 motherboard and voicecard. Porting Braids or Plaits’ code to it might be simpler than fighting with all the limitations of the AVR platform.

I can post the Eagle file for this (2 voices per card :D), but I worry this might turn into too many horrible questions piling in my inbox.


Yes, I’m a little disappointed by this and it was my long-term dream and ambition for Ambika. I tried to read up on the interfacing protocols etc, but in the end I realized that it was more than I could realistically handle as a hobby in my free time. It would have been a different story if I’d had the required electronics skill.

On the other hand I am really fond of the Ambika character, including reasonable amounts of aliasing. For certain sounds it’s the perfect ingridient.

Edit: I would like to see the eagle files for that prototype card though :slight_smile: .


@aaronlevin Hi, I think Emilie answered your questions. Cheers

Yes, I was thinking that an STM32 chip could handle a two-voice voicecard. I’d also like to see the Eagle file!

While I do have electronics ability (recent EE grad, designed some boards before) it’s still a huge undertaking to go back to hardware design with this. I’m not likely to have that amount of time to dedicate to it, but it depends on how the year plays out.

@pichenettes I appreciate your detailed response. Thank you. What you wrote makes sense.

@Bjarne thank you also for following up. I may send a PR merging the recent (unimportant) changes just as an exercise to get the project compiling.

Why do you tease us so! An STM32 Ambika with Plaits as its primary oscillators! I secretly hope you’ll design something one day, a small desktop synth with all the MI goodies inside (plaits, ripples, clouds, rings.) Your modules are laid out well; it wouldn’t even need a screen. :slight_smile: There are so many polyphonic analog synths out there I think people are starting to crave something new. They are giving stuff like the hydrasynth, korg wave, and the microfreak a chance and loving it. (On the micro freak, it could have been better and more interesting)

I’d “settle” for a polyphonic MPE desktop version of Elements at this point, lol :slight_smile:

I’d love to look at the eagle file as well please! Again, it’s all a question of time availability though… I’ve been thinking about a shruthi using plaits code as well for a while…

An ambika with added fx card (clouds/warps code :slight_smile: ) could be amazing fun…

Maybe a small group of people could be formed for stm32 ambika???


I’ve been silently wishing this would happen, but at this point it looks like there just isn’t enough community to ever see it.

On the other hand I did have a thought the other day that might be an easier way to expand Ambika to God level without having to start from scratch, and without having to build new hardware and also something with much less frustrating coding and bug testing environment.
That would be to using something really cheap and powerful, but small enough to fit into an existing ambika case, say a Pi Zero, and offload as much as possibly on to that and connect them via port 7. We already have power rails etc, and with the CPU underclocked they use less power than an OLED.

Something with wifi/blueooth/usb host/lvds display would be even better provided it can fit.

Ofcourse it would be much better just to have it drive the Ambika voice cards directly, but I think that job is beyond my coding skills and would require building new hardware, by that time you may aswell make a new synth.

I haven’t noticed random crashes but then I haven’t been using my ambika very much as I’ve been working on another project. I would be happy to help you debug this though. Are you able to describe times when it has crashed, and what the crash looks like? I’m assuming it’s the controller crashing. Could it also be an undervoltage condition?

Maybe I can try to revisit this firmware and upload a ‘stable’ version, i.e. roll back the breaking changes I’ve made.

As for the STM32 thing, I was thinking about this a while ago and I think that the area in which the Ambika is most constrained is voicecard processing power. And specifically in terms of waveform generation. You can’t offload this to another processor because it would take even more processing to transfer the samples from one chip to another. So the voicecard CPUs are what needs upgrading.

But rather than keep the Ambika architecture, which Emilie has said is really not ideal, I thought maybe having a kind of STM32 Shruti version could be a possibility. In order to achieve polyphony, I don’t think it’s necessary to have the full 6 part flexibility of Ambika but maybe 2 parts (i.e. bitimbral), each with 3-4 voices. This could be achieved by just making each “STM32ti” a monotimbral but polyphonic synth, and allowing chaining of synths. Then you just load the same patchsets onto each synth and you have ‘parts’. If you transmit MIDI CCs down the chain line, you could even edit the same patch on all synths in the chain with just one of them.

But I should add, this is all hypothetical, I’m not really planning on doing anything STM related anytime soon.

Yeah the crashing seems totally random I cant reproduce it. It does seem to be in conjunction with editing parameters or accessing the library though. I’ll have another go and see.
It’s very possible that it is changes to the code that I have made that are causing it, or at least my mods over the top of your refactoring. Its possible I’ve missed something. For one thing, I’m not using any of your voice card changes as I found it hard to roll back to a stable place. So just slightly tweaked YAM voice cards really, with the refactored controller.

With regard to the STM32, it has come up in discussion a couple of times, I actually think some of Ambikas vibe comes from the low res DACs. While it is annoying hearing the stepping in the envelopes, I don’t find the aliasing the be that much of a problem as I rarely play notes that high.

Today we’re faced with a counter intuitive problem that we all have access to things that are too good. Floating point math oscillators and perfect filters are common place, and most people are going to great lengths to make plugins that reduce quality and bit depth and add other imperfections to get vibe back. Novation Peak is pretty much what Ambika would be like if it had 24bit DACs etc, but it often gets a bad wrap for sounding too sterile. The more perfect you make these things, the more like a plugin they sound. Sure the filter plays a big part, but Ambika is poly, and poly sounds usually have little resonance if any at all. The sounds I go for usually have resonance in the single digit range, and cutoff fairly open. In this scenarios the filters aren’t doing much, and all the voice cards sounds alike.
But nothing else in my kit sounds like Ambika, its just got a cool flavour that IMO should stay. If I want high fidelity wavetables, I already have Serum for that.

On the other hand, an Ambika with better DAW integration, selectable CC maps (e.g control via a sthruthi XT) more sub waves (Sine), more LFO types (filtered noise), and direct marriage to novation Launchkey, and some of the things I’d like to implement now we have some space. On top of that, Bluetooth LE midi / Wifi and a USB Host would be awesome via Port 7 add-on.

If it turns out there is enough love within this community to get something better in the works, I’m in! But if we’re starting over, why stop at STM32 when you could go full blown FFPGA then the skies the limit. We can only dream.

Hmmmm, it could be something to do with if you added fields to structs and some pointers aren’t working as they should be. Invalid pointer operations are definitely something that would cause that kind of crash.

Or, it could be the fact that you are using old voicecard firmware. I’m not 100% sure that the changes I made to the controller code are backwards compatible with the old voicecard firmware…

I agree that having too much freedom can inhibit creativity, and that’s why I wanted to build the Ambika - to get away from my laptop. Having said that, the beauty of having more processing power is being able to choose what you improve and what you don’t worry about. Of the different kinds of noise in a digital synth, I think aliasing is the one that needs the most care. No old school analogue synths have aliasing. So when people think of the ‘warm retro analogue sound’ missing from high quality digital synths, it’s certainly wasn’t caused by reducing the waveform aliasing. In fact if you listen to samples of antialiased waveforms from research into digital synthesis, they sound absolutely incredible. E.g. (10 years old). Listen to those softsync samples!

The extra processing power is also very useful to allow higher quality modulations, and allow effects like reverb or delay. A very low hanging fruit is being able to have a higher sample rate, which also reduces aliasing somewhat. It would be very easy to keep the 8-bit quantisation noise by rendering waveforms at 32 bits and then discretising them to 8 bits before sending to the DAC: sample_8bit = (sample_32bit & 0xff000000) >> 24.

Of course, the controller improvements you describe are cool too. To me they they fall more in the domain of expanding the codebase and enhancing the interface, which needs more development (programmer) power over CPU power. Perhaps more memory is needed, I will concede.

FPGAs are very powerful but developing for FPGAs is a pain in the ass for hobbyist developers. No open source toolchains, everything is very proprietary, etc. I would leave FPGA development for full time engineers, like at Novation.

Ok I’ll have another look over it and triple check and push to gh.

And yes I agree more processing power is always a good thing, even if it isn’t used. There’s just something going on with Ambika, a certain grit thats adding to the harmonic content, and a certain lofi instability that just makes it sound more vibey and cool than all my soft synth collection. My knowledge doesnt extend far enough to know from where it comes… some from the filter, maybe more from aliasing or jittery clock? In any case it has a voice of its own and I love it :slight_smile:

1 Like

Honestly I think it’s mainly just the analogue filters. I think that’s the main thing that Ambika has going for it. Maybe the 8-bitness helps too.

Edit - I guess you’re right about the aliasing sounding unique, in the sense that if you want that authentic 8 bit video game kind of sound, you’d probably only get that by leaving aliasing in there. But that’s the easiest thing to do on a digital synth.

Just to be clear - I’m not trying to disagree with you on any of these points, I’m mainly trying to say that it’s definitely possible to both have higher performance hardware and maintain a lo-fi sound (in whichever way you want) on a digital synth.

Yes I agree for the most part. I have a random combo of SMRII and 4P cards in my Ambika, and I like how it ands diversity to the sounds, but I do notice with the filters open and resonance very low or off, I cant tell any difference between them, which just makes me wonder what else is happening that makes it sound so different to a soft synth with an 8bit crusher on it or something. But I guess the opamps are doing more than just filtering.

One obvious leap in logic in all this, and something I’m surprised we haven’t seen yet, is a hybrid plugin/analog filter setup. You could almost do it with a Shruthi’s input and Midi, but sync needs to be tighter like USB. Like the synth equivalent of the Bettermaker EQs. Maybe a USB parent board running 6 x Ripples? Somewhere in a parallel universe, Ambikas have 6 TRS inserts and OSC/VCA happens in the DAW. If only I had a portal gun…

Help, help, are we on gearslutz?

8-bit consoles rarely have 8-bit (as in, 8-bit DACs, 8-bit sample depth) sound. What people call the “8-bit sound” is very often the sound of hardware square, pulse and noise generators running in the MHz range (and thus without much aliasing).

I doubt the op-amps do anything here… Maybe some slight roll-off of the highs due to particularly large caps in their feedback loops for stability. You’d have to use the shittiest op-amps (741s) to hear a stronger effect (slew-limiting).

Ambika will never sound like a VA going through a bit-depth reducer.

There are many approximations in the internal computations - it’s not just the output sample that has a limited resolution, it’s all the internal steps to compute it. Each oscillator, the mixing code - everything is low-resolution, and resolution is lost at each step.

Also the 12-bit DAC used for the raw oscillators signal is not a part designed for audio output. It’s not perfectly linear. On the Shruthi, there was a specific tone due to the use of PWM for the oscillators signal.

And finally, some of the control signals for the filter are generated by PWM - even with some low-pass filtering this causes a slight modulation and instability of the filter cutoff or the resonance, which, in some circumstances, can be heard in the audible range.

1 Like

8-bit consoles rarely have 8-bit (as in, 8-bit DACs, 8-bit sample depth) sound. What people call the “8-bit sound” is very often the sound of hardware square, pulse and noise generators running in the MHz range (and thus without much aliasing).

I’m imagining things like the NES which I’m pretty sure had between 4 and 7 bits for sound output depending on the waveform - according to here In this video of the Legend of Zelda theme, you can even see the 16 steps on the triangle wave! And I’m fairly sure that you can hear the aliasing on the square wave used for the bass part there, but I could be wrong.

There are many approximations in the internal computations - it’s not just the output sample that has a limited resolution, it’s all the internal steps to compute it. Each oscillator, the mixing code - everything is low-resolution, and resolution is lost at each step.

Okay yes, I take your point here. I suppose if you really wanted to, you could emulate this on a higher bit machine. And keep the good old MCP4822 to faithfully reproduce the exact same nonlinearity :wink:

The sample playback feature is implemented by post-processing a 1-bit stream - there is no proper DAC!

This is not samples going through a DAC, but a dedicated logic circuit which can only generate that waveform. There might be the equivalent of a 4-bit R2R DAC inside.

The square wave is generated by a timer that divides a main clock in the MHz range.

Obviously, an emulator which is not carefully coded can alias badly!

I’ve been thinking hard about an stm32 ambika and am planning on building a test setup soon. I’ve been looking at the ambika architecture and code. Is anyone else interested? The hardware is pretty straight forward. The hard/time-consuming part, by a very very long way, is the firmware. Is anyone else interested in a small group (keeping it really really small) to talk about ideas etc.
I’d strongly suggest only people who have a decent stm32 programming base!
All the hard work is in interfacing multiple stm32s, screens, dacs, etc. (The hardware isnt particularly tricky to do as far as I can tell so fw experience is the most important thing)
This may not go anywhere as it’ll be a lot of work so this is just a very early idea sharing and a bit of a play.
I have test/prototype setup planned and am going to get some prototype boards made in the next few weeks. But it may be good to exchange ideas now before getting the pcbs.
My initial plan for a proof of concept is to get one stm32 talking to a voice card, passing note, envelope, filter, resonance data (not the full ambika voice data!) and get a voice card emitting a waveform plus cv via dacs, just to see how hard it will be and what is needed (getting the voicecard running first).
I’ve got loads of ideas for what I’d like eventually with effects etc but it’s all a bit pie in the sky!
Happy to post some pcbs out to people who are keen to build when I get them… (ideally uk/europe as postage cost isnt huge!) Should be a pretty easy build if you’re happy soldering stm32s and fine pitch ics.


Wow thats exciting news! I’m up for a tinker. Just to be clear though, are you talking about using STM32 for the voice card, controller or both? My understanding if where this discussion inevitably ends up is that to overcome Ambikas major shortcomings in sound quality, we need to do away with the atm328p and MCP4822 and scale up all the code. I think this is usually where someone says this is too much work, better to start from scratch and it goes in the too hard basket?

1 Like