To be honest, it’s hard to think of scenarios where this behavior can cripple a patch. I mean when the outputs of Clocked will go high when reset is triggered.
I just tested a few other clocks and they all work the same, but the bidoo one has actually this behavior. When the reset is triggered, its outputs are going high, which means that upon reset, the sequencer\switch will move one step forward and not to the start of the sequence. This can be a bit of a hassle actually, moving everything back again. Maybe a short delay between the reset and turning the clock high could help. First, the clock will go high, and after a very short time, the reset will trigger the sequencer. I don’t know…
That’s a really interesting issue…
1 Like
@Vortico The issue is nontrivial and multifaceted, therefore it’s not easy to explain all of it succintly, but I will try to explain one of those facets in a minimal working example. Although my example may appear contrived, it represents a broader class of use cases that somtimes happen in other setups. In the picture below, we want to be able to press reset in order to restart our song. If we press reset while the LFO is high, then the first step will play correctly, but if we press when it’s low, then the first step will not play. If we decrease PW, then the first step will miss more often when reset is pressed. The problem occurs because SEQ3 is processing the rising clock edge it sees when the LFO output goes to high (after it received the reset), but because the reset was directly routed to SEQ3, the reset got there first (unfortunately). Thus the LFO’s rise is seen as a new proper clock edge and the first step only lasted one or two Rack samples (and the step is effectively skipped). Hence my 1ms-clock-ignore-on-reset proposal in the infamous issue 938. The rabbit hole goes deeper if we start talking about run switches and the different clock modules we have in Rack 
2 Likes
Great summary Jim, that also serves to illustrate the problem with different implementations. Reseting to the last step in order to not miss the first step is indeed one way to do it.
This highlights the actual need for us to get together with Andrew and make a standard for how sequencers, sequential switches and clocks should behave regarding run and reset behavior, in order to not miss any first steps. I personally am not a big fan of the approach that consists in reseting to the last step, since in a multi-pattern sequencer, that would mean also resetting to the last pattern, which is a bit awkward. But in the end, I think I would prefer a standard that I don’t like to no standard at all, because for the users it would clear things up immensely and we would have an agreed upon and predictable way of doing things.
2 Likes
Okay, that makes sense. How have Eurorack modules solved this problem?
2 Likes
It will take a bit of research for me to answer that one since I don’t have any Eurorack gear, and reading through a bunch of module manuals will be tedious, but as a starting point in my research, Steve Baker suggested a very interesting video, and it seems like sync issues do also occur in Eurorack, and must be dealt with there as well. What’s super interesting in this video, is that in the last part (last 3 minutes or so), we are able to see that the Euclidean Circles module implements precisely my idea of ignoring a clock that happens too soon after a reset. The window seems shorter than the 1ms I use, but like I mentioned before, my choice of 1ms (44 samples at 44.1kHz) was arbitrary, and it can be shorter.
Thanks Steve, and when time permits, I’d have a few tests for you to run on your Pamela if you feel like it!
If anyone else has any Eurorack clock modules, and would like to help out, please let me know.
3 Likes
Would it work to just ignore the clock signal while the reset gate is still over some value? Or is there a magic number of samples that have to pass to avoid troubles?
The reset gating idea is interesting, I will think more about this. If every module that produces resets follows Racks standard for minimal trigger duration, then we know it will last at least 1ms, and it would perhaps alleviate modules from having to count this themselves. The AS module I used in my 3-module example above uses 1ms tirggers (irrespective of how long you keep your finger on the button), but for other switches that would keep reset high as long as the button is pressed, we’d have to see how that affects things.
As for the number of samples for the clock-igore method (I really need a new name for that one!), which I use in all my sequencers, I would say the absolute minimum would be something like 10 samples, but it’s hard to have a precise number, since it depends on how people chain their resets and the delays incurred in those modules.
FWIW I’ve started implementing the NORD MODULAR mode in my “resettable” modules.
that is reset can be IMMEDIATE or ARMED
if ARMED the RESET will happen to the next CLOCK in
this is already in the 5 steps module (using contextual menu)
will be in BIG NUMBER, and all coming “timeable” modules
I changed all the modules to emit 1 msec pulses
9 Likes
Declared a standard at https://github.com/VCVRack/Rack/issues/938#issuecomment-455836149. I decided that 1ms is the obvious choice, since nobody needs clocks faster than 1000 Hz (and if they do, they should expect undefined results for other reasons too), and 44.1kHz/1000Hz = 44 samples is more than enough to support reasonably long chains of cables (which each induce 1 sample delay).
7 Likes