Syncing multiple clocks

[dayunbao]

What's the best way to sync multiple Clocks? I have one that starts when I instantiate a class. It's sole purpose is to send out a MIDI Clock message on every quarter note. I'm using it to turn on an LED on the sequencer so the user has a visual representation of the BPM. It looks like this:

# In __init__()
self.midi_clock = Clock()
self.midi_clock.change(beats_per_minute=self._beats_per_minute)
self.midi_clock_event_id = self.midi_clock.cue(self.midi_clock_callback, quantization='1/4')

# Callback definition
def midi_clock_callback(self, _: ClockContext, delta=0.25, time_unit=TimeUnit.BEATS) -> None:
        self.midi_out_port.send(self.midi_clock_message)

        return delta, time_unit

# In a run() method called after __init__()
self.midi_clock.start()

I have another clock I'm using for recording MIDI Note On and Note Off messages created by pressing a button on the sequencer. One of the things I want that Clock to do is start a metronome that plays a click on every quarter note. I'm also attempting to quantize played notes to a 1/16th note, although I'm still working out the best way to do that. That clock looks like this:

# in __init__
self.recording_clock = Clock()
self.recording_clock.change(beats_per_minute=self._beats_per_minute)
self.recording_clock_event_id = None

# Called when the sequencer mode is changed to RECORD
def start_recording_sequence(self) -> None:
        self.recording_clock_event_id = self.recording_clock.cue(self.record_clock_callback, quantization='1/4')
        self.recording_clock.start()

# Callback definition
def record_clock_callback(self, context = ClockContext, delta=0.0625, time_unit=TimeUnit.BEATS) -> None:
        self.play_metronome()
        self.recording_measure = context.desired_moment.measure
        self.recording_measure_offset = context.desired_moment.measure_offset
        self.current_recording_seconds = context.desired_moment.seconds
        self.recording_offset = context.desired_moment.offset

# How I'm starting the metronome
def play_metronome(self) -> None:
        if self.click_track is None:
            self.click_track = self.click_pattern.play(context=self.server, quantization='1/4', clock=self.recording_clock)
        else:
            self.click_track.play()

# How I'm creating the metronome Pattern
def create_metronome(self) -> EventPattern:
        return EventPattern(
            frequency=self.click_sequence,
            synthdef=metronome,
            delta=0.25,
            duration=0.0625,
        )

I need both clocks to be synced. Is that what the arguments to Clock's start method are for? Should I set the initial_time, initial_offset, and initial_measure of the clock I'm starting when recording to the clock sending MIDI Clock messages? Right now they aren't synced. I'm guessing that the quantization argument to Clock.cue references an internal value? Not a global one all Clocks check?

[dayunbao]

I need both clocks to be synced. Is that what the arguments to Clock's start method are for? Should I set the initial_time, initial_offset, and initial_measure of the clock I'm starting when recording to the clock sending MIDI Clock messages?

That did the trick.

[josephine-wolf-oberholtzer]

