December 21, 2014
I am trying the WTOscillators in DXSynth. Increasing the table size to say, 4096, I realised that the plugin loads a lot slower than if I run it at 512. I reckon this is because the synth calculates the tables at start time.
Using the quasi band limited oscillators, the plugin starts immediately.
I want to use WTOscillators as it sounds better to me, is there any way to use big table sizes and load quickly? Is it possible/faster to pre-compute the results and put it in a file? Is this common practice among wavetable synths to do so?
January 29, 2017
First, the DXSynth only uses a single sinusoidal table as all its oscillators are sinusoids. So, a simple fix would be to alter the oscillator object to become sinusoidal-only. And you really only need one sinusoidal table.
However, if you are wanting to use non-sinusoidal waveforms in PM/FM synthesis, beware - the solution to the FFT of the PM/FM equations for non-sinusoids is unknown, and is not simply a linear combination of Bessel functions for each non-sinusoidal harmonic. Aliasing will become a big problem.
In the CWtOscillator object, the wavetables are all generated when the plugin loads and there are 9-octaves of each wave + the sinusoid.
You could certainly pre-calculate the tables and store them in a file, just like the BLEP tables in synthfunctions.h. It would be up to you to decide on how dense the tables are - in the book, I use one table per octave, but you could also use one table per minor third. Since the book's tables are based off of the note A, you can hear the difference as the tables are switched around this boundary. One downside to precomputing the tables is that they will be compiled into your final plug-in and could make the overall size much larger. In the synth projects, about 4MB of the overall size is just the BLEP tables.
But, if you read the part of the chapter that deals with the possibility of aliasing when the read index moves too quickly in non-sinusoidal tables, then simply making the tables larger isn't the overall answer. See the top of p.215 in section 5.20. In commercial synths, the tables usually get shorter as the octave gets higher, which is noted in that section as well. In one popular synth from 1986, I know that the table sizes varied from 512 samples on the low end to just 32 at the top of the musical range.
The sample-based synths do the same thing: we take the time-hit up front to parse the samples into buffers from WAV files, rather than trying to perform block-reads while rendering, which is the way you would do it in iOS with AudioFileServices. Like the wavetables, this allows us instant access to the data. Table-izing the long audio samples from those synths would bloat out the size of the plugin potentially into the gigabyte range.
In hardware synths, the wavetables are stored in ROM or RAM and are accessed instantly. In older designs, one IC would fetch the samples from the tables, and another would perform the interpolation operation.
I like to have a similar instant access to the tables/buffers.
December 21, 2014
Yup, I was trying out the Saw and Square wavetables in PM, the behaviour of the BLEP saw/square oscillators vs the wtoscillators are really different when used for PM. The BLEP oscillators sound more pleasing when PM-ed.
I think I will go with a combo of the WTOscillator for sine and the BLEP for the rest, for the best of both worlds.
Thanks for the heads up on the table size, it's something I hadn't considered.
Most Users Ever Online: 36
Currently Browsing this Page:
Guest Posters: 1
Newest Members:Matt, dspstudent, strings4v, TheSmile, semihyavuzz, alfredLue, danioc, midnightskate3, Alia5, Shamal Sundar
Moderators: W Pirkle: 209
Administrators: Tom: 67, JD Young: 80, Will Pirkle: 0, W Pirkle: 209