On May 25, 2006, at 5:23 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
Ah yes, [pwm~] is using zexy's [>~]. I was looking at [pwm].
That example (I am looking at K01.pulse.width.mod.pd from 0.38.4)
is very simple, but as it is, it is not usable. Notice how the
LOW and HIGH change values. PWM needs be 0 for LOW and 1 for
HIGH. That example is usable in an audio context, since DC
offset doesn't really matter. I guess you could rely on the DAC
in the soundcard to remove the DC, but that is probably asking
for trouble. I am open to suggestions for a different algorithm. Or perhaps
someone should write [>~] in Pd.Maybe min~ would work better. The code is in d_arithmetic.c so it
seems trivial to make a >~ (and <~, >=~, <=~, ==~, !=~) that uses
essentially the same code except for one or two lines in the
perform routine. ...except for the error caused by the finite sampling rate, which
means that you never know exactly when the signal switches inside
of one sample time, so you get extra unwanted frequencies. Possible
solution to this would be some kind of interpolation between
samples so that the output of >~ could be intermediate between 0
and 1 if the transition occurred during the sample time and not at
the exact edge.
Feel free to make my PWM objects perfect, you can commit directly.
A generalized band-limited pwm~ object could also be used as a
squarewave.
I had [square~] sitting around on my drive for a while, I just
committed it:
externals/hcs/square~.pd
.hc
"Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies."
- Amy Smith