DSP Robotics Support

support - I think it's time, and a good idea - to start thinking about double precision (instead of 32bit) greens and streamy things (at least oscillators). The reason is simple. It affects precision, especially over time. And no - ruby is not the answer, because it's too slow for these things. Making short loops is also not the answer (not to mention, that perfect loops are not achievable at this precision at 0.01Hz resolution). //edit: actually it may also refer to some interias of wavetable based generation?

Last two stereo tracks in these snapshots should be synced across time (one part comes from sound synthesis, another - from amplitude modulation). Lovely shift isn't it? I will send my listeners to you, in case of complaints.

I can imagine a robot driven by current precision.

Could you explain this comparison, is based on what, so we can better understand?

It's simple. Single-cycle based wave file, at 0.01Hz resolution - should be perfectly loopable every 100 seconds. But it isn't.

One thing may be related to current precicion of floats - frequencies are converted from Hz into 0-1 range. Working in range from 0 to 10k+, I had to limit my resolution from 0.001 into 0.01Hz anyway. But when you use periods in seconds (taken from frequencies), then it limits your accuracy too. It also starts matter when more scaling operations are made on greens (rounding).

But second thing, more probable here - is related to wavetable-based nature of everything osc'ing, including sine oscs. On SM forum, cyto proved some time ago, that custom made (ASM) sine oscillator can be loopable corectly. But his version had some issues with phase resolution, and some other (plus - it's not wavetable). Using FS oscs - you are not able to have perfect loopsIt means, that if you wish to sync some streamy oscey things via ratio - you end up with surprises. I don't know, maybe it can be corrected somehow internally iin current accuracy.