Impromptu Clocked: coming changes and call for discussion

If I get the proposal right, on reset, you’ll get highs on reset and all clk outputs. the clk outputs staying high until “run” is triggered.

Exactly. I’m curious to know why it wouldn’t work with piano roll though. If internally in Clocked, assuming we make the change, I make double sure to set the clock outputs high a few samples before sending a reset (when reset is pressed Clocked), then I believe your module would see the clock go high and then immediately after, get a reset, so it should be in a good state, even with clock railed high. If you are using Rack’s Schmitt Trigger, then it will only trigger when it goes low and then back high again. But perhaps you have a different implementation or method I am not aware of.

The issue you mention (Scornovik) is definitely good to keep in mind, I’ll have to try it out. It’s probably not a big change in Clocked, but in order for it to have an impact, and unless there are major side effects, then the new method would have to be the default, and users could revert to the former behavior with an option as you suggest. I’ll wait a bit and see how things develops, but it probably is not much trouble to make the change, so your option thing is a good idea.

You raise another good point too, with a “hot” wire in our hands coming from Clocked when we make connections, it may be inconvenient. When we connect Clocked to a sequencer that has its run state turned on it would automatically step the sequencer. It would in fact always step a sequential switch, but since resets are so very common in patches, it might be a small price to pay in order to have the first step always play when we start things up.

P.S. that discussion you were having is what triggered my post :wink:

Yep, so if clock goes high, I’ll step forward and play the next note, then reset will position me back before the start of the sequence. Then I’ll receive a run trigger, but, all I do on that is start allowing clocks in. The clock is already high, so it won’t trigger the clock event and won’t play the first note.

The fix is easy enough, when I receive the run trigger, if the clock is high, regardless of whether it triggered, assume it triggered.

It’s a minor fix, and probably a good thing to do anyway, but the current version won’t work.

Actually, I could do that on pattern change too, which might alleviate some timing issues. Not completely, because I will still play the wrong note for a sample or two first, but at least it’ll stay in sync.

When I was making my last sequencer, I thought about doing it like the ER101: no run switch/input! Man that would make things easier. Just a clock and a reset; that would be neat, but it doesn’t look like it’s what’s expected in the Rack ecosystem judging by how things have evolved.

my very first version didn’t have a run input, but people want to be able to turn it off :stuck_out_tongue:

More specifically, they expect the noise to stop when they press stop on the clock.

tbf I was planning on adding one anyway, just wasn’t sure on exactly how it should work. apparently I missed a subtlety

Could you elaborate more on “clock-ignore-on-run-or-reset”? I think I remember from the original post on github issues that you were suggesting that a clock receiver (like a sequencer) should ignore any rising clock edges that might occur simultaneously with the reset going down? Is that still needed, or is the idea (now) that no proper device would even send a low to high right after coming out of reset? In this new world, would ignore clock no longer be necessary / desirable?

I would love to see some standardization here! It would be great to have a page of timing diagrams showing your proposal, but I think it’s possible to understand without that. I’ll ponder some more - just wanted to get in a quick reply.

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.

Marc, would this keeping high until run is hit on Clocked thing you guys are talking about help it not send a trigger to outputs set to divisions when the clock first starts? Like if I have division set for /64 so it can trigger something later, it always triggers it right when you hit run which is sometimes frustrating and requires a work around to skip the first pulse, such as just using an additional clock divider module. Thanks, and I hope one day all sequencers will have this nice run/reset behavior your clocks and sequencers have.

Tagging @synthi because reasons :wink:

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 :slight_smile:

2 Likes