Clock Accuracy - 10ms?

[nix]

Nope, I don't think you need frames.
Maybe draw the LFO with Ruby, and use stream to read the resulting float array

[Nowhk]

I guess there was a bug in the "int" function causing "int" to round up. I just tested it with the current Beta version (= new DSP/ASM) and it's fixed there.

I don't understand (having this approx bug) how Wave Player build-in module has work till now.
Looks at the Precise Counter module inside it:

Immagine.png (66.96 KiB) Viewed 19942 times

if you play the sample at original pitch (step=1 from DSP code), the value of CountInt (which is the index of the sample that will be read by the following Interpolation module; to be precise, that value-1 since is zero-based) will never get odd values

Out of DSP Code (step=1):

First iteration: 1+0 (feedback prim), than 0.5 (-0.5), than Round... CountInt=0
Second iteration: 1+1 (feedback prim), than 1.5 (-0.5), than Round... CountInt=2 (BUG)
Third iteration: 1+2 (feedback prim), than 2.5 (-0.5), than Round... CountInt=2
Fourth iteration: 1+3 (feedback prim), than 3.5 (-0.5), than Round... CountInt=4 (BUG)

and so on...

The odd values will never be considered. But it seems that the sample play fine. How can play fine if odd index (reading the wave loaded in memory) will be ignored?

I'm curious about this...

[MyCo]

First iteration: 1+0 (feedback prim), than 0.5 (-0.5), than Round... CountInt=0
Second iteration: 1+1 (feedback prim), than 1.5 (-0.5), than Round... CountInt=2 (BUG)
Third iteration: 1+2 (feedback prim), than 2.5 (-0.5), than Round... CountInt=2
Fourth iteration: 1+3 (feedback prim), than 3.5 (-0.5), than Round... CountInt=4 (BUG)

Are those real debug values or just your estimates?
Round Primitive(0.5) should output 1
Round Primitive(2.5) should output 3

It's not black magic, the Double stream round primitive just uses frndint:
http://x86.renejeschke.de/html/file_mod ... d_110.html

Note to myself: We should change that to SSE2

[Nowhk]

First iteration: 1+0 (feedback prim), than 0.5 (-0.5), than Round... CountInt=0
Second iteration: 1+1 (feedback prim), than 1.5 (-0.5), than Round... CountInt=2 (BUG)
Third iteration: 1+2 (feedback prim), than 2.5 (-0.5), than Round... CountInt=2
Fourth iteration: 1+3 (feedback prim), than 3.5 (-0.5), than Round... CountInt=4 (BUG)

Are those real debug values or just your estimates?
Round Primitive(0.5) should output 1
Round Primitive(2.5) should output 3

It's not black magic, the Double stream round primitive just uses frndint:
http://x86.renejeschke.de/html/file_mod ... d_110.html

Note to myself: We should change that to SSE2

Real debug values (I guess ):

Bug Round Double.fsm

(6.76 KiB) Downloaded 930 times

Play a note: it outputs 0 (on Round Primitive(0.5) Poly readout) and 2 (on Round Primitive(2.5) Poly readout), not 1 and 3.

[TheOm]

This is known as "round to even".
This is done to reduce bias in numerical calculations.
It is not a bug.

[Nowhk]

This is known as "round to even".
This is done to reduce bias in numerical calculations.
It is not a bug.

Oh I see, thanks TheOm. So this is not a bug at all, even if MyCo supposed it here.

Then, I guess that in the new version that seems to be fixed you just change the way "tie-breakinground" is managed: from "half to even" to "half down", right?

Anyway, the problem above stay: the Wave Player never reads odd values, but it still play a sample perfectly.
How is this possible?

[TheOm]

No, MyCo is talking about the int() function. That is indeed a bug (or at least unexpected behaviour).
But the int function is strange anyway because it is not documented in the User Guide.
And in my version of FS(3.0.8.1) from what I can see it only affects the first SSE channel, so it was fundamentally broken anyway.

Anyway, the problem above stay: the Wave Player never reads odd values, but it still play a sample perfectly.
How is this possible?

I think you have some fundamental misunderstanding here. The rounding mode (like round to even) only affects the behaviour when the value is exactly in between two whole numbers.

[Nowhk]

No, MyCo is talking about the int() function. That is indeed a bug (or at least unexpected behaviour).
But the int function is strange anyway because it is not documented in the User Guide.
And in my version of FS(3.0.8.1) from what I can see it only affects the first SSE channel, so it was fundamentally broken anyway.

I think you have some fundamental misunderstanding here. The rounding mode (like round to even) only affects the behaviour when the value is exactly in between two whole numbers.

Yes, Tie-breaking: "Rounding a number y to the nearest integer requires some tie-breaking rule for those cases when y is exactly half-way between two integers — that is, when the fraction part of y is exactly 0.5."

I can have part of y when it's exactly 0.5 in the example: after it get feedback of itself (let say 2), 0.5 is subtracted; thus 1.5 after Round should be 1, not 2:

Immagine.png (11.36 KiB) Viewed 19925 times

I'm missing all odd values, since all input is an integer (playing sample at original pitch) less 0.5, in a range between 0 and wavefile size.

[tulamide]

*popcorn ready*

[TheOm]

But it works out perfectly, see:
CountInt = round(Input - 0.5)
Input is 2, that means CountInt = round(2 - 0.5) = 2
CountFrac is Input - CountInt, which is 2 - 2 = 0.
WavePlayer always reads (1.0-CountFrac) * sample[CountInt] + CountFrac * sample[CountInt+1]
(simple linear interpolation)
which in this example turns out to be:
(1.0 - 0.0) * sample[2] + 0.0 * sample[3] = sample[2]
which is exactly what it should be.

Now try with Input = 3 (odd number)
CountInt = round(3 - 0.5) = 2
CountFrac = 3 - 2 = 1
(1.0 - 1.0) * sample[2] + 1.0 * sample[3] = sample[3]
works exactly like it's supposed to.