Initially when I started the discussion, I was focused on resets, and I did implement a clock-ignore during 1ms after any reset occurs. But I have since extended that to the run state also as follows: when the sequencer receives a trigger on the run input and run gets turned on, I also ignore clocks during the next 1ms here too, since I assume that the clock was also just started, and if I was to process that fresh new clock edge that is likely coming in as a result of the clock just restarting, then the sequencer would instantly skip the step it was on, which is not what we want.
After thinking about this more, if my proposal for railing clock outputs high on reset was to be implemented in Clocked, there would be no need to implement clock-ignore in any form, provided we connect Clocked’s reset and clock signals directly to sequencers/seqswitches. But in generel, this can not be assumed, and we might actually still need the clock-ignore-after-reset strategy for the following case: say someone uses Clocked as their master clock/reset, and they connect Clocked’s reset everywhere in the patch to reset things. Then they take a clock output from Clocked, send it through an external clock divider or other module, before routing it to the clock input of a sequencer. When they hit reset on Clocked, Clocked would rail all the clocks high, and then a few samples later emit the reset. The extra delay incurred by the clock divider might still make a clock edge arrive at the module after the reset arrives, since reset was directly routed. Anytime the clock arrives after the reset, if there is no clock-ignore, then a step is effectively missed in the sequencer or sequential switch.
Everyone is free to design as they wish, but I really think that any module that has both clock and reset inputs, like sequencers and sequential switches, should ignore any clock edge occurring within 1ms (arbitrary number I chose) after a reset occurs. For the 1ms choice, I was assuming that no clock above 1kHz would be sent to my sequencers. It could be 0.1ms, who knows, but it should be long enough for all spurious clock events (those that are direct consequences of the reset) to propagate throughout the patch before the first real clock event occurs.
These issues are really messy to think of, and it can potentially be a small barrier to entry for people just starting out, when they see their patches missing the first step.