I am interested in generating some square waves with Pd, with pulse widths that are consistently m samples long and periods that are n samples long.

Is there a signal that provides a sample count that increases continuously, or better yet, wraps at some value? Like an inverse phasor~ (instead of counting up to 1.0 at different rates, it counts at the same rate up to n)

@mattgomes28 The reason I'm looking to do the math directly on samples is because it is important to me to choose oscillation frequencies whose periods are a multiple of the sample time (so there is no dithering from one period to the next).

For example, if I want to make 499Hz square wave with a duty cycle of 2%, then I cannot achieve this exactly if my sample rate is 48000Hz. (The number of samples in the period, or on samples are both not integers), and the output waveform is not perfectly the same one period to the next.

Instead of backsolving for what are "stable" frequencies and duty cycles, I'd like to just choose sample counts directly.

You can change the 44100 to 48000 or whatever sample rate in the patches I set up.

I was able to get DC after setting the period to 1 sample. Do you need to change the pulse timing at signal rate?

@gusgus You could look into [count~] from the cyclone library. It adds 1 at every sample and wraps at a number you specify.

Just posting for reference. This has signal level period and pulse length in samples. Kind of pointless because the whole concept is spoiled by parameters changing in time

samplepulsesg.pd

if all you need is to convert to periods that are integer samples long you could do something like this:

Thanks for all the helpful replies and code examples. I ended up going with [count~], which is already available in Purr Data.

Hi all. I'm trying to do a sample counter for various purposes. But i can't use externals beacause i have to do some Camomile projects (in the future Camomile may support externals but as it is now i have to go the vanilla path).
So this is a little idea. The drawback is that it can't count forever. But it can count a very high number of seconds/samples if an high number of max seconds to run is set.
Is a very rough attempt and i don't know if it is precise enough. Probably has to be nested in a subpatch with a [ block~ 1 ] object?
Is [ expr~ int($v1) ] bad for cpu performance?
anyway...
AS-samples-count~.pd

@alfonso.santimone Hi, this seems to be more precise:
AS-samples-count2.pd

Indeed you need [block~ 1] as well as a a snapshot that updates at each sample. Also round instead of int seems to be more precise. I don't know if it's too expensive but I can't think of other ways to do it. I tried [bang~] attached to a [f]x[+ 1] counter but it only bangs every 64 samples even with block 1, not sure why.

@weightless said:

@alfonso.santimone Hi, this seems to be more precise:
AS-samples-count2.pd

Indeed you need [block~ 1] as well as a a snapshot that updates at each sample. Also round instead of int seems to be more precise. I don't know if it's too expensive but I can't think of other ways to do it. I tried [bang~] attached to a [f]x[+ 1] counter but it only bangs every 64 samples even with block 1, not sure why.

@weightless Hi, thanks for the suggestions. The snapshot~, btw, is just there for monitoring purposes. I plan to use the counter with an audio rate output.

thanks!

@alfonso.santimone Yes, sorry my last patch was a mess and full of errors and wasn't much of a fix. I don't know how precise these methods are but perhaps you could also try with [line~]?

why don't you use
[1 (
|
[rpole~ 1]

@seb-harmonik.ar thanks for the suggestion!! i just forgot all the filter design arsenal!