I have to admit that I never tried to sync multiple clocks. I typically just use one and schedule everything on it (since I typically don't care about tempo just absolute time).

But the initial_* values to start() are intended for the synchronizing you're trying to do.

[dayunbao]

Awesome. Thanks. I might change things later, but because the Sequencer module has a few different states, like recording, playback, as well as performance (which is simply passing along Note On and Note Off messages to the DualOscillator), I didn't want to cram everything into one clock callback.

…

On Sun, Jan 26, 2025, 6:40 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: I have to admit that I never tried to sync multiple clocks. I typically just use one and schedule everything on it (since I typically don't care about tempo just absolute time). But the initial_* values to start() are intended for the synchronizing you're trying to do. — Reply to this email directly, view it on GitHub <#421 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVNNEUKJDBWH3PNAIQIJLL2MUMYHAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGAYTINA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[josephine-wolf-oberholtzer]

FWIW, you can have multiple clock callbacks. And they can also specify if the next call should be scheduled by seconds or beat. It's not really documented (sorry, everyone).

https://github.com/supriya-project/supriya/blob/mixers/supriya/clocks/bases.py#L268-L271

Basically, if your callback returns a float, it schedules it as the beat delta, but if it returns (offset, TimeUnit.SECONDS) you can schedule it as a seconds delta.

[dayunbao]

Oh, this would be very useful. I spent a lot of time today trying to figure out how to start the metronome and let it play for 4 beats/1 measure before starting the callback I use when recording a played sequence of notes. This is usually how it works in music. You get 1 measure to set the tempo in your head before beginning to play. I didn't figure out a good solution, tho. So I could schedule a callback that does nothing for 1 measure, and then starts another callback?

…

On Sun, Jan 26, 2025, 7:05 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: FWIW, you can have multiple clock callbacks. And they can also specify if the next call should be scheduled by seconds or beat. It's not really documented (sorry, everyone). https://github.com/supriya-project/supriya/blob/mixers/supriya/clocks/bases.py#L268-L271 Basically, if your callback returns a float, it schedules it as the beat delta, but if it returns (offset, TimeUnit.SECONDS) you can schedule it as a seconds delta. — Reply to this email directly, view it on GitHub <#421 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVNNES5EDIKDDHVPNSJ46D2MUPXHAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGAZTGNQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[josephine-wolf-oberholtzer]

Yeah, you could. Just be careful about not creating infinite loops between callbacks - I can't and won't check for that.

Callbacks also know when they've been called, when they hoped they would be called, and how many times they've been called.

The first arg your callback is called with is a ClockContext which encodes the current and desired Moments (which encode timing information), and the CallbackEvent which encodes information about what's being called, what it's being called with (*args, **kwargs) and the number of invocations of that callback (which increases each time your callback gets called).

[josephine-wolf-oberholtzer]

... which means hypothetically you could write a callback that checks if this is the first time it's been called and does one thing (and returns one kind of delta) and then does something else (and returns a different kind of delta) for each subsequent invocation.

[dayunbao]

So the type of the value returned by the initial callback can decide if a new callback is used? Not sure I'm totally following.

…

On Sun, Jan 26, 2025, 7:56 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: ... which means hypothetically you could write a callback that checks if this is the first time it's been called and does one thing (and returns one kind of delta) and then does something else (and returns a different kind of delta) for each subsequent invocation. — Reply to this email directly, view it on GitHub <#421 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVNNEUNDTXHG47GKEKL4FL2MUVULAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGA3TAOA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[dayunbao]

It sounds a bit like method overriding in OOP inheritance.

…

On Sun, Jan 26, 2025, 8:01 PM yun bao ***@***.***> wrote: So the type of the value returned by the initial callback can decide if a new callback is used? Not sure I'm totally following. On Sun, Jan 26, 2025, 7:56 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: > ... which means hypothetically you could write a callback that checks if > this is the first time it's been called and does one thing (and returns one > kind of delta) and then does something else (and returns a different kind > of delta) for each subsequent invocation. > > — > Reply to this email directly, view it on GitHub > <#421 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACVNNEUNDTXHG47GKEKL4FL2MUVULAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGA3TAOA> > . > You are receiving this because you authored the thread.Message ID: > ***@***.*** > com> >

[josephine-wolf-oberholtzer]

No, you're misunderstanding. I'm literally talking about putting an if/else block inside your callback that switches on the context.event.invocations field to decide what to do.

def my_clock_callback(context, *args, **kwargs):
    # first time this callback has been called
    if context.event.invocations == 0:
        do_something()
        return 1, TimeUnit.BEATS
    # every subsequent time this callback is called
    else:
        do_something_else()
        return 0.345, TimeUnit.SECONDS

[dayunbao]

Oh, I think I see. You're talking about using the same callback, but changing the wait time between invocations. So for the example I was talking about, I'd check if `invocations` equaled zero, if so return some value that caused a 1 measure delay before the callback was called again, then in subsequent invocations do whatever I needed to do. Right?

…

On Sun, Jan 26, 2025, 8:05 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: No, you're misunderstanding. I'm literally talking about putting an if/else block inside your callback that switches on the context.event.invocations field to decide what to do. def my_clock_callback(context, *args, **kwargs): if context.event.invocations == 0: do_something() return 1, TimeUnit.BEATS else: do_something_else() return 0.345, TimeUnit.SECONDS — Reply to this email directly, view it on GitHub <#421 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVNNEUP3DASAQ7T6WB5E2T2MUWWLAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGA3TMNQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[josephine-wolf-oberholtzer]

Correct.

[dayunbao]

Cool. Thanks!

…

On Sun, Jan 26, 2025, 8:17 PM Joséphine Wolf Oberholtzer < ***@***.***> wrote: Correct. — Reply to this email directly, view it on GitHub <#421 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVNNESDGNHRJRAUKEYOBGL2MUYDJAVCNFSM6AAAAABV4KBDC2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJWGA4DGMA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>