clock source order causes unintended tempo inheritance

[dndrks]

current behavior:

• set norns to internal clock at 90bpm
• become inspired to switch to Link to sync a DAW or app
• since the option layout for CLOCK > source is internal,midi,link,crow, I'll often hit midi before link
• switching from internal to midi causes the tempo to jump up to 120bpm
• now, when i switch from midi to link, I carry over the 120bpm

if I'm fast + precise, I can sneak past midi to link without my tempo changing, but I'm often neither fast nor precise :)

i guess some super-low hanging fruit would be to just switch midi and link's positions in the menu, so that the shift from internal to link can carry over the current internal bpm? but i can't tell how much infrastructure might rely on indexes from params:get("clock_source")...

another spitball (unsure how feasible): could norns request the bpm from another Link peer when Link is first selected, rather than immediately push the likely-inaccurate inherited 120bpm?

[artfwo]

(changed the title as it's not a beta-specific problem)

midi clock basically has a fallback tempo of 120 bpm - something we require for the sync mechanism to work and every source technically keeps track of its own tempo.

but we also have a source tempo follower that updates clock_tempo param every second to keep the internal source tempo in sync with midi/crow (see #1097 and #1100 for reference).

one solution would be to remove it completely to let each source live with its own tempo and only allow updates to internal and link tempo when changing the param, wdyt?

[dndrks]

ah super good thoughts!! thank you artem <3

but we also have a source tempo follower that updates clock_tempo param every second to keep the internal source tempo in sync with midi/crow (see #1097 and #1100 for reference).

I can't recall, but this was to avoid a jarring tempo change when (for example) the artist switches from MIDI to internal, yeah?

---

nb. I apologize if any of the following is annoying / off-base, but figured it'd be helpful to share

one solution would be to remove it completely to let each source live with its own tempo and only allow updates to internal and link tempo when changing the param, wdyt?

I think the ideal situation might require approaching the source more flexibly than we might want to. for example, if I set source to MIDI, i can't change the tempo from norns -- the new tempo has to come from an external device.

this is a departure from what folks might expect working with DAWs or MIDI devices, which typically follows:

• I have an "internal" tempo of 96bpm
• I enable external syncing, but the tempo remains 96bpm until the DAW/device receives an external clock signal (let's say at 130bpm)
• once it does, the tempo shifts to 130bpm and you cannot change the tempo from the receiving DAW/device
• if you disable external syncing, the tempo returns to 96bpm
  • with Elektron boxes, they'd just switch back to 96bpm after not receiving a MIDI clock signal within a certain amount of time, regardless of the status of the "external sync" setting

in this way, external clock signals are handled as a temporary modification of these devices'/environments' internal clock, rather than an exclusive source (at least, until they're running). i guess they're more purely "sync" mechanisms than they are overwriting mechanisms.

again, this flexibility might not be feasible/desirable for norns, but I think it'd be rad if at least the tempo value remained consistent when switching between sources until norns receives a "clock event" from that source to prompt a change (eg. this guideline for Link).

does that read clearly? lmk if anything requires more detail / clarification!

[artfwo]

it does, although technically we don't have internal/external classification right now, all sources are more or less equally "external".

now, each source keeps a periodically updated reference - internal/crow/midi update it at regular intervals defined by the incoming signal, and link kinda continuously follows the time and the session. the reference is used all the time to calculate current beat by comparing it with the "wall clock time". to do that, the reference also remembers the tempo from when it was last updated (regardless of when that happened).

what you're proposing would either require some interaction between the sources (which i'd rather avoid as it introduces a lot of unnecessary complexity), or keeping a fallback tempo within each source that can be adjusted simultaneously for each source with the clock_tempo param.

internal and link sources obviously won't need fallback tempo, as they never "lose" the signal by nature, so setting fallback tempo could be implemented in them as a stub. midi and crow can update the reference with the fallback tempo when the signal is lost.

as to the second part (switching back to 96 after midi or crow device stops sending data), it would be easy to implement with the above precondition.

the problem might be in displaying the "external" tempo in the params menu. my blind guess is that we'll either have to implement a special param type and formatter for tempo to show both "fallback" and "external" tempos depending on the source, or just show the tempo returned from the clock elsewhere. from the usability perspective, reading and setting the tempo at same place would be a better option i think.

I can't recall, but this was to avoid a jarring tempo change when (for example) the artist switches from MIDI to internal, yeah?

i can't recall either, probably, yes. although i think in some cases this might be an undesirable behavior too.