SynthMaker

Wavetable Oscillators (more or less CPU?)

Archive · 2010 10 old posts

From the original SynthMaker forum (2004–2014), with its members’ names and dates.

NekroDisko ·

Hey! I´m just wondering, are the Wavetable-Oscillators more CPU-heavy than the stock ones? If so, why... If not, very good! I´ve read somewhere that they can be more CPU-intensive than the ordinary ones (and that you should use some form of green-Sample/hold solution for keeping the CPU down,when using text-arrays). Why? Or should I see this as a negliable difference?

exonerate ·

The wavetable osc will use more CPU. This is because the wavetable can be updated in realtime. So extra code will be used to take account of this.

Storing your waveforms in an array is faster, because the text has to be converted to a float array which in SM is very slow. This will not affect the CPU of the audio, only when selecting different waveforms. Everytime you switch to another waveform the text to float array convertion takes place. If it is already in an array no convertion happens so switching of waveforms will be faster.

If you are storing your waveforms as text on the harddrive then there is a "text to float array" module you can use in the dev toolkit which is much faster than directly connecting a text to a float array. (My convertion is much faster than SMs!)

Cheers 😉

Exo

NekroDisko ·

So, it is faster, but more CPU-demanding?... Fair enough... So I guess that in an LFO for example that uses many different waveforms you should (or could) use the ordinary oscillators for Sine,Triangle,Saw,Square and Noise waveforms and only use a wavetable-oscillator for any other custom waveforms... Am I right? Will this be a viable solution?

Why I relate to an LFO here is because I plan to extend my previously posted LFO and build a monster-LFO for you all to enjoy...

Thanx for the reply, and for clearing out this issue, which has riddled me for a long time... 🙂

Dave ·

exonerate wrote: The wavetable osc will use more CPU. This is because the wavetable can be updated in realtime. So extra code will be used to take account of this.

What do you mean with "can be updated in realtime"? Drawing into it?

exonerate ·

Dave wrote: exonerate wrote: The wavetable osc will use more CPU. This is because the wavetable can be updated in realtime. So extra code will be used to take account of this.

What do you mean with "can be updated in realtime"? Drawing into it?

Yes that's what I ment.

Dave ·

exonerate wrote: Yes that's what I ment.

So there's really a big difference (regarding cpu-power) when the draw-function is removed?

exonerate ·

Dave wrote: exonerate wrote: Yes that's what I ment.

So there's really a big difference (regarding cpu-power) when the draw-function is removed?

No the wavetable create will always use the same CPU I think. I was refering to the fact that it uses more CPU than the standard oscs.

The standard oscs also use wavetables, so the code (I'm refering to the code used to write the actual primtives here which we cannot see) should almost be the same. The standard oscs only ever read from the wavetable (which is the .dat files you see next to your plugin.) These wavetables cannot be changed.

In the wavetable create the wavetable is written to (ie when drawing or just when selecting a new waveform) and is also read from by the wavetable read. Basically a variable cannot be written to and read from at the same time, or you will get weird results. So the variable is "locked" when being written to so that it cannot be read while this is happening. This has overhead and will increase CPU usage a bit.

So I'm just refering to the internal code of that component.

Cheers 😉

Exo

MegaHurtz ·

For a lfo I think it`s best to do it in maths, where I`d personally rather do modulation with a function instead of a wavetable. becouse the wavetable generates more unwanted byproducts. (And synthmakers oscs are wavetables). The only problem is that the cos funtion is a bit heavy, only not too heavy to use in a modest patch. So.. I think the anser is you can use anything as long as you keep your designs on the simple side. The added effects are the worst cpu hoggers.

Dave ·

Sylenth1 uses wavetables too but uses really less cpu... try this with SM - the cpu will burn if using 25 oscs for example.

MegaHurtz ·

it`s not that bad really. There is no way that if you know wich waveforems to use, you cant progress beyond float arrays. four times fld and fstp uses approx 45 cycles, thats not even close to a promile on my slightly outdated machine. if you tend to use jz with it (wich you very wel can do) it uses about zip. it`s all about how much you can optimise the codes, wich they have to do in C++ aswell. Im ever growing away from the need to use green stuff on anything, its yust hiding cpu. and doing it intrusive and slowly. as they did in synthmaker too, you need to draw the line at about gui stuff.

Wrote something here? To have a post removed or your name hidden, write to [email protected].

Before your first post

A few rules keep this a friendly place. You agree to them once.

Shown next to what you post, here and in the app. It doesn’t have to be your real name: 3–24 lower-case letters, digits or _ (capitals become lower case, spaces become _).

    Then your post goes up straight away.

    Delete this reply?

    Open it in SynthMaker?

    It goes on the track you’re editing there, in place of that track’s sound, and into My sounds. Your other tracks stay as they are.

    Want to keep that track’s sound? Start a new song in SynthMaker first (Song › New song), then open this.

    Report this reply?

    Only the developer reads reports. The person isn’t told who reported them.

    What’s wrong with it?

    Block this person?

    You won’t see their posts and replies here any more. They aren’t told, and you can unblock them at any time.

    People you’ve blocked

    Their posts and replies are hidden from you. Unblock someone to see them again.

    The community rules

    A few rules keep this a friendly place. Everyone agrees to them once, before their first post.