I have created a kind of pulse width sine thingie where I can define the nr of sine waves in one period by use of a comparitor
Works great , more or less
Obviously the sine needs to be stationary (0hz° ) and the phase input is modulated by a phasor .
The issue is settting the starting phase of the sine because when it's a cosine there are discontinuties ( becasue it starts from 1) , the starting phase sometimes works with the nr. 1.429 ,but most of the time not (blue rectangle on picture )
Max msp obviously suffers from the same issues with cycle~ but it has a sinx~ object which takes 2*pi as input.
Here's the stuff


narrow sine.pd

@gentleclockdivider Sorry, this may not answer your question, but this is how I would do it in vanilla:
synchronous sine bursts.pd

Interesting use of the s/h~
I guess it's just a matter of preference of using a comparator or S/H
The -~ 0.25 in your example is exactly what solved it
Thanks

@gentleclockdivider The [samphold~] idiom is from Pd's audio example help, B11.sampler.nodoppler

@gentleclockdivider said:

I guess it's just a matter of preference of using a comparator or S/H

Don't want to stop you from doing so. But keep in mind that [phasor~] is not accumulating in a reliable way: Recording and reading the floats in an array you can see, due to precision, it accumulates non-predictably and rarely counts to 1 or starts from 0.
If you want reliable, steady precision, [samplehold~] is the way to go.

The quoted paper in the sources explains [phasor~] in depth:
https://github.com/pure-data/pure-data/blob/7f87e06a97db50a4c46af236e8bd41534d005bfa/src/d_osc.c#L53

B11.sampler.nodoppler

Wondering if Vanilla's documentation comes with Plugdata?
Highly recommended to read into it!

also not what you asked, but i wanted to point out that in this use case it wont matter much how the waveform looks like.

have you thought about building this based on a buffer? ...