feat: add clock.link.get_number_of_peers()

[robbielyman]

this PR adds _norns.clock_link_get_number_of_peers() a new Lua function which will return the number of peers connected to this Norns over Ableton Link.

related discussion on Lines:

this PR does not make a user-facing change to display the number of peers anywhere on norns, but it enables that change to be made solely in Lua. i'd happily help brainstorm or contribute that Lua change as well, if there's interest.

[artfwo]

thanks for the contribution!

i recall there's no need to pass returned number of peers through protected link_shared_data struct, as numPeers()/abl_link_num_peers() is thread-safe, so the lua function could just call abl_link_num_peers() directly every time (saving the need to update the field in the scheduler callback, which gets called very frequently).

could you update the PR accordingly? thx!

[robbielyman]

yes, i’d be happy to make that change, but unfortunately i need more guidance: since the link pointer is only present in the clock thread, the ableton function can currently only feasibly be called from that thread. changing that would require placing the link pointer somewhere accessible from the main thread, which seems to me like a can of worms better left unopened.

in case this is useful information, given that the function is marked as realtime safe in the header by Ableton, it sounds like it’s not a problem to call very frequently.

[artfwo]

yes, i’d be happy to make that change, but unfortunately i need more guidance: since the link pointer is only present in the clock thread, the ableton function can currently only feasibly be called from that thread. changing that would require placing the link pointer somewhere accessible from the main thread, which seems to me like a can of worms better left unopened.

in case this is useful information, given that the function is marked as realtime safe in the header by Ableton, it sounds like it’s not a problem to call very frequently.

yeah, link object itself could be moved out of the thread, for instance declared as static in clock_link.c, and initialized in clock_link_init().

the wrapper in clock.c is also superfluous, clock_link.h is included in weaver, so the function can be called from there directly too. hope this helps! lmk if you have any more questions!

[robbielyman]

i made the change! it might now not be the case that the number of peers is zero when norns has Link disabled—i'm not likely to test what the behavior is for several days, but it would be a pretty easy check for anyone able to both build norns and connect to it via Link.

[artfwo]

the number of peers should be displayed only when clock source is set to link. i'd leave that logic to the scripts.

[robbielyman]

good point. well ok, i think this is ready for review :)

[artfwo]

good point. well ok, i think this is ready for review :)

number_of_peers field in the shared struct is unnecessary.

[robbielyman]

just got a chance to sync up with my norns; everything seems a-ok! here's a little test script to demonstrate:

function init()
  clock.run(function()
      while true do
        clock.sleep(1)
        redraw()
      end
  end)
end

function redraw()
  screen.font_size(15)
  screen.move(1,50)
  screen.clear()
  if params:get("clock_source") ~= 3 then
    screen.text("source != link")
  else
    screen.text("peers: " .. _norns.clock_link_get_number_of_peers())
  end
  screen.update()
end

to verify, make sure your norns is on the same network as another link-enabled device, set the clock_source param to "link" and join the link session with another device. the script's screen should say peers: 1 (or some other positive number matching your expectations).

[artfwo]

Generally the _norns API is sort of reserved for libraries. I'd suggest providing a wrapper in core/clock.lua.

clock.get_num_link_peers or similar.

[robbielyman]

i’m well aware of the distinction between the _norns interface and user-facing Lua changes like clock.lua. (i mean, i also know that you know that i’m aware.) as i mentioned in the PR description, making those changes is beyond the scope i set for myself.

now, i’m happy to increase the scope, since reading between the lines of your comment it sounds to me like you want me to. i think it would be helpful for me if you could communicate similar asks more directly in the future.

[artfwo]

now, i’m happy to increase the scope, since reading between the lines of your comment it sounds to me like you want me to. i think it would be helpful for me if you could communicate similar asks more directly in the future.

yeah, it's a tiny change that improves the usability of the feature, so why not :) thanks for adding it!