hi, any tips for additive synth?

i've made a polyphonic patch,each voice is a bank of [osc~] up to 20 for each. When there are numerous voices playing this adds up quite quickly - 4 voices is already 80 [osc~] and pushing 80% cpu

This tends to wack the cpu on this machine (1ghz powerbook). Is there a more efficient way to do this? MAybe using FM/PM synthesis? Or is there a external out there....

As a reference point creating a bank of 20 sine osc in Supercollider shows ~4%cpu. I know SC is efficient, but surely pd can do better than 80% no?

thanks

edit - each partial does need independent level control for the desired result

If the spectrum you want is harmonic then there's lots of shortcuts that can get the efficiency down to a fraction of what you are seeing now with separate [osc~] objects.

Each [osc~] is actually a table lookup sinewave oscillator if you see the source code. Start by replacing many separate [osc~] objects with one [phasor~] and many [*~ n][cos~] leaves. Each will give you the nth harmonic and you can sum them all and divide by the total number to get a cheap additive signal. Of course they are all in perfect phase relative to t=0, which has advantages and disadvantages which are a bit too much to get into now.

A cool method is discrete summation. You use a formula that gives a closed form expression of two sines equivalent to adding many together.

And yes, FM is also a good friend for many classes of sound, but it's harder to work out how to get exact spectra evolution than with DSF.

(sorry to be absent from the discussion so much lately, will be frequenting the forum more in the new year, happy break to all!! andy)

sounds great. but way over my head!

examples in patches would be really helpful. Typically, when is [cos~] used? Other than in this example (which i can't fully get my head around)... I think i understand the maths

Study this simple shortcut first, by listening to the spectrum of each one and
then looking inside each box.

http://www.pdpatchrepo.info/hurleur/additive-cheats.pd

thank you You teach well sir. But why doesn't (i've tried) using an [osc~] and multiplyng~ it's output work? Is it because you haven't got the harmonics that you need to subtract from in the multiplied branches?

Okay, truth be told, I'm rather clueless as to what cos~ is actually doing.

But either way, is what we have here actually pseudo-subtractive synthesis? Are you being ironic with sound!?

cos~ is a cosine wavetable. If you feed a phasor into this it will read through the wavetable and output a cosine wave. This is useful for implementing FM or PM synthesis - take a gander at the help examples to get a better idea

I think the efficiency come from just using one generator (phasor) and reading from tables which are relatively cheap.

Obi - doesnt the timbre suffer if all the phases are equal (sounds a bit static)? I think in the expensive version they are all running at different phases which makes the result richer. Can wrap~ be used to offset the phases and still be cheaper than a bank of osc~ objects

> Obi - doesnt the timbre suffer if all the phases are equal (sounds a bit static)? I
> think in the expensive version they are all running at different phases which
> makes the result richer. Can wrap~ be used to offset the phases and still be
> cheaper than a bank of osc~ objects

Yes, but it depends on how the wave is used. "Suffer" might not be the best word. Some sounds thrive on phase synchrony.

Having free running (independent) oscillators or a common phase makes very little difference to a constant timbre, a drone/sustained note. The ear doesn't pick out any phase relationships, even if they change slowly within the sound.

But if you want a very percussive sound, like a struck string, to sound correct and reliably trigget on each hit, you need to sync the phases.

The method given above is equivalent to using [sinesum( messages with [tabosc~] or waveshaping - the component phases are governed entirely by the driving waveform. In a polyphonic instrument each voice would be identical and the total result would sound dry/sampled/2D. But with independent oscillators each voice would start with subtly different component phases, and the total result is much deeper/richer/fat.

To compromise efficiency and quality it's good to supplement very terse methods like the one shown with some chorus/flanger/phaser

About [wrap~], it is unneccesary in this case because [cos~] is a periodic function which already remaps the domain. In fact the domain offset _is_ the phase offset, but in out case they are all integers (multiples of 2 * pi if we didn't have Pd rotation normalised functions) so each is a harmonic that aligns with one beneath it. [wrap~] could be used to align phases from a line. In fact a [line~] plus a [wrap~] is a [phasor~]. But we wouldn't get different frequencies by taking the cosine of shifted copies, instead we need to multiply each new phase by a constant to change its slope. The slope multiplier, m in the equation y = mx+c, gives the rate of change and hence the frequency. Interestingly that means if the phases are synced perfectly there's always a transient at the start t=0 where every cosine must be simultaneously 1, so great for struck body sounds.

Are there any sinsum table with a lot of waveforms. I am looking not only for the basic waveforms but also for other kinds that exist.

just send different values to the table.

eg, sinesum 0.5 0.2 0.75 0.678 0.1 0.3

or something like that. have a look at the help file for arrays, it tells you how it works.

I found [cheby~] much more flexible than sinesum - I mean, if you want to change the harmonics dynamically using sinesum you need to work with lists and I still have problems with that. Read the helpfile, it is very explicit.
[cheby~] is part f Pd extended.