clock get_beat_sec returning the wrong value when called via tempo_change_handler

[sonocircuit]

when clock.get_beat_sec() is called via clock.tempo_change_handler() the returned value is off by 1bpm. here is the script to reproduce the described behaviour.

[dndrks]

ah, good catch, thank you!
seems like clock.get_beat_sec() calls clock.get_tempo(), which is just a wrapper for a c-layer getter (_norns.clock_get_tempo()).

i recall (maybe erroneously) that passing the new tempo as an arg into clock.tempo_change_handler() was a concession to this data flow (with the workaround you found, of performing the calculation with the tempo provided), but maybe @artfwo has more accurate insight?

[artfwo]

basically, yeah. get_beat_sec() could depend on the tempo param value instead (param value always lags behind clock.get_tempo() a bit).

that would fix synchronicity, but does it break other get_beat_sec use-cases, i.e. lfo library?

[dndrks]

hmm -- super good call, ty @artfwo !!
as a general user, i would assume that the tempo param value is the single source of truth. so any library which relies on clock.get_beat_sec() would either be unaffected or would technically be fixed, no?

[artfwo]

i think that won't hurt, although i've never used this function and not 100% sure here.

BUT, i would generally try to avoid get_beat_sec in clock'ed code in the first place, as we cannot 100% rely on the duration of a beat being stable between 2 sync points.

that said, it's probably fine to change get_beat_sec to depend on param, as it's all lua layer, and consistency might improve things there a bit.