'clock.internal.start()' isn't calling script-defined 'clock.transport.start'

[dndrks]

summary

in beta230405, it looks like clock.internal.start(), which can either be called by a script or via PARAMS > clock > reset, isn't calling a script-defined clock.transport.start function. this is a break in expected behavior, as it performs as intended under the previous stable release.

checking out each of the PR's since the last release (221214), i narrowed the change to #1634, though there isn't anything obvious (to me) that would cause this issue -- but the callback is definitely called as expected using the codebase just before (#1654's merger is my touchstone).

test script

nb. switch norns to the internal clock for these tests

function clock.transport.start()
  print('the clock has started!')
end

results

before commit #1634 (running #1654):

>> clock.internal.start() -- executed via repl
<ok>
the clock has started!

also, via K3 hits on PARAMS > clock > reset:

the clock has started!
the clock has started!
...etc

running commit #1634 (and after):

>> clock.internal.start() -- executed via repl
<ok>

K3 on PARAMS > clock > reset doesn't fire the callback either.

[Dewb]

a potential place to start snooping around might be the introduction of librt -- that's one change in #1634 that suggests potential for side effects.

[tehn]

we confirmed that librt seems to be the culprit here. we're going to revert #1634 until further testing and fixes can be found, as we're holding up a long-awaited update