Re: Filter response curve
Re: Filter response curve
- Subject: Re: Filter response curve
- From: Brian Willoughby <email@hidden>
- Date: Tue, 07 Feb 2017 22:13:18 -0800
Ok. I see what you mean now.
I'm referring to the format and representation of the numbers that we actually have in the memory buffers when running the software that we've written. All of the forms that can be expressed on paper have been put out of my mind so I can concentrate on the actual values sent to FFT subroutines and the values returned from those subroutines. All of my discussion of rectangular and polar coordinates directly corresponds to the format of the data parameters for common libraries like Accelerate and vecLib.
Folks are welcome to migrate to music-dsp for theory, if they like. However, if you want to discuss methods for writing code on macOS using CoreAudio and the Accelerate framework, then I recommend keeping the latter questions on this mailing list.
Brian Willoughby
Sound Consulting
p.s. I recently completed an application which graphs the Signal Transfer Function of selected AudioUnits. I have previously written an application which generates an impulse and graphs the frequency response of selected AudioUnits. These techniques are quite valuable when developing an AudioUnit (or even when building an AUGraph).
On Feb 7, 2017, at 10:00 PM, Evan Balster <email@hidden> wrote:
> Hey, Brian —
>
> Apologies for the confusing language. I tend to prefer logarithmic representation because of its elegant similarity to polar representation; the real part of the complex logarithm is the logarithm of the input number's magnitude, while the imaginary part of the logarithm is the input number's phase.
>
> For example, the natural logarithm of -1 is i*pi — a phase of 180 degrees and a log-magnitude of zero. The natural logarithm of e*i is 1+i*pi/2 — 1, because of the scalar e term, and pi/2 because of the quarter-circle orientation imposed by i.
>
> That said, these concepts are a bit heady for the discussion here and I've probably created more confusion than I've resolved! We can discuss further on music-dsp if you like.
>
> – Evan Balster
> creator of imitone
>
> On Tue, Feb 7, 2017 at 11:46 PM, Brian Willoughby <email@hidden> wrote:
>> Hello all,
>>
>> I apologize for being pedantic, but I believe that even the smallest misrepresentation can cause a lot of grief for a newcomer.
>>
>>
>> To that end, I'd like to point out that the phase chart does not correspond to the imaginary part (of the "logarithm" or anything else).
>>
>> Fourier Transforms produce paired results in real and imaginary parts. These real & imaginary pairs are also known as the rectangular form. In order to obtain the magnitude and phase, the rectangular coordinates must be converted to a polar form. In the polar form, the "radius" corresponds to the magnitude and the "angle" corresponds to the phase.
>>
>> It's true that some software API reuse the imaginary buffer to hold the phase values after a conversion from rectangular to polar coordinates, but my point is that the data is never both imaginary and phase. When the data represents imaginary values, there is no real world analog of what those values mean. However, when converted to polar form, the newly calculated values do correspond to the phase response for each frequency bin.
>>
>>
>> A secondary and much more minor point is that the magnitude is not necessarily a logarithm. The only guarantee is that the magnitude is the square root of the sum of the squares of the real and imaginary parts. The primary result in a linear amplitude, but we humans aren't generally able to make as much sense of linear amplitudes. Therefore, it's nearly universal that the magnitudes will be converted to a decibel scale, which is a logarithm by definition.
>>
>>
>> Apart from these corrections, Evan is correct - especially about the fact that mathematics has proven that the impulse response of a linear, time-invariant system like a filter corresponds precisely to the frequency response.
>>
>>
>> p.s. When converting from rectangular to polar coordinates, the magnitude is calculated using the root of two squares, as mentioned above, while the phase is calculated using trigonometric math to determine the angle based on the x and y vectors from the real and imaginary parts. Since trigonometric math is usually rather expensive in terms of CPU cycles, many FFT-based spectrum algorithms will only calculate the magnitude and not bother calculating the phase. For most applications, the phase is not necessary, so leaving it out makes the program run faster. In other words, it's too bad that the phase is not the imaginary part, because that would mean we didn't have to do any further calculations!
>>
>> Brian Willoughby
>> Sound Consulting
>>
>>
>> On Feb 7, 2017, at 1:17 PM, Evan Balster <email@hidden> wrote:
>> > A filter's transfer function simultaneously describes its response to a one-sample impulse and its response to any complex frequency in the z-domain. There's no need to compromise.
>> > The reason for this? Applying a filter to a signal is the same as convolving the signal by the filter's impulse response. Convolution in the time domain, as exemplified by filters, is identical to multiplication in the frequency domain. Thus we can look at any point in the transfer function (as evaluated in the z-domain) and derive the effect the described filter will have on that frequency.
>> >
>> > To expand on that: When we graph the filter response, the transfer function is what's getting graphed. A magnitude chart depicts the logarithm of the transfer function's magnitude for e^(iw) where w is angular frequency; a phase chart depicts the imaginary part of the logarithm.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden