Moog Labyrinth Clock Architecture Limitation: SEQ2 Cannot Clock SEQ1

The Moog Forum Moog Semi-Modular Analog Synthesizers
1

Moog Labyrinth Clock Architecture Limitation: SEQ2 Cannot Clock SEQ1

Summary

The Moog Labyrinth’s dual sequencer system has an undocumented architectural limitation: while SEQ1 can be used to clock SEQ2 via the patch bay, the reverse is not possible using internal signals alone. Attempting to have SEQ2 trigger outputs clock SEQ1 results in a system deadlock where both sequencers freeze.

Expected Behavior

Based on the manual’s description of the patch bay (pages 43-44), patching SEQ2 TRIG to CLOCK 1 should allow SEQ2’s trigger outputs (generated when the play head hits an ON bit) to advance SEQ1 one step at a time. This would enable polymetric patterns where SEQ2 runs continuously while SEQ1 advances only on SEQ2’s active steps.

Actual Behavior

When SEQ2 TRIG is patched to CLOCK 1, both sequencers immediately freeze. This occurs regardless of what is patched to CLOCK 2.

Test Results

Test 1: SEQ1 clocking SEQ2 (works as expected)

  • Patch: SEQ1 TRIG → CLOCK 2

  • Result: SEQ1 runs on internal clock; SEQ2 advances only when SEQ1 hits an ON bit

  • Status: ✓ Works correctly

Test 2: SEQ2 clocking SEQ1 with internal CLOCK to CLOCK 2

  • Patch: CLOCK output → CLOCK 2, then SEQ2 TRIG → CLOCK 1

  • Expected: SEQ2 runs on internal clock; SEQ1 advances only when SEQ2 hits an ON bit

  • Result: Both sequencers freeze immediately when SEQ2 TRIG is patched to CLOCK 1

  • Status: ✗ Does not work

Test 3: SEQ2 clocking SEQ1 with external MIDI clock

  • Setup: External MIDI clock via Type A TRS adapter

  • Patch: MIDI clock active, then CLOCK output → CLOCK 2, then SEQ2 TRIG → CLOCK 1

  • Result: Same freeze behavior as Test 2

  • Status: ✗ Does not work

Test 4: Reverse of Test 1 to confirm pattern

  • Patch: CLOCK output → CLOCK 1, then SEQ1 TRIG → CLOCK 2

  • Result: Both sequencers freeze; pressing TRIGGER button advances only SEQ2

  • Status: ✗ Same deadlock pattern

Additional Observations

  1. When in the frozen state, pressing the TRIGGER button (which normally only fires envelope generators) causes one or both sequencers to advance one step. This suggests the trigger outputs are being generated but the clock system itself has stalled.

  2. The ADVANCE button does nothing while RUN/STOP is active (normal behavior), but works normally when stopped.

  3. Removing the patch cable from CLOCK 1 immediately restores normal operation.

  4. The freeze occurs even when patching while the sequencers are already running—the moment the cable is inserted into CLOCK 1, everything stops.

Technical Analysis

The manual states (page 43-44):

  • CLOCK 1: “This is the clock input for SEQ1. The internal CLOCK set by TEMPO (or MIDI CLOCK when present) is normalled to the input of this jack.”

  • CLOCK 2: “This is the clock input for SEQ2. The input to the CLOCK 1 jack is normalled to the input of this jack.”

The key phrase is that CLOCK 2 receives “the input to the CLOCK 1 jack”—meaning whatever signal is present at CLOCK 1, including patched signals. This creates the normalling chain: Internal Clock → CLOCK 1 → CLOCK 2.

The limitation appears to be that patching to CLOCK 1 doesn’t merely break the normalled connection—it appears to disable or stall the internal clock system entirely, including the CLOCK output. This creates a deadlock:

  1. SEQ2 TRIG only outputs pulses when SEQ2 advances to an ON bit

  2. SEQ2 cannot advance because it needs clock pulses

  3. The internal clock system has stalled because CLOCK 1 is patched

  4. Neither sequencer can move

Possible Workaround (Untested)

Based on the technical analysis, it may be possible to achieve SEQ2-clocks-SEQ1 behavior using a completely external clock source that does not originate from the Labyrinth:

  1. External clock source (separate sequencer, clock module, drum machine trigger out) → CLOCK 2

  2. SEQ2 TRIG → CLOCK 1

  3. Press RUN/STOP

In theory, this would keep SEQ2 running independently of the Labyrinth’s internal clock system while SEQ1 waits for SEQ2’s triggers. However, this has not been tested and may still result in the same deadlock behavior if the issue is related to patching CLOCK 1 itself rather than the clock source.

Conclusion

The Labyrinth’s clock architecture is designed with SEQ1 as the “leader” sequencer and SEQ2 as the “follower.” While this works well for many use cases, it prevents a common generative patching technique without external hardware. This limitation is not documented in the manual and was discovered through experimentation.

Recommendations for Moog

  1. Document this limitation in the manual or on the product support page

  2. Consider whether a firmware update could address this by keeping the internal clock running even when CLOCK 1 is patched

  3. Add this information to the “Exploring Labyrinth” section or patch bay documentation

Environment

  • Moog Labyrinth (firmware version not displayed/unknown)

  • Testing conducted December 2024

  • MIDI tested with Type A TRS adapter

This document may be freely shared for troubleshooting and community discussion purposes.

2

This is totally expected behavior, but only after analysis.

Clock 2 input is normalled from Clock 1 input so patching Clock 2 out to clock 1 in would be expected to freeze the sequences.

However, having done that, patching main Clock Out to Clock 2 in might be expected to get things working.

It won’t, because Clock Out follows Clock 1 In.

So Clock 1 in is a main clock in for the whole device.

Clock 2 in just runs Seq 2

Which I think is what we want.

Should you need Seq 1 to be advanced by Seq 2 then you need to use an external clock. This can be checked by using the Mod Oscillator as a clock.
In that case the main Clock out follows the pattern of Seq 2 triggers.

3

@andybutler I second your reply. Clock Output following Clock1 Input is to be expected and completely logical. One observes the same behaviour with the other semimodulars. And this feature is helpful for building clock chains over several instruments, which I do quite often, e.g. DFAM → Labyrinth → Subharmonicon. However, a notice on this behaviour in the manual could be helpful.