Basemath instance drift

[tomara-x]

When running 2 instances of uBasemath (same behavior must happen with Basemath) with one of them having steps of int lengths and the other with fractional steps

kl1[]      fillarray    1, 1, .2,.2,.2,.2,.2,.2,.2,.2,.2,.2
kl2[]      fillarray    1, 3

This first step trigger on both of them should happen at the same time since the lengths add up.
It does happen for a while, but the drift keeps increasing. (around 0.2 seconds after 4 minutes)
I'm thinking floating point inaccuracy from the time unit division:

#define TEMPO #128#
ktimeunit = 1/($TEMPO/60)

This is printed as "0.46875" but I'm not sure how csound handles it internally or how to control the variable bit size.
Imma try with time-unit=1 and see..

edit: nope, I was totally wrong about the floating point thing.

july, 27 2022 edit: okay maybe not totally wrong, kiddo

[tomara-x]

ooo even this is problematic:

kl1[]      fillarray    2, 2
kl2[]      fillarray    2, 1, 1

(still on tempo=128) regardless of tempo actually

this is bad as well:

kl1[]      fillarray    1, 2, 1
kl2[]      fillarray    2, 1, 1

while this, of course, is not:

kl1[]      fillarray    2, 2
kl2[]      fillarray    2, 2

[tomara-x]

lmao even at time-unit=1 and integer lengths there's still a drift

kl1[]      fillarray    2, 2
k1AS, kb1[] uBasemath 1, kl1
schedkwhen  kb1[0], 0, 0, "test", 0, .05, 440*(2^4)
kl2[]      fillarray    2, 1, 1
k2AS, kb2[] uBasemath 1, kl2
schedkwhen  kb2[0], 0, 0, "test", 0, .05, 440*(2^3)

[tomara-x]

^ this is weird! it stops drifting after a bit (those are 2 events happening very close to each other every 4 seconds)

rtevent:         T  4.001 TT  4.001 M:    -3.05    -3.05 
rtevent:         T  4.002 TT  4.002 M:    -7.96    -7.96                                
rtevent:         T  8.001 TT  8.001 M:    -1.97    -1.97
rtevent:         T 12.000 TT 12.000 M:    -3.05    -3.05                                
rtevent:         T 12.001 TT 12.001 M:    -7.96    -7.96                                
rtevent:         T 15.999 TT 15.999 M:    -1.97    -1.97                                
rtevent:         T 16.001 TT 16.001 M:    -7.96    -7.96                                
rtevent:         T 19.998 TT 19.998 M:    -2.38    -2.38                                
rtevent:         T 20.001 TT 20.001 M:    -7.96    -7.96                                
rtevent:         T 23.997 TT 23.997 M:    -2.26    -2.26                                
rtevent:         T 24.001 TT 24.001 M:    -7.96    -7.96                                
rtevent:         T 27.996 TT 27.996 M:    -2.02    -2.02                                
rtevent:         T 28.001 TT 28.001 M:    -7.96    -7.96                                
rtevent:         T 31.995 TT 31.995 M:    -2.84    -2.84                                
rtevent:         T 32.001 TT 32.001 M:    -7.96    -7.96                                
rtevent:         T 35.994 TT 35.994 M:    -1.95    -1.95                                
rtevent:         T 36.001 TT 36.001 M:    -7.96    -7.96                                
rtevent:         T 39.993 TT 39.993 M:    -2.52    -2.52                                
rtevent:         T 40.001 TT 40.001 M:    -7.96    -7.96                                

and they just keep going with this gap of 0.008 seconds

[tomara-x]

soooo I have no clue!

[tomara-x]

I hate to say it.. I very much hate to say it, but it must be the metro...

[tomara-x]

time for a manual dive

[tomara-x]

I don't wanna go the clock way! Give it a clock input that's as fast as you want the resolution to be and the lengths become counters (clock dividers). It would solve this since the two instances would run on the same clock. But we'd lose the fractional stuff and it's so cool and easy! You'd have to have a multiplied x15 clock on the outside and go:
15, 5,5,5, 15, 3,3,3,3,3 instead of the 1, 1/3, 1/3, 1/3, 1, 1/5, 1/5, 1/5, 1/5, 1/5

[tomara-x]

we lose the divisions too.. these are very sad times!

[tomara-x]

oh yeah! you can just *= an array! so have fun with the fractions and then multiply it until it's just ints! (◠‿☆)
[edit: scalearray would be great for this too]
yeah, the divisions though...

[tomara-x]

I'll leave those versions and implement clocked ones.. not sure, maybe just a clocked u version at first.

[tomara-x]

ooo I already have a clock divider!

[tomara-x]

would this be fixed if instead of the metro, we use a phasor and we rest phase each step? doesn't the metro already be at phase 0 when it outputs a click though?

I'm hungry!

[tomara-x]

I haven't been working on the clocked versions, been playing around with FM and the numeric score (and pondering the orb of course)

[tomara-x]

I wanna investigate why this happens in the first place. Like, I get where the problem is (when we switch the frequency of the metro) but I don't understand why this is a problem.
It's kinda interesting so I'll leave doing this here, but I probably won't change the Basemathes so I'll switch it to an investigation, and move to a new issue where I track the implementation of the BasemathC and uBasemathC tBasemath and utBasemath

[tomara-x]

tBasemath rules!

[tomara-x]

i'll have to move basma.orc to tbasma.orc cause will need an equal version?
still will have to do the flexible-active-step versions of all of them

[tomara-x]

a power-of-2 sampling rate and ksmps solves this

[tomara-x]

by the way since this turned out to be a metro thing, not a basmath thing, using more than one metro to run different tBasmath would still have possibility of drifting if under the same sr/kr conditions. the only way to keep them in sync would be to either do the sr thing or to run them usi g the same metro. (that's as far as i understand it now. maybe i'll figure out other ways to workaround this, maybe syncphasor? something)

[tomara-x]

not a perfect solution, there are still some frquencies which will go out of sync (it's so much better though)
also i wanted to test the hrtf opcodes which depend on sr being 44.1, 48, or 96kHz so...