The default BPM for the Impromptu clock modules is 120. And that translates to 0V on its BPM output. It then uses a log2f function to convert BPM above and below 120. When connecting multiple Impromptu clocks, they all understand that protocol.
Is that some sort of standard or just a plug-in specific protocol? I don’t see many other modules with a BPM input, just a clock input. And the code for the one I looked at has a different mapping (30 linear BPM per volt).
Jens is a man of few words. After reading that link, I see it clearly says that yes, what Impromptu does is the recommendation.
Idon’t really know much about it. But I have added a pic, as to not let the reader guide by fear, uncertainty or doubt to click a link they do not knowest where endesth…
Thank you all for the quick response.
I had read the header “Pitch and Frequencies” and just assumed audio frequencies because it starts out saying “volts per octave” and there are no octaves in this case. So, I missed that last sentence about low frequency oscillators and clocks defaulting to 120 BPM (2 Hz) and following the save 2^V standard.
I agree that that is confusing. I get tripped up on that each time I deal with it.
The new Surge XT modules have a right-click option to use BPM CV instead of pulse clock on modules that have clock inputs for sync like the Delay etc. I’m also surprised it isn’t used more as figuring out the BPM is practically instantaneous (so much faster sync) using BPM CV as there is no need to calculate the time between clock pulses - particularly as a lot of modules that do use pulse clock for sync tend to use a very slow 1X beat clock.
Meander has a BPM input. That makes syncing to CLOCKED very easy. But Meander also has an X8 clock input. The two work together.
But there are octaves - 240 BPM is one octave above 120 BPM
Yes, it’s an exponential relationship between voltage and BPM and the BPM-CV standard is almost identical to the volt-per-octave standard for Rack. The only difference is in the definition of 0V. So for V/Oct, 0V==C4 note, -1V==C3, 1V==C5 etc, where for BPM-CV 0V==120BPM, -1V==60BPM, 1V==240BPM, etc.
Definately (IMHO) BPM-CV is the way to go for tempo instead of (often fragile) beat-detection. Makes things simpler and much more robust and e.g. the Impromptu clocks have BPM-CV output so it’s easy to sync to a master clock.
One question?.How does the leading clock edge stay in sync?
It would seem like a rest is also required after connecting a module at a minimum right? Or am I missing something?
Additionally if the BPM is going change mid “song” How each module handles the transition may be different, so they may get out of sync, right?
It seems that no matter what I try for sync, I often have to hit reset to get things in sync with the clock and each other. I always have a master reset button in all of my patches for this reason.
And for the speedcore experimentalists or there, if you start off with 122.64 bpm (2.044 Hz LFO), + 7 volts will turn your beat into middle C. 
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.
I’m not sure I follow (out of sync), can you explain what you mean? Do you mean phase as simply “the leading edge of a clock pulse” or something else?
I hope I got your misunderstanding right.
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.
A picture says it all:
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:
