to fundamental" in the figure), and to compute phases for both <TT>cos~</TT> objects which operate as shown earlier in Figure <AHREF="node100.html#fig06.16">6.17</A>.
<P>
The waveshaping portion of the patch uses a half period of a sinusoid
as a lookup function (to compensate for the frequency doubling because
of the symmetry of the lookup function). To get a half-cycle of the sine function
we multiply the phase by 0.5 and subtract 0.25, so that the adjusted phase
runs from -0.25 to +0.25, once each period. This scans the positive half
of the cycle defined by the <TT>cos~</TT> object.
<P>
The amplitude of the half-sinusoid is then adjusted by an index of modulation
object, we create an ordered pair of messages to the <TT>tabwrite</TT> object.
First, at right, goes the index itself, from 0 to 199. Then for the left inlet,
the first <TT>expr</TT> object adjusts the index to range from -4 to 4 (it
previously ranged from 0 to 199) and the second one evaluates the
Gaussian function.
<P>
In this patch we have not fully addressed the issue of updating the
center frequency quotient at the appropriate times. Whenever the carrier
frequency is changed the sample-and-hold step properly delays the update
of the quotient. But if, instead or in addition, the fundamental itself
changes abruptly, then for a fraction of a period the <TT>phasor~</TT> object's frequency and the quotient are out of sync. Pd does not allow
the <TT>samphold~</TT> output to be connected back into the <TT>phasor~</TT> input without the inclusion of an explicit delay (see the next chapter) and
there is no simple way to modify the patch to solve this problem.
<P>
Assuming that we <I>did</I> somehow clock the <TT>phasor~</TT> object's input
synchronously with its own wraparound points, we would then have to do the
same for the bandwidth/fundamental quotient on the right side of the patch
as well. In the current scenario, however, there is no problem updating
that value continuously.
<P>
A practical solution to this updating problem could be simply to rewrite the
entire patch in C as a Pd class; this also turns out to use much less CPU time
than the pictured patch, and is the more practical solution overall--as long
as you don't want to experiment with making embellishments or other changes to
the algorithm. Such embellishments might include: adding an inharmonic upward
or downward shift in the partials; allowing to switch between smooth and
sampled-and-held center frequency updates; adding separate gain controls for
even and odd partials; introducing gravel by irregularly modulating the phase;
allowing mixtures of two or more waveshaping functions; or making sharper
percussive attacks by aligning the phase of the oscillator with the timing of
an amplitude envelope generator.
<P>
One final detail about amplitude is in order: since the amplitude of the
strongest partial decreases roughly as <IMG
WIDTH="66" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
SRC="img572.png"
ALT="$1/(1+b)$"> where <IMG
WIDTH="10" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
SRC="img21.png"
ALT="$b$"> is the index of
modulation, it is sometimes (but not always) desirable to correct the amplitude
of the output by multiplying by <IMG
WIDTH="37" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img606.png"
ALT="$1+b$">. This is only an option if <IMG
WIDTH="10" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
SRC="img21.png"
ALT="$b$"> is
smoothly updated (as in this example), not if it is sampled-and-held.
One situation in which this is appropriate is in simulating plucked strings (by
setting center frequency to the fundamental, starting with a high index of
modulation and dropping it exponentially); it would be appropriate to hear
the fundamental dropping, not rising, in amplitude as the string decays.
