external MIDI transport stop messages seem to kill all clocks (permanently)

[dndrks]

hiii! happy friday!!

i've been going through some MIDI clock + transport examples for the seamstress + grid study and ran into a few behaviors that felt potentially useful to raise. to try and keep stuff clean, i'll log separate tickets for each issue! lmk if i can help with any further info or testing!!

test script, running 0.24.5:

function clock.transport.start()
  print("started", clock.get_beats())
  test_clock = clock.run(
    function()
      while true do
        clock.sync(1/4)
        print('step', clock.get_beats())
      end
    end
  )
end

function clock.transport.stop()
  print("stopped")
  clock.cancel(test_clock)
  test_clock = nil -- clean up the variable
end

steps to repro:

• run the code snippet above
• change clock source from internal to MIDI via the parameters menu
• execute clock.cancel(test_clock) and test_clock = nil on the command line to stop the rogue clock
• start external MIDI clock (tested here with Live)
• after a few beats, stop the external MIDI clock
• restart the external MIDI clock

expected results: restarting the external MIDI clock will re-fire the clock.transport.start() callback and the quarter-beat prints will resume from 0

experienced results: restarting the external MIDI clock does re-fire the clock.transport.start() callback, which initiates a new clock_test clock (eg. _seamstress.clock.threads[test_clock] returns a thread), but the clock doesn't seem to be running -- there are no clock-executed prints. the only way to get my script's clock running again is to restart seamstress.

additional debugging just to see if this was just an issue with the transport-initiated clocks, i also executed clock.run(function() while true do clock.sleep(1) print('hello!!') end end) after canceling the rogue test_clock. it began printing hello!! to the REPL, and continued after I started the external MIDI clock -- stopping the external MIDI clock caused the hello!!'s to stop printing as well. subsequent executions trying to force the hello!! do not launch.