Sequencer Step Delay Problem

[varice]

Even though the manual states that the clocked sequencers will advance immediately to the next step when a clock signal occurs, there is a problem with the sequencer modules control level and logic signal outputs being delayed well after the clock signal arrives to advance to the next step. But, signals patched to the value and trigger/gate inputs pass through the sequencers immediately with each calculation cycle, so the delay problem is with the step advance, and not completely with the outputs.

When the sequencer module is operated at the blue control rate (24 kHz), the step advance is delayed by *at least* two control rate cycles. This can easily cause the problem of lost timing synch within a patch. Any trigger/gate signal generated from the original clock external of the sequencer module will occur before the sequencer advances to the next step. So, any modules (EGs, S&Hs, MIDI Note Send, etc.) that are triggered this way will not immediately have the next sequencer step value to work with, resulting in glitches, wrong notes, etc.

The attached patch exposes this problem. There are two oscillators, one is getting a pitch level from the selected sequencer, the other one is getting the same source except through a sample and hold module. In Variation 1, the S&H is being triggered by the clock. It is easy to tell that the two oscillators are not producing the same pitch. What is happening is that the sequencer is not advancing in time to present the next step value to the S&H. The S&H is grabbing the old sequencer value. Variation 2 has a Clocked Delay Register module switched on before the S&H to control the delay time before the S&H is triggered. As you can see, the sample delay value has to be set to a value of at least 5 before the S&H can finally grab the right value from the sequencer. The Delay Register is being clocked at 48 kHz, two times the 24 kHz control signal rate. So a sample delay setting of 5 should equal about 2.5 control rate cycles. A setting of 4 is too short, the S&H starts grabbing the old value (hence my assertion above that the sequencer step delay is at least two cycles).

All this means is that you need to be aware of the step delay. If possible, you can avoid any problems by using the sequencer trigger/gate outputs for all event timing (as they are step delayed by the same amount as the sequencer value output). But if you do any fancy trigger/gate patching external of the sequencers, you may need to add for example, a logic delay module to keep everything in synch. Even the minimum delay time of 0.10ms can be enough time for the sequencers to catch up.

The Control Sequencer does not appear to suffer this step delay problem. But all four of the clocked sequencers have this problem. The delay is relatively very long. It is so long that I suspect that it may be intentional and therefore not a bug, but only an “undocumented feature”. Also, something unique about these four sequencers is that they are designed to be chained serially. Maybe this step delay is necessary for this serial operation. But if that is true, then it sure would have been better to mention this step delay in the manual!

Many thanks to Tim Kleinert for mentioning that he found this sequencer delay problem:

http://electro-music.com/forum/post-376651.html&highlight=#376651

I have been frustrated and puzzled in the past about why some of my patches just would not work as expected. This explains why at least some of the patches with sequencers were troublesome.

This problem is evident in the G2 OS version 1.40 and the 1.40 Demo (as well as all previous versions that I have used).

---

seq step delay.pch2
Description:	A patch that demonstrates the clocked sequencer step delay problem.	Download (listen)
Filename:	seq step delay.pch2
Filesize:	3.83 KB
Downloaded:	4360 Time(s)

---

[jamos]

Thanks so much for quantifying this, guys. I have a song sequencer that I have used in various incarnations for a while (a set of sequencing modules in one slot switch the behavior of sequencers in other slots), but they have always been plagued by strange timing problems. This gives me some fresh ideas on how to fix things.