robbielyman / seamstress

seamstress is an art engine
GNU General Public License v3.0
129 stars 12 forks source link

unexpected Link transport behavior #81

Closed dndrks closed 1 year ago

dndrks commented 1 year ago

hiiiii :) hope all's well!

while writing up the clock transport part of the seamstress grid study, i noticed that Link had some unexpected behavior w/r/t beat counts and transport messages. hopefully the video + repro case captures what I'm seeing, but please let me know if anything's opaque!!

test script

function init()
  params:set("clock_source", 3) -- 3: set to link, 2: set to MIDI, 1: set to internal
end

function clock.transport.start()
  print("starting clock!", clock.get_beats())
  run_me = clock.run(function()
    while true do
      clock.sync(1)
      print("beat", clock.get_beats())
    end
  end)
end

function clock.transport.stop()
  clock.cancel(run_me)
  print("stopping clock!", clock.get_beats())
end

expected behavior

when using MIDI transport + clock from Live with the above script, pressing 'play' in Live results in:

starting clock! 0.00010683615509892
beat    1.0000261767223
beat    2.0000396733478
beat    3.0000215286501
beat    4.0000149995859
...

pressing 'stop' in Live results in an immediate call to clock.transport.stop()

stopping clock! 17.743015894879

experienced behavior

vid here: https://vimeo.com/875665345/ebb57fd102

when using Link with 1 Bar global launch quantization and the test script, pressing 'play' in Live results in:

starting clock! -3.05312
beat    -2.99995
beat    -1.99998
beat    -0.999982
beat    2.2e-05
beat    1.000006
beat    2.000018
...

this seems the spot where Link quantum could come in handy -- to be able to specify, in seamstress, when to 'actually' start.

pressing 'stop' in Live results in a delayed call to clock.transport.stop(), fixed to 1 bar. changing the global launch quantization doesn't seem to affect this timing.


thank you thank you thank you!