Clock Accuracy - 10ms?

[Nowhk]

I suspect they use doubles to prevent rounding errors

including double precision counter.

But does it really makes differences in your opinion? In the end, if I made a VST that run in a DAW, it will run at 32bit float precision (float). FL Studio runs at 32bit floating point and occasionally 80bit floating point (when really needed). Thus, i'll get rounding errors anyway when playing within the DAW.

One time, gol (the developer of FL Studio) said to me that even 20bit is "already 4 to 6 bits more than perfection."

because Flowstone lacks a "Delay by one sample" primitive for doubles. I will keep looking at it.

Uhm, I don't understand what do you mean with "Delay by one sample". For what I see here, the whole algorithm lacks some interpolation points. I'm not able to fix it, but I could have found a way to "emulate" floor using DSP code and keep the sampler working on with "general approch":

Code: Select all

foreach sample:
   base = index-index % 1; // floor emulation
   frac = index - base;
   out = in[base] * (1 - frac) + in[base + 1] * frac
   index = index + step;


It works with float values, and maybe it does an heavy operation more (% is more expencive than sub 0.5 and round, I think).

What's your opinioni on this approch? I keep trying to implement loop (i.e. index_pointer>=sample_length).

[Nowhk]

I've improved the schematic for a better visualization between "general" approch (I've called it mayae, since he is the guy who give to me the kicking code) and the one by Exo:

Linear Interpolation Emulation.fsm

(3.34 KiB) Downloaded 810 times

the results are very different between the two scenario. I don't know which is better, but seems that mayae one got "stable" values during the time. Pseudo code:

Code: Select all

foreach sample:
   base = index-index % 1; // floor emulation
   frac = index - base
   out = in[base] * (1 - frac) + in[(base + 1) % N] * frac
   index += speed
   if(index >=sample_length)
   {
      index = 0
   }


The only "problem" of this would be the "float" precision. But really: if you can't catch difference in audio between a CD (16bit) and a 32bit floating point, really could I get considerable "noise" using a float 32 bit instead of double 64?