BPM Voltage Standard?

Development
21

Some follow-up thoughts:

  1. 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.
  2. So perhaps this standard could exist, but it would be completely on the digital side of the analog/digital dividing line.
  3. 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.
1 Like
22

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 :slight_smile: I think Rack is a good place to start.

23

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.

Or maybe I am naive?

24

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.

25

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.

26

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

27

Just want to point out the obvious that all of this is true for a square wave as well as a saw.

2 Likes
28

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

4 Likes
29

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.

1 Like
30

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.

2 Likes
31

Does anyone know all the modules that use phase as clock?

It would be nice to put down a dedicated list.

1 Like
32

and while we are at it - and semi-related - I believe “nord reset” is better than the more common “immediate reset”.

1 Like
33

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.

1 Like
34

There are only two possibilities - either it quantizes the clock period to the nearest even sample, or is uses a normal phase accumulator that will make the edges jitter back and forth the make the correct tempo. Either would we totally fine - what are you worrying about? (and, once again, any clock has the exact same issue).

35

Yeah, I suppose either way would be fine for the lower frequencies implied by a clock. When you point out that rounding to the nearest integer sample is an option, that makes sense. A few months ago I watched a video by Venus Theory that proves humans can’t discern small changes in BPM. Clearly rounding isn’t good enough for audio frequencies, but clock frequencies could be quite workable.

1 Like
36

I think most implementations would tend be be accurate with a l+/- half sample jitter? Looks like that’s what VCV LFO does?

	// Advance phase
	float_4 deltaPhase = simd::fmin(freq * args.sampleTime, 0.5f);
	phases[c / 4] += deltaPhase;
	phases[c / 4] -= simd::trunc(phases[c / 4]);
37

Oh phase is great. You get position but you also get accurate tempo with a simple few sample derivative

I’m all for people suggesting a standard and moving towards it. The surge clock modes are all in one bit of code so adding a third mode would be easy if we all agree

2 Likes
38

and what is your opinion on reset?

39

So I coded the surge lfo so tempo and reset were separate - with phase input on some of my modules phase would win indeed

For things like a temposync delay reset doesn’t matter

40

well, ok, but the entire world isn’t tempo-sync delay, right? You must have noticed how many posts there are here about sequencers and similar devices responding differently to reset.