Shabby~ (also flext) [long math]
Frank Barknecht
barknech at ph-cip.uni-koeln.de
Mon Apr 22 11:12:29 CEST 2002
Hi Larry,
Larry Troxler hat gesagt: // Larry Troxler wrote:
> What version of pd have you been developing shabby~ on? I tried it with
> pd-0.34.2 and it seems the help patch doesn't load - it can't create
> objects like "nbx".
"numberbox" was included in 0.35. It shouldn't be necessary for a working
patch, as long as you see the sliders in [pd controls]. The nbx's just
show the values of the sliders withouth patch cords.
> However it could be some strange gcc version problem. Rather than
> installing gcc 3.x, I built both flext and shabby~ with the Redhat gcc
> 2.96 after changing the makefiles to disable optimization (-O0). This is
> under of the assumption that the reason gcc 3.x is recommended is
> because of the optimization bugs in the earlier gcc. But I could be
> wrong, and I will soon go ahead and install gcc 3.x.
I could not get sha[bbff]y to work with anything less that 3.0, and
happens with all or a lot of flext externals: I wrote some very simple
flext-test-externals (dspobj~, pan~) that also failed to load.
So I built pd and flext with 3.0. OTOH a lot of older externals do not
load if I build them with gcc-3.0, most prominent example is GEM, but
I also could not load grantab. These externals build and load just
fine in a 3.0-compiled PD when I compile them with gcc-2.96.4.
This can really drive you crazy.
> A question about the install paths: I'm sorry to have not followed this
> discussion, and I guess I will have to look in the list archives. Has
> some decision been reached on a standard for pd paths? I ask this
> because until now I have no /usr/lib/pd/extra directory. Most things I
> install in /usr/local/pd/externs/* .
Oh yes, sha..y installs in pd/extra I'll change that in a next
release: I think externs is the usual place for externals not by
Miller, but there isn't a consensus about this (?)
> Finally, a question about what shabby~ does (realizing that if I had it
> running, I might not need to ask): I surmize that shabby~ mixes together
> the results of waveshaping synthesis on a number of polynomials, and
> that each inlet is the amplitude of an x-axis sine wave that is used for
> lookup in the respective polynomial.
So far all's correct. sha..y~ has a first inlet, that should get the
output of an [osc~] (== x) (but you can input other signals for glitch
sounds), the osc~-signal gets distorted by sending it through 9 or 11
Chebychev polynoms "as x" scaled by the values at the other inlets f1, f2,
f3,...
output =
f1 * 1
+ f2 * x
+ f3 * 2*pow(x,2) -1
+ ...
The f1,f2,... inlets can hold signals (shabby~) of floats (therefore
the mnemonic 'ff' in shaffy~) BTW: I'm looking for ways to make this
more effective. Even in shaffy~ I need to do a lot of
pow(x,y)-operations. If you have any ideas...
> But what I am confused about is the harmonic content of each of
> these polynomials (which of course depends on the amplitude of the
> driving sine wave, i.e. with waveshaping, the harmonic content is
> richer with higher driving amplitudes). Can you maybe clarify my
> muddled mind?
That process is described in Doge/Jerse "Computer Music" chapter
5.2C "Calculating an Output Spectrum from a Transfer Function"
Here's the rundown. If you could get to run the help patch: I
included a spectrum done with a fft analysis, where you can see the
results of changing the amplitude of the incoming osc~.
Let the transfer function be like above:
(1) output = f1 + f2*x + (f3*2*pow(x,2) - 1) + ...
Dodge and Jerse show, that you can calculate the resulting spectrum
with the help of a table based on Pascal's triangle:
divisor | h0 h1 h2 h3 h4
pow(x,0) 0.5 | 1
pow(x,1) 1 | 1
pow(x,2) 2 | 2 1
pow(x,3) 4 | 3 1
pow(x,4) 8 | 6 4 1
...
"This table shows the amplitudes of the harmonics produced by a term
in the polynominal when the amplitude of the driving sinusoid is 1"
(Dodge/Jerse) The true amplitude value has to be divided by the
divisor first. And the first harmonic here is in fact h0/2, don't ask
why, I didn't get that fully.
In our example this means:
f1*pow(x,0) produces [f1*h0] : 0.5 (?)
f2*pop(x,1) produces [f2*h1] : 1
f3*2*pop(x,1) produces [f3*2*(2*h0) + f3*2*h2] : 2
Adding this we get the strengths of the harmonics:
h0: f1:0.5 + f3*2*2:2 = 2*f1 + 2*f3
h1: f2
h2: f3*2:2 = f3
But x is in fact a*x with a being the amplitude of the osc~.
This gives:
(2) output = f1 + f2*a*x + f3*2*pow(a*x,2) - 1 + ...
= f1 + f2*a*x + f3*2*pow(a,2)*pow(x,2) - 1 + ...
If a==1 this produces above spectrum with the first, second and third
harmonics in certain amplitudes, just like three respectivley tuned
and scaled osc~'s. If "a" is changed, the changes in amplitude of the
harmonics go with the appropriate power of "a". If I'm now not totally
disturbed by all this, the correct resulting spectrum is:
f1*pow(a*x,0) produces [f1*(h0*1)] : 0.5 (?)
f2*pop(a*x,1) produces [f2*(h1*a)] : 1
f3*2*pop(a*x,1) produces [f3*2*(2*h0*1) + f3*2*( h2*pow(a,2) )] : 2
h0: f1:0.5 + f3*2*2:2 = 2*f1 + 2*f3
h1: f2 * a
h2: (f3*2*pow(a,2)):2 = f3 * pow(a,2)
So, even if I made mistakes in the math above (it's early in the
morning here...), basically this means, that the smaller a gets, the
smaller the contribution of the harmonics to the outgoing signal and
that decline goes in powers of the harmonics index.
And now, my mind is muddled as well...
Ciao,
--
Frank Barknecht _ _______footils__
More information about the Pd-list
mailing list