Hi,
The new DSP module looks exciting.
However, just after trying the waveforms, I found them heavily aliased at higher frequencies. Do you offer them band limited or just raw ?
The other features of the DSP module sounds good to me.
best
Sinan
1 Like
The oscillator class really just takes a lambda as it’s generator so it will generate whatever function you supply it with. The demo just uses simple lambdas (std::sin, the sign of the input, …) for the different waveforms. You can give it a better generator function or pass it through different filters to transform the output.
Hello again,
Thanks for the response, it is more clear now your purpose.
However in your demo case, you basically demonstrate “not to do” waveform type in a digital synthesiser implementation for your new DSP library. A potentioal user who opens up your demo and hits the play button, while changing the frequency slider will hope to hear more advanced solutions (actually just standard now) for these basic waveform processing issues in the digital domain.
I totally accept your explanation, however is it a good choice to put in the demo of an advanced DSP toolkit a full aliasing waveform playback ?
While there are several methods to achieve band limited waveforms, I believe post filtering of the waveform is not the one.
best wishes
Sinan
I don’t think it makes any sense to add alias free waveforms to the library. There is no general solution for this problem. It really depends on the requirements you have:
- CPU usage
- Memory usage (tables?)
- Stability when modulating pitch
- Amount of anti aliasing
- Hard sync support
Once you offer an anti aliased waveform generator, people want the perfect one 
Maybe its better to leave it…
1 Like
a few of them would do
" if there were no people, it would be perfect democracy and very easy to govern a country "
Maybe a minBlep implementation with variable table size would be a good choice for most cases.
1 Like