[PD] is this a spectral gate?
Hello lllist, I am still pretty new at FFT things but I am having a lot of fun. I know Tom Erbe's soundhack has something called a "spectral gate" so I thought I'd give it a shot and try to make my own in Pd after reading about it. Doesn't sound all that great, it actually ends up sounding like a really low quality wma file or something :) Is this technically a spectral gate? I'm using [>~] from zexy which in my mind says, "Look at all of the frequencies in the block and only allow those which are above value x to pass through." I've attached the patch here - any info or guidance is much appreciated. Any sound that goes through it pretty much loses all definition and clarity - is there a fix for this? Kevin -- http://pocketkm.blogspot.com specgate.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
yeah i think you're distorting the daylights out of it. have a look at the help patch i03-resynthesis. it shows how to divide the signal so it doesn't max out crazily. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
on this topic, i would really love to know about more experiments and creations with fft usage. i have found that the sounds that are available with Max/Msp patches and the magnitude of VST plugins tend to have an amazing depth to the sounds and processing capabilities. alsa, i am committed to linux and bost these things are so out of reach. pd seems to have all the theory and capability to do the impressive fft audio processing but i find really nice examples difficult to find. i tend to get base level examples of what you have described.(wma files :). thanks On 2/20/07, hard off <[EMAIL PROTECTED]> wrote: yeah i think you're distorting the daylights out of it. have a look at the help patch i03-resynthesis. it shows how to divide the signal so it doesn't max out crazily. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, Kevin McCoy hat gesagt: // Kevin McCoy wrote: > I am still pretty new at FFT things but I am having a lot of fun. I know > Tom Erbe's soundhack has something called a "spectral gate" so I thought I'd > give it a shot and try to make my own in Pd after reading about it. Doesn't > sound all that great, it actually ends up sounding like a really low quality > wma file or something :) > > Is this technically a spectral gate? I'm using [>~] from zexy which in my > mind says, "Look at all of the frequencies in the block and only allow those > which are above value x to pass through." I've attached the patch here - > any info or guidance is much appreciated. Any sound that goes through it > pretty much loses all definition and clarity - is there a fix for this? I'm not really sure what spectral gate does, but you've probably seen doc/3.audio.examples/I03.resynthesis.pd which is a kind of equalizer or multiband-filter. Maybe you've taken this patch as a model for your patch. But then some things are wrong in your adaption. First: [tabreceive $0-hann] will not receive anything, because [table $0-hann] is missing. So it will only output zeros. Either remove the multiplication with $0-hann, or add the [pd Hann-window] to the patch. But the real (and imaginary) mistake is the actual "gating" with [>~]. If you open the fft~-help.pd file (Help on rfft~), and print~ what comes out of rfft~'s outlets, you will see something like this: real: 0.00016968 -4.6019e-07 -2.1632e-07 -3.2469e-07 -9.2026e-07 32 -7.499e-07 -3.2501e-07 -3.1411e-07 -9.6657e-07 -6.2494e-05 -1.4388e-06 -5.035e-07 -5.0472e-07 -1.665e-06 -2.3571e-05 -5.8313e-07 -7.5066e-08 -6.2174e-07 -2.1764e-06 -1.0339e-05 -1.8991e-06 -3.5305e-07 1.376e-07 -2.2529e-06 -4.486e-06 -4.1878e-07 -1.9073e-06 -5.2361e-07 -1.7626e-06 -2.8447e-06 -2.943e-07 -7.6485e-08 0000000 00000000 00000000 00000000 imaginary: 0-2.7462e-09 1.9217e-07 -1.4215e-06 -1.0745e-07 -0.00013828 1.4264e-07 -2.5163e-07 1.0069e-07 3.7871e-07 -5.0489e-06 2.0548e-06 -1.8181e-08 -4.5923e-07 1.5607e-07 -6.6416e-06 -2.0862e-07 -5.8076e-07 6.2139e-08 -3.0756e-07 -4.1732e-06 6.2431e-07 -2.9043e-07 -5.2873e-07 -2.2713e-07 -3.1568e-06 -1.1066e-07 -0 -2.0931e-07 -3.162e-07 -6.2198e-07 -2.3119e-07 00000000 00000000 00000000 00000000 Now if you clip this with [>~ 0.8] you will get a series of 0 and 1 in each of these numbers. It might sound funky, but it's not what you want to achieve. So lets first have a look at what [rfft~] does: It will give you two signals. One is called the real, the other the imaginary part, but lets forget about this for now and look at it from a bit afar: Generally a FFT will do a spectral analysis. It will calculate, what sine waves you need to add up to get the same signal as that played in the current signal block. Basically it will tell you the frequencies and phases (first and second inlets) and amplitudes of a lot of [osc~] objects that, if you add them all up, would resynthesize your current signal. (You cannot directly use these [osc~] objects to resynthesize what comes from rfft~ but lets for a moment assume that we could.) How many [osc~] objects you can control, will depend on the block-size: The FFT will generate control data for blocksize/2 oscillators. So with a blocksize of 64, you get frequencies, phase and amplitudes for 32 osc~s. Now for some deep mathematical reasons all these [osc~] objects have fixed tunings: They all are multiples (harmonics) of Samplerate/Blocksize. So it starts at f0 = 0 Hertz, the next [osc~] would have a frequency f1= 1 * SR/BS, the next at f2=2*SR/BS up to the final one: f_final = (BS/2) * SR/BS == SR/2 or the Nyquist-frequency. For a blocksize of 16 and a samplerate of 48000 Hz this would be: f0: 0 f1: 1 * 48000/16 = 3000 f2: 2 * 48000/16 = 6000 ... f32: 8 * 48000/16 = 24000 (Actually of course these are bs/2 + 1 frequencies, but 0 and Nyquist are special anyway so I thought I could cheat a bit. ;)) Because the frequencies are fixed and known, the rfft~ object doesn't need to specify them explicitly. It only needs to calculate the amplitude and the phase of every partial [osc~]. Now the tricky parts to understand are these: [rfft~] will not directly output the amplitudes and the phases, but this strange thing called real and imaginary part. These carry exactly the same information about amplitude and phase, but encoded a bit differently than you are probably used to from working with [osc~]: They are specified in a kind of polar coordinate system, where
Re: [PD] is this a spectral gate?
Hallo, sorry, I made some upside-down-errors: Frank Barknecht hat gesagt: // Frank Barknecht wrote: > phs = arctan(re/im) Should be: phs = arctan(im/re) > phs(x*re,x*im) = atan(x*re/x*im) = atan(re/im) = phs(re,im) And here as well: phs(x*re,x*im) = atan(x*im/x*re) = atan(im/re) = phs(re,im) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
wow! thanks for all that Frank!! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Clap clap clap! Bravo, that was brilliant. Let's add it to the wiki somewhere! ~Kyle On 2/20/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > Hallo, > Kevin McCoy hat gesagt: // Kevin McCoy wrote: > > > I am still pretty new at FFT things but I am having a lot of fun. I know > > Tom Erbe's soundhack has something called a "spectral gate" so I thought I'd > > give it a shot and try to make my own in Pd after reading about it. Doesn't > > sound all that great, it actually ends up sounding like a really low quality > > wma file or something :) > > > > Is this technically a spectral gate? I'm using [>~] from zexy which in my > > mind says, "Look at all of the frequencies in the block and only allow those > > which are above value x to pass through." I've attached the patch here - > > any info or guidance is much appreciated. Any sound that goes through it > > pretty much loses all definition and clarity - is there a fix for this? > > I'm not really sure what spectral gate does, but you've probably seen > doc/3.audio.examples/I03.resynthesis.pd which is a kind of equalizer > or multiband-filter. > > Maybe you've taken this patch as a model for your patch. But then some > things are wrong in your adaption. First: [tabreceive $0-hann] will > not receive anything, because [table $0-hann] is missing. So it will > only output zeros. Either remove the multiplication with $0-hann, or > add the [pd Hann-window] to the patch. > > But the real (and imaginary) mistake is the actual "gating" with [>~]. > If you open the fft~-help.pd file (Help on rfft~), and print~ what > comes out of rfft~'s outlets, you will see something like this: > > real: > 0.00016968 -4.6019e-07 -2.1632e-07 -3.2469e-07 -9.2026e-07 32 > -7.499e-07 -3.2501e-07 > -3.1411e-07 -9.6657e-07 -6.2494e-05 -1.4388e-06 -5.035e-07 -5.0472e-07 > -1.665e-06 -2.3571e-05 > -5.8313e-07 -7.5066e-08 -6.2174e-07 -2.1764e-06 -1.0339e-05 -1.8991e-06 > -3.5305e-07 1.376e-07 > -2.2529e-06 -4.486e-06 -4.1878e-07 -1.9073e-06 -5.2361e-07 -1.7626e-06 > -2.8447e-06 -2.943e-07 > -7.6485e-08 0000000 > 00000000 > 00000000 > 00000000 > imaginary: > 0-2.7462e-09 1.9217e-07 -1.4215e-06 -1.0745e-07 -0.00013828 > 1.4264e-07 -2.5163e-07 > 1.0069e-07 3.7871e-07 -5.0489e-06 2.0548e-06 -1.8181e-08 -4.5923e-07 > 1.5607e-07 -6.6416e-06 > -2.0862e-07 -5.8076e-07 6.2139e-08 -3.0756e-07 -4.1732e-06 6.2431e-07 > -2.9043e-07 -5.2873e-07 > -2.2713e-07 -3.1568e-06 -1.1066e-07 -0 -2.0931e-07 -3.162e-07 > -6.2198e-07 -2.3119e-07 > 00000000 > 00000000 > 00000000 > 00000000 > > Now if you clip this with [>~ 0.8] you will get a series of 0 and 1 in > each of these numbers. It might sound funky, but it's not what you > want to achieve. > > So lets first have a look at what [rfft~] does: It will give you two > signals. One is called the real, the other the imaginary part, but > lets forget about this for now and look at it from a bit afar: > > Generally a FFT will do a spectral analysis. It will calculate, what > sine waves you need to add up to get the same signal as that played in > the current signal block. Basically it will tell you the frequencies > and phases (first and second inlets) and amplitudes of a lot of [osc~] > objects that, if you add them all up, would resynthesize your current > signal. (You cannot directly use these [osc~] objects to resynthesize > what comes from rfft~ but lets for a moment assume that we could.) > > How many [osc~] objects you can control, will depend on the > block-size: The FFT will generate control data for blocksize/2 > oscillators. So with a blocksize of 64, you get frequencies, phase and > amplitudes for 32 osc~s. > > Now for some deep mathematical reasons all these [osc~] objects have > fixed tunings: They all are multiples (harmonics) of > Samplerate/Blocksize. So it starts at f0 = 0 Hertz, the next [osc~] > would have a frequency f1= 1 * SR/BS, the next at f2=2*SR/BS up to the > final one: f_final = (BS/2) * SR/BS == SR/2 or the Nyquist-frequency. > For a blocksize of 16 and a samplerate of 48000 Hz this would be: > > f0: 0 > f1: 1 * 48000/16 = 3000 > f2: 2 * 48000/16 = 6000 > ... > f32: 8 * 48000/16 = 24000 > > (Actually of course these are bs/2 + 1 frequencies, but 0 and Nyquist > are special anyway so I thought I could cheat a bit. ;)) > > Because the frequencies are fixed and known, the rfft~ object doesn't > need to specify them explicitly. It only needs to calculate the > amplitude and the phase of every partial [osc~]. > > Now the tricky parts to understand are these: > > [rfft~] will
Re: [PD] is this a spectral gate?
> reach. pd seems to have all the theory and capability to do the > impressive fft audio processing but i find really nice examples > difficult to find. i tend to get base level examples of what you have > described.(wma files :). > Check out the phase vocoder examples in the audioexamples, a use- and beautiful (imho) realworld application of FFT, changing pitch and speed of samples independently. Another application is a way of convolution for 2 signals by multiplying the spectra. Cheers, Malte -- Malte Steiner media art + development -www.block4.com- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
I wish there was an "fft for dumbies" ... or, I guess, some kind of fft "black boxes" to play with, where you don't need to understand the math. Frank's recent post completely lost me, though given a bit of study I can probably decode it. But, for instance, in Reaktor or Plogue Bidule, you can move stuff into fft, mess with it, and resynthesize, without having any idea what the hell the math is. In comparison, I really couldn't understand the PD fft examples at all, it's just been too many years since I had a math class. I hope to get back into the math soon and understand at least enough for the PD fft stuff, but I have a lot of coding and design work and tracks I have to finish, before I can do that. ~David On 2/20/07, Malte Steiner <[EMAIL PROTECTED]> wrote: > > > reach. pd seems to have all the theory and capability to do the > > impressive fft audio processing but i find really nice examples > > difficult to find. i tend to get base level examples of what you have > > described.(wma files :). > > > > Check out the phase vocoder examples in the audioexamples, a use- and > beautiful (imho) realworld application of FFT, changing pitch and speed > of samples independently. > > Another application is a way of convolution for 2 signals by multiplying > the spectra. > > Cheers, > > Malte > -- > Malte Steiner > media art + development > -www.block4.com- > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Wow, I heard of "fftease" before, but I had never actually looked carefully at it. That looks incredibly promising, thanks so much! I should probably start to look seriously at VASP too - I'm really starting to get more interested in PD for non-realtime sound design anyway, as opposed to a realtime tweaking environment. ~David On 2/21/07, Kevin McCoy <[EMAIL PROTECTED]> wrote: > David, > > I sympathize - what about the fftease package? I don't know anything > about it but it may have something like you described if I remember > correctly. I was really screwed on understanding FFT until I looked > at the VASP examples and then it made a little sense. The wonderful > thing about Pd is that you still don't always need to understand the > math, just playing with trial and error works too! Which would have > been fine for me except my patch sounded like poo, hence the post. > > Frank, > > When I got the mail I was like "damn, boy!" Thanks for the info, I > will go over it for the next couple of days and see if I can't get > something going. I really appreciate the time you put into that - > this is not the first time you've helped me out, and I am always > grateful. > > Kevin > > On 2/20/07, David Powers <[EMAIL PROTECTED]> wrote: > > I wish there was an "fft for dumbies" ... or, I guess, some kind of > > fft "black boxes" to play with, where you don't need to understand the > > math. Frank's recent post completely lost me, though given a bit of > > study I can probably decode it. > > > > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > > into fft, mess with it, and resynthesize, without having any idea what > > the hell the math is. In comparison, I really couldn't understand the > > PD fft examples at all, it's just been too many years since I had a > > math class. I hope to get back into the math soon and understand at > > least enough for the PD fft stuff, but I have a lot of coding and > > design work and tracks I have to finish, before I can do that. > > > > ~David > > > > On 2/20/07, Malte Steiner <[EMAIL PROTECTED]> wrote: > > > > > > > reach. pd seems to have all the theory and capability to do the > > > > impressive fft audio processing but i find really nice examples > > > > difficult to find. i tend to get base level examples of what you have > > > > described.(wma files :). > > > > > > > > > > Check out the phase vocoder examples in the audioexamples, a use- and > > > beautiful (imho) realworld application of FFT, changing pitch and speed > > > of samples independently. > > > > > > Another application is a way of convolution for 2 signals by multiplying > > > the spectra. > > > > > > Cheers, > > > > > > Malte > > > -- > > > Malte Steiner > > > media art + development > > > -www.block4.com- > > > > > > ___ > > > PD-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > ___ > > PD-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > -- > > > > http://pocketkm.blogspot.com > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
David, I sympathize - what about the fftease package? I don't know anything about it but it may have something like you described if I remember correctly. I was really screwed on understanding FFT until I looked at the VASP examples and then it made a little sense. The wonderful thing about Pd is that you still don't always need to understand the math, just playing with trial and error works too! Which would have been fine for me except my patch sounded like poo, hence the post. Frank, When I got the mail I was like "damn, boy!" Thanks for the info, I will go over it for the next couple of days and see if I can't get something going. I really appreciate the time you put into that - this is not the first time you've helped me out, and I am always grateful. Kevin On 2/20/07, David Powers <[EMAIL PROTECTED]> wrote: > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, where you don't need to understand the > math. Frank's recent post completely lost me, though given a bit of > study I can probably decode it. > > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > into fft, mess with it, and resynthesize, without having any idea what > the hell the math is. In comparison, I really couldn't understand the > PD fft examples at all, it's just been too many years since I had a > math class. I hope to get back into the math soon and understand at > least enough for the PD fft stuff, but I have a lot of coding and > design work and tracks I have to finish, before I can do that. > > ~David > > On 2/20/07, Malte Steiner <[EMAIL PROTECTED]> wrote: > > > > > reach. pd seems to have all the theory and capability to do the > > > impressive fft audio processing but i find really nice examples > > > difficult to find. i tend to get base level examples of what you have > > > described.(wma files :). > > > > > > > Check out the phase vocoder examples in the audioexamples, a use- and > > beautiful (imho) realworld application of FFT, changing pitch and speed > > of samples independently. > > > > Another application is a way of convolution for 2 signals by multiplying > > the spectra. > > > > Cheers, > > > > Malte > > -- > > Malte Steiner > > media art + development > > -www.block4.com- > > > > ___ > > PD-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- http://pocketkm.blogspot.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, David Powers hat gesagt: // David Powers wrote: > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, where you don't need to understand the > math. Frank's recent post completely lost me, Now I'm disappointed ... > though given a bit of study I can probably decode it. ... ah, and relieved a bit again. ;) > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > into fft, mess with it, and resynthesize, without having any idea what > the hell the math is. In comparison, I really couldn't understand the > PD fft examples at all, it's just been too many years since I had a > math class. The power of Pd of course is, that you can influence things on a much lower level than NI allows you to do in Reaktor - although I admit, that I only know Reaktor from screenshots. The downside is, that you have to dig deeper to make the most out of Pd. This is especially true for FFT applications. The actual FFT patches often are very simple and they contain just of a handful of objects. It's the knowledge hidden inside that makes them difficult to understand. While you can skip a lot of the math, you cannot do FFT in Pd without at least understanding what kind of data is generated by the two [rfft~] outlets. Because without understanding this, you cannot even "fool around" with the data in between [rfft~] and [rifft~] in a meaningful way. Anyway, to give you a blackbox maybe like in Reaktor, attached is a Spectral Delay GOP abstraction ready to be dropped into any glitch patch. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 0 0 820 636 10; #N canvas 227 106 775 691 fft-analysis 0; #X obj 20 126 *~; #X obj 19 61 inlet~; #X obj 20 150 rfft~; #X obj 41 102 tabreceive~ \$0-hann; #X obj 21 549 *~; #X obj 66 530 tabreceive~ \$0-hann; #X obj 21 476 rifft~; #X obj 21 581 outlet~; #X obj 43 320 wrap~; #X obj 22 344 -~; #X obj 22 410 /~ 44.1; #X obj 21 505 /~ 64; #X obj 21 292 tabreceive~ \$0-delay; #X obj 154 326 tabreceive~ \$0-feedback; #X obj 158 366 *~; #X obj 122 367 *~; #X obj 16 7 block~ 512 4; #X obj 22 372 *~ 512; #X text 246 443 read out the delay and feedbackarrays for; #X text 246 469 every audio block (= fft frame) and use the; #X text 247 491 integer value of each delay bin as multiplier; #X text 252 512 of the blocksize to calculate the pointer; #X text 250 533 back into the vd~s before resynthesis.; #X obj 201 385 samplerate~; #X obj 201 363 loadbang; #X msg 283 364 bang; #X obj 201 407 / 1000; #X obj 20 235 delwrite~ \$0-re 12000; #X obj 60 212 delwrite~ \$0-im 12000; #X obj 22 441 vd~ \$0-re; #X obj 119 441 vd~ \$0-im; #X text 275 211 write real and imaginary part into delay-buffer; #X obj 229 39 tabreceive~ \$0-gain; #X obj 230 68 *~; #X text 273 59 Just to show we're doing something \, we multiply each channel by a gain controlled by an array in the main window. The control is quartic-scaled for easy editing.; #X obj 231 94 *~; #X obj 19 185 *~; #X obj 61 185 *~; #X obj 300 175 print~; #X msg 316 148 bang; #X floatatom 297 127 5 0 0 0 - - -; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 36 0; #X connect 2 1 37 0; #X connect 3 0 0 1; #X connect 4 0 7 0; #X connect 5 0 4 1; #X connect 6 0 11 0; #X connect 8 0 9 1; #X connect 9 0 17 0; #X connect 10 0 29 0; #X connect 10 0 30 0; #X connect 11 0 4 0; #X connect 12 0 8 0; #X connect 12 0 9 0; #X connect 13 0 15 1; #X connect 13 0 14 1; #X connect 14 0 28 0; #X connect 15 0 27 0; #X connect 17 0 10 0; #X connect 23 0 26 0; #X connect 24 0 23 0; #X connect 25 0 23 0; #X connect 26 0 10 1; #X connect 29 0 6 0; #X connect 29 0 15 0; #X connect 30 0 6 1; #X connect 30 0 14 0; #X connect 32 0 33 0; #X connect 32 0 33 1; #X connect 33 0 35 0; #X connect 33 0 35 1; #X connect 35 0 37 1; #X connect 35 0 36 1; #X connect 36 0 27 0; #X connect 37 0 28 0; #X connect 39 0 38 0; #X restore 52 492 pd fft-analysis; #N canvas 35 66 600 441 Hann-window 0; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-hann 512 float 0; #X coords 0 1 511 0 200 120 1; #X restore 293 249 graph; #X msg 171 263 0; #X obj 65 312 osc~; #X obj 65 264 samplerate~; #X obj 65 335 *~ -0.5; #X obj 65 358 +~ 0.5; #X obj 57 383 tabwrite~ \$0-hann; #X text 279 241 1; #X text 272 359 0; #X text 288 372 0; #X obj 65 288 / 512; #X obj 57 241 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 336 221 Hann window; #X text 113 310 period 512; #X text 90 215 recalculate Hann; #X text 125 230 window table; #X obj 57 146 loadbang; #X msg 79 179 \; pd dsp 1; #X text 40 27 The Hann window is now recomputed on 'loadbang' to make the file smaller (it doesn't have to be saved with the array.); #X text 474 375 511; #X connect 1 0 2 1; #X connect 2 0 4 0; #X connect 3 0 10 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 10 0 2 0; #X connect 11 0 3 0; #X connect 11 0 1 0; #X connect 11 0 6 0; #X connect 16 0 11 0; #X connect 16 0 17 0; #X restore 170 493 pd Hann-window; #N canvas
Re: [PD] is this a spectral gate?
Frank, OK I was able to look at this sooner than I expected (can't sleep!). Thank you *so* much. It makes perfect sense now!! Even though I don't understand their basis completely, those formulas for amp/phase really help. I can't wait to do some insane stuff, and of course I will post my results to the list. On a second note, I don't understand why basic FFT is thought of as being "advanced". I think other things are much more difficult to understand! Let's do as Kyle suggested and get this on the community site somewhere maybe with some images of arrays to clarify? Vasp was such a help to me because I could look at the arrays after the calcs were done. Thanks again - I owe you a beer if we ever meet. K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, Kevin McCoy hat gesagt: // Kevin McCoy wrote: > Let's do as Kyle suggested and get this on the community > site somewhere maybe with some images of arrays to clarify? Hm, seems my mail from yesterday git lost: I already put it on my site here: http://footils.org/cms/show/60 including some corrections. I guess I'll add some images to that the next day as well and clarify stuff a bit more. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
fftease covers most popular spectral manipulation goodies. Originally by Eric Lyon and ported to pd by Thomas Grill, IIRC. ./MiS "David Powers" <[EMAIL PROTECTED]> writes: > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, where you don't need to understand the > math. Frank's recent post completely lost me, though given a bit of > study I can probably decode it. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
David Powers wrote: > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, I started my fftadventure this way, using the phase vocoder examples and embed them into my patches. I think meanwhile there is a pvoc object out to simplify things but didnt checked out yet. Funny is the catch up the commercial vendors play, having these techniques later in nice packages like Roland V-Synth and their so called elastic audio (I love marketing), long after we have this available here, but whom I tell this... Cheers, Malte -- Malte Steiner media art + development -www.block4.com- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
This looks sweet, thanks Frank! Hoping to have a play with this as soon as I get to do some actual music making later this week. By the way, I thought I'd clarify what I meant with the example of Plogue Bidule. The website invites one to: "Transform audio in the spectral domain, with Bidule's FFT modules. Time domain audio is split into two types of data, frequencies and magnitudes, which can be manipulated using a wide variety of spectral bidules." http://www.plogue.com/img/Spectral.png So basically, in most of the "simple" fft software, they split the signal into freq and amplitude. You can see in the screenshot this is represented by yellow and orange connectors, and they have specific objects so you can play with a whole bunch of crazy transformations on both freq and amp, and then you can resynthesize it back with an inverse fft module. I see that I can also get the freq and amplitude info from PD's fft, once I'm awake enough to follow your math anyway! But I'm wondering where the phase comes in exactly - in Plogue I'm assuming the phases are somehow calculated auto-magically? They DO let you set the blocksize of the signal with the fft. Also, how does this relate to [fiddle~], because fiddle I understand, it gives me a fundamental freq and the amplitude of some number of harmonics, and I could take that info (for instance) to resynthesize stuff in some additive synth. ~David On 2/21/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > Hallo, > David Powers hat gesagt: // David Powers wrote: > > > I wish there was an "fft for dumbies" ... or, I guess, some kind of > > fft "black boxes" to play with, where you don't need to understand the > > math. Frank's recent post completely lost me, > > Now I'm disappointed ... > > > though given a bit of study I can probably decode it. > > ... ah, and relieved a bit again. ;) > > > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > > into fft, mess with it, and resynthesize, without having any idea what > > the hell the math is. In comparison, I really couldn't understand the > > PD fft examples at all, it's just been too many years since I had a > > math class. > > The power of Pd of course is, that you can influence things on a much > lower level than NI allows you to do in Reaktor - although I admit, > that I only know Reaktor from screenshots. The downside is, that you > have to dig deeper to make the most out of Pd. This is especially true > for FFT applications. The actual FFT patches often are very simple and > they contain just of a handful of objects. It's the knowledge hidden > inside that makes them difficult to understand. > > While you can skip a lot of the math, you cannot do FFT in Pd without > at least understanding what kind of data is generated by the two > [rfft~] outlets. Because without understanding this, you cannot even > "fool around" with the data in between [rfft~] and [rifft~] in a > meaningful way. > > Anyway, to give you a blackbox maybe like in Reaktor, attached is a > Spectral Delay GOP abstraction ready to be dropped into any glitch > patch. > > Ciao > -- > Frank Barknecht _ __footils.org_ __goto10.org__ > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On 2/21/07, David Powers <[EMAIL PROTECTED]> wrote: > I see that I can also get the freq and amplitude info from PD's fft, > once I'm awake enough to follow your math anyway! But I'm wondering > where the phase comes in exactly - in Plogue I'm assuming the phases > are somehow calculated auto-magically? They DO let you set the > blocksize of the signal with the fft. Forgot to mention: in Bidule, they do also let you change the windowing settings for the fft and inverse-fft, it's another built-in part of the module. And from reading your tutorial another time, it's slowly making more sense, I think it's the phase stuff that I wasn't taking into account, has been confusing me. ~David ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
This looks sweet, thanks Frank! Hoping to have a play with this as soon as I get to do some actual music making later this week Hey guys, sorry I arrived a little late to the thread Frank, did you post an example of the FFT patch that you explained? If so, would you mind posting it again? :-) Thanks, Jared ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
jared wrote: > Hey guys, sorry I arrived a little late to the thread > > > > Frank, did you post an example of the FFT patch that you explained? > > > > If so, would you mind posting it again? J all postings are archived at http://lists.puredata.info there you can search what people have said in the past years as well as getting all the attachments. fmga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Great, thanks. I wasn't sure if it was just a quick patch that he posted via the list. -Original Message- From: IOhannes m zmoelnig [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 7:38 PM To: jared Cc: 'David Powers'; pd-list@iem.at Subject: Re: [PD] is this a spectral gate? jared wrote: > Hey guys, sorry I arrived a little late to the thread > > > > Frank, did you post an example of the FFT patch that you explained? > > > > If so, would you mind posting it again? J all postings are archived at http://lists.puredata.info there you can search what people have said in the past years as well as getting all the attachments. fmga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, jared hat gesagt: // jared wrote: > This looks sweet, thanks Frank! Hoping to have a play with this as > soon as I get to do some actual music making later this week > > Hey guys, sorry I arrived a little late to the thread > > Frank, did you post an example of the FFT patch that you explained? They were attached to the mail, and they are also linked from here: http://footils.org/cms/show/60 in slightly update versions. The other patch I'm talking about is I03.resynthesis.pd from the audio.examples Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, David Powers hat gesagt: // David Powers wrote: > This looks sweet, thanks Frank! Hoping to have a play with this as > soon as I get to do some actual music making later this week. By the > way, I thought I'd clarify what I meant with the example of Plogue > Bidule. The website invites one to: "Transform audio in the spectral > domain, with Bidule's FFT modules. Time domain audio is split into two > types of data, frequencies and magnitudes, which can be manipulated > using a wide variety of spectral bidules." > http://www.plogue.com/img/Spectral.png Funny: That image looks like it does exactly the same as the specdelay~.pd patch I posted. The only difference is that the Bin_Delay module in Bidule is two objects in Pd: delwrite~ and vd~. ;) > So basically, in most of the "simple" fft software, they split the > signal into freq and amplitude. You can see in the screenshot this is > represented by yellow and orange connectors, and they have specific > objects so you can play with a whole bunch of crazy transformations on > both freq and amp, and then you can resynthesize it back with an > inverse fft module. Yes, the same principle is in use in Pd as well, only that instead of phase and amplitude (often also called "magnitude") you get "real" and "imaginary" data in Pd. But this is only a different point of view on the same thing: one is a "rectangular" view the other is "polar". But you can convert between both views back and forth. The DSP-Guide has a nicer explanation of the conversion: http://www.dspguide.com/ch8/8.htm Polar and rectangular (or cartesian) is just expressing the same thing with different words. It's like saying: * go left 4 feet and straight ahead another 4 feet versus saying: * go 5.65 feet in a 135 degree diagonal direction. Both instructions will let you end in the same spot, although they use completely different numbers: o | | | |x o \ \ \ \x Ah, how I love ASCII! > I see that I can also get the freq and amplitude info from PD's fft, > once I'm awake enough to follow your math anyway! But I'm wondering > where the phase comes in exactly - in Plogue I'm assuming the phases > are somehow calculated auto-magically? Maybe they are using the formulas I gave in my little guide. Really, re/im vs. phs/amp is just a conversion. I guess, the FFT_0 module in Bidule has phase information in its left outlet and amplitude info in the right, orange path. As you can see in the screenshot the phase info in Bidule is passed practically unchanged (only delayed a bit), because the operations like gain or filtering only work on amplitudes: They multiply the amplitudes. This doesn't affect the phases at all. It's similar with Pd's real/imaginary view on the issue. In fact for pure amplitde scaling you don't even need to convert from re/im to phase/amplitude, you can just multiply the re/im data directly with something to scale the amplitudes. (Because phase information is not affected by gain changes.) However you need to multiply both signal paths to actually keep the phases unchanged. See I03.resynthesis.pd for this in action. > They DO let you set the blocksize of the signal with the fft. Also, > how does this relate to [fiddle~], because fiddle I understand, it > gives me a fundamental freq and the amplitude of some number of > harmonics, and I could take that info (for instance) to resynthesize > stuff in some additive synth. fiddle works a bit differently, but it will not give enough information to make a clean resynthesis. Remember: An FFT on a blocksize of 1024 will give you 1024/2 = 512 resynthesis channels, or 512 virtual "oscillators". fiddle~ basically only gives one frequency. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On 2/21/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > fiddle works a bit differently, but it will not give enough > information to make a clean resynthesis. Remember: An FFT on a > blocksize of 1024 will give you 1024/2 = 512 resynthesis channels, or > 512 virtual "oscillators". fiddle~ basically only gives one frequency. > Aha, okay. I'm really beginning to understand this more, everything you said made things much more clear to me. Oh, and just to clarify: I think you mean that [fiddle~] will give you more than one frequency, but all the additional freqs are harmonics of one fundamental frequency - so you can get timbre information about a single note melody, at least I had some success doing this in experiments, and resynthesizing with an additive bank of [osc~]... Not, by any means, a super-accurate resynthesis, but I was using it more to do timbre morphs rather than any accurate representation. ~David ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Frank Barknecht wrote: >> So basically, in most of the "simple" fft software, they split the >> signal into freq and amplitude. You can see in the screenshot this is >> represented by yellow and orange connectors, and they have specific >> objects so you can play with a whole bunch of crazy transformations on >> both freq and amp, and then you can resynthesize it back with an >> inverse fft module. >> > > Yes, the same principle is in use in Pd as well, only that instead of > phase and amplitude (often also called "magnitude") you get "real" and > "imaginary" data in Pd. But this is only a different point of view on > the same thing: one is a "rectangular" view the other is "polar". But > you can convert between both views back and forth. The DSP-Guide has > a nicer explanation of the conversion: > http://www.dspguide.com/ch8/8.htm > what is the advantage of spitting out these values in polar coords? -- tasty electronic music vittles -- bluevitriol.com the only music blog you need-- playtherecords.com you are the dj. interactive music -- improbableorchestra.com random observations of the bizarre -- vitriolix.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On Tue, Feb 20, 2007 at 12:54:21PM +0100, Frank Barknecht wrote: > This means, that resynthesizing this signal at SR=48000 would be > similar to using oscillators like this: > > [osc~ 0] > | > [*~ 4.4602] > > [osc~ 6000] > | > [*~ 1.1871] > > [osc~ 12000] > | > [*~ 0.62254] > > [osc~ 18000] > | > [*~ 0.47394] > > ... > > and so on (Note that without normalizing these values are to loud.) > > However: All these oscillators would also need to have their phases > set accordingly, so you cannot just use above oscillator bank directly > in real life. Can't you use [osc~]'s right inlet to accomplish that? Anyway, I've always seen spectral modifiers that work on the amplitude data only. What happens if you work on the phase data only? I mean, what does it sound like? I guess I should just try it. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
osc~'s right inlet only takes data, if I'm correct. k On 2/21/07, Chris McCormick <[EMAIL PROTECTED]> wrote: > On Tue, Feb 20, 2007 at 12:54:21PM +0100, Frank Barknecht wrote: > > This means, that resynthesizing this signal at SR=48000 would be > > similar to using oscillators like this: > > > > [osc~ 0] > > | > > [*~ 4.4602] > > > > [osc~ 6000] > > | > > [*~ 1.1871] > > > > [osc~ 12000] > > | > > [*~ 0.62254] > > > > [osc~ 18000] > > | > > [*~ 0.47394] > > > > ... > > > > and so on (Note that without normalizing these values are to loud.) > > > > However: All these oscillators would also need to have their phases > > set accordingly, so you cannot just use above oscillator bank directly > > in real life. > > Can't you use [osc~]'s right inlet to accomplish that? > > Anyway, I've always seen spectral modifiers that work on the amplitude > data only. What happens if you work on the phase data only? I mean, what > does it sound like? I guess I should just try it. > > Best, > > Chris. > > --- > [EMAIL PROTECTED] > http://mccormick.cx > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- http://pocketkm.blogspot.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On Wed, Feb 21, 2007 at 08:11:01PM -0600, Kevin McCoy wrote: > osc~'s right inlet only takes data, if I'm correct. Exactly. It takes a message to set the phase, if I remember correctly. Wait, I'm wrong. It only resets the phase according to the help file. I wonder how hard it would be to make the number at the right inlet actually set the phase. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: > Can't you use [osc~]'s right inlet to accomplish that? For one, it's a message inlet, but more importantly: The channels of a FFT come as (the first half of the) samples in a sample block. You'd need to filter out the single samples to get control data for a single osc and that is very unpractical. But of course it's interesting to try, maybe just for a handful of oscillators. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote: > what is the advantage of spitting out these values in polar coords? According to the DSP-Guide it this: When should you use rectangular notation and when should you use polar? Rectangular notation is usually the best choice for calculations, such as in equations and computer programs. In comparison, graphs are almost always in polar form. As shown by the previous example, it is nearly impossible for humans to understand the characteristics of a frequency domain signal by looking at the real and imaginary parts. In a typical program, the frequency domain signals are kept in rectangular notation until an observer needs to look at them, at which time a rectangular-to-polar conversion is done. http://www.dspguide.com/ch8/8.htm Probably Miller thinks of Pd primarily as a tool for calculations so he kept the re/im representation. I also think, that the algorithm to calculate the Fourier transform, the Fast-FT or FFT, generates re/im pairs, so skipping the final conversion to polar unless necessary is faster. But I need to verify this. Maybe some DSP expert (Chuck?) can confirm this? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Yes, this is true. For many FFT based effects (like spectral gates), you don't really need to convert completely to polar (this conversion can be more expensive than the FFT). For a spectral gate, just calculate the amplitude from real and imag, make your gate decision based on the amplitude and threshold, and then apply the same gain reduction to both real and imag. Add attack and release to the gate-gain for smoother results. Or even quicker, avoid the sqrt in amplitude calculation, and use a squared threshold to compare against the squared amplitude. On Feb 21, 2007, at 11:33 PM, Frank Barknecht wrote: > I also think, that the algorithm to > calculate the Fourier transform, the Fast-FT or FFT, generates re/im > pairs, so skipping the final conversion to polar unless necessary > is faster. - - - - - tom erbe ~ [EMAIL PROTECTED] ~ studio director ~ ucsd department of music ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
> When should you use rectangular notation and when should you use > polar? Addition vs. Multiplication, of course Addition must be done in rectangular coordinates a+bi + c+di=(a+c) + (b+d)i which we cannot do in polar coordinates, we have to convert back to rect. coords Multiplication is simpler in polar coordinates (a+bi) * (c+di)=(a*c-b*d) + (a*d+b*c)i vs. polar coordinates: r1*e^(a*i) * r2*e^(b*i)=r1*r2*e^((a+b)*i) it's simpler in polar coordinates--requires fewer calculations > Rectangular notation is usually the best choice for > calculations, such as in equations and computer programs. This is also true for the FFT. FFT is just a convenient factorization of the fourier transform, that speeds up computations from O(N^2) to O(N*log(N)). The fourier transform consists of multiplying and adding complex numbers (a complex valued matrix equation), so the numbers should be kept in rect. form for the sake of doing addition. Plus, of course, we have no native data types in C for doing complex multiplication. Fortran is another thing; it even works with complex vectors. In C, you have to write the loop and write the whole equation for doing complex multiplication. In fortran, you just say x*y. Multiply this matrix, A*bFortran says, yes, sir. (Fortran 90, at least, not sure about Fortran 77) It is nearly pointless to convert to polar coordinates just for the sake of doing multiplication, unless you have a lot of things you want to multiply. I think we should have some simple abstractions to do the simple operations for complex multiplication, division, conjugate, addition, subtraction, probably several more. I don't know why I haven't done it yet. *Every single time I have to do one of the butterfly calculations on a pair of fft's, I have to write it down on paper first.* :) I agree that the polar form is easier to read, and the multiplication of two complex numbers shows very clearly what happens. The amplitudes multiply, and the phases add. Chuck ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On 2/21/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > Anyway, to give you a blackbox maybe like in Reaktor, attached is a > Spectral Delay GOP abstraction ready to be dropped into any glitch > patch. Thanks Frank this little black box is wonderful. i think pd would be really attractive to more people of there were more patches like this around. sure it is simplistic to want "plugins" without knowing anything about the math behind it, but having gadgets to mess with in this way allows new users and intermediate pders real tools to play with and perform with from the outset, as well as tools to investigate and hack. (i guess i'm one without a mathmatical bone in my body) the help examples that come with pd are great but limited. would be awesome to see more little blackboxes that sound this great, cheers! > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
oh and thanks for the fft tute to frank! On 2/23/07, we are <[EMAIL PROTECTED]> wrote: > On 2/21/07, Frank Barknecht <[EMAIL PROTECTED]> wrote: > > > Anyway, to give you a blackbox maybe like in Reaktor, attached is a > > Spectral Delay GOP abstraction ready to be dropped into any glitch > > patch. > > Thanks Frank > this little black box is wonderful. i think pd would be really > attractive to more people of there were more patches like this around. > sure it is simplistic to want "plugins" without knowing anything about > the math behind it, but having gadgets to mess with in this way allows > new users and intermediate pders real tools to play with and perform > with from the outset, as well as tools to investigate and hack. (i > guess i'm one without a mathmatical bone in my body) the help examples > that come with pd are great but limited. > would be awesome to see more little blackboxes that sound this great, cheers! > > > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
On Wed, 21 Feb 2007 10:30:28 +0100 Frank Barknecht <[EMAIL PROTECTED]> wrote: A couple of little improvements to specdelay to make it more useful as an audio effect. > Hallo, > David Powers hat gesagt: // David Powers wrote: > > > I wish there was an "fft for dumbies" ... or, I guess, some kind of > > fft "black boxes" to play with, where you don't need to understand the > > math. Frank's recent post completely lost me, > > Now I'm disappointed ... > > > though given a bit of study I can probably decode it. > > ... ah, and relieved a bit again. ;) > > > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > > into fft, mess with it, and resynthesize, without having any idea what > > the hell the math is. In comparison, I really couldn't understand the > > PD fft examples at all, it's just been too many years since I had a > > math class. > > The power of Pd of course is, that you can influence things on a much > lower level than NI allows you to do in Reaktor - although I admit, > that I only know Reaktor from screenshots. The downside is, that you > have to dig deeper to make the most out of Pd. This is especially true > for FFT applications. The actual FFT patches often are very simple and > they contain just of a handful of objects. It's the knowledge hidden > inside that makes them difficult to understand. > > While you can skip a lot of the math, you cannot do FFT in Pd without > at least understanding what kind of data is generated by the two > [rfft~] outlets. Because without understanding this, you cannot even > "fool around" with the data in between [rfft~] and [rifft~] in a > meaningful way. > > Anyway, to give you a blackbox maybe like in Reaktor, attached is a > Spectral Delay GOP abstraction ready to be dropped into any glitch > patch. > > Ciao > -- > Frank Barknecht _ __footils.org_ __goto10.org__ > specdelay~.pd Description: Binary data specdelay~-help.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
that is one hell of a lot of fun to play with. padawan12 wrote: > On Wed, 21 Feb 2007 10:30:28 +0100 > Frank Barknecht <[EMAIL PROTECTED]> wrote: > > > A couple of little improvements to specdelay to make it more useful as an > audio effect. > > >> Hallo, >> David Powers hat gesagt: // David Powers wrote: >> >> >>> I wish there was an "fft for dumbies" ... or, I guess, some kind of >>> fft "black boxes" to play with, where you don't need to understand the >>> math. Frank's recent post completely lost me, >>> >> Now I'm disappointed ... >> >> >>> though given a bit of study I can probably decode it. >>> >> ... ah, and relieved a bit again. ;) >> >> >>> But, for instance, in Reaktor or Plogue Bidule, you can move stuff >>> into fft, mess with it, and resynthesize, without having any idea what >>> the hell the math is. In comparison, I really couldn't understand the >>> PD fft examples at all, it's just been too many years since I had a >>> math class. >>> >> The power of Pd of course is, that you can influence things on a much >> lower level than NI allows you to do in Reaktor - although I admit, >> that I only know Reaktor from screenshots. The downside is, that you >> have to dig deeper to make the most out of Pd. This is especially true >> for FFT applications. The actual FFT patches often are very simple and >> they contain just of a handful of objects. It's the knowledge hidden >> inside that makes them difficult to understand. >> >> While you can skip a lot of the math, you cannot do FFT in Pd without >> at least understanding what kind of data is generated by the two >> [rfft~] outlets. Because without understanding this, you cannot even >> "fool around" with the data in between [rfft~] and [rifft~] in a >> meaningful way. >> >> Anyway, to give you a blackbox maybe like in Reaktor, attached is a >> Spectral Delay GOP abstraction ready to be dropped into any glitch >> patch. >> >> Ciao >> -- >> Frank Barknecht _ __footils.org_ __goto10.org__ >> >> >> >> >> ___ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Hallo, padawan12 hat gesagt: // padawan12 wrote: > A couple of little improvements to specdelay to make it more useful as an > audio effect. Very nice. Now one can do instant french filter house with it as well! With under 100 objects: $ grep obj specdelay~.pd | wc -l 98 Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
That is very nice. We need more stuff like this! Unfortunately, the sound breaks up badly when I draw in the arrays. Does that happen on other platforms? I am on Mac OS X. I wonder if there is a more efficient way to do the drawing part. I added a little splash of color and some simple step-by-step instructions for the newbies. Stuff like this is the perfect way to inspire people to learn Pd. specdelay~-help.pd Description: Binary data .hc On Feb 23, 2007, at 1:10 PM, Josh Steiner wrote: that is one hell of a lot of fun to play with. padawan12 wrote: On Wed, 21 Feb 2007 10:30:28 +0100 Frank Barknecht <[EMAIL PROTECTED]> wrote: A couple of little improvements to specdelay to make it more useful as an audio effect. Hallo, David Powers hat gesagt: // David Powers wrote: I wish there was an "fft for dumbies" ... or, I guess, some kind of fft "black boxes" to play with, where you don't need to understand the math. Frank's recent post completely lost me, Now I'm disappointed ... though given a bit of study I can probably decode it. ... ah, and relieved a bit again. ;) But, for instance, in Reaktor or Plogue Bidule, you can move stuff into fft, mess with it, and resynthesize, without having any idea what the hell the math is. In comparison, I really couldn't understand the PD fft examples at all, it's just been too many years since I had a math class. The power of Pd of course is, that you can influence things on a much lower level than NI allows you to do in Reaktor - although I admit, that I only know Reaktor from screenshots. The downside is, that you have to dig deeper to make the most out of Pd. This is especially true for FFT applications. The actual FFT patches often are very simple and they contain just of a handful of objects. It's the knowledge hidden inside that makes them difficult to understand. While you can skip a lot of the math, you cannot do FFT in Pd without at least understanding what kind of data is generated by the two [rfft~] outlets. Because without understanding this, you cannot even "fool around" with the data in between [rfft~] and [rifft~] in a meaningful way. Anyway, to give you a blackbox maybe like in Reaktor, attached is a Spectral Delay GOP abstraction ready to be dropped into any glitch patch. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a spectral gate?
Yeah - I agree. This would be a nice addition to the pd examples since it uses all standard objects, or maybe there could be a package that includes things like this. I started learning Pd in May of last year and I always thought the audio examples were fine; effective but a little dry. Something like this would allow people to have a lot more fun from the get-go! It's things like this, or Derek's particlechamber (too bad it needs grid) that would be great especially for people coming from other softwares or the electronic music scene, just to demonstrate that these kind of things are happening in pd right off the bat :) Might be a nice little bit of encouragement. I don't have any problems with drawing the arrays on an iMac g5 10.4. Kevin On 3/1/07, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > That is very nice. We need more stuff like this! > > Unfortunately, the sound breaks up badly when I draw in the arrays. > Does that happen on other platforms? I am on Mac OS X. I wonder if > there is a more efficient way to do the drawing part. > > I added a little splash of color and some simple step-by-step > instructions for the newbies. Stuff like this is the perfect way to > inspire people to learn Pd. > > > > .hc > > On Feb 23, 2007, at 1:10 PM, Josh Steiner wrote: > > > that is one hell of a lot of fun to play with. > > > > > > padawan12 wrote: > >> On Wed, 21 Feb 2007 10:30:28 +0100 > >> Frank Barknecht <[EMAIL PROTECTED]> wrote: > >> > >> > >> A couple of little improvements to specdelay to make it more > >> useful as an > >> audio effect. > >> > >> > >>> Hallo, > >>> David Powers hat gesagt: // David Powers wrote: > >>> > >>> > I wish there was an "fft for dumbies" ... or, I guess, some kind of > fft "black boxes" to play with, where you don't need to > understand the > math. Frank's recent post completely lost me, > > >>> Now I'm disappointed ... > >>> > >>> > though given a bit of study I can probably decode it. > > >>> ... ah, and relieved a bit again. ;) > >>> > >>> > But, for instance, in Reaktor or Plogue Bidule, you can move stuff > into fft, mess with it, and resynthesize, without having any > idea what > the hell the math is. In comparison, I really couldn't > understand the > PD fft examples at all, it's just been too many years since I had a > math class. > > >>> The power of Pd of course is, that you can influence things on a > >>> much > >>> lower level than NI allows you to do in Reaktor - although I admit, > >>> that I only know Reaktor from screenshots. The downside is, that you > >>> have to dig deeper to make the most out of Pd. This is especially > >>> true > >>> for FFT applications. The actual FFT patches often are very > >>> simple and > >>> they contain just of a handful of objects. It's the knowledge hidden > >>> inside that makes them difficult to understand. > >>> > >>> While you can skip a lot of the math, you cannot do FFT in Pd > >>> without > >>> at least understanding what kind of data is generated by the two > >>> [rfft~] outlets. Because without understanding this, you cannot even > >>> "fool around" with the data in between [rfft~] and [rifft~] in a > >>> meaningful way. > >>> > >>> Anyway, to give you a blackbox maybe like in Reaktor, attached is a > >>> Spectral Delay GOP abstraction ready to be dropped into any glitch > >>> patch. > >>> > >>> Ciao > >>> -- > >>> Frank Barknecht _ __footils.org_ __goto10.org__ > >>> > >>> > >>> > >>> > >>> > >>> ___ > >>> PD-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > >>> listinfo/pd-list > >>> > > > > > > ___ > > PD-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > > listinfo/pd-list > > > > > > All information should be free. - the hacker ethic > > > > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > -- http://pocketkm.blogspot.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
