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__