I'm teaching myself some DSP stuff, using Miller's Techniques, a Digital Filters book, and some other references, and I'm loving it. I am wondering, though, how one comes up with a complex audio signal for use in Pd. I want to experiment with [czero~], and I've also wondered where complex signals come from for [fft~]. It doesn't seem like it would be possible to create a complex signal from a real one, but maybe there are ways to synthesize them?
Thanks. -Chuckk
Quoting Chuckk Hubbard badmuthahubbard@gmail.com:
I'm teaching myself some DSP stuff, using Miller's Techniques, a Digital Filters book, and some other references, and I'm loving it. I am wondering, though, how one comes up with a complex audio signal for use in Pd. I want to experiment with [czero~], and I've also wondered where complex signals come from for [fft~]. It doesn't seem like it would be possible to create a complex signal from a real one, but maybe there are ways to synthesize them?
I thought that usual practice was to put another batch of real signals in the complex part, since they are orthogonal, no interaction, it could be anything. Complex audio sounds the same as real audio ;)
Martin
I didn't think of that. But then why have objects using complex signals?
On 6/10/06, martinrp@alcor.concordia.ca martinrp@alcor.concordia.ca wrote:
Quoting Chuckk Hubbard badmuthahubbard@gmail.com:
I'm teaching myself some DSP stuff, using Miller's Techniques, a Digital Filters book, and some other references, and I'm loving it. I am wondering, though, how one comes up with a complex audio signal for use in Pd. I want to experiment with [czero~], and I've also wondered where complex signals come from for [fft~]. It doesn't seem like it would be possible to create a complex signal from a real one, but maybe there are ways to synthesize them?
I thought that usual practice was to put another batch of real signals in the complex part, since they are orthogonal, no interaction, it could be anything. Complex audio sounds the same as real audio ;)
Martin
--
On Sun, 11 Jun 2006, Chuckk Hubbard wrote:
I didn't think of that. But then why have objects using complex signals?
Because a Fourier transform of complex signals is a more basic operation than a Fourier transform of real signals. the complex Fouriers work in a more uniform fashion: sine and cosine are replaced by a single operation that includes both.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Chuckk Hubbard wrote:
I'm teaching myself some DSP stuff, using Miller's Techniques, a Digital Filters book, and some other references, and I'm loving it. I am wondering, though, how one comes up with a complex audio signal for use in Pd. I want to experiment with [czero~], and I've also wondered where complex signals come from for [fft~].
I'm not sure I understand your question: Do you want to know why processing a real signal with the Fourier Transormation can result in a complex signal?
It doesn't seem like it would be possible to create a complex signal from a real one, but maybe there are ways to synthesize them?
A real signal can be regarded as a special case of a complex signal with the imaginary part set to zero. To create a complex signal just add an imaginary part, e.g. real signal x -> hilbert transformation of x -> x', which is the imaginary part of the analytic signal z=x + jx', z is complex now.
br, Piotr
On 6/11/06, Piotr Majdak piotr@majdak.com wrote:
Chuckk Hubbard wrote:
I'm teaching myself some DSP stuff, using Miller's Techniques, a Digital Filters book, and some other references, and I'm loving it. I am wondering, though, how one comes up with a complex audio signal for use in Pd. I want to experiment with [czero~], and I've also wondered where complex signals come from for [fft~].
I'm not sure I understand your question: Do you want to know why processing a real signal with the Fourier Transormation can result in a complex signal?
No, I want to know why there is an [fft~] object that is not for real signals, and how to make something into a complex signal.
I read a few pages further in Theory and Techniques, though, and found the suggestion of regarding a real signal as a complex signal plus its complex conjugate, and including the complex conjugate for every filter. I'm about to print out the next few pages and take a look at the rest of the chapter.
It doesn't seem like it would be possible to create a complex signal from a real one, but maybe there are ways to synthesize them?
A real signal can be regarded as a special case of a complex signal with the imaginary part set to zero. To create a complex signal just add an imaginary part, e.g. real signal x -> hilbert transformation of x -> x', which is the imaginary part of the analytic signal z=x + jx', z is complex now.
br, Piotr
OK, but Hilbert involves FFT, which involves distortion. And a signal with the imaginary part set to zero won't represent the same sines and cosines.
Chuckk Hubbard wrote:
On 6/11/06, Piotr Majdak piotr@majdak.com wrote:
No, I want to know why there is an [fft~] object that is not for real signals, and how to make something into a complex signal.
Consider following situation: a signal x should be filtered with two filters hL and hR to signals yL and yR for presentation via headphones.
Using complex signals you can do it with one filtering task only.
- Create a complex filter: hZ = hL + ihR
- Perform the fFiltering yZ = IFT(FT(x)*FT(hZ))
- yZ is yL + iyR now.
Result: only _one_ filtering for _two_ signals, but you need a _complex_ fourier transformation ;-)
OK, but Hilbert involves FFT, which involves distortion.
FT is just one way to calculate the HT. A good approx. can be achieved with a FIR filter. The result will be a real signal, but you consider it as the imaginary part of what ever you want (here: analytic signal).
And I really don't know what do you mean by "FFT, which involves distortion". You don't mean distortions as in "nonlinear distortions", don't you?
And a signal with the imaginary part set to zero won't represent the same sines and cosines.
Same as what? Sorry, don't understand it...
br, Piotr
On 6/14/06, Piotr Majdak piotr@majdak.com wrote:
Chuckk Hubbard wrote:
OK, but Hilbert involves FFT, which involves distortion.
FT is just one way to calculate the HT. A good approx. can be achieved with a FIR filter. The result will be a real signal, but you consider it as the imaginary part of what ever you want (here: analytic signal).
And I really don't know what do you mean by "FFT, which involves distortion". You don't mean distortions as in "nonlinear distortions", don't you?
I mean that the reconstituted sound is not exactly the same as the original signal.
And a signal with the imaginary part set to zero won't represent the same sines and cosines.
Same as what? Sorry, don't understand it...
The same as having the imaginary part set to the sums of all of the sines of the values of which the real part is the cosines. I mean, it's not really possible for the same sum of rotating bodies to have two different sets of vertical values? The imaginary part does affect what's happening, no?
-Chuckk
Hi Chuckk,
Chuckk Hubbard wrote:
On 6/14/06, Piotr Majdak piotr@majdak.com wrote:
And I really don't know what do you mean by "FFT, which involves distortion". You don't mean distortions as in "nonlinear distortions", don't you?
I mean that the reconstituted sound is not exactly the same as the original signal.
If:
- x is a sequence in a discrete space (i think hilbert space is OK) with
the length N,
- DFT is the discrete fourier transformation with the length of N,
- IDFT is the inverse transformation to DFT,
- we neglect all the numerical quantization and overflow for a while,
then:
IDFT(DFT(x)) = x
Even with numerical limitations it's not a problem. Try this in MATLAB: x=rand(10000,1); y=ifft(fft(x)); sqrt(sum((y-x).^2))/length(x)
I get: 1.6806e-018, which shows that the residual error of reconstruction of x is rather low even for dealing with long sequences.
And a signal with the imaginary part set to zero won't represent the same sines and cosines.
Same as what? Sorry, don't understand it...
The same as having the imaginary part set to the sums of all of the sines of the values of which the real part is the cosines.
I still can not follow your explanation, because you compare real signals with complex signals, which, of course are not the same. But...
I mean, it's not really possible for the same sum of rotating bodies to have two different sets of vertical values? The imaginary part does affect what's happening, no?
...I have the impression, that you're trying to explain komplex numbers with signals from the real world. There is no physical meaning of the set of komplex numbers! It is just a tool to perform some calculations easier (see last mail for example) and interprete the results in a "human" way (e.g. what's the sqrt(-1)?). Thus, as long as you deal with real signals, there is no imaginary part what can affect any rotation body. Introduce complex signal, there we have it :-)
br, Piotr
On Wed, 14 Jun 2006, Chuckk Hubbard wrote:
I mean that the reconstituted sound is not exactly the same as the original signal.
after a [fft~], a [ifft~], and then dividing by the block size, what's different from the original? prolly just arithmetic error from addition and multiplication.
BTW, if you look at relative errors on individual bins you are not looking at the right thing. Your relative error should be computed relative to the magnitude of the whole sound. If you have a case where you really need to have low individual relative errors, then you might have a point, but I wonder, do you have such a case?
a pair of FFT on a block size of 1024 is supposed to be roughly like 20 layers each containing 2 [+~], 3 [*~] and 2 [z~], arranged in a rather regular pattern.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Okay, I've read through some of the Fourier explanation in this Digital Filters book, and I think I understand. That was going to be one of my next questions: if the data of the FFT actually has the same number of possibilities as the audio data itself (by bit rate and block size), is there then a 1 to 1 relationship, where no two audio blocks could have the same FFT data. I take the answer to be yes. I was told by an electrical engineer that short block sizes miss lower frequencies, but that seems to be covered with the DC channel, even down to a block size of 4. I was a little confused by the possibility of having, for instance, 7 oscillators tuned within .001 Hz of each other, since there is only one value for each channel, and I read that FFT is more accurate if the frequency of the sound is known and is in a harmonic relationship with the bins. But it makes sense that, with a discrete signal, some combination of possible values from neighboring channels would create the same signal. So, the idea is just that the transform data is easier to read if there is a harmonic relationship- not that the reconstructed signal will be truer?
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal? The reason I am concerned about this is that, going by Miller's chapter on filter design, more can be done with a single-sample delay if the coefficient is complex. Is this process exactly the same as the Hilbert transform or is there some subtle difference? I'm anxious to start designing filters.
I've been extensively cross-referencing between Miller's Theory and Techniques, Erik Spjut's chapter on DSP in the Csound Book, and Digital Filters by RW Hamming. It amazes me that, with the help of the other two books and mathworld, I am beginning to comprehend a lot of the Hamming concepts, which seemed totally inscrutable last fall. Too bad I go to an art school that would never pay for MathLab in a million years.
Thanks. Chuckk
On 6/19/06, Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 14 Jun 2006, Chuckk Hubbard wrote:
I mean that the reconstituted sound is not exactly the same as the original signal.
after a [fft~], a [ifft~], and then dividing by the block size, what's different from the original? prolly just arithmetic error from addition and multiplication.
BTW, if you look at relative errors on individual bins you are not looking at the right thing. Your relative error should be computed relative to the magnitude of the whole sound. If you have a case where you really need to have low individual relative errors, then you might have a point, but I wonder, do you have such a case?
a pair of FFT on a block size of 1024 is supposed to be roughly like 20 layers each containing 2 [+~], 3 [*~] and 2 [z~], arranged in a rather regular pattern.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Le Lundi 19 Juin 2006 23:12, Chuckk Hubbard a écrit :
Too bad I go to an art school that would never pay for MathLab in a million years.
Then go fetch Gnu Octave: http://www.gnu.org/software/octave/ -- Marc
On 6/20/06, Marc Lavallée marc@hacklava.net wrote:
Le Lundi 19 Juin 2006 23:12, Chuckk Hubbard a écrit:
Too bad I go to an art school that would never pay for MathLab in a million years.
Then go fetch Gnu Octave: http://www.gnu.org/software/octave/ -- Marc
There is a god. I seem to recall someone recommending this last summer some time, but I didn't need it yet. I've been wracking my brain to remember its name. I'll be at this some time. Thanks!!!
-Chuckk
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
Okay, I've read through some of the Fourier explanation in this Digital Filters book, and I think I understand. That was going to be one of my next questions: if the data of the FFT actually has the same number of possibilities as the audio data itself (by bit rate and block size), is there then a 1 to 1 relationship, where no two audio blocks could have the same FFT data. I take the answer to be yes. I was told by an electrical engineer that short block sizes miss lower frequencies, but that seems to be covered with the DC channel, even down to a block size of 4.
Well, it's a bit more complicated than that, you don't loose lower frequencies, you loose frequency resolution with smaller windows.
First, the true Fourier transform only is valid for "endless" periodic signals like additions of sine waves. There we have no information loss when transforming back and forth. But as we don't have infinite periodic signals in real world, windowing is used to make signals look as if they were infinite and periodic. But windowing changes the original signal (it's like amplitude modulation) and it limits the frequency resolution of the resulting spectrum. Assuming you use a window of 100 samples at a sample rate of 10,000 kHz. Then the fundamental frequency of your analysis will be 10,000/100 = 1000 Hz and you will only get harmonics between +/-Nyquist: -5000, -4000, ..., -1000, 0, 1000, ..., 5000.
Using a larger window, like 1000 samples, you get a finer resolution in steps of 10,000/1000 = 10 Hz: -5000, -4990, -4980, ..., 0, 10, 20, ..., 5000 however you loose temporal resolution, as you now have to wait 1000 samples instead of only 100 to detect changes in frequency content.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Chuckk,
Chuckk Hubbard wrote:
Okay, I've read through some of the Fourier explanation in this Digital Filters book, and I think I understand. That was going to be one of my next questions: if the data of the FFT actually has the same number of possibilities as the audio data itself (by bit rate and block size), is there then a 1 to 1 relationship, where no two audio blocks could have the same FFT data. I take the answer to be yes.
Yes.
I was told by an electrical engineer that short block sizes miss lower frequencies, but that seems to be covered with the DC channel, even down to a block size of 4.
Not really - it depends on the signal. Imagine a simple signal with length of 4 samples: [1 0 0 0]. This unit pulse contains all frequencies...
I was a little confused by the possibility of having, for instance, 7 oscillators tuned within .001 Hz of each other, since there is only one value for each channel, and I read that FFT is more accurate if the frequency of the sound is known and is in a harmonic relationship with the bins.
If you want to FT a signal you describe and see the harmonics differences in the spectrum you need long block sizes. But not due to some FT limitations, it's just because you need longer signals in the time domain to represent several slightly detuned sines. Taking just four samples from such a signal, the information about the sines gets lost. This problem is called windowing and the lost of the accuracy after the FT is the leakage effect (information of the frequencies gets smeared over several bins).
But it makes sense that, with a discrete signal, some combination of possible values from neighboring channels would create the same signal. So, the idea is just that the transform data is easier to read if there is a harmonic relationship- not that the reconstructed signal will be truer?
Yes, sometimes you can interprete data better in the frequency domain better.
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal?
Using [rfft~] you can process real signals only...
I've been extensively cross-referencing between Miller's Theory and Techniques, Erik Spjut's chapter on DSP in the Csound Book, and Digital Filters by RW Hamming. It amazes me that, with the help of the other two books and mathworld, I am beginning to comprehend a lot of the Hamming concepts, which seemed totally inscrutable last fall.
You are not alone. We all had to start somewhere :-)
Too bad I go to an art school that would never pay for MathLab in a million years.
As Marc wrote you: try Octave...
br, Piotr
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
I was a little confused by the possibility of having, for instance, 7 oscillators tuned within .001 Hz of each other, since there is only one value for each channel, and I read that FFT is more accurate if the frequency of the sound is known and is in a harmonic relationship with the bins.
If you want to FT a signal you describe and see the harmonics differences in the spectrum you need long block sizes. But not due to some FT limitations, it's just because you need longer signals in the time domain to represent several slightly detuned sines.
I didn't think of that.
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal?
Using [rfft~] you can process real signals only...
I meant like:
[readsf~] (for instance)
|
[rfft~]
| |
[ifft~] [num\ [num
| | | |
[czero~]
|
[dac~]
I suppose I could just try it and see if it works...
Too bad I go to an art school that would never pay for MathLab in a million years.
As Marc wrote you: try Octave...
Badass.
Thanks. -Chuckk
br, Piotr
On 6/20/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal?
Using [rfft~] you can process real signals only...
I meant like: [readsf~] (for instance) | [rfft~] | | [ifft~] [num\ [num
| | | | [czero~] | [dac~]I suppose I could just try it and see if it works...
It doesn't. Nor does: [osc~] | [rfft~] [sig~ 0] | | [ifft~]
regardless of scaling. At a harmonic, the real part of the output matches the input, but changing the frequency causes mad distortion. ?
Chuckk Hubbard wrote:
On 6/20/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal?
Using [rfft~] you can process real signals only...
I meant like: [readsf~] (for instance) | [rfft~] | | [ifft~] [num\ [num
| | | | [czero~] | [dac~]I suppose I could just try it and see if it works...
You transform the signal from [readsf~] to the frequency domain (it's complex now), then transform it back to the time domain (now it's real again and identical to the signal from [readsf~]). Why do you do that?
According to the help patch, [czero~] does: y[n] = x[n] - a[n] * x[n-1]. To get a consistent filtering with [czero~] the imaginary part of the result should be zero (the real part can be the input for [dac~], as you did it), which means, that a[n] must be conj(x[n]), or in this case the imag(a)=0. Of course, you can use a chain of [czero~]s, where the intermediate results are complex. However, after the last [czero~], the result should be real.
To play with [czero~], try the [pd test] subpatch in the help file of [czero~].
It doesn't. Nor does: [osc~] | [rfft~] [sig~ 0] | | [ifft~]
Can you tell me, what are you trying to do? You know, this patch works (no errors), but I don't know how to interpret the resulting signals...
br, Piotr
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Chuckk Hubbard wrote:
On 6/20/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Another question: if I just ran rfft~ on a signal, and then ran ifft~ on the transform, would that create the same signal as a complex signal?
Using [rfft~] you can process real signals only...
I meant like: [readsf~] (for instance) | [rfft~] | | [ifft~] [num\ [num
| | | | [czero~] | [dac~]I suppose I could just try it and see if it works...
You transform the signal from [readsf~] to the frequency domain (it's complex now), then transform it back to the time domain (now it's real again and identical to the signal from [readsf~]). Why do you do that?
The inverse transform is complex, from a real forward transform. I'm just trying to find out what the imaginary part should be.
According to the help patch, [czero~] does: y[n] = x[n] - a[n] * x[n-1]. To get a consistent filtering with [czero~] the imaginary part of the result should be zero (the real part can be the input for [dac~], as you did it), which means, that a[n] must be conj(x[n]), or in this case the imag(a)=0. Of course, you can use a chain of [czero~]s, where the intermediate results are complex. However, after the last [czero~], the result should be real.
To play with [czero~], try the [pd test] subpatch in the help file of [czero~].
If I understand you correctly, this is similar to what Miller's book talks about. Pairing every complex filter with another with the conjugate of its coefficient, so that the real signal can be treated as the sum of two complex signals which are conjugates of each other. Hallelujah, I just made it work. Not so hard. Far easier than trying to make a real signal complex.
It doesn't. Nor does: [osc~] | [rfft~] [sig~ 0] | | [ifft~]
Can you tell me, what are you trying to do? You know, this patch works (no errors), but I don't know how to interpret the resulting signals...
Writing the original signal and the real and imaginary parts of the output to graphs shows lots of alterations. It is fine with a block containing an integer number of cycles, but otherwise gets weird results. See attached.
-Chuckk
Hi chucck,
Chuckk Hubbard wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
If I understand you correctly, this is similar to what Miller's book talks about. Pairing every complex filter with another with the conjugate of its coefficient, so that the real signal can be treated as the sum of two complex signals which are conjugates of each other. Hallelujah, I just made it work. Not so hard. Far easier than trying to make a real signal complex.
Glad to hear it!
Writing the original signal and the real and imaginary parts of the output to graphs shows lots of alterations. It is fine with a block containing an integer number of cycles, but otherwise gets weird results. See attached.
Every time you write the signals to the tables, the phase of the original signal changes. Because of the windowing effects the processed signal (FT->Re{}->IFT) changes dramatically: the real part of the FT result contains the information about the symmetric part of the original signal (=cosines), which changes with its phase.
Thanks for the nice example - it took me a while to analyze what happens here.
br, Piotr
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Hi chucck,
Chuckk Hubbard wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
Writing the original signal and the real and imaginary parts of the output to graphs shows lots of alterations. It is fine with a block containing an integer number of cycles, but otherwise gets weird results. See attached.
Every time you write the signals to the tables, the phase of the original signal changes. Because of the windowing effects the processed signal (FT->Re{}->IFT) changes dramatically: the real part of the FT result contains the information about the symmetric part of the original signal (=cosines), which changes with its phase.
So it doesn't work. I mean, I understand, with a rectangular window there are discontinuities that read as crazy frequencies, but essentially this doesn't work for supplying the imaginary part. I guess it's just academic now, but I'm still curious.
-Chuckk
Thanks for the nice example - it took me a while to analyze what happens here.
br, Piotr
-- Piotr Majdak Institut für Schallforschung Österreichische Akademie der Wissenschaften Reichsratsstr. 17 A-1010 Wien Tel.: +43-1-4277-29511 Fax: +43-1-4277-9296 E-Mail: piotr@majdak.com WWW: http://www.kfs.oeaw.ac.at
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Chuckk Hubbard wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
So it doesn't work. I mean, I understand, with a rectangular window there are discontinuities that read as crazy frequencies, but essentially this doesn't work for supplying the imaginary part. I guess it's just academic now, but I'm still curious.
I'm not used to analysis of a spectrum by looking at its real and imaginary parts. Usually, I analyse the amplitude and phase of a spectrum. Thus, can you tell me what do you want to analyze and what "doesn't work"?
br, Piotr
On 6/21/06, Piotr Majdak piotr@majdak.com wrote:
Chuckk Hubbard wrote:
On 6/20/06, Piotr Majdak piotr@majdak.com wrote:
So it doesn't work. I mean, I understand, with a rectangular window there are discontinuities that read as crazy frequencies, but essentially this doesn't work for supplying the imaginary part. I guess it's just academic now, but I'm still curious.
I'm not used to analysis of a spectrum by looking at its real and imaginary parts. Usually, I analyse the amplitude and phase of a spectrum. Thus, can you tell me what do you want to analyze and what "doesn't work"?
br, Piotr
To supply the missing imaginary part to a real signal. It doesn't work to merely put the result of rfft~ into ifft~, either directly or with zeros for the imaginary part, in a 64 sample block size. Now that I think of it, if the signal is recorded, using an astronomically large window size would seem to do it. I wonder what Pd's limitations are.
-Chuckk
Hi Chuckk,
Chuckk Hubbard wrote:
To supply the missing imaginary part to a real signal.
Call me a narrow thinking technician, but I still have no idea what "supply the missing part" is. Why do you miss it? Is it supposed to be there? I mean: that's the real signal. No imaginary part there. And now: you want to add an imaginary part to that. OK, so far. What model do you have? What are your expectations doing that? What are the properties of the signal you want to change? ....
br, Piotr
On 6/22/06, Piotr Majdak piotr@majdak.com wrote:
Hi Chuckk,
Chuckk Hubbard wrote:
To supply the missing imaginary part to a real signal.
Call me a narrow thinking technician, but I still have no idea what "supply the missing part" is. Why do you miss it? Is it supposed to be there? I mean: that's the real signal. No imaginary part there. And now: you want to add an imaginary part to that. OK, so far. What model do you have? What are your expectations doing that? What are the properties of the signal you want to change? ....
br, Piotr
Okay, sorry for my terminology. I'm just curious whether it is possible to take a real signal and create a complex signal with the real signal as its real part, where the imaginary rotation implied by the complex signal mirrors the imaginary sine and cosine of an imaginary body whose rotation would create that real signal. I was told there is exactly one imaginary signal corresponding to any real signal. I couldn't make the Hilbert transform work right. Maybe this isn't of any use for any reason, but I'm curious how to do it.
On Thu, 22 Jun 2006, Chuckk Hubbard wrote:
I was told there is exactly one imaginary signal corresponding to any real signal.
There are two: cos(x) is both Re(e^ix) and Re(e^-ix). It's the same for all other signals.
I couldn't make the Hilbert transform work right. Maybe this isn't of any use for any reason, but I'm curious how to do it.
Hmm, did you try phase-shifting the original signal by 90 degrees?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 22 Jun 2006, Mathieu Bouchard wrote:
On Thu, 22 Jun 2006, Chuckk Hubbard wrote:
I was told there is exactly one imaginary signal corresponding to any real signal.
There are two: cos(x) is both Re(e^ix) and Re(e^-ix). It's the same for all other signals.
Oh, and I also wanted to say: the average of those two is exactly the real signal cos(x), so the complex spectrum of cos(x) has two non-zero values,
one for a positive frequency (counterclockwise spinning)
one for a negative frequency (clockwise spinning)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo!
Using [rfft~] you can process real signals only...
I meant like: [readsf~] (for instance) | [rfft~] | | [ifft~] [num\ [num
| | | | [czero~] | [dac~]
hm - why do you use [rfft~] - [ifft~] ? THis will give you the same signal as bevor (well, you would have to scale it by 1/blocksize somewhere) and the imaginary part will be 0 ...
[rfft~] is the same as [fft~] with 0 to the imaginary input - but [rfft~] should be faster than [fft~] ...
LG Georg
On 6/20/06, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
Using [rfft~] you can process real signals only...
I meant like: [readsf~] (for instance) | [rfft~] | | [ifft~] [num\ [num
| | | | [czero~] | [dac~]hm - why do you use [rfft~] - [ifft~] ? THis will give you the same signal as bevor (well, you would have to scale it by 1/blocksize somewhere) and the imaginary part will be 0 ...
Nope, it changes the signal. The imaginary part is wildly distorted, and the scaling seems to depend on the frequency of the input.
[rfft~] is the same as [fft~] with 0 to the imaginary input - but [rfft~] should be faster than [fft~] ...
There seems to be a slight difference between [rfft~] and [fft~] with 0 imaginary input though. I don't know if it matters.
-Chuckk
LG Georg
On Mon, 19 Jun 2006, Chuckk Hubbard wrote:
Okay, I've read through some of the Fourier explanation in this Digital Filters book, and I think I understand. That was going to be one of my next questions: if the data of the FFT actually has the same number of possibilities as the audio data itself (by bit rate and block size), is there then a 1 to 1 relationship, where no two audio blocks could have the same FFT data. I take the answer to be yes.
For floats, it's not, but it's not terribly off the mark anyway (just rounding error).
The mapping is only perfect in the (Real-based) Complex numbers and also in the Algebraic-numbers-based Complex numbers. However those systems are more difficult to compute with, so you find them in only a few apps, such as Mathematica and Maple. (Not even in Matlab, if I'm not mistaken).
I was told by an electrical engineer that short block sizes miss lower frequencies, but that seems to be covered with the DC channel, even down to a block size of 4.
Short block sizes miss lower frequencies, but that is irrelevant, because such low frequencies are outside the scope of one single block: it's cross-block information. You can see a low frequency as an oscillation of the DC channel over many blocks.
I was a little confused by the possibility of having, for instance, 7 oscillators tuned within .001 Hz of each other, since there is only one value for each channel, and I read that FFT is more accurate if the frequency of the sound is known and is in a harmonic relationship with the bins.
FFT gives a perfect spike if the input is a sinusoid of same frequency as a bin. If it isn't, the spike will be curved, spilling over many bins. You can refine the value of the frequency by looking at the shape of the spike, and/or by looking at how the phase of the spike changes from block to block.
So, the idea is just that the transform data is easier to read if there is a harmonic relationship- not that the reconstructed signal will be truer?
The reconstructed signal will be fine. If instead of sin(440t) you get sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example) then this only means that the latter is the closest approximation to the former in the context of that particular block size.
Too bad I go to an art school that would never pay for MathLab in a million years.
What do you need Matlab for?... PureData can do a lot of the job, and if it isn't enough, then add GridFlow (which has [#fft]).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi!
Mathieu Bouchard wrote:
What do you need Matlab for?... PureData can do a lot of the job, and if it isn't enough, then add GridFlow (which has [#fft]).
Copy from http://www.mathworks.com/products/matlab/description1.html:
# High-level language for technical computing # Development environment for managing code, files, and data # Interactive tools for iterative exploration, design, and problem solving # Mathematical functions for linear algebra, statistics, Fourier analysis, filtering, optimization, and numerical integration # 2-D and 3-D graphics functions for visualizing data # Tools for building custom graphical user interfaces # Functions for integrating MATLAB based algorithms with external applications and languages, such as C, C++, Fortran, Java, COM, and Microsoft Excel
You are not one of these guys thinking the world ends at the edge of a pd-external, do you?
Sorry, I couldn't resist (dogmatism allergy)...
br, Piotr
On Wed, 21 Jun 2006, Piotr Majdak wrote:
You are not one of these guys thinking the world ends at the edge of a pd-external, do you?
I certainly don't... I say that you can do a lot of the Matlab stuff in Pd. Some advantages can be that you don't have to leave Pd to do that, so that the learning curve is smoother, and you don't have to do cross-language integration.
Speaking of which, isn't there a pd extern for connecting/linking with Octave?
dogmatism
I'm not really known for that...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 6/20/06, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 19 Jun 2006, Chuckk Hubbard wrote:
Okay, I've read through some of the Fourier explanation in this Digital Filters book, and I think I understand. That was going to be one of my next questions: if the data of the FFT actually has the same number of possibilities as the audio data itself (by bit rate and block size), is there then a 1 to 1 relationship, where no two audio blocks could have the same FFT data. I take the answer to be yes.
For floats, it's not, but it's not terribly off the mark anyway (just rounding error).
The mapping is only perfect in the (Real-based) Complex numbers and also in the Algebraic-numbers-based Complex numbers. However those systems are more difficult to compute with, so you find them in only a few apps, such as Mathematica and Maple. (Not even in Matlab, if I'm not mistaken).
I guess the question is, can anyone hear the difference?
So, the idea is just that the transform data is easier to read if there is a harmonic relationship- not that the reconstructed signal will be truer?
The reconstructed signal will be fine. If instead of sin(440t) you get sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example) then this only means that the latter is the closest approximation to the former in the context of that particular block size.
Can it be heard?
Too bad I go to an art school that would never pay for MathLab in a million years.
What do you need Matlab for?... PureData can do a lot of the job, and if it isn't enough, then add GridFlow (which has [#fft]).
I'm specifically curious about seeing integration and convolution, although I haven't found how to do that in Octave yet.
-Chuckk
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Chuckk Hubbard wrote:
On 6/20/06, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 19 Jun 2006, Chuckk Hubbard wrote:
I guess the question is, can anyone hear the difference?
No, see below.
So, the idea is just that the transform data is easier to read if there is a harmonic relationship- not that the reconstructed signal will be truer?
The reconstructed signal will be fine. If instead of sin(440t) you get sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example) then this only means that the latter is the closest approximation to the former in the context of that particular block size.
Can it be heard?
If you have any differences between the original and reconstructed signals, then they will be introduced by quantization (try a FFT with 8-bit fixed point DSP) or by overflow or by windowing effects - not by FT->IFT. This means: FT and IFT work as they are supposed to work - all problems and differences in the perfect reconstruction of your signals are caused by inproper signal processing. And this means: if you have differences after FT->IFT then you will have differences after simple multiplications and/or additions too, because your system is not adequate to do this job.
I'm specifically curious about seeing integration and convolution, although I haven't found how to do that in Octave yet.
If x is the sequence with your signal in MATLAB (Octave has the same syntax), then
Integration is y=sum(x); Convolution is y=conv(x,f); where f is the sequence with the impulse response of the filter FT is X=fft(x); IFT is y=ifft(X);
The syntax is quite easy - if you need some help about MATLAB, write me a personal mail - I'll do my best.
br, Piotr
On 6/21/06, Piotr Majdak piotr@majdak.com wrote:
Chuckk Hubbard wrote:
On 6/20/06, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 19 Jun 2006, Chuckk Hubbard wrote:
Can it be heard?
If you have any differences between the original and reconstructed signals, then they will be introduced by quantization (try a FFT with 8-bit fixed point DSP) or by overflow or by windowing effects - not by FT->IFT. This means: FT and IFT work as they are supposed to work - all problems and differences in the perfect reconstruction of your signals are caused by inproper signal processing. And this means: if you have differences after FT->IFT then you will have differences after simple multiplications and/or additions too, because your system is not adequate to do this job.
For some reason I hadn't checked this before, and my system is indeed adequate. I wasn't sure if Pure Data's FFT has built-in windowing or not, apparently it doesn't.
I'm specifically curious about seeing integration and convolution, although I haven't found how to do that in Octave yet.
If x is the sequence with your signal in MATLAB (Octave has the same syntax), then
Integration is y=sum(x); Convolution is y=conv(x,f); where f is the sequence with the impulse response of the filter FT is X=fft(x); IFT is y=ifft(X);
The syntax is quite easy - if you need some help about MATLAB, write me a personal mail - I'll do my best.
Cool, thanks, you might hear from me soon. I wonder what's the simplest way to do convolution natively in Pd?
-Chuckk
br, Piotr
Hallo!
Cool, thanks, you might hear from me soon. I wonder what's the simplest way to do convolution natively in Pd?
A convolution is simply a multiplication in frequency domain: so you have to fft~ or rfft~ your signal, then make a (complex!) multiplication and transform it back to time domain (rfft~) ... You should also use a window (see the fft examples), normalization (1/blocksize) and maybe a bigger blocksize (with block~) with an overlap ...
LG Georg
Chuckk Hubbard wrote:
On 6/21/06, Piotr Majdak piotr@majdak.com wrote:
For some reason I hadn't checked this before, and my system is indeed adequate. I wasn't sure if Pure Data's FFT has built-in windowing or not, apparently it doesn't.
Yes, it has! It windows the signal with a rectangular window by taking only the blocksize amount of samples from an infinite long signal. This corresponds to convolution of the spectrum(!) with sinc-function (sin(x)/x) for every frequency bin. That's the leakage effect...
Cool, thanks, you might hear from me soon. I wonder what's the simplest way to do convolution natively in Pd?
Georg described already the "fast convolution" method (Grüsse an Georg). Even simplier convolution is using [FIR~] from the iem lib. Just load an impulse response to a table and convolve it with a signal. [FIR~] implements _the_ direct discrete convolution.
BTW: I think that it's hard to debug and to understand these problems using a high-optimized real time software like pd. I propose you to use Matlab/Octave/SciLab or another numeric software package with many plot possibilities and signal control/editing sample by sample in an non-real time environment. Then, use the new knowledge to implement your ideas in pd :-)
br, Piotr
Chuckk Hubbard wrote:
I guess the question is, can anyone hear the difference?
this is a very narrow view of things from a musicians perspective.
there are other fields where Pd is used and where it is entirely irrelevant whether you can hear the difference but instead it is important that the system works as expected.
mfg.adsr. IOhannes
On Wed, 21 Jun 2006, Chuckk Hubbard wrote:
The mapping is only perfect in the (Real-based) Complex numbers and also in the Algebraic-numbers-based Complex numbers. However those systems are more difficult to compute with, so you find them in only a few apps, such as Mathematica and Maple. (Not even in Matlab, if I'm not mistaken).
I guess the question is, can anyone hear the difference?
No, your question was, is the mapping exactly 1-to-1 ? Well, it's not. However you won't actually hear a difference unless you really want to. If you want to hear a difference, use [-~] to take the difference between the original signal and the one that's supposed to be identical. Then use [*~ 1000000]. You might be able to hear some noises.
If you're one of those people who think they hear the difference between 16-bit and 24-bit audio, you might not need the [*~ 1000000] ;-)
The reconstructed signal will be fine. If instead of sin(440t) you get sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example) then this only means that the latter is the closest approximation to the former in the context of that particular block size.
Can it be heard?
The closest approximation is actually as exact as above. The reconstructed signal will sound like sin(440t) but only within that block. The continuation of sin(440t) to another block won't have the same FFT. Looping one block of that sin(440t) over and over won't sound like sin(440t) because what you're doing in effect is chopping parts of sin(440t) so that it becomes blocksize-periodic.
I'm specifically curious about seeing integration and convolution, although I haven't found how to do that in Octave yet.
(other people already have given good answers about this in this thread)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 6/22/06, Mathieu Bouchard matju@artengine.ca wrote:
On Wed, 21 Jun 2006, Chuckk Hubbard wrote:
The mapping is only perfect in the (Real-based) Complex numbers and also in the Algebraic-numbers-based Complex numbers. However those systems are more difficult to compute with, so you find them in only a few apps, such as Mathematica and Maple. (Not even in Matlab, if I'm not mistaken).
I guess the question is, can anyone hear the difference?
No, your question was, is the mapping exactly 1-to-1 ? Well, it's not. However you won't actually hear a difference unless you really want to. If you want to hear a difference, use [-~] to take the difference between the original signal and the one that's supposed to be identical. Then use [*~ 1000000]. You might be able to hear some noises.
I tried that, couldn't hear it.
If you're one of those people who think they hear the difference between 16-bit and 24-bit audio, you might not need the [*~ 1000000] ;-)
The reconstructed signal will be fine. If instead of sin(440t) you get sin(420t)+0.2*sin(460t)+0.04*sin(500t)+... (completely made up example) then this only means that the latter is the closest approximation to the former in the context of that particular block size.
Can it be heard?
The closest approximation is actually as exact as above. The reconstructed signal will sound like sin(440t) but only within that block. The continuation of sin(440t) to another block won't have the same FFT. Looping one block of that sin(440t) over and over won't sound like sin(440t) because what you're doing in effect is chopping parts of sin(440t) so that it becomes blocksize-periodic.
The reconstructed signal seems to sound fine, even with 4 detuned oscillators far from block size, ignoring the actual values of the FFT.
Thanks. Chuckk
On Thu, 22 Jun 2006, Chuckk Hubbard wrote:
you want to hear a difference, use [-~] to take the difference between the original signal and the one that's supposed to be identical. Then use [*~ 1000000]. You might be able to hear some noises.
I tried that, couldn't hear it.
try [*~ 10000000] then? zoom into the sound until you can hear the residue.
The reconstructed signal seems to sound fine, even with 4 detuned oscillators far from block size, ignoring the actual values of the FFT.
This is because you play the reconstructed signal blocks exactly once each. I was talking about the effect of looping one block over and over, which is related to the fact that each block is treated as if it were periodic (unless using a window filter)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 6/24/06, Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 22 Jun 2006, Chuckk Hubbard wrote:
you want to hear a difference, use [-~] to take the difference between the original signal and the one that's supposed to be identical. Then use [*~ 1000000]. You might be able to hear some noises.
I tried that, couldn't hear it.
try [*~ 10000000] then? zoom into the sound until you can hear the residue.
The reconstructed signal seems to sound fine, even with 4 detuned oscillators far from block size, ignoring the actual values of the FFT.
This is because you play the reconstructed signal blocks exactly once each. I was talking about the effect of looping one block over and over, which is related to the fact that each block is treated as if it were periodic (unless using a window filter)
OK, that makes sense, but still, a real rfft~ into a complex ifft~ gives distortion even when each block plays once. I read your reply about the 90 deg phase, but I'm using waves that don't match the block size. The real output signal almost follows the input, and the imaginary output appears to approach infinity at the ends... Maybe a huge block size.
-
Chuckk Hubbard -
Frank Barknecht -
Georg Holzmann -
IOhannes m zmölnig -
Marc Lavallée -
martinrp＠alcor.concordia.ca -
Mathieu Bouchard -
Piotr Majdak