Soft synth idea - am I crazy?

[Kirl]

Great to hear you're making good progress, keep it up! Looks like a really interesting book as well!

Bunch of cool links in this thread too! 

[Raizor]

On the subject of cool links, here's a list of all Synth Secrets articles from Sound on Sound. Not really related to coding but they cover loads of synth theory and explain how lots of components work. I've leaned a ton reading through them.

[hellfire]

On the subject of cool links, here's a list of all Synth Secrets articles from Sound on Sound. Not really related to coding but they cover loads of synth theory and explain how lots of components work.

Although the series doesn't address coders in the first place, it conveys a very good understanding of creating sounds that are musically useful.
This is absolutely essential and especially useful for coders who never touched an actual synth or even instrument before.
That's why I already linked it 3 years ago

Do you have an approach for anti-aliasing yet?

[Raizor]

Do you have an approach for anti-aliasing yet?

Not touched on that at all yet Hellfire. Any tips? I take it that it's not as simple as working at a higher sample-rate and downsampling during mixing?

[hellfire]

Not touched on that at all yet Hellfire. Any tips?
I take it that it's not as simple as working at a higher sample-rate and downsampling during mixing?

Proper anti-aliasing is essential for a synth, otherwise it will just sound like crap when playing higher notes.
There are several possible approaches, each has its pro and cons.

Probably the easiest way is a global oversampling factor with a lowpass filter.
Since the harmonics of your source-waveforms are falling off rather slowly (and you want to keep most of the audible spectrum), you'd need quite a large oversampling factor to cover the worst cases.
But other parts of your signal route might need no oversampling at all.

So another option is to oversample each generator as much as it requires.
If you're generating a sawtooth at 50hz, at 20khz it's fallen to 1/400 and you don't have to care much.
With the low-pass included into the oscilator you have an additional option to control its' timbre.
On the other hand you will usually put some kind of lowpass after the oscilator section anyway.

But all the oversampling is just trying to compensate errors which are already present.
So it makes perfectly sense to generate wave-forms which don't contain frequency beyond the audible range in the first place.
It's computationally a little bit heavy to run hundreds of sine oscilators to generate a saw, though.
So you'd need a bit of precalc, eg generate a wavetable for every note and interpolate for the frequencies in between.
This solves some problems but involves new ones, for example syncing oscilators or changing pitch quickly (frequency modulation).

Of course that can be solved, too. Since the band-limited and non-limited waveforms only differ significantly at level-jumps, you can just store the difference between the two wave-forms (commonly called minbleps) and mix that piece of sound into your non-bandlimited waveform.
Although this sounds nice and simple it's quite some trouble to fade the blep before the next phase-jump happens.

So after all there's no approach which works particularly well in all scenarios.

[Raizor]

Great info Hellfire, thanks very much. K++

Which of the methods would you most likely use, or would that depend on the specific scenario?

As I'm progressing, pre-calc for at least some things is seeming more and more likely. Especially after hearing the lovely sounds that come with using pre-calculated wave tables.  I'll do some info hunting and reading on the approaches you mentioned.

In regard to a low-pass filter inside the oscillator, is this the norm? Looking at V2 the other day, I could see no other obvious way of implementing the "color" slider for an oscillator, so this definitely seems like something to add.

Reading through example for wave table generation, they seem to FFT (or IFFT) a lot. Is this a good idea or would it add too much overhead (in terms of code size for the replayer). Just wondering if there's a cheaper alternative that sounds comparable.

[hellfire]

In regard to a low-pass filter inside the oscillator, is this the norm? Looking at V2 the other day, I could see no other obvious way of implementing the "color" slider for an oscillator, so this definitely seems like something to add.

I think in v2 the color attribute morphs between saw- and triangle-wave (and something comparable for the other wave-forms).
For sine waves you can morph to sin^2 or something like that.

Reading through example for wave table generation, they seem to FFT (or IFFT) a lot. Is this a good idea or would it add too much overhead.

If you use a naive radix-2 fft the code is very simple.
To precalc a wave-table for every note using additive synthesis, you can simply upsample the note from one octave above and just add the missing harmonic.

[Raizor]

