replace in opening quotations
This commit is contained in:
parent
1ca5c25706
commit
19822c017f
@ -499,7 +499,7 @@ original version by: Nikos Drakos, CBLU, University of Leeds
|
||||
<LI><A NAME="tex2html390"
|
||||
HREF="node180.html">Narrow-band companding: noise suppression</A>
|
||||
<LI><A NAME="tex2html391"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<LI><A NAME="tex2html392"
|
||||
HREF="node182.html">Phase vocoder time bender</A>
|
||||
</UL>
|
||||
|
||||
@ -85,7 +85,7 @@ nominal amplitude <IMG
|
||||
<DIV ALIGN="CENTER"><A NAME="fig01.04"></A><A NAME="1090"></A>
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 1.4:</STRONG>
|
||||
The relationship between ``MIDI" pitch and frequency in cycles per
|
||||
The relationship between "MIDI" pitch and frequency in cycles per
|
||||
second (Hertz). The span of 24 MIDI values on the horizontal axis represents
|
||||
two octaves, over which the frequency increases by a factor of four.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
|
||||
34
node101.html
34
node101.html
@ -86,7 +86,7 @@ The phase-aligned formant (PAF) synthesis algorithm.</CAPTION>
|
||||
Example F12.paf.pd (Figure <A HREF="#fig06.17">6.18</A>) is a realization of the PAF generator,
|
||||
described in Section <A HREF="node96.html#sect6.paf">6.4</A>.
|
||||
The control inputs specify the fundamental frequency, the center frequency, and
|
||||
the bandwidth, all in ``MIDI" units. The first steps taken in the realization
|
||||
the bandwidth, all in "MIDI" units. The first steps taken in the realization
|
||||
are to divide center frequency by fundamental (to get the center frequency quotient)
|
||||
and bandwidth by fundamental to get the index of modulation for the
|
||||
waveshaper. The center frequency quotient is sampled-and-held so that it is
|
||||
@ -95,7 +95,7 @@ only updated at periods of the fundamental.
|
||||
<P>
|
||||
The one oscillator (the <TT>phasor~</TT> object) runs at the fundamental
|
||||
frequency. This is used both to control a <TT>samphold~</TT> object which
|
||||
synchronizes updates to the center frequency quotient (labeled ``C.F. relative
|
||||
synchronizes updates to the center frequency quotient (labeled "C.F. relative
|
||||
to fundamental" in the figure), and to compute phases for both <TT>cos~</TT> objects which operate as shown earlier in Figure <A HREF="node100.html#fig06.16">6.17</A>.
|
||||
|
||||
<P>
|
||||
@ -115,7 +115,7 @@ The amplitude of the half-sinusoid is then adjusted by an index of modulation
|
||||
WIDTH="38" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img588.png"
|
||||
ALT="${\omega_b}/\omega$">). The table
|
||||
(``bell-curve") holds an unnormalized Gaussian curve sampled
|
||||
("bell-curve") holds an unnormalized Gaussian curve sampled
|
||||
from -4 to 4 over 200 points (25 points per unit), so the center of the table,
|
||||
at point 100, corresponds to the central peak of the bell curve. Outside the
|
||||
interval from -4 to 4 the Gaussian curve is negligibly small.
|
||||
@ -145,31 +145,31 @@ Filling in the wavetable for Figure <A HREF="#fig06.17">6.18</A>.</CAPTION>
|
||||
WIDTH="57" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img623.png"
|
||||
ALT="\fbox{ $\mathrm{until}$\ }"> :
|
||||
<A NAME="7054"></A>When the left, ``start" inlet is banged, output sequential bangs (with no
|
||||
elapsed time between them) iteratively, until the right, ``stop" inlet is
|
||||
banged. The stopping ``bang" message must originate somehow from the
|
||||
<TT>until</TT> object's outlet; otherwise, the outlet will send ``bang" messages
|
||||
<A NAME="7054"></A>When the left, "start" inlet is banged, output sequential bangs (with no
|
||||
elapsed time between them) iteratively, until the right, "stop" inlet is
|
||||
banged. The stopping "bang" message must originate somehow from the
|
||||
<TT>until</TT> object's outlet; otherwise, the outlet will send "bang" messages
|
||||
forever, freezing out any other object which could break the loop.
|
||||
|
||||
<P>
|
||||
As used here, a loop driven by an <TT>until</TT> object
|
||||
counts from 0 to 199, inclusive. The loop count is maintained by the
|
||||
``<TT>f</TT>" and ``<TT>+ 1</TT>" objects, each of which feeds the other. But
|
||||
since the ``<TT>+ 1</TT>" object's output goes to the right inlet of the
|
||||
``<TT>f</TT>", its result (one greater) will only emerge from the
|
||||
``<TT>f</TT>" the next time it is banged by ``<TT>until</TT>". So each bang
|
||||
from ``<TT>until</TT>" increments the value by one.
|
||||
"<TT>f</TT>" and "<TT>+ 1</TT>" objects, each of which feeds the other. But
|
||||
since the "<TT>+ 1</TT>" object's output goes to the right inlet of the
|
||||
"<TT>f</TT>", its result (one greater) will only emerge from the
|
||||
"<TT>f</TT>" the next time it is banged by "<TT>until</TT>". So each bang
|
||||
from "<TT>until</TT>" increments the value by one.
|
||||
|
||||
<P>
|
||||
The order in which the loop is started matters: the upper ``<TT>t b b</TT>"
|
||||
object (short for ``trigger bang bang") must first send zero to the
|
||||
``<TT>f</TT>", thus initializing it, and then set the <TT>until</TT> object sending
|
||||
The order in which the loop is started matters: the upper "<TT>t b b</TT>"
|
||||
object (short for "trigger bang bang") must first send zero to the
|
||||
"<TT>f</TT>", thus initializing it, and then set the <TT>until</TT> object sending
|
||||
bangs, incrementing the value, until stopped. To stop it when the value
|
||||
reaches 199, a <TT>select</TT> object checks the value and, when it sees the
|
||||
match, bangs the ``stop" inlet of the <TT>until</TT> object.
|
||||
match, bangs the "stop" inlet of the <TT>until</TT> object.
|
||||
|
||||
<P>
|
||||
Meanwhile, for every number from 0 to 199 that comes out of the ``<TT>f</TT>"
|
||||
Meanwhile, for every number from 0 to 199 that comes out of the "<TT>f</TT>"
|
||||
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
|
||||
|
||||
@ -100,7 +100,7 @@ notes.
|
||||
<DD>Echos: At time shifts between about 30 milliseconds and about a second,
|
||||
the later copy of the signal can sound like an echo of the earlier one. An echo
|
||||
may reduce the intelligibility of the signal (especially if it consists of
|
||||
speech), but usually won't change the overall ``shape" of melodies or
|
||||
speech), but usually won't change the overall "shape" of melodies or
|
||||
phrases.
|
||||
|
||||
<P>
|
||||
|
||||
@ -92,7 +92,7 @@ A convenient logarithmic scale for pitch is simply to
|
||||
count the number of half-steps from a reference pitch--allowing fractions to
|
||||
permit us to specify pitches which don't fall on a note of the Western scale.
|
||||
The most commonly used logarithmic pitch scale is
|
||||
<A NAME="1100"></A>``MIDI pitch", in which the pitch 69 is assigned to a frequency of 440 cycles
|
||||
<A NAME="1100"></A>"MIDI pitch", in which the pitch 69 is assigned to a frequency of 440 cycles
|
||||
per second--the A above middle C. To convert between a MIDI pitch <IMG
|
||||
WIDTH="17" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
|
||||
SRC="img111.png"
|
||||
@ -153,7 +153,7 @@ second.
|
||||
MIDI itself is an old hardware protocol which has unfortunately insinuated
|
||||
itself into a great deal of software design. In hardware, MIDI allows only
|
||||
integer pitches between 0 and 127. However, the underlying scale is well
|
||||
defined for any ``MIDI" number, even negative ones; for example a ``MIDI pitch"
|
||||
defined for any "MIDI" number, even negative ones; for example a "MIDI pitch"
|
||||
of -4 is a decent rate of vibrato. The pitch scale cannot, however, describe
|
||||
frequencies less than or equal to zero cycles per second. (For a clear
|
||||
description of MIDI, its capabilities and limitations, see
|
||||
|
||||
@ -104,7 +104,7 @@ delay lines in parallel.</CAPTION>
|
||||
|
||||
<P>
|
||||
In order to work with power-conserving delay networks we will need an
|
||||
explicit definition of ``total average power".
|
||||
explicit definition of "total average power".
|
||||
If there is only one signal (call it <IMG
|
||||
WIDTH="31" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img80.png"
|
||||
@ -542,7 +542,7 @@ Flat frequency response in recirculating networks: (a) in general,
|
||||
using a rotation matrix <IMG
|
||||
WIDTH="15" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
|
||||
SRC="img36.png"
|
||||
ALT="$R$">; (b) the ``all-pass" configuration.</CAPTION>
|
||||
ALT="$R$">; (b) the "all-pass" configuration.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="381" HEIGHT="287" BORDER="0"
|
||||
SRC="img765.png"
|
||||
|
||||
@ -80,7 +80,7 @@ To make this work in practice it is necessary to open the input of the
|
||||
reverberator only for a short period of time, during which the input sound is
|
||||
not varying too rapidly. If an infinite reverberator's input is left open for
|
||||
too long, the sound will collect and quickly become an indecipherable mass. To
|
||||
``infinitely reverberate" a note of a live instrument, it is best to wait until
|
||||
"infinitely reverberate" a note of a live instrument, it is best to wait until
|
||||
after the attack portion of the note and then allow perhaps 1/2 second of the
|
||||
note's steady state to enter the reverberator. It is possible to build chords
|
||||
from a monophonic instrument by repeatedly opening the input at different
|
||||
|
||||
@ -137,7 +137,7 @@ a delay of <IMG
|
||||
SRC="img783.png"
|
||||
ALT="$x[n-1.5]$">.
|
||||
We could do this using standard four-point interpolation, putting a cubic
|
||||
polynomial through the four ``known" points (0, x[n]), (1, x[n-1]), (2, x[n-2]),
|
||||
polynomial through the four "known" points (0, x[n]), (1, x[n-1]), (2, x[n-2]),
|
||||
(3, x[n-3]), and then evaluating the polynomial at the point 1.5. Doing
|
||||
this repeatedly for each value of <IMG
|
||||
WIDTH="13" HEIGHT="13" ALIGN="BOTTOM" BORDER="0"
|
||||
|
||||
@ -435,9 +435,9 @@ classic variant uses a single delay line, with no enveloping at
|
||||
all. In this situation it is necessary to choose the point at
|
||||
which the delay time jumps, and the point it jumps to, so that the output
|
||||
stays continuous. For example, one could find a point where the output signal
|
||||
passes through zero (a ``zero crossing") and jump discontinuously to another one.
|
||||
passes through zero (a "zero crossing") and jump discontinuously to another one.
|
||||
Using only one delay line has the advantage that the signal output sounds
|
||||
more ``present". A disadvantage is that, since
|
||||
more "present". A disadvantage is that, since
|
||||
the delay time is a function of input signal value, the output is no longer
|
||||
a linear function of the input, so non-periodic inputs can give rise to
|
||||
artifacts such as difference tones.
|
||||
|
||||
@ -108,7 +108,7 @@ inlet takes an audio signal and writes it continuously into the delay line.
|
||||
WIDTH="86" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img821.png"
|
||||
ALT="\fbox{ \texttt{delread\~}}">:
|
||||
<A NAME="8425"></A>read from (or ``tap") a delay line. The first creation argument gives the name
|
||||
<A NAME="8425"></A>read from (or "tap") a delay line. The first creation argument gives the name
|
||||
of the delay line (which should agree with the name of the corresponding
|
||||
<TT>delwrite~</TT> object; this is how Pd knows which <TT>delwrite~</TT> to
|
||||
associate with the <TT>delread~</TT> object). The
|
||||
|
||||
@ -106,7 +106,7 @@ achievable delay is one sample.
|
||||
Here the objects on the left side, from the top down to the
|
||||
<TT>clip -0.2 0.2</TT> object,
|
||||
form a waveshaping network; the index is set by the
|
||||
``timbre" control, and the waveshaping output varies between a near sinusoid
|
||||
"timbre" control, and the waveshaping output varies between a near sinusoid
|
||||
and a bright, buzzy sound. The output is added to the output of the
|
||||
<TT>vd~</TT> object. The sum is then high pass filtered (the <TT>hip~</TT> object
|
||||
at lower left), multiplied by a
|
||||
@ -121,10 +121,10 @@ that the signal cannot exceed 1 in absolute value.
|
||||
The length of the delay is controlled by the signal input to the
|
||||
<TT>vd~</TT> object. An oscillator with variable frequency and gain, in the
|
||||
center of the figure, provides the delay time. The oscillator is added to
|
||||
one to make it nonnegative before multiplying it by the ``cycle depth" control,
|
||||
one to make it nonnegative before multiplying it by the "cycle depth" control,
|
||||
which effectively sets the range of delay times. The minimum possible
|
||||
delay time of 1.46 milliseconds is added so that the true range of delay times
|
||||
is between the minimum and the same plus twice the ``depth". The reason for this
|
||||
is between the minimum and the same plus twice the "depth". The reason for this
|
||||
minimum delay time is taken up in the discussion of the next example.
|
||||
|
||||
<P>
|
||||
|
||||
@ -82,7 +82,7 @@ the software package specifies the network, sometimes called a
|
||||
which essentially corresponds to the synthesis algorithm to be used, and then
|
||||
worries about how to control the various unit generators in time. In this
|
||||
section, we'll use abstract block diagrams to describe patches, but in the
|
||||
``examples" section (Page <A HREF="node18.html#sect1.examples"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
|
||||
"examples" section (Page <A HREF="node18.html#sect1.examples"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
|
||||
SRC="crossref.png"></A>), we'll choose a
|
||||
specific implementation environment and show some of the software-dependent
|
||||
details.
|
||||
@ -158,13 +158,13 @@ Parts (c) and (d) show a more gently-varying possibility for <IMG
|
||||
ALT="$y[n]$"> and the
|
||||
result. Intuition suggests that the result shown in (b) won't sound like an
|
||||
amplitude-varying sinusoid, but instead like a sinusoid interrupted by
|
||||
an audible ``pop" after which it continues more quietly. In general, for
|
||||
an audible "pop" after which it continues more quietly. In general, for
|
||||
reasons that can't be explained in this chapter, amplitude control signals
|
||||
<IMG
|
||||
WIDTH="30" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img2.png"
|
||||
ALT="$y[n]$"> which ramp smoothly from one value to another are less likely to give
|
||||
rise to parasitic results (such as that ``pop") than are abruptly changing
|
||||
rise to parasitic results (such as that "pop") than are abruptly changing
|
||||
ones.
|
||||
|
||||
<P>
|
||||
@ -173,7 +173,7 @@ sinusoids are the signals most sensitive to the parasitic effects of
|
||||
quick amplitude change. So when you want to test an amplitude transition, if
|
||||
it works for sinusoids it will probably work for other signals as well.
|
||||
Second, depending on the signal whose amplitude you are changing, the amplitude
|
||||
control will need between 0 and 30 milliseconds of ``ramp" time--zero for the
|
||||
control will need between 0 and 30 milliseconds of "ramp" time--zero for the
|
||||
most forgiving signals (such as white noise), and 30 for the least (such as a
|
||||
sinusoid). All this also depends in a complicated way on listening levels and
|
||||
the acoustic context.
|
||||
|
||||
@ -86,8 +86,8 @@ tilde objects, and because of the connections, the object <TT>a~</TT> must
|
||||
produce its output before either of <TT>b~</TT> or <TT>c~</TT> can run;
|
||||
and
|
||||
both of those in turn are used in the computation of <TT>d~</TT>. So the
|
||||
possible orderings of these four objects are ``a-b-c-d" and
|
||||
``a-c-b-d". These
|
||||
possible orderings of these four objects are "a-b-c-d" and
|
||||
"a-c-b-d". These
|
||||
two orderings will have exactly the same result unless the computation of
|
||||
<TT>b~</TT> and <TT>c~</TT> somehow affect each other's output (as
|
||||
delay operations might, for example).
|
||||
@ -98,7 +98,7 @@ delay operations might, for example).
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 7.26:</STRONG>
|
||||
Order of execution of tilde objects in Pd: (a), an acyclic network.
|
||||
The objects may be executed in either the order ``a-b-c-d" or ``a-c-b-d". In
|
||||
The objects may be executed in either the order "a-b-c-d" or "a-c-b-d". In
|
||||
part (b), there is a cycle, and there is thus no compatible linear ordering of
|
||||
the objects because each one would need to be run before the other.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
@ -253,7 +253,7 @@ a new object:
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 7.27:</STRONG>
|
||||
A patch using block size control to lower the loop delay below
|
||||
the normal 64 samples: (a) the main patch; (b) the ``delay-writer" subpatch
|
||||
the normal 64 samples: (a) the main patch; (b) the "delay-writer" subpatch
|
||||
with a <TT>block~</TT> object and a recirculating delay network.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="558" HEIGHT="252" BORDER="0"
|
||||
|
||||
@ -90,7 +90,7 @@ G05.execution.order.pd (Figure <A HREF="#fig07.28">7.28</A>).
|
||||
Using subpatches to ensure that delay lines are written before they
|
||||
are read in non-recirculating networks:
|
||||
(a) the <TT>delwrite~</TT> and <TT>vd~</TT> objects might be executed in either
|
||||
the ``right" or the ``wrong" order; (b) the <TT>delwrite~</TT> object is inside the
|
||||
the "right" or the "wrong" order; (b) the <TT>delwrite~</TT> object is inside the
|
||||
<TT>pd delay-writer</TT>
|
||||
subpatch and the <TT>vd~</TT> object is inside the <TT>pd delay-reader</TT> one.
|
||||
Because of the audio connection between the two subpatches, the order of
|
||||
@ -116,8 +116,8 @@ the subpatch as a whole. So everything in the one subpatch happens before
|
||||
anything in the second one.)
|
||||
|
||||
<P>
|
||||
In this example, the ``right"
|
||||
and the ``wrong" way to make the comb filter have audibly different results.
|
||||
In this example, the "right"
|
||||
and the "wrong" way to make the comb filter have audibly different results.
|
||||
For delays less than 64 samples, the right hand side of the patch (using
|
||||
subpatches) gives the correct result, but the left hand side can't produce
|
||||
delays below the 64 sample block size.
|
||||
|
||||
@ -78,7 +78,7 @@ Section <A HREF="node108.html#sect7.network">7.3</A>.
|
||||
Using a variable, non-recirculating comb filter we
|
||||
take out odd harmonics, leaving only the even ones, which
|
||||
sound an octave higher. As before, the spectral envelope of the sound is
|
||||
roughly preserved by the operation, so we can avoid the ``chipmunk" effect we
|
||||
roughly preserved by the operation, so we can avoid the "chipmunk" effect we
|
||||
would have got by using speed change to do the transposition.
|
||||
|
||||
<P>
|
||||
@ -86,7 +86,7 @@ would have got by using speed change to do the transposition.
|
||||
<DIV ALIGN="CENTER"><A NAME="fig07.29"></A><A NAME="8278"></A>
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 7.29:</STRONG>
|
||||
An ``octave doubler" uses pitch information (obtained using
|
||||
An "octave doubler" uses pitch information (obtained using
|
||||
a <TT>fiddle~</TT> object) to tune a comb filter to remove the odd harmonics
|
||||
in an incoming sound.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
|
||||
@ -75,14 +75,14 @@ idea of a comb filter. Here we combine the input signal at four different
|
||||
time shifts (instead of two, as in the original non-recirculating comb filter),
|
||||
each at a different positive or negative gain. To do this, we insert the
|
||||
input signal into a delay line and tap it at three different points; the
|
||||
fourth ``tap" is the original, un-delayed signal.
|
||||
fourth "tap" is the original, un-delayed signal.
|
||||
|
||||
<P>
|
||||
|
||||
<DIV ALIGN="CENTER"><A NAME="fig07.30"></A><A NAME="8287"></A>
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 7.30:</STRONG>
|
||||
A ``shaker", a four-tap comb filter with randomly varying gains
|
||||
A "shaker", a four-tap comb filter with randomly varying gains
|
||||
on the taps.</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="591" HEIGHT="386" BORDER="0"
|
||||
|
||||
@ -136,7 +136,7 @@ common to use more than four recirculating delays; one reverberator in the Pd
|
||||
distribution uses sixteen. Finally, it is common to allow separate control of
|
||||
the amplitudes of the early echos (heard directly) and that of the
|
||||
recirculating signal; parameters such as these are thought to control
|
||||
sonic qualities described as ``presence", ``warmth", ``clarity", and so on.
|
||||
sonic qualities described as "presence", "warmth", "clarity", and so on.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
|
||||
@ -72,8 +72,8 @@ Pitch shifter</A>
|
||||
Example G09.pitchshift.pd (Figure <A HREF="#fig07.33">7.33</A>) shows a realization of the pitch shifter
|
||||
described in Section <A HREF="node115.html#sect7.pitchshift">7.9</A>. A delay line (defined and written
|
||||
elsewhere in the patch) is read using two <TT>vd~</TT> objects. The delay
|
||||
times vary between a minimum delay (provided as the ``delay" control) and the
|
||||
minimum plus a window size (the ``window" control.)
|
||||
times vary between a minimum delay (provided as the "delay" control) and the
|
||||
minimum plus a window size (the "window" control.)
|
||||
|
||||
<P>
|
||||
|
||||
@ -112,7 +112,7 @@ t = {2 ^ {h/12}} = {e ^ {\log(2)/12 \cdot h}} \approx {e ^ {0.05776 h}}
|
||||
</DIV>
|
||||
<BR CLEAR="ALL">
|
||||
<P></P>
|
||||
(called ``speed change" in the patch). The computation labeled ``tape
|
||||
(called "speed change" in the patch). The computation labeled "tape
|
||||
head rotation speed" is the same as the formula for <IMG
|
||||
WIDTH="13" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img112.png"
|
||||
|
||||
@ -103,11 +103,11 @@ the <IMG
|
||||
One customarily marks each of the <IMG
|
||||
WIDTH="21" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img898.png"
|
||||
ALT="$Q_i$"> with an ``o" (calling it a ``zero")
|
||||
ALT="$Q_i$"> with an "o" (calling it a "zero")
|
||||
and each of the <IMG
|
||||
WIDTH="19" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img899.png"
|
||||
ALT="$P_i$"> with an ``x" (a ``pole"); their names are borrowed
|
||||
ALT="$P_i$"> with an "x" (a "pole"); their names are borrowed
|
||||
from the field of complex analysis. A plot showing the poles and zeroes
|
||||
associated with a filter is unimaginatively called a <A NAME="10312"></A><I>pole-zero plot</I>.
|
||||
|
||||
|
||||
@ -107,7 +107,7 @@ the smallest <IMG
|
||||
ALT="$\tau$"> if any at which a signal repeats is called the signal's
|
||||
<A NAME="1175"></A><I>period</I>.
|
||||
In discussing periods of digital audio signals, we quickly run into the
|
||||
difficulty of describing signals whose ``period" isn't an integer, so that the
|
||||
difficulty of describing signals whose "period" isn't an integer, so that the
|
||||
equation above doesn't make sense. For now we'll effectively
|
||||
ignore this difficulty by supposing that the signal <IMG
|
||||
WIDTH="31" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
|
||||
@ -78,7 +78,7 @@ Section <A HREF="node78.html#sect5.waveshaping">5.3</A> almost always contain a
|
||||
This is inaudible, but, since it specifies electrical power that is sent
|
||||
to your speakers, its presence reduces the level of loudness you can
|
||||
reach without distortion. Another name for a constant signal component is
|
||||
<A NAME="10330"></A>``DC", meaning ``direct current".
|
||||
<A NAME="10330"></A>"DC", meaning "direct current".
|
||||
|
||||
<P>
|
||||
An easy and practical way to remove the zero-frequency component from an audio
|
||||
|
||||
@ -225,7 +225,7 @@ where <IMG
|
||||
ALT="$q$"> is the
|
||||
<A NAME="10499"></A><I>quality</I> of the filter, defined as the center frequency divided by
|
||||
bandwidth. Resonant filters are often specified in terms of the center
|
||||
frequency and ``q" in place of bandwidth.
|
||||
frequency and "q" in place of bandwidth.
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
|
||||
@ -109,7 +109,7 @@ gain is one at frequency 0.
|
||||
SRC="img1017.png"
|
||||
ALT="\fbox{ \texttt{bp\~}}">:
|
||||
<A NAME="10844"></A>resonant filter. The middle inlet takes control messages to set the center
|
||||
frequency, and the right inlet to set ``q".
|
||||
frequency, and the right inlet to set "q".
|
||||
|
||||
<P>
|
||||
<BR><!-- MATH
|
||||
|
||||
@ -82,7 +82,7 @@ using the <TT>vcf~</TT> object, introduced here:
|
||||
WIDTH="53" HEIGHT="39" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1022.png"
|
||||
ALT="\fbox{ \texttt{vcf\~}}">:
|
||||
<A NAME="10846"></A>a ``voltage controlled" band-pass filter,
|
||||
<A NAME="10846"></A>a "voltage controlled" band-pass filter,
|
||||
similar to <TT>bp~</TT>, but with a signal inlet to control center frequency.
|
||||
Both <TT>bp~</TT> and <TT>vcf~</TT> are one-pole resonant filters as
|
||||
developed in Section <A HREF="node143.html#sect8.twopolebandpass">8.3.4</A>; <TT>bp~</TT> outputs only
|
||||
@ -109,7 +109,7 @@ Example H04.filter.sweep.pd (Figure <A HREF="#fig08.29">8.29</A>) demonstrates u
|
||||
<TT>phasor~</TT> object (at top) creates a sawtooth wave to filter. (This is
|
||||
not especially good practice as we are not controlling the possibility of
|
||||
foldover; a better sawtooth generator for this purpose will be developed in
|
||||
Chapter 10.) The second <TT>phasor~</TT> object (labeled ``LFO for sweep")
|
||||
Chapter 10.) The second <TT>phasor~</TT> object (labeled "LFO for sweep")
|
||||
controls the time-varying center frequency. After adjusting to set the depth
|
||||
and a base center frequency (given in MIDI units), the result is converted into
|
||||
Hertz (using the <TT>tabread4~</TT> object) and passed to <TT>vcf~</TT> to set
|
||||
|
||||
12
node16.html
12
node16.html
@ -92,7 +92,7 @@ top to bottom they are:
|
||||
Message boxes, with a flag-shaped border, interpret the text as a message to
|
||||
send whenever the box is
|
||||
activated (by an incoming message or with a pointing device). The message in this
|
||||
case consists simply of the number ``21".
|
||||
case consists simply of the number "21".
|
||||
|
||||
<P>
|
||||
</LI>
|
||||
@ -104,10 +104,10 @@ when you load a patch. Object boxes may hold hundreds of different
|
||||
classes of objects--including oscillators, envelope generators, and other
|
||||
signal processing modules to be introduced later--depending on the text
|
||||
inside. In this example, the box holds an adder. In most Pd patches, the
|
||||
majority of boxes are of type ``object". The first word typed into an object
|
||||
majority of boxes are of type "object". The first word typed into an object
|
||||
box specifies its
|
||||
<A NAME="1223"></A><I>class</I>,
|
||||
which in this case is just ``+". Any additional (blank-space-separated) words
|
||||
which in this case is just "+". Any additional (blank-space-separated) words
|
||||
appearing in the box are called
|
||||
<A NAME="1225"></A><A NAME="1226"></A><I>creation arguments</I>,
|
||||
which specify the initial state of the object when it is created.
|
||||
@ -131,7 +131,7 @@ by typing values in it.
|
||||
</LI>
|
||||
</UL>
|
||||
In Figure
|
||||
<A HREF="#fig01.10">1.10</A> (part a) the message box, when clicked, sends the message ``21" to an
|
||||
<A HREF="#fig01.10">1.10</A> (part a) the message box, when clicked, sends the message "21" to an
|
||||
object box which adds 13 to it. The lines connecting the boxes carry data
|
||||
from one box to the next; outputs of boxes are on the bottom and inputs on top.
|
||||
|
||||
@ -167,8 +167,8 @@ object outputs messages, but the <TT>*~</TT> object
|
||||
outputs a signal. The inputs of a given object may or may not accept
|
||||
signals (but they always accept messages, even if only to convert them to
|
||||
signals). As a convention, object boxes with signal inputs or outputs
|
||||
are all named with a trailing tilde (``<TT>~</TT>") as in ``<TT>*~</TT>"
|
||||
and ``<TT>osc~</TT>".
|
||||
are all named with a trailing tilde ("<TT>~</TT>") as in "<TT>*~</TT>"
|
||||
and "<TT>osc~</TT>".
|
||||
|
||||
<P>
|
||||
<HR>
|
||||
|
||||
@ -115,7 +115,7 @@ at 1001 Hertz?
|
||||
</LI>
|
||||
<LI>A one-pole complex filter is excited by an impulse to make a tone at 1000
|
||||
Hertz, which decays 10 decibels in one second (at a sample rate of 44100
|
||||
Hertz). Where would you place the pole? What is the value of ``q"?
|
||||
Hertz). Where would you place the pole? What is the value of "q"?
|
||||
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
@ -155,7 +155,7 @@ Finally, we will develop some standard applications such as the phase vocoder.
|
||||
<LI><A NAME="tex2html3015"
|
||||
HREF="node180.html">Narrow-band companding: noise suppression</A>
|
||||
<LI><A NAME="tex2html3016"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<LI><A NAME="tex2html3017"
|
||||
HREF="node182.html">Phase vocoder time bender</A>
|
||||
</UL>
|
||||
|
||||
@ -71,7 +71,7 @@ Properties of Fourier transforms</A>
|
||||
|
||||
<P>
|
||||
In this section we will investigate what happens when we take the Fourier
|
||||
transform of a (complex) sinusoid. The simplest one is ``DC", the special
|
||||
transform of a (complex) sinusoid. The simplest one is "DC", the special
|
||||
sinusoid of frequency zero. After we derive the Fourier transform of that, we
|
||||
will develop some properties of Fourier transforms that allow us to apply the
|
||||
result to any other sinusoid.
|
||||
|
||||
@ -96,10 +96,10 @@ to find this out is just to run Pd on the relocated file and see what Pd
|
||||
complains it can't find.
|
||||
|
||||
<P>
|
||||
There should be dozens of files in the ``examples" folder, including the
|
||||
There should be dozens of files in the "examples" folder, including the
|
||||
examples themselves and the support files. The filenames of the examples
|
||||
all begin with a letter (A for chapter 1, B for 2, etc.) and a number, as
|
||||
in ``A01.sinewave.pd".
|
||||
in "A01.sinewave.pd".
|
||||
|
||||
<P>
|
||||
The example patches are also distributed with Pd, but beware that you may find
|
||||
|
||||
@ -137,7 +137,7 @@ is:
|
||||
Much ink has been spilled over the design of suitable window functions for
|
||||
particular situations, but here we will consider the simplest one, named the
|
||||
<A NAME="12504"></A><A NAME="12505"></A><I>Hann</I>
|
||||
window function (the name is sometimes corrupted to ``Hanning" in DSP circles).
|
||||
window function (the name is sometimes corrupted to "Hanning" in DSP circles).
|
||||
The Hann window is:
|
||||
<BR><P></P>
|
||||
<DIV ALIGN="CENTER">
|
||||
|
||||
@ -273,7 +273,7 @@ described in the following sections.)
|
||||
|
||||
<P>
|
||||
Finally we reconstruct an output signal. To do this we apply the inverse of
|
||||
the Fourier transform (labeled ``iFT" in the figure). As shown in
|
||||
the Fourier transform (labeled "iFT" in the figure). As shown in
|
||||
Section <A HREF="node166.html#sect9-IFT">9.1.2</A> this can be done by taking another Fourier transform,
|
||||
normalizing, and flipping the result backwards. In case the reconstructed
|
||||
window does not go smoothly to zero at its two ends, we apply the Hann
|
||||
@ -289,7 +289,7 @@ of four and space each window <IMG
|
||||
WIDTH="68" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1154.png"
|
||||
ALT="$H=N/4$"> samples past the previous one), we can
|
||||
reconstruct the original signal faithfully by omitting the ``modification"
|
||||
reconstruct the original signal faithfully by omitting the "modification"
|
||||
step. This is because the iFT undoes the work of the <IMG
|
||||
WIDTH="27" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
|
||||
SRC="img1155.png"
|
||||
|
||||
@ -86,8 +86,8 @@ Block diagram for narrow-band noise suppression by companding.</CAPTION>
|
||||
A
|
||||
<A NAME="12582"></A><I>compander</I>
|
||||
is a tool that amplifies a signal with a variable gain, depending on the
|
||||
signal's measured amplitude. The term is a contraction of ``compressor" and
|
||||
``expander". A compressor's gain decreases as the input level increases, so
|
||||
signal's measured amplitude. The term is a contraction of "compressor" and
|
||||
"expander". A compressor's gain decreases as the input level increases, so
|
||||
that the
|
||||
<A NAME="12584"></A><I>dynamic range</I>,
|
||||
that is, the overall variation in signal level, is reduced. An expander does
|
||||
|
||||
@ -73,7 +73,7 @@ Timbre stamping (classical vocoder)</A>
|
||||
<DIV ALIGN="CENTER"><A NAME="fig09.09"></A><A NAME="12598"></A>
|
||||
<TABLE>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 9.9:</STRONG>
|
||||
Block diagram for timbre stamping (AKA ``vocoding'').</CAPTION>
|
||||
Block diagram for timbre stamping (AKA "vocoding'').</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="257" HEIGHT="420" BORDER="0"
|
||||
SRC="img1172.png"
|
||||
|
||||
@ -80,7 +80,7 @@ Examples</A>
|
||||
<LI><A NAME="tex2html3230"
|
||||
HREF="node180.html">Narrow-band companding: noise suppression</A>
|
||||
<LI><A NAME="tex2html3231"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<LI><A NAME="tex2html3232"
|
||||
HREF="node182.html">Phase vocoder time bender</A>
|
||||
</UL>
|
||||
|
||||
@ -157,14 +157,14 @@ block of computation outputs the same first <IMG
|
||||
ALT="$N$"> samples of the table.
|
||||
|
||||
<P>
|
||||
In this example, the table ``$0-hann" holds a Hann window function
|
||||
In this example, the table "$0-hann" holds a Hann window function
|
||||
of length 512, in agreement with the specified block size. The signal
|
||||
to be analyzed appears (from the parent patch) via the <TT>inlet~</TT> object.
|
||||
The channel amplitudes (the output of the <TT>rfft~</TT> object) are reduced
|
||||
to real-valued magnitudes: the real and imaginary parts are squared separately,
|
||||
the two squares are added, and the result passed to the <TT>sqrt~</TT> object.
|
||||
Finally the magnitude is written (controlled by a connection not shown in
|
||||
the figure) via <TT>tabwrite~</TT> to another table, ``$0-magnitude", for
|
||||
the figure) via <TT>tabwrite~</TT> to another table, "$0-magnitude", for
|
||||
graphing.
|
||||
|
||||
<P>
|
||||
@ -234,7 +234,7 @@ A modification is applied, however: each channel is multiplied by a
|
||||
(positive real-valued) gain. The complex-valued amplitude for each channel is
|
||||
scaled by separately multiplying the real and imaginary parts by the gain. The
|
||||
gain (which depends on the channel) comes from another table, named
|
||||
``$0-gain". The result is a graphical equalization filter; by mousing in the
|
||||
"$0-gain". The result is a graphical equalization filter; by mousing in the
|
||||
graphical window for this table, you can design gain-frequency curves.
|
||||
|
||||
<P>
|
||||
|
||||
20
node180.html
20
node180.html
@ -52,7 +52,7 @@ original version by: Nikos Drakos, CBLU, University of Leeds
|
||||
SRC="index.png"></A>
|
||||
<BR>
|
||||
<B> Next:</B> <A NAME="tex2html3260"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<B> Up:</B> <A NAME="tex2html3254"
|
||||
HREF="node178.html">Examples</A>
|
||||
<B> Previous:</B> <A NAME="tex2html3248"
|
||||
@ -76,7 +76,7 @@ Narrow-band companding: noise suppression</A>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 9.16:</STRONG>
|
||||
Noise suppression as an example of narrow-band companding: (a)
|
||||
analysis and reconstruction of the signal; (b) computation of the
|
||||
``mask".</CAPTION>
|
||||
"mask".</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="663" HEIGHT="477" BORDER="0"
|
||||
SRC="img1227.png"
|
||||
@ -151,8 +151,8 @@ and otherwise replaced by zero.
|
||||
|
||||
<P>
|
||||
The mask itself is the product of the measured average noise in each channel,
|
||||
which is contained in the table ``$0-mask", multiplied by a value named
|
||||
``mask-level". The average noise is measured in a subpatch
|
||||
which is contained in the table "$0-mask", multiplied by a value named
|
||||
"mask-level". The average noise is measured in a subpatch
|
||||
(<TT>pd calculate-mask</TT>), whose contents are shown in part (b) of the
|
||||
figure. To compute the mask we are using two new new objects:
|
||||
|
||||
@ -186,7 +186,7 @@ the contents of a table, affecting up to the first <IMG
|
||||
|
||||
<P>
|
||||
The power averaging process is begun by sending a time duration in milliseconds
|
||||
to ``make-mask". The patch computes the equivalent number of blocks <IMG
|
||||
to "make-mask". The patch computes the equivalent number of blocks <IMG
|
||||
WIDTH="10" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
|
||||
SRC="img21.png"
|
||||
ALT="$b$">
|
||||
@ -214,11 +214,11 @@ stops evolving.
|
||||
|
||||
<P>
|
||||
To use this patch for classical noise suppression requires at least a few
|
||||
seconds of recorded noise without the ``signal" present. This is played into
|
||||
the patch, and its duration sent to ``make-mask", so that the
|
||||
``$0-mask" table holds the average measured noise power for each channel.
|
||||
seconds of recorded noise without the "signal" present. This is played into
|
||||
the patch, and its duration sent to "make-mask", so that the
|
||||
"$0-mask" table holds the average measured noise power for each channel.
|
||||
Then, making the assumption that the noisy part of the signal rarely exceeds 10
|
||||
times its average power (for example), ``mask-level" is set to 10, and the
|
||||
times its average power (for example), "mask-level" is set to 10, and the
|
||||
signal to be noise-suppressed is sent through part (a) of the patch. The noise
|
||||
will be almost all gone, but those channels in which the signal exceeds 20
|
||||
times the noise power will only be attenuated by 3dB, and higher-power channels
|
||||
@ -251,7 +251,7 @@ from any other one.)
|
||||
SRC="index.png"></A>
|
||||
<BR>
|
||||
<B> Next:</B> <A NAME="tex2html3260"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<B> Up:</B> <A NAME="tex2html3254"
|
||||
HREF="node178.html">Examples</A>
|
||||
<B> Previous:</B> <A NAME="tex2html3248"
|
||||
|
||||
10
node181.html
10
node181.html
@ -11,8 +11,8 @@ original version by: Nikos Drakos, CBLU, University of Leeds
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
|
||||
<TITLE>Timbre stamp (``vocoder")</TITLE>
|
||||
<META NAME="description" CONTENT="Timbre stamp (``vocoder")">
|
||||
<TITLE>Timbre stamp ("vocoder")</TITLE>
|
||||
<META NAME="description" CONTENT="Timbre stamp ("vocoder")">
|
||||
<META NAME="keywords" CONTENT="book">
|
||||
<META NAME="resource-type" CONTENT="document">
|
||||
<META NAME="distribution" CONTENT="global">
|
||||
@ -66,7 +66,7 @@ original version by: Nikos Drakos, CBLU, University of Leeds
|
||||
<!--End of Navigation Panel-->
|
||||
|
||||
<H2><A NAME="SECTION001373000000000000000">
|
||||
Timbre stamp (``vocoder")</A>
|
||||
Timbre stamp ("vocoder")</A>
|
||||
</H2>
|
||||
|
||||
<P>
|
||||
@ -99,7 +99,7 @@ are <IMG
|
||||
WIDTH="28" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1237.png"
|
||||
ALT="$c[k]$"> for the control source, we just
|
||||
``whiten" the filter input, multiplying by <IMG
|
||||
"whiten" the filter input, multiplying by <IMG
|
||||
WIDTH="46" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1238.png"
|
||||
ALT="$1/f[k]$">, and then stamp the control
|
||||
@ -113,7 +113,7 @@ done by limiting the whitening factor <IMG
|
||||
SRC="img1238.png"
|
||||
ALT="$1/f[k]$"> to a specified maximum value
|
||||
using the <TT>clip~</TT> object. The limit is controlled by the
|
||||
``squelch" parameter, which is squared and divided by 100 to map values
|
||||
"squelch" parameter, which is squared and divided by 100 to map values
|
||||
from 0 to 100 to a useful range.
|
||||
|
||||
<P>
|
||||
|
||||
18
node182.html
18
node182.html
@ -55,7 +55,7 @@ original version by: Nikos Drakos, CBLU, University of Leeds
|
||||
<B> Up:</B> <A NAME="tex2html3280"
|
||||
HREF="node178.html">Examples</A>
|
||||
<B> Previous:</B> <A NAME="tex2html3276"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<B> <A NAME="tex2html3282"
|
||||
HREF="node4.html">Contents</A></B>
|
||||
<B> <A NAME="tex2html3284"
|
||||
@ -84,7 +84,7 @@ Phase vocoder for time stretching and contraction.</CAPTION>
|
||||
<P>
|
||||
The phase vocoder usually refers to the general technique of passing from
|
||||
(complex-valued) channel amplitudes to pairs consisting of (real-valued)
|
||||
magnitudes and phase precession rates (``frequencies"), and back, as
|
||||
magnitudes and phase precession rates ("frequencies"), and back, as
|
||||
described in Figure <A HREF="node175.html#fig09.11">9.11</A> (Section <A HREF="node175.html#sect9.phase">9.5</A>). In
|
||||
Example I07.phase.vocoder.pd (Figure <A HREF="#fig09.18">9.18</A>), we use this technique with the
|
||||
specific aim of time-stretching and/or time-contracting a recorded sound
|
||||
@ -118,8 +118,8 @@ computation than a full-precision square root and reciprocal would.
|
||||
|
||||
<P>
|
||||
The process starts with a sub-patch, <TT>pd read-windows</TT>, that outputs
|
||||
two Hann-windowed blocks of the recorded sound, a ``back" one and a
|
||||
``front" one 1/4 window further forward in the recording. The window
|
||||
two Hann-windowed blocks of the recorded sound, a "back" one and a
|
||||
"front" one 1/4 window further forward in the recording. The window
|
||||
shown uses the two outputs of the sub-patch to guide the amplitude
|
||||
and phase change of each channel of its own output.
|
||||
|
||||
@ -142,7 +142,7 @@ After normalizing <IMG
|
||||
SRC="img1198.png"
|
||||
ALT="$S[m-1,k]$">, its complex conjugate (the normalized inverse)
|
||||
is multiplied by the windowed Fourier
|
||||
transform of the ``back" window <IMG
|
||||
transform of the "back" window <IMG
|
||||
WIDTH="32" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1199.png"
|
||||
ALT="$T[k]$">, giving the product <IMG
|
||||
@ -151,7 +151,7 @@ transform of the ``back" window <IMG
|
||||
ALT="$R[k]$"> of
|
||||
Page <A HREF="node176.html#sect9.phaserelationship"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
|
||||
SRC="crossref.png"></A>.
|
||||
Next, depending on the value of the parameter ``lock", the computed value of
|
||||
Next, depending on the value of the parameter "lock", the computed value of
|
||||
<IMG
|
||||
WIDTH="33" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1206.png"
|
||||
@ -163,9 +163,9 @@ is done using <TT>lrshift~</TT> objects, whose outputs are added into <IMG
|
||||
WIDTH="33" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1206.png"
|
||||
ALT="$R[k]$"> if
|
||||
``lock" is set to one, or otherwise not if it is zero.
|
||||
"lock" is set to one, or otherwise not if it is zero.
|
||||
The result is then normalized and multiplied by the Hann-windowed Fourier transform
|
||||
of the ``front" window (<IMG
|
||||
of the "front" window (<IMG
|
||||
WIDTH="37" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img1196.png"
|
||||
ALT="$T'[k]$">) to give <IMG
|
||||
@ -239,7 +239,7 @@ can be made using daisy-chained cross-fades.
|
||||
<B> Up:</B> <A NAME="tex2html3280"
|
||||
HREF="node178.html">Examples</A>
|
||||
<B> Previous:</B> <A NAME="tex2html3276"
|
||||
HREF="node181.html">Timbre stamp (``vocoder")</A>
|
||||
HREF="node181.html">Timbre stamp ("vocoder")</A>
|
||||
<B> <A NAME="tex2html3282"
|
||||
HREF="node4.html">Contents</A></B>
|
||||
<B> <A NAME="tex2html3284"
|
||||
|
||||
12
node19.html
12
node19.html
@ -73,7 +73,7 @@ Constant amplitude scaler</A>
|
||||
Example A01.sinewave.pd, shown in Figure <A HREF="#fig01.11">1.11</A>, contains essentially the
|
||||
simplest possible patch that makes a sound,
|
||||
with only three object boxes. (There are also comments, and two message
|
||||
boxes to turn Pd's ``DSP" (audio) processing on and off.) The three object boxes
|
||||
boxes to turn Pd's "DSP" (audio) processing on and off.) The three object boxes
|
||||
are:
|
||||
|
||||
<P>
|
||||
@ -144,20 +144,20 @@ consult the Pd documentation for details.
|
||||
<P>
|
||||
The two message boxes show a peculiarity in the way messages are parsed in
|
||||
message boxes. Earlier in Figure <A HREF="node16.html#fig01.10">1.10</A> (part a), the message
|
||||
consisted only of the number 21. When clicked, that box sent the message ``21"
|
||||
consisted only of the number 21. When clicked, that box sent the message "21"
|
||||
to its outlet and hence to any objects connected to it. In this current
|
||||
example, the text of the message boxes starts with a semicolon. This is a
|
||||
terminator between messages (so the first message is empty), after which the
|
||||
next word is taken as the name of the recipient of the following message. Thus
|
||||
the message here is ``dsp 1" (or ``dsp 0") and the message is to be sent, not
|
||||
the message here is "dsp 1" (or "dsp 0") and the message is to be sent, not
|
||||
to any connected objects--there aren't any anyway--but rather, to the object
|
||||
named ``pd". This particular object is provided invisibly by the Pd program
|
||||
named "pd". This particular object is provided invisibly by the Pd program
|
||||
and you can send it various messages to control Pd's global state, in this case
|
||||
turning audio processing on (``1") and off (``0").
|
||||
turning audio processing on ("1") and off ("0").
|
||||
|
||||
<P>
|
||||
Many more details about the control aspects of Pd, such as the above, are
|
||||
explained in a different series of example patches (the ``control examples") in
|
||||
explained in a different series of example patches (the "control examples") in
|
||||
the Pd release, but they will only be touched on here as necessary to
|
||||
demonstrate the audio signal processing techniques that are the subject of this
|
||||
book.
|
||||
|
||||
@ -98,7 +98,7 @@ jumps so that the result repeats from one period to the next.
|
||||
Example J03.pulse.width.mod.pd (not shown) combines two sawtooth waves, of opposite sign, with
|
||||
slightly different frequencies so that the relative phase changes
|
||||
continuously. Their sum is a rectangle wave whose width varies in time. This
|
||||
is known as pulse width modulation (``PWM").
|
||||
is known as pulse width modulation ("PWM").
|
||||
|
||||
<P>
|
||||
|
||||
|
||||
@ -75,7 +75,7 @@ Strategies for band-limiting sawtooth waves</A>
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 10.14:</STRONG>
|
||||
Alternative techniques for making waveforms with corners: (a) a
|
||||
triangle wave as the minimum of two line segments; (b) clipping a triangle wave to
|
||||
make an ``envelope".</CAPTION>
|
||||
make an "envelope".</CAPTION>
|
||||
<TR><TD><IMG
|
||||
WIDTH="617" HEIGHT="359" BORDER="0"
|
||||
SRC="img1377.png"
|
||||
@ -101,7 +101,7 @@ shape is used as in the previous example, and the falling shape differs only
|
||||
in that its phase is set so that it falls to zero at a controllable point (not
|
||||
necessarily at the end of the cycle as before). The <TT>clip~</TT> object prevents
|
||||
it from rising above 1 (so that, if the intersection of the two segments is
|
||||
higher than one, we get a horizontal ``sustain" segment), and also from falling
|
||||
higher than one, we get a horizontal "sustain" segment), and also from falling
|
||||
below zero, so that once the falling shape reaches zero, the output is zero for
|
||||
the rest of the cycle.
|
||||
|
||||
|
||||
@ -96,8 +96,8 @@ A03.line.pd; (c) A05.output.subpatch.pd.</CAPTION>
|
||||
WIDTH="77" HEIGHT="41" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img150.png"
|
||||
ALT="\fbox{ $ \mathrm{dbtorms} $}"> : Decibels to linear
|
||||
amplitude conversion. The ``RMS" is a misnomer; it should have been named
|
||||
``dbtoamp",
|
||||
amplitude conversion. The "RMS" is a misnomer; it should have been named
|
||||
"dbtoamp",
|
||||
since it really converts from decibels to any linear amplitude unit, be it
|
||||
RMS, peak, or other. An input of 100 dB is normalized to an output of 1.
|
||||
Values greater than 100 are fine (120 will give 10), but values less than or
|
||||
@ -116,7 +116,7 @@ one way or another to avoid using it.)
|
||||
|
||||
<P>
|
||||
The two number boxes are connected to the input and output of the
|
||||
<TT>dbtorms</TT> object. The input functions as a control; ``mouse" on it
|
||||
<TT>dbtorms</TT> object. The input functions as a control; "mouse" on it
|
||||
(click and drag upward or downward) to change the amplitude. It has been set to range from
|
||||
0 to 80; this is protection for your speakers and ears, and it's wise to build
|
||||
such guardrails into your own patches.
|
||||
|
||||
@ -1046,7 +1046,7 @@ Index</A>
|
||||
<DT><STRONG>in Pd</STRONG>
|
||||
<DD><A HREF="node49.html#3723">Control operations in Pd</A>
|
||||
</DL>
|
||||
<DT><STRONG>quality (``q'')</STRONG>
|
||||
<DT><STRONG>quality ("q'')</STRONG>
|
||||
<DD><A HREF="node149.html#10499">Impulse responses of recirculating</A>
|
||||
<DT><STRONG>real part of a complex number</STRONG>
|
||||
<DD><A HREF="node105.html#7764">Complex numbers</A>
|
||||
|
||||
@ -120,8 +120,8 @@ the beginning and end values of a segment in <TT>line~</TT>'s output.
|
||||
|
||||
<P>
|
||||
The treatment of <TT>line~</TT>'s right inlet is unusual among Pd objects in that
|
||||
it forgets old values; a message with a single number such as ``0.1" is
|
||||
always equivalent to the pair, ``0.1 0". Almost any other object will retain
|
||||
it forgets old values; a message with a single number such as "0.1" is
|
||||
always equivalent to the pair, "0.1 0". Almost any other object will retain
|
||||
the previous value for the right inlet, instead of resetting it to zero.
|
||||
|
||||
<P>
|
||||
|
||||
@ -81,10 +81,10 @@ have equal amplitudes.
|
||||
<P>
|
||||
The amplitude control in this example is taken care of by a new object called
|
||||
<TT>output~</TT>. This isn't a built-in object of Pd, but is itself a Pd patch
|
||||
which lives in a file, ``output.pd". (You can see the internals of
|
||||
which lives in a file, "output.pd". (You can see the internals of
|
||||
<TT>output~</TT> by opening the properties menu for the box and selecting
|
||||
``open".) You get two controls, one for amplitude in dB (100 meaning ``unit
|
||||
gain"), and a ``mute" button. Pd's audio processing is turned on automatically
|
||||
"open".) You get two controls, one for amplitude in dB (100 meaning "unit
|
||||
gain"), and a "mute" button. Pd's audio processing is turned on automatically
|
||||
when you set the output level--this might not be the best behavior in
|
||||
general, but it's appropriate for these example patches. The mechanism for
|
||||
embedding one Pd patch as an object box inside another is discussed in Section
|
||||
|
||||
20
node23.html
20
node23.html
@ -71,7 +71,7 @@ Conversion between frequency and pitch</A>
|
||||
|
||||
<P>
|
||||
Example A06.frequency.pd (Figure <A HREF="#fig01.13">1.13</A>) shows Pd's object for converting
|
||||
pitch to frequency units (<TT>mtof</TT>, meaning ``MIDI to frequency") and its
|
||||
pitch to frequency units (<TT>mtof</TT>, meaning "MIDI to frequency") and its
|
||||
inverse <TT>ftom</TT>. We also introduce two other object classes,
|
||||
<TT>send</TT> and <TT>receive</TT>.
|
||||
|
||||
@ -105,7 +105,7 @@ Conversion between pitch and frequency in A06.frequency.pd.</CAPTION>
|
||||
<A NAME="1405"></A><A NAME="1406"></A>convert MIDI pitch to frequency units according to the
|
||||
Pitch/Frequency Conversion Formulas (Page <A HREF="node11.html#eq-pitchmidi"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]"
|
||||
SRC="crossref.png"></A>). Inputs
|
||||
and outputs are messages (``tilde" equivalents of the two also exist,
|
||||
and outputs are messages ("tilde" equivalents of the two also exist,
|
||||
although like <TT>dbtorms~</TT> they're expensive in CPU time).
|
||||
The <TT>ftom</TT> object's output is -1500
|
||||
if the input is zero or negative; and likewise, if you give <TT>mtof</TT> -1500 or lower it outputs zero.
|
||||
@ -125,11 +125,11 @@ if the input is zero or negative; and likewise, if you give <TT>mtof</TT> -1500
|
||||
SRC="img157.png"
|
||||
ALT="\fbox{ $ \mathrm{r} $}">:
|
||||
<A NAME="1407"></A><A NAME="1408"></A>Receive messages non-locally.
|
||||
The <TT>receive</TT> object, which may be abbreviated as ``<TT>r</TT>",
|
||||
The <TT>receive</TT> object, which may be abbreviated as "<TT>r</TT>",
|
||||
waits for non-local messages to be sent by a <TT>send</TT> object (described below)
|
||||
or
|
||||
by a message box using redirection (the ``;" feature discussed in the
|
||||
earlier example, A01.sinewave.pd). The argument (such as ``frequency" and ``pitch"
|
||||
by a message box using redirection (the ";" feature discussed in the
|
||||
earlier example, A01.sinewave.pd). The argument (such as "frequency" and "pitch"
|
||||
in this example) is the name to which messages are sent. Multiple
|
||||
<TT>receive</TT> objects may share the same name, in which case any message
|
||||
sent to that name will go to all of them.
|
||||
@ -148,7 +148,7 @@ sent to that name will go to all of them.
|
||||
WIDTH="31" HEIGHT="33" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img159.png"
|
||||
ALT="\fbox{ $\mathrm{s}$\ }">:
|
||||
<A NAME="1409"></A><A NAME="1410"></A>The <TT>send</TT> object, which may be abbreviated as ``<TT>s</TT>", directs
|
||||
<A NAME="1409"></A><A NAME="1410"></A>The <TT>send</TT> object, which may be abbreviated as "<TT>s</TT>", directs
|
||||
messages to <TT>receive</TT> objects.
|
||||
|
||||
<P>
|
||||
@ -156,11 +156,11 @@ Two new properties of number boxes are used here. Earlier we've used them
|
||||
as controls or as displays; here, the two number boxes each function as both.
|
||||
If a number box gets a number in its inlet, it not only displays the number
|
||||
but also repeats the number to its output. However, a number box may also be sent
|
||||
a ``set" message, such as ``set 55" for example. This would set the value
|
||||
a "set" message, such as "set 55" for example. This would set the value
|
||||
of the number box to 55 (and display it) but not cause the output that would
|
||||
result from the simple ``55" message. In this case, numbers coming from the
|
||||
two <TT>receive</TT> objects are formatted (using message boxes) to read ``set 55" instead
|
||||
of just ``55", and so on. (The special word ``$1" is replaced by the
|
||||
result from the simple "55" message. In this case, numbers coming from the
|
||||
two <TT>receive</TT> objects are formatted (using message boxes) to read "set 55" instead
|
||||
of just "55", and so on. (The special word "$1" is replaced by the
|
||||
incoming number.) This is done because otherwise we would have an infinite
|
||||
loop: frequency would change pitch which would change frequency and so on
|
||||
forever, or at least until something broke.
|
||||
|
||||
@ -89,7 +89,7 @@ oscillators, effectively turning them on and off.
|
||||
|
||||
<P>
|
||||
Even when all four oscillators are combined (with the toggle switch in the
|
||||
``1" position), the result fuses into a single tone,
|
||||
"1" position), the result fuses into a single tone,
|
||||
heard at the pitch of the leftmost oscillator. In effect this patch sums a
|
||||
four-term Fourier series to generate a complex, periodic waveform.
|
||||
|
||||
|
||||
@ -77,7 +77,7 @@ a continuous stream at some sample rate. The sample rate isn't really a
|
||||
quality of the audio signal, but rather it specifies how fast the individual
|
||||
samples should flow into or out of the computer. But audio signals are at
|
||||
bottom just sequences of numbers, and in practice there is no requirement that
|
||||
they be ``played" sequentially. Another, complementary view is that
|
||||
they be "played" sequentially. Another, complementary view is that
|
||||
they can be stored in memory, and, later, they can be read back in any
|
||||
order--forward, backward, back and forth, or totally at random. An
|
||||
inexhaustible range of new possibilities opens up.
|
||||
@ -224,7 +224,7 @@ x[ \lfloor y[n] \rflo...
|
||||
<IMG
|
||||
WIDTH="44" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img173.png"
|
||||
ALT="$\lfloor y[n] \rfloor$"> means, ``the greatest integer not
|
||||
ALT="$\lfloor y[n] \rfloor$"> means, "the greatest integer not
|
||||
exceeding <IMG
|
||||
WIDTH="30" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img2.png"
|
||||
@ -246,7 +246,7 @@ same for <IMG
|
||||
ALT="$y[1]$"> and <IMG
|
||||
WIDTH="28" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img177.png"
|
||||
ALT="$z[1]$"> and so on. The ``natural" range for the input <IMG
|
||||
ALT="$z[1]$"> and so on. The "natural" range for the input <IMG
|
||||
WIDTH="30" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img2.png"
|
||||
ALT="$y[n]$">
|
||||
|
||||
14
node28.html
14
node28.html
@ -72,12 +72,12 @@ Sampling
|
||||
</H1>
|
||||
|
||||
<P>
|
||||
``Sampling"
|
||||
"Sampling"
|
||||
<A NAME="2203"></A>
|
||||
is nothing more than recording a live signal into a wavetable, and then later
|
||||
playing it out again. (In commercial samplers the entire wavetable is
|
||||
usually called a ``sample" but to avoid confusion we'll only use the word
|
||||
``sample" here to mean a single number in an audio signal.)
|
||||
usually called a "sample" but to avoid confusion we'll only use the word
|
||||
"sample" here to mean a single number in an audio signal.)
|
||||
|
||||
<P>
|
||||
At its simplest, a sampler is simply a wavetable oscillator, as was shown in
|
||||
@ -281,7 +281,7 @@ h[n] = 12 {{\log_2} \left \vert y[n] - y[n-1] \right \vert}
|
||||
</DIV>
|
||||
<BR CLEAR="ALL">
|
||||
<P></P>
|
||||
(Here the enclosing bars ``<IMG
|
||||
(Here the enclosing bars "<IMG
|
||||
WIDTH="7" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
|
||||
SRC="img202.png"
|
||||
ALT="$\vert$">" mean absolute value.)
|
||||
@ -361,7 +361,7 @@ at the beginning of each new cycle.
|
||||
|
||||
<P>
|
||||
It's well known that transposing a recording also transposes its timbre--this
|
||||
is the ``chipmunk" effect. Not only are any periodicities (such as might
|
||||
is the "chipmunk" effect. Not only are any periodicities (such as might
|
||||
give rise to pitch) transposed, but so are the frequencies of
|
||||
the overtones. Some timbres, notably those of vocal sounds, have characteristic
|
||||
frequency ranges in which overtones are stronger than other nearby ones.
|
||||
@ -378,7 +378,7 @@ wavetables periodically. In Section <A HREF="node27.html#sect2.oscillator">2.1<
|
||||
repeated quickly enough that the repetition gives rise to a pitch, say between
|
||||
30 and 4000 times per second, roughly the range of a piano. In the current
|
||||
section we assumed a wavetable one second long, and in this case
|
||||
``reasonable" transposition factors (less than four octaves up) would give rise
|
||||
"reasonable" transposition factors (less than four octaves up) would give rise
|
||||
to a rate of repetition below 30, usually much lower, and going down as low as
|
||||
we wish.
|
||||
|
||||
@ -506,7 +506,7 @@ location as the segment's midpoint, we first subtract <IMG
|
||||
<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2.5:</STRONG>
|
||||
A simple looping sampler, as yet with no amplitude control.
|
||||
There are inputs to control the frequency and the segment size and location.
|
||||
The ``-" operation is included if we wish the segment location to be specified
|
||||
The "-" operation is included if we wish the segment location to be specified
|
||||
as the segment's midpoint; otherwise we specify the location of the left
|
||||