Right, I should have written “keeps the tempo in sync”. The other half of sync of course is the starting point. For that you need a reset pulse, which clocks have and many LFO’s and sequencers have.
Yeah, that’s a rare occurrence though. The modules could go out of sync or stay in sync, that would be implementation specific. Modular doesn’t have the equivalent of MIDI-Sync so the only solution I think would be another reset signal on tempo-change. Alternatively modules that want to get this right could take both the clock and bpm-cv, and use the bpm-cv for their tempo and the clock to sync their phase on bpm-cv change. It might still be difficult to avoid the occasional jankines though.
We have something just as powerful: Phase. But not all modules support it. Using phase as a clock allows for both abrupt and gradual tempo changes at any point in time without the risk of loosing sync because you know exactly where you are timewise, even between beats.
There’s quite some support already like ZZC’s stuff, Surge XT’s LFO, most of Count Modula’s sequencers, Bogaudio’s ADDR, ~PDArray and of course Shapemaster to name a few (Edit: NYSTHI BZ-Mapper and DHE Scannibal need to be in this list) to name a few, but even more support would be nice to solve our sync problems.
If 0V would be the start of a beat and 10V the end, then using a sawtooth wave (0V-10V) as a clock signal, we could progress phase linearly (phase = time if you like).
So when the wave reaches say 7.50V, each connected module knows exactly and instantly that we are at three-quarters in between beats, if that makes sense.
The upshot is that the precise timing information is centralized. Individual modules don’t have to calculate, interpolate or determine at what point exactly to switch or fade BPM because that information is reflected instantly by the voltage level of the phase clock.
A better explanation with nice pictures can be found at: ZZC | Clock
Right, or to be more precise - “as a clock-phase signal”. It’s smart thinking, I really like it. The Impromptu guys (ping @marc_boule) are pretty good at driving standards like this. It would be interesting, if they like the idea as well, to drive a standard like that from the Impromptu clocks, and then let it spread like ripples to other modules interested in tight sync. Which potentially is a lot of modules, basically anything that takes a clock/BPM-CV/reset signal.
I love the idea of using a sawtooth wave to drive a phase sync signal. It makes so much more sense than having a trigger-based clock where you have no clue that the frequency is changing until you get the next trigger. Even then, you have nothing other than guessing about how exactly the frequency is changing as a function of time. Everyone will guess differently and instantly be out of sync.
However, although the sawtooth idea will work great with a “perfect” sawtooth in the digital world, it will require some finesse to work in the analog world, due to bandlimiting. And this matters in VCV Rack (and other software synths) because many sawtooth waves emulate Gibbs ripple and use anti-aliasing.
I’m not saying I know the best solution to this, but I thought I would point out that there is always a tension in software synths between two contradictory goals:
Emulate analog circuitry realistically
Transcend the analog world (e.g. polyphonic cables and high-precision math).
Even if you have a perfect digital sawtooth, there are some modules out there that exist in both software and hardware implementations. They would be hard-pressed to follow a solution that works only in the digital world.
So perhaps this standard could exist, but it would be completely on the digital side of the analog/digital dividing line.
Or perhaps the sawtooth isn’t the ideal wave. Although more complicated to implement as a phase signal, something like a sine wave might be better suited to both sides of the analog/digital line. Because the sine is inherently band-limited, it would better enable dual hardware/software module implementations.
Yes. The idea would be that modules that only care about advancing on the beat, can just receive a clock signal like now. Modules that care about being in tempo-sync with a clock, would recieve the “clock-phase” signal instead of a clock. Now they’re always in sync with the tempo and the beat, and don’t have to do beat-detection. And modules that generate their own internal clock, for e.g. ratchets, and also want to stay in sync with a master-clock, can receive the BPM-CV for tempo and clock-phase for sync.
Yes, the master clock needs to generate a perfect sawtooth. Don’t think it’s too hard.
I wouldn’t want to solve the problems of the whole world at once I think Rack is a good place to start.
I thought band limiting (synonym for anti-aliasing in this case?) is inherently a digital issue to avoid aliasing. Easy enough to drop anti-aliasing from any phase clock. I didn’t think analog circuits have band limiting features unless the purpose is to build some type of filtering effect.
And many hardware modules have digital guts in this day and age. Or they could be hybrid, using digital for the clock only.
Analog units have what is known as a major pole for a gain bandwidth product. It is an inherent property of parasitic capacitance sometimes boosted by the Miller effect. This kind of works like a Nyquist frequency, but reduces gain above the frequency, instead of reflecting alias noise below it.
What @jackokring said is spot-on, although if you can understand that, you probably don’t need to ask the question, LOL. In simpler terms, real analog circuits cannot produce perfect square waves or sawtooth waves because the abrupt discontinuity in the signal would require infinite frequency bandwidth. There are always frequency limits in an analog circuit, and they are highly variable due to physical cables acting like a combination of a resistor, capacitor, and inductor. Cables and wires also act like antennas that transmit and receive unwanted signals with each other.
Yes, absolutely. I wasn’t advocating for a particular approach. I just wanted to raise the issue, so that if a choice is made, it is done consciously. This is clearly a trade-off where improving one aspect makes another less pleasant.
In that spirit of brainstorming, perhaps this hypothetical standard could encourage making the phase sync oscillator (PSO?) a little like an LFO in that it could have both sawtooth and sine wave outputs. Then you can pick which output a particular module wants.
Oh, sorry for another double-post, but another important thing I wanted to bring up. Even in the purely digital world, it is not always possible to have a “perfect” sawtooth. With a finite sampling rate, suppose you want a 120 BPM signal. If your sampling rate is 48 kHz, no problem: you just ramp up every 400 samples. But if you change the sampling rate to 44.1 kHz, now the cycle has to be 367.5 samples. It gets even worse if you want 121.3 BMP, etc.
The phase-clock designer has to make a choice how to represent a sawtooth whose period doesn’t mesh with the sample rate, and furthermore, all receivers of the phase-clock signal have to agree on how to sync with it.
This is not a horrible problem, but it is a problem that needs to be consciously approached and agreed upon, otherwise it’s not really a “standard”.
From a creator perspective (I’m not a developer just an advocate in favor of the phase clock) it gives us as much control over the time aspect of our creations as we already have over pitch or timbre.
I’ll leave it to Karlheinz Stockhausen to make the point more succinctly:
@LarsBjerregaard: Phase input on Impromptu sequencers would indeed be awesome.
@cosinekitty: I like how your mind immediately thinks about edge cases, problems and solutions. I feel Bitwig’s “the grid” has shown it to be a viable way to drive time in a digital modular environment. Aside from it being the standard it offers a few creative and utility blocks (reverse, pinch, skew, etc.).
I was more thinking, to start, of clock-phase output from the Impromptu clocks, actually. But yes. It would be a good demonstrator to have both - an implementation of the clock-phase provider and the clock-phase consumer. To prove the concept and have something others can copy.
Personally I’m quite content with Sergey Ukolov’s implementation of a clock with phase generator for VCV. Unfortunately we haven’t heard from him since March '22. I do see your point that it would be valuable relating to standards and adoption within the VCV creator and dev community to have a clock-phase signal as an option in the impromptu clocks. Heading over to github.
Now that @soundismovement pointed us to the ZZC Clock module, I’m kinda curious about it and I want to see how exactly it generates its ramps and square waves when the beat period is not congruent with the sample rate. Assuming it does its job in some reasonable way, it might as well become a de facto standard for phase sync in VCV Rack.
I think Rack is a good place to start.