Shabby~ (also flext) [long math]

[Frank Barknecht]

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__