Tagging @synthi because reasons 
1 Like
In this case I’m assuming the external clock divider is either a piece of hardware, or a module that does not implement all of your reset recommendations? Because I think that the idea for your reset spec is to make this unnecessary (yes?).
The only thing that doesn’t feel quite right is the somewhat arbitrary 1ms. I understand where it comes from, but it certainly sets an upper limit on what a practical clock speed is.
Us old timers are used to high res clocks like 96ppq up to 384 ppq. Specifically because people wanted sequencers to have an imperceptible clocking error.
That said, using high res clocks may not be a general enough use case to care about.
I remember a discussion on FB about ppqn going that route.
That being said, I know that there’s a few developers who’ve strayed from trigger standards, with @synthi having mentioned in the NYSTHI manual writing group that: “generally my PULSE OUT are 0.0001 seconds (or 4 samples long at 44100 Hz)”
Hi Adi, just to make sure I follow your question, the part
keeping high until run is hit on Clocked
actually has two aspects to it, one that I have already done for the next update (and may solve your problem), and another aspect as well that I want to explore.
The first aspect concerns an already running Clocked and everything is running properly in your patch. When you turn Run off, and then back on again, Clocked 0.6.12 would internally reset itself, such that a /64 output would restart to the beginning when run gets turned on again. This is no longer the case in 0.6.13 (released soon), since now when we turn off Run, all clock outputs keep their voltages stable at whatever they were, and simply continue along when run is restarted. Thus you will not get that unwanted pulses when run comes back on again, and your timings should be preserved.
The second aspect concerns the reset. Say we we have a patch in which a Clocked is not running, and we have the clock and reset inputs of a sequential switch connected the clock and reset outputs of Clocked. Clocked is not running, we press reset to initialize everything (the sequential switch moves to step 1), wait a bit, and then turn on run. The clocks were low in their default reset levels, and as soon as we turn on Run, the clocks go high for their first pulse, the switch sees this and moves to step 2 instantly, thereby skipping the first step. This would be corrected if we decide to put all clock outputs high in Clocked after it gets reset, such that no pulse is seen when started.
I hope that helps make it clear, feel free to followup. If you want to test the new Clocked for your /64 issue, please let me know your platform, and I’ll try to get you a build within 24 hrs. Cheers!
I talked a bit with Antonio regarding this issue, and in Janneker (if I remember correctly), he did change it to comply with the 1ms standard, as Janneker was not triggering some modules (some control inputs in my sequencers and VCV Pulse Matrix’s clock input for example). I believe the trigger standard is there so that as developers, when we optimize our modules to not sample control signals at audio rate, we know the minimum at which we must sample them to make sure we catch them. If some devs make modules following the 1ms standard, and others emit 0.1ms pulses, then some pulses will not always be detected.
Agree with Squinky though, 1ms in my clock-ignore was just an ad-hoc value, and it can certainly be much smaller. If ever a standard was agreed upon for this, I would definitely follow it, and it would make sense that high resolution clocks be supported.
2 Likes
Maybe set the standard for ‘clock and reset were pretty much the same time’ based on LFO/BPM standard? Could be inverse of the LFO/BPM CV CV standard.
9V PPQN = 1 / 1024hz ( 0.9765625 ms), 10V 1 / 2048 hz (0.48828125 ms)
1ms is about one ‘beat’ at 60,000 BPM (LFO CV = 8.966V)
One beat at 122880 BPM (LFO CV = 10.0V) is 0.48828125 ms
Marc, that all makes perfect sense! I think a correction of this second aspect you mentioned would fix an issue with divisions firing on the first step, since a divided output wouldn’t trigger at run since the gate is already up from the reset. I would then be worried that the x1 or x4 outputs wouldn’t fire on run for the same reason though. But this whole thing might be a bit over my head, and I might not be fully understanding the implications of what your suggesting, and my thought is sort of a side issue anyway. That said, I would be honored to test the new Clocked version! I’m on windows 10, and thanks Marc!
To be honest, the reason I haven’t discussed this at all is because every time I see it brought up, the thread instantly fills with 300 pages of people talking and I honestly don’t have the time to even begind reading it. (And it’s happened at least in four places, same result). Can someone reply to me and give me a one-paragraph explanation on what the issue is, so I can fix it?
I certainly wouldn’t expect a clock that is not running to be emitting a high signal.
I don’t see a problem here. There are always other gates and switches if a module doesn’t have a separate run mode and you want to interrupt the clock with one.
I think it’s about the difference between pausing the clock being a “full pause” as in the world stopping as-is, and pausing the clock simply stopping the output of beats from the clock.
take sequential switch 8>1 from ml, or seq3 from fundamental.
aim: press run on a clock and get the patch playing in sync.
trigger the reset inputs. expectation, everything is primed, ready to play.
press run, clock starts.
first clock pulse. expectation, play first note. but seq3 and seq switch move to their second positions and play those notes, with associated gates and outputs.
some sequencers, eg piano roll and scorovnik, reset to before the first note and the first clock has them play the note in the first position.
for shorter thread and sample patches see: Sequential Switch Reset Question
2 Likes
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