05-21-2025, 02:22 AM
I’ve been doing some precise testing with CBPB clock FX and may have found a timing inconsistency that could be a bug.
Test Scenario:
• Pattern length: 4 steps
• Each step has CBPB 106 (clock divider /8)
• On step 4, I trigger a TRKx → SYNC to force track resync
• I start playback from a stopped state using Shift + Play, ensuring alignment with main clock zero-cross
• Expected total duration: 4 steps × (1 row /8) = 32 steps
Observation:
After about two full loops, I hear a clear stutter or “glitch” when the SYNC command is triggered. This implies that the pattern playback loop actually completes faster than 32 steps, despite the CBPB settings suggesting it should take exactly that long. The SYNC occurs before the expected main clock zero-cross at step 32, leading to an audible desynchronization.
Control Test:
When I perform the exact same test using a track clock divider of /8 (instead of CBPB FX), the loop plays back with perfect timing — every 4 steps take exactly 32 steps, and the SYNC aligns perfectly with the main clock zero-cross. There is no stutter or drift.
Conclusion:
This suggests that while CBPB FX are clocked based on the main clock (as documented), their implementation may allow the pattern to advance steps faster than expected, likely due to the playback engine continuing to step through rows regardless of trigger delay. That would mean CBPB affects event timing but not actual pattern step duration, resulting in loops playing faster than intended if you rely on CBPB to control overall timing.
Let me know if this is expected behavior, or if it might be worth reviewing how CBPB timing interacts with step progression and sync points.
Thanks as always for your incredible work — the system is genius!
Test Scenario:
• Pattern length: 4 steps
• Each step has CBPB 106 (clock divider /8)
• On step 4, I trigger a TRKx → SYNC to force track resync
• I start playback from a stopped state using Shift + Play, ensuring alignment with main clock zero-cross
• Expected total duration: 4 steps × (1 row /8) = 32 steps
Observation:
After about two full loops, I hear a clear stutter or “glitch” when the SYNC command is triggered. This implies that the pattern playback loop actually completes faster than 32 steps, despite the CBPB settings suggesting it should take exactly that long. The SYNC occurs before the expected main clock zero-cross at step 32, leading to an audible desynchronization.
Control Test:
When I perform the exact same test using a track clock divider of /8 (instead of CBPB FX), the loop plays back with perfect timing — every 4 steps take exactly 32 steps, and the SYNC aligns perfectly with the main clock zero-cross. There is no stutter or drift.
Conclusion:
This suggests that while CBPB FX are clocked based on the main clock (as documented), their implementation may allow the pattern to advance steps faster than expected, likely due to the playback engine continuing to step through rows regardless of trigger delay. That would mean CBPB affects event timing but not actual pattern step duration, resulting in loops playing faster than intended if you rely on CBPB to control overall timing.
Let me know if this is expected behavior, or if it might be worth reviewing how CBPB timing interacts with step progression and sync points.
Thanks as always for your incredible work — the system is genius!