DSP Robotics Support

A question.

In FlowStone, the built-in oscillators - are wavetables with fixed shape content?

I ask, because if so, then there would be no quality difference between fixed osc's and the ones with wavetable loading option.

tester wrote:In FlowStone, the built-in oscillators - are wavetables with fixed shape content?

Yes!

tester wrote:I ask, because if so, then there would be no quality difference between fixed osc's and the ones with wavetable loading option.

There are differences, especially in the Saw. Theoretically they should sound the same, but there seems to be a bug in the saw table generation process. I've told that Malc already, but don't know when he'll go for it.

Okay, thanks!

My main interest is in sine quality as a reference, but I'm thinkig to add "shape selector" as an extension to my current project. So no reason to bother with duplicating modules (which in my case - makes a big difference); instead of - sine can be loaded by default, and added to the repository of shapes.

On the other hand it would be interesting there - to have also sawtooth/ramp and flip/flop (rectangle) in a pure flat form, for driving other modules. I'm curious if it's possible.

tester wrote:but I'm thinkig to add "shape selector" as an extension to my current project. So no reason to bother with duplicating modules

Sines are the only oscillator that don't really need the anti-aliasing properties of the wavetables - so the basic sine oscillator is a little more efficient that the saw/triangle or wavetable forms. But I have used the "all wavetable" method myself a few times when the small extra CPU load seems outweighed by keeping the waveform selection simple - if offering the ability to load custom wave shapes from files, for example, it can be a real PITA to also offer the stock oscillators as an alternative.

tester wrote:On the other hand it would be interesting there - to have also sawtooth/ramp and flip/flop (rectangle) in a pure flat form, for driving other modules. I'm curious if it's possible

You could easily have a 'no anti-aliasing' version of the oscillators, but you would then have to have two alternative forms that you switched between, as you can't turn off the anti-aliasing filtering of the wavetable primitives.
So for each array of raw 'shape data', you would have one oscillator that used the wavetable form, and a second one that read the data directly from an 'Float Array to mem' (a looped sample-player in effect)

I'm trying to avoid too many switches inside the app. From the past, I remember, that it caused signifficant glitches under higher (but not highest) load. Right now I'm addinng to this fellow some "live coordination" mode between units, so it's expanding anyway (I'm not sure yet how/if it will affect the realtime functionality). Still don't know how to make the "ping" work in vst mode in terms of rendering the output.