Hi, Ah, the new flext is released, and it includes the workaround needed for compiling shaffy~ with g++:
flext 0.2.2:
- workaround for buggy gcc 3.0.4 RTTI implementation
So here they are, finally joined:
shabby~ and shaffy~ - waveshaping PD externals running on Max as well
- Who is shabby~?
shabby~ is a waveshaper using 11 Chebyshev polynoms to generate harmonics from an incoming sinewave. Each polynom will have a signal inlet to specify its amplitude in the signal. You can use shabby~ to have a decent additive synth that allows control over the harmonics in the course of a note at signal rate. But beware: it's not very fast.
shabby~ uses the flext C++ layer for Max/MSP and pd (pure data) externals available at http://www.parasitaere-kapazitaeten.net/Pd/ext/
- Who is shaffy~?
shaffy~ is shabby~'s little brother. He uses float inlets to scale the amplitudes of only 9 polynom harmonics because of Max compatibility. This makes it a lot faster than shabby~ and made some optimizations possible, but you can only update the polynom factors at message rate. That's okay for most things, but might be to slow for some applications.
You need at least flext version 0.2.2 for shaffy~ because it includes a needed workaround for g++.
Happy shaffying with the package including both externals at: http://footils.radio-worldwi.de/shabby-0.2.tgz
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
It compiled, but when i try to create a [shabby~] or [shaffy~] i get:
/usr/lib/pd/extra/shabby~.pd_linux: /usr/lib/pd/extra/shabby~.pd_linux: undefined symbol: _ZN9flext_obj8m_holderE shabby~ ... couldn't create /usr/lib/pd/extra/shaffy~.pd_linux: /usr/lib/pd/extra/shaffy~.pd_linux: undefined symbol: _ZN9flext_obj8m_holderE shaffy~ ... couldn't create pd: exiting
any ideas?
On Mon, 2002-04-15 at 03:53, Frank Barknecht wrote:
Hi, Ah, the new flext is released, and it includes the workaround needed for compiling shaffy~ with g++:
flext 0.2.2:
- workaround for buggy gcc 3.0.4 RTTI implementation
So here they are, finally joined:
shabby~ and shaffy~ - waveshaping PD externals running on Max as well
- Who is shabby~?
shabby~ is a waveshaper using 11 Chebyshev polynoms to generate harmonics from an incoming sinewave. Each polynom will have a signal inlet to specify its amplitude in the signal. You can use shabby~ to have a decent additive synth that allows control over the harmonics in the course of a note at signal rate. But beware: it's not very fast.
shabby~ uses the flext C++ layer for Max/MSP and pd (pure data) externals available at http://www.parasitaere-kapazitaeten.net/Pd/ext/
- Who is shaffy~?
shaffy~ is shabby~'s little brother. He uses float inlets to scale the amplitudes of only 9 polynom harmonics because of Max compatibility. This makes it a lot faster than shabby~ and made some optimizations possible, but you can only update the polynom factors at message rate. That's okay for most things, but might be to slow for some applications.
You need at least flext version 0.2.2 for shaffy~ because it includes a needed workaround for g++.
Happy shaffying with the package including both externals at: http://footils.radio-worldwi.de/shabby-0.2.tgz
Ciao,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Joschi hat gesagt: // Joschi wrote:
It compiled, but when i try to create a [shabby~] or [shaffy~] i get:
/usr/lib/pd/extra/shabby~.pd_linux: /usr/lib/pd/extra/shabby~.pd_linux: undefined symbol: _ZN9flext_obj8m_holderE shabby~ ... couldn't create /usr/lib/pd/extra/shaffy~.pd_linux: /usr/lib/pd/extra/shaffy~.pd_linux: undefined symbol: _ZN9flext_obj8m_holderE shaffy~ ... couldn't create pd: exiting
any ideas?
Not exactly ;(
Now, most probably this has to do with your compiler. flext-externals are very sensitive in regard to compilers. Which are you using? It actually has to be the same as the one you compiled PD and flext with. In my makefile, g++-3.0 is hardcoded. Maybe you have to change this. But I don't know, if shaffy~ and shabby~ can run with older compilers, I couldn't test this, because I have built my PD with gcc-3.0, as well.
I hope this can help..., but I'm not sure it does.
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi list,
what is the fastest way to get the sum from a list of integers ? actually i unpack the list and play around with the [+ ] ... wich causes to make big patch for nothing, whereas i suppose there may be somewhere somekind of list2sum object ... or maybe a better method ...
someone ? :)
thanks
stm
stm_sq^n wrote:
hi list,
what is the fastest way to get the sum from a list of integers ? actually i unpack the list and play around with the [+ ] ... wich causes to make big patch for nothing, whereas i suppose there may be somewhere somekind of list2sum object ... or maybe a better method ...
as far as i know, there is no [list2sum] (i would recommend simply [sum])
this is surely an overhead but: if you have lists of varying length you can use zexy's [mean], which gets (1/n)*sum(), and multiply it with the [length] of the list...
mfg.c.asdr IOhannes
Hello IOhannes,
Imz> if you have lists of varying length you can use zexy's Imz> [mean], which gets (1/n)*sum(), and multiply it with the [length] of the Imz> list...
thanks, it's much better this way than using the [unpack ] and [+ ] combo.
thanks !
stm
Hi Frank,
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".
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.
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/* .
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. 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?
Regards
Larry
[nbx] is new in pd 0.35 so i assume that shabby requires that version of pd.
On Sun, 21 Apr 2002, Larry Troxler wrote:
Hi Frank,
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".
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.
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/* .
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. 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?
Regards
Larry
Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi
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__
-
Frank Barknecht -
IOhannes m zmoelnig -
Joschi -
Josh Steiner
-
Larry Troxler -
stm_sq^n