Shabby~ (also flext) [long math]
barknech at ph-cip.uni-koeln.de
Mon Apr 22 11:12:29 CEST 2002
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,
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
h2: f3*2:2 = f3
But x is in fact a*x with a being the amplitude of the osc~.
(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...
Frank Barknecht _ _______footils__
More information about the Pd-list