Yea
I would love that to be more standardized
With phase it is way less difficult tho right? But still a problem
I guess “i don’t have an answer to the problem everyone has” though 
- in surge 20 I just needed tempo mostly but in some of the new 21 modules phase would be great
no, I think reset is no less difficult with phase.
Yeah that may be right for everything except in phase speed 1 lfos
Hard topic - don’t pretend to be an expert. Works well in bitwig and see places it could work in rack but agree it won’t if there’s no standard and might not if there is
Is it straightforward to accurately derive the current tempo from a short period of the clock-phase signal? Because in that case you wouldn’t even need the BPM-CV signal (nor clock). All that would be needed is the clock-phase signal to cover all tempo and sync bases (except reset,start,stop). I’m curious, I’m learning, this is exiting…
Pondering it a bit more, there’s probably some edge-cases that needs thinking through. As an example, a consumer module receiving a trigger/clock is never in doubt exactly when the clock tick happens, but with only clock-phase it might never receive or hit the exact 10V voltage before the phase wraps around again. So it would either need to compare the previous to the current phase-value and determine “the tick happened”, or a voltage would need to be determined that says something like “at the max. BPM provided by the standard you’ll always hit 9,99V and that value means the tick happened”.
Yeah you need 2 samples to accurately know a trigger start point. But the benefit is you also know the sub sample start time if you have perfect digital phase.
There’s some nuance with floats - they have 6 digits of accuracy so 2 adjacent samples in a 100second wavelength saw at 48k have only noise between them - that you would solve
But yes I would add phase as a third option with ppq and bpm to surge tempo inputs if this was standardized
@baconpaul is completely correct here. Yes, you still need two samples to know when the phase “ticked” (wrapped?). Most ppl would probably use a Schmidt trigger.
And, yes, trying to calculate the tempo based on two samples of phase will certainly run into numeric precision issues, i.e. I doubt that it would work in many cases.
The phase sync on ShapeMaster is more of an accidental byproduct rather than something done with intention. When we were making it, we never envisioned the ‘CV playhead’ option could be used for syncing – and if we had we would have made it a Pro only feature.
So yeah… standardisation of phase sync is a terrible idea – the fewer people that know about it and use it the better. In fact this thread should probably be closed and deleted for the common good.
haha!
Total convert since ZZC appeared, haven’t used another clock since.
I do hope Sergey reappears.
oh, for sure it’s a cool module. But there is room in the world for more than one clock. A lot of ppl like Impromptu Clocked because of all the features. So it would be cool if that popular module supported phase output.
My prior clock of choice.
I wonder if we should ask Andrew to add a section to the voltage standard manual that some clocks and control rate and tempo tools also use a 10v 0-10 saw cycle per quarter note to represent phase and thus tempo and sync. That’s what the standard we are taking would be about right?
I think he will be most to do that after modules already agree and implement it. fwiw several of us come up with a “standard” for copying a pasting note date - I don’t think Andrew was interested in this “standard” it’s here, btw.
Also, on a small point, you says “quarter note” whereas is think it would be more proper to say “clock” as clocks are not always quarter notes?
Please allow me to resurrect this thread, I have a question pertaining Volts, Hz and BPM.
Using a constant Volt generator such as Alikins specific value (which uses the voltage standard in VCV) I generate -1.124V =120Hz which should equal 56.25BPM ?
When I feed -1.124V to ZZC Clock or any other clock that has V/Oct input The BPM readouts and generated are off by an exponential amount, The higher the voltage, the bigger the difference.
I figured that If I apply a voltage offset of 0.0313 volts the BPM readout then is correct
This however is not happening if I feed the voltage to an LFO with V/oct input and then feed the LFO WF out to the clock input.
This whole BPM conversion should be so straightforward but I just can’t quite understand why is not following the logic of 1Hz =60bpm or BPM= (F*60)/128 logic.
Can anyone help me understand why an offset is needed if feeding a V/oct but not when feeding the same signal to an LFO to generate a WF ? Also why is the @alikins module giving the wrong BPM ?
Strong upvote adding phase support to @marc_boule s impromptu clock (input at least.) to neatly translate between the two workflows.
Inputs on the sequencers would also open many neatly synced opportunities with current phase based modules…
The way i see it, the phase workflow appears stronger in the sync category, but still feels a touch foreign/ unsupported. Bridging some gaps would produce the ultimate workflow imo.
Ive been dying to see zzc phaseque supported in 2.0. (The previously leading method) one day. 
@zezic
Also i have said it before but the stellare link module would be made INFINITELY better with phase support. It is how link works with most daws.
For LFOs, the standard is different.
2 * 2^{-1.124} = 0.91764 Hz = 55.0584 BPM, which is correct.
For VCOs, the standard is
261.6256 * 2^{-1.124} = 120.04 Hz
As for phase support, I don’t think I will be getting into that unfortunately (@sounds )
@marc_boule thank you for the clarification. However I am still unclear as to why feeding -1.124V to bog audio LFO with V/Oct input and in turn feeding the LFO square wave to the square wave input of clock gives a readout of 56.26 BPM which is correct for the logic of 1Hz =60bpm or BPM= (F*60)/128. Should that not read 55.05 BPM ?
Could it be that perhaps the default setting of the Hz knob on the BogAudio module is tweaking things a bit, i.e. 2.044 Hz? Setting it to 2 Hz with right-click parameter entry might do the trick. This knob still seems to have an effect when a VOct cable is connected.
