I was wondering if it may be possible to mod an Ambika to be more PPGish. Is it possible to somehow use 12bit waves, or increase the sample rate? I assume it is also possible to use SSM or SSM clone filters (there were Shruthi like this originally I believe), though I wonder how different the standard SRM4 filter would really sound to an SSM, though both are clearly more syrupy than the CEM filters on the Mircowave 1. I have the Microwave 1 and love it, and while I would really like a PPG, they are unafordable.
I’m not a huge fan of wavescanning, more the tone of the PPG, the glassy clarity of the digital waves mixed with sweet, transparently syrupy filters. Current Ambika demos don’t seem to really do that, that’s why I’m wondering if a mod could, though I’m not sure if it’s really possible to increase sample rate or bit depth of the waves, say, by using a more hi-fi processor that a tech could install on a mod.
@puggle what you’re asking would require a total firmware rewrite in addition to new hardware, i.e. very far from a drop-in MCU replacement, closer to developing a new synth. But prove me wrong!
The problem is that a more powerful processor comes in a different package and will definitely be surface mounted. Not very practical for a DIY poly - most people still fear SMD. Also the whole firmware has to be ported. That’s a shitload of work.
Ah. Gotcha. I kinda figured that if it were that easy, someone would’ve likely done it already.
> Is it possible to somehow use 12bit waves
You wouldn’t hear the difference.
> or increase the sample rate
The PPG wave uses variable sample rate, which gives very crunchy notes in the low registers, and no audible aliasing in the high register.
Ambika uses fixed sample rate - no “crunchiness” in the low register, and aliasing in the high register.
Emulating variable sample rate playback with a fixed sample rate system is possible, but CPU expensive.
> there were Shruthi like this originally I believe
There were such filter boards because I was a complete idiot. Let’s not get into that again… SSM this or that doesn’t mean anything - all that matters is the circuit built around it - parameters like filter input level (and thus overdrive), resonance level drop compensation…
Removing C22 from your SMR4 filter boards, and replacing R26 by a 18k or 22k resistor will give your filters more headroom, and remove the resonance level drop compensation.
> current Ambika demos
Maybe because the people who recorded this demo did not want their Ambika to sound like a PPG wave?
There are parameters you can act on - filter cutoff, oscillator level and drive in the mixer… that have an impact on the clarity of the sound.
The closest you’ll get to a PPG wave these days is the Modal 002/001. It uses variable sample rate just like the PPG.
Has anyone ever made a hardware synth that uses a fixed sample-rate for lower registers, and variable sample-rate for higher notes?
That would seem logical, if crunchy low-frequencies and aliasing at higher frequencies are both considered Bad Things.
> Has anyone ever made a hardware synth that uses a fixed sample-rate for lower registers, and variable sample-rate for higher notes?
You don’t need to use a variable sample rate to get aliasing-free higher notes. But the way of doing that is too CPU intensive for the Shruthi (maybe by not that much… maybe Bjarne would like to give it a try)!
“Crunchy” low-frequencies are kind of cool on the VS / PPG…
Do you know much about the way modal does it with the 002/001? they don’t use DSP but NCOs, which seem to be some sort of signal generator.
Any microcontroller can do it - just use a timer interrupt to write a sample directly to the DAC. Adjust the interrupt rate when the frequency needs to change. Interrupt frequency is the note frequency x the single cycle size. To get good resolution, you can drop every second sample (and repeat the process) at high frequency.
The downsides are that:
- You must use one timer per oscillator, and some MCUs don’t have that many high resolution timers.
- You must use one separate DAC per channel to avoid race conditions.
- Cross modulation (like ringmod) gets complicated - you need to recompute it and rewrite its DAC value every time either oscillator changes.
- Hardsync without aliasing is not possible.
I remember seeing the Modal boards pictures and there were Atmegas on them - probably two.
So yes, they are doing something different, but no it’s nothing high tech or fancy. NCO is just a fancy name to drive the point home.
That’ll be why there’s no FM/ring mod on it then.
Their Euro stuff is out this summer, so it will be easier to see the 002 oscillator components.
It’s weird they still use 8-bit Atmegas, with 32-bit MCU ICs now so cheap…
It’s called efficiency, only using what you need to do a job.
I remember car sharing with someone who had an old Ford Fiesta, it didn’t have an intermittent wiper mode even though that would have only added £5 to the cost of the car. But £5 times a million is a lot of money.
> But £5 times a million is a lot of money.
Or maybe, this “bare minimum” model existed only to make a pricier, middle range model look like a better choice… It’s not £5 times a million, it’s whatever they overcharged the better model for, times two million…
Well, it’s what someone said to me
But yes, the cost of adding some features can be quite minimal. I was given an Amstrad satellite receiver with a remote control that was busted, I bought another one used, but it didn’t have the remote control. They were similar models, I opened up both, swapped the front control PCBs over and hey presto, a working receiver with remote control.
@pichenettes Hi Olivier, I just noticed that you mentioned me in this thread. I don’t think I’ve got the stamina to accept the challenge, but could you clarify a little what kind of technique you’re thinking of for real time band limiting of wavetables?
> don’t need to use a variable sample rate to get aliasing-free higher notes. But the way of doing that is too CPU intensive for the Shruthi (maybe by not that much… maybe Bjarne would like to give it a try)!
There’s a topic about windowed sync here in the Forums. That might help.
How to do it :
- Store the integral (“cumsum”) of the wavetable in flash.
- Normal interpolated wavetable playback.
- Differentiate the result, and apply a scale factor.
It works well because when you integrate the waveform, it becomes much more sine-like.
- it’s likely that it’ll require 16-bit wavetable data - less preset waveforms in flash and more CPU used to read and interpolate the data. If you use 8-bit for the integrated waveform, it’s pretty much like using 4 bit or 5 bits for the original waveform.
- Additional cost of differentiation and scaling.
That’s an interesting link, @pichenettes. I had a bit of a skim through it. I must admit, I don’t understand the maths, but I did notice it talked about oversampling. Doesn’t this method make oversampling unnecessary, or at least reduce the need for it?
Do you use DPW techniques in any existing MI products (Braids, Sheep spring to mind)?
Oversampling is mentioned only as one of the existing approaches. It’s not needed.
DPW is not used in any MI product. There’s not enough flash in Braids (unless we use the integrated wavetable in a 8-bit format, and that’s too low-res), and Sheep is too close to the CPU limit to allow it.