Thanks Hellfire.

[Raizor]

Great to hear you're making good progress, keep it up! Looks like a really interesting book as well!

Bunch of cool links in this thread too! 

Book just arrived. Had a quick scan and it looks fantastic. Loads of great info in there.

I started rolling everything up into a managed C# VSTI last night. So far, so good

[Raizor]

I've got myself into a bit of a confused pickle in terms of voices and patch instances and could do with a little advice if possible.

At present I have a separate instance of each patch per voice. For example, if I have 10 voices and 2 patches, each of the 10 voices will have its own copy of each of the 2 patches. This seemed to make sense initially as a lot of the patch components need per-instance settings for internal time and setting values. The only logical way I could overcome this was to have a unique instance of each patch per voice. Otherwise, if I just use a reference to a single global patch within the voice, the voices screw up the patch settings as each voice is played (voice 1 increments patch time when played, then voice 2 starts to play the patch time and further increments the patch time etc).

When i edit a patch in the GUI, I update the associated patch instance for each of the voices to keep everything in sync.

As I'm coming to implement LFOs and other items that modulate other parameters for patch components, things are starting to get quite messy. I wondering if there's a more elegant solution? I considered the idea of having a patch and its variable parameters stored separately, with a unique instance of a set of patch parameters per voice and a single instance of the actual patch which the voice would provide its parameter set to when using the patch.

Hopefully this makes sense, sorry if it's a bit unclear.

Any suggestions would be great. Thank you.

EDIT: It's ok, I figured it out. I decided to have a separate param object that each patch component can contain instances of. Each param instance has an array of values (one value per voice) so I can track the state of each voice individually while still only needing one global instance of a patch object. So far, this is working well. As an aside, the Basic Synth book I mentioned before is excellent. It covers loads of stuff including the wavetable interpolation that Hellfire mentioned before. A great book for anyone attempting a synth

[Raizor]

Still making progress with this but it's a little slow due to having what seems like a never ending head cold :|

I'm still trying to get my LFOs working properly. In case anyone is reading this and is not sure what an LFO (low frequency oscillator) is, I'll try and briefly explain.

Imagine you have a stack of various controls to make up a synth patch (instrument). Let's take a wave oscillator as an example. The wave oscillator generates a constant tone (sine, saw wave etc) and when its output is played, results in a continuous tone (beeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee etc). The wave oscillator takes a note (midi note number corresponding to a particular pitch/frequency) or frequency as input and this controls pitch of the sound that comes out of the wave oscillator. It's common to have some sliders or knobs on the wave oscillator control to control things such as output volume or modify the frequency by a certain amount. This is all well and good and allows you to twiddle the knobs or slide the sliders to change the sound. However, to make things more interesting, we'd like these knobs to twiddle themselves by a certain amount over time and for this we need an LFO.

An LFO is similar to the wave oscillators we use to generate the wave sounds, except that it operates at a much lower frequency (typically below 10hz and rarely above 20hz). The lower the frequency, the slower the output values change over time. So an LFO with its frequency set low generates a slowly undulating wave. If we go back to our wave oscillator and imagine the volume knob has a float parameter to represent volume in the range 0 to 1, we can use the output from the LFO to modify the volume parameter and have the same effect as manually twiddling the volume knob. As the LFO output wave drops, the volume drops down and increases back up as the LFO wave rises again. This gives us a nice means of controlling parameters automatically. We can even use one LFO to modify the parameters of another for all sorts of crazy sounds.

Anyway, my implementation uses a buffer to store the output from the LFO. If an item parameter (such as wave oscillator volume) is linked to the LFO, it reads values from the LFO output buffer to modify the volume. This works nicely apart from the fact that the LFO output buffer can be shared by multiple parameters. When a voice plays, the values in the LFO buffer will not be the same for each voice, which sounds a bit crappy. For example, if I have an LFO and a wave oscillator that uses the LFO values to control frequency change, when voice 1 starts the values in the LFO are such that the pitch increases. Now if another voice starts playing shortly after, the LFO wave could be on a down slope resulting in this voice starting with its pitch decreasing. I'm trying to get round the issue without having to store more than one output buffer for the LFO if possible. If anyone has any advice or if I've approached this the wrong way, I'd appreciate some tips.

Apologies for typos, using my iPad, which is awful for typing (is it too much to ask for virtual cursor keys instead of a crazy magnifying glass?!?

Thanks

Raizor

EDIT: I think I'm going to give wavewables for LFO samples a go. Seems to make the most sense, and I need to get that sorted for other stuff (wavetables for sound generation etc).

[Jim]

You need to separate the data in the buffer from the playback.  Effectively each playback item needs its own pointer into the data.

Or, is the problem that the buffer data has changed due to time elapsing?

Jim

[Raizor]

@Jim

Thanks for the response. The buffer data isn't changing, it's the different time index per voice that was the problem.

I seem to have a solution though. I'm pre-generating a wave buffer at 1hz and then using the current sample index for the oscillator buffer to index into the pre-generated buffer. If I multiply the sample index from the oscillator buffer by the desired frequency and then modulus against the pre-generated buffer length, I get the correct sine (or whatever) value from the pre-generated buffer - almost for free It seems to work surprisingly well and with a little bit of interpolation, should solve a lot of my problems.

As an aside, what's the correct term when you use modulus? Above I said "modulus against" but I'm not sure of the correct terminology.

[hellfire]

A keypress event usually triggers a reset the lfo's phase (just as it resets the oscilators and volume envolpe).
There's usually an option to enable/disable such triggers.

[Raizor]

Thanks Hellfire, that's handy info.

[hellfire]

One nice thing about LFOs is that you don't have to evaluate them per sample.
You're probably mixing at some granularity, let's say 64 or 128 samples at each time.
So you can fetch your lfo output at the start and end of your block and interpolate them linearly.
The interpolation of all parameters is essential to avoid discontinuities.

[Raizor]

One nice thing about LFOs is that you don't have to evaluate them per sample.
You're probably mixing at some granularity, let's say 64 or 128 samples at each time.
So you can fetch your lfo output at the start and end of your block and interpolate them linearly.
The interpolation of all parameters is essential to avoid discontinuities.

Thanks Hellfire. I am sort of evaluating my LFOs per sample at present (using a wavetable). It seems to work quite well, but your approach might give me a performance boost. I hit a few snags with the wavetables, which I seem to have overcome now. Once I've got it broken down even further (separate tables per octave/semitone), I'll write some notes here as they may be useful to someone else in the future.

One thing that's been causing me problems is ring modulation. From what I understand, I should multiply the samples of two oscillators together to ring modulate them. Is that correct? I seemed to end up with just really weak and quiet output when trying that.

I've also been looking at other vst synths for some inspiration (especially for GUI design). Cakewalk Z3ta really blew my socks off. Some lovely features in there, especially the mini pattern editor allowing little patterns within the patch

[ferris]

Make sure to look at how Massive does its modulation routing GUI. It's s00per simple and intuitive

[hellfire]

One thing that's been causing me problems is ring modulation. From what I understand, I should multiply the samples of two oscillators together to ring modulate them. Is that correct? I seemed to end up with just really weak and quiet output when trying that.

The output of ring modulation contains sum and difference of the original frequencies (thus making your signal wider).
So your oscillators need proper tuning to produce harmonic output or you'll just hear noise (which can still be useful for percussions).
To make the sound more interesting you should try to apply the ring-modulation after (resonant) filtering (there's a sound example over here).

[Raizor]

Make sure to look at how Massive does its modulation routing GUI. It's s00per simple and intuitive

Will do Ferris, thanks.

One thing that's been causing me problems is ring modulation. From what I understand, I should multiply the samples of two oscillators together to ring modulate them. Is that correct? I seemed to end up with just really weak and quiet output when trying that.

The output of ring modulation contains sum and difference of the original frequencies (thus making your signal wider).
So your oscillators need proper tuning to produce harmonic output or you'll just hear noise (which can still be useful for percussions).
To make the sound more interesting you should try to apply the ring-modulation after (resonant) filtering (there's a sound example over here).

Sorry Hellfire, I'm still lost. What do you mean by "proper tuning" please?