Impromptu Clocked: coming changes and call for discussion

Plugins & Modules
1

I’ve been thinking a bit about clock reset issues lately, and a post by @Soothsayer in this same category has prompted my current post. My post here pertains in particular to how clocks interact with sequencers and sequential switches, and I am starting to think a small change might be needed. I’ll first summarize the next change coming to Clocked in my upcoming update 0.6.13, for those that are not aware yet, and then I will propose my idea.

New in upcoming Impromptu 0.6.13: As a result of discussions with Jim and Steve, and my own findings as well, we have decided that Clocked’s outputs should hold their current levels when run is stopped. This acts in effect like a pause, and the clocks continue on their way from where they left off if we turn on run again. We have to keep clocks that are high in their high state when the clock stops, so that another pulse is not created when we start it up again. Such an approach is needed for when we are clocking different sequencers that use different clock ratios, such that everything stays in sync when we stop the patch and intend to start it up again from where we left off. In the current version 0.612, when we toggle run in Clocked, all internal counters get reset, which is not ideal. Further reading:

(issue is closed, but it can be read, and even revived if needed).

Proposal: In all versions of Clocked (0.6.12 and upcoming 0.6.13), when Clocked is reset, all clock outputs are reset to their low state, and they immediately rise when run is turned on. My thinking is that Clocked should actually set all its outputs high when we do a reset, even if it is not running. It would thus be ready in that state (called “armed”, lets say, just for purposes of discussion), such that when we turn on run, the clocks are already high and would not immediately trigger sequencers and sequential switches, thereby properly playing the first step.

There was a discussion here https://github.com/VCVRack/Rack/issues/938 about sequencers missing their first steps, and in Impromptu sequencers the problem was solved with a clock-ignore-on-run-or-reset method, but in some use cases, proper behavior in Impromptu sequencers requires that the run cable still needs to be connected from the clock to the sequencer’s run input, or alternatively, that the option ResetOnRun is selected in the right click menu. The new idea above would seem better and more general, and could potentially be applied to sequencers and sequential switches that don’t have a run input.

I’d love to hear from anyone who might see any downsides to this, perhaps I’m overlooking something. I’d also be curious to hear from those that have Eurorack clocks (Pam’s workout, etc), to see how it is done in the real world :slight_smile: @Omri_Cohen, @JimT

6 Likes
2

Literally just been having a discussion about this again: Sequential Switch Reset Question

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.

I imagine the behaviour for things like sequential switch will work. Assuming the clk output stays high for the pulse duration after run was triggered, I think it can be made to work for other sequencers. I dont’ think piano roll will work today, but it can be made to work. If we’ve got some unmaintained modules, they might not get updated. I’m thinking scorovnik, and if they don’t play the first note now, they won’t.

But, I can’t help feeling that all the clk outputs going high like that is just going to look very weird. And have strange effects when doing things like wiring up modules to a reset clock.

Is it difficult to implement? If not, maybe a test version or hide the feature in the menu so we can take a look and see the implications.

3

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:

4

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.

5

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.

6

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

7

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.

8

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.

9

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.

10

Tagging @synthi because reasons :wink:

1 Like
11

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.

12

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)”

13

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!

14

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
15

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

16

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!

17

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?

18

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.

19

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.

20

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