Re: [music-dsp] FIR blog post & interactive demo

[STEFFAN DIEDRICHSEN]

Like many other things ….

Steffan 

> On 19.03.2020|KW12, at 17:01, Ethan Fenn  wrote:
> 
> So interestingly those two #define's together would have no effect!
> 

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Fenn]

As long as we're going off the rails...

 This provoked me into learning something new:
https://stackoverflow.com/questions/24177503/how-does-the-c-preprocessor-handle-circular-dependencies

So interestingly those two #define's together would have no effect!

-Ethan



On Thu, Mar 19, 2020 at 7:34 AM STEFFAN DIEDRICHSEN 
wrote:

> #define analog digital
> #define digital analog
>
> and now read again ….
>
>
> Best,
>
> Steffan
>
>
> > On 19.03.2020|KW12, at 12:31, Theo Verelst  wrote:
> >
> > Maybe a side remark, interesting nevertheless: the filtering in digital
> domain, as
> > compared with the analog good ol' electronics filters isn't the same in
> any of the
> > important interpretations of sampled signals being put on any regular
> digital to
> > analog converter, by and large regardless of the sampled data and it's
> known properties
> > offered to the digital filter.
> >
> > So, reconstructing the digital simulation of an analog filter into a
> electronic
> > signal through either a (theoretically , or near-) perfect
> reconstruction DAC or an
> > ordinary DAC with any of the widely used limited-time interval over
> sampled  FIR or IIR
> > simplified "reconstruction" filters, isn't going to yield a perfect
> equivalent of a
> > normal, phase shift based electronics (or mechanics based) filter. Maybe
> unfortunately,
> > but it's only an approximation, and no theoretically pleasing sounding
> mathematical
> > derivation of filter properties is going to change that.
> >
> > It is possible to construct digital signals, where givens are hard-known
> about the signal
> > which given a certain DAC will 'reconstruct' or simply result in an
> output signal which
> > approaches a certain engineered ideal to any degree of accuracy. In
> general though, the
> > signal between samples can only be known through perfect reconstruction
> filtering
> > (taking infinite time and resources), and DACs that are used in studio
> and consumer
> > equipment should be thoroughly signal prepared by pre-conditioning the
> digital signal
> > feeding it such that it's very limited reconstruction filtering is used
> such that certain
> > output signal ideals are approximated to the required degree of accuracy.
> >
> > Including even a modest filter in that picture isn't easy!
> >
> > Theo V.
> > ___
> > dupswapdrop: music-dsp mailing list
> > music-dsp@music.columbia.edu
> > https://lists.columbia.edu/mailman/listinfo/music-dsp
> >
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[STEFFAN DIEDRICHSEN]

#define analog digital
#define digital analog

and now read again ….


Best,

Steffan


> On 19.03.2020|KW12, at 12:31, Theo Verelst  wrote:
> 
> Maybe a side remark, interesting nevertheless: the filtering in digital 
> domain, as
> compared with the analog good ol' electronics filters isn't the same in any 
> of the
> important interpretations of sampled signals being put on any regular digital 
> to
> analog converter, by and large regardless of the sampled data and it's known 
> properties
> offered to the digital filter.
> 
> So, reconstructing the digital simulation of an analog filter into a 
> electronic
> signal through either a (theoretically , or near-) perfect reconstruction DAC 
> or an
> ordinary DAC with any of the widely used limited-time interval over sampled  
> FIR or IIR
> simplified "reconstruction" filters, isn't going to yield a perfect 
> equivalent of a
> normal, phase shift based electronics (or mechanics based) filter. Maybe 
> unfortunately,
> but it's only an approximation, and no theoretically pleasing sounding 
> mathematical
> derivation of filter properties is going to change that.
> 
> It is possible to construct digital signals, where givens are hard-known 
> about the signal
> which given a certain DAC will 'reconstruct' or simply result in an output 
> signal which
> approaches a certain engineered ideal to any degree of accuracy. In general 
> though, the
> signal between samples can only be known through perfect reconstruction 
> filtering
> (taking infinite time and resources), and DACs that are used in studio and 
> consumer
> equipment should be thoroughly signal prepared by pre-conditioning the 
> digital signal
> feeding it such that it's very limited reconstruction filtering is used such 
> that certain
> output signal ideals are approximated to the required degree of accuracy.
> 
> Including even a modest filter in that picture isn't easy!
> 
> Theo V.
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
> 

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

Hi Eric

I'm sure your filterbank EQ sounds fine. Aliasing should be contained to a
very low level if appropriate windows/overlap are used and the filter
response isn't pushed to any extremes.

But, zero-phase (offline) processing is straightforward to achieve with
FIR. You just do a linear-phase design, and then compensate the output by
exactly that delay. Opinions differ as to whether linear phase is
preferable to minimum phase in audio terms, due to issues like pre-echo.
This is a moot point for mild EQ settings, which is why you most often see
linear/zero phase EQs used in mastering contexts.

Zero-phase (offline) IIR can be also be achieved by filtering in two
passes: one forward in time, and the other backwards in time. However this
requires the filter design to be a "square root" of the desired response,
so there is some extra work compared to the FIR flavor.

But, note that linear phase FIR requires the roots to come in reciprocal
pairs, which is an equivalent "squared response" constraint. I.e., you can
design a linear phase FIR by starting with a min-phase FIR of half the
length (and square root of the desired response), and then convolving it
with its time-reversal, just as in the IIR case.

Ethan

On Sun, Mar 15, 2020 at 6:06 PM Zhiguang Eric Zhang  wrote:

>
> Hi Ethan,
>
>
> It's been a few years since I've ran or heard this FFT filterbank EQ.  I
> do remember it being quite clean, indeed, I chose to work on it precisely
> because I realized that it could be designed to be zero-phase (meaning no
> phase distortion like you get from traditional FIR/IIR eqs).
>
> The 'perfect reconstruction' dogma is tricky because you have to remember
> that we are also discussing this in the context of audio coding and
> compression, where the coefficients are necessarily changed in order to get
> coding gain and also quantization noise (which is masked through
> application of the psychoacoustic model, etc).
>
> I urge you to take a look or even run the algorithm in my github with
> audio if you want to hear whether or not there is quantization noise from
> this FFT EQ or not (from changing the coefficients, etc).
>
>
> cheers,
> Eric Z
> https://www.github.com/kardashevian
>
> On Fri, Mar 13, 2020 at 6:18 PM Ethan Duni  wrote:
>
>> On Thu, Mar 12, 2020 at 9:35 PM robert bristow-johnson <
>> r...@audioimagination.com> wrote:
>>
>>>  i am not always persuaded that the analysis window is preserved in the
>>> frequency-domain modification operation.
>>
>>
>> It definitely is *not* preserved under modification, generally.
>>
>> The Perfect Reconstruction condition assumes that there is no
>> modification to the coefficients. It's just a basic guarantee that the
>> filterbank is actually able to reconstruct the signal to begin with. The
>> details of the windows/zero-padding determine exactly what happens to all
>> of the block processing artifacts when you modify things.
>>
>> if it's a phase vocoder and you do the Miller Puckette thing and apply
>>> the same phase to a entire spectral peak, then supposedly the window shape
>>> is preserved on each sinusoidal component.
>>
>>
>> Even that is only approximate IIRC, in that it assumes well-separated
>> sinusoids or similar?
>>
>> The larger point being that preserving window shape under modification is
>> an exceptional case that requires special handling.
>>
>> for analysis, there might be other properties of the window that is more
>>> important than being complementary.
>>>
>>
>> That's true enough: this isn't as crucial in analysis-only as it is for
>> synthesis. Although, I do consider Parseval to be pretty bedrock in terms
>> of DSP intuition, and would not want to introduce frame-rate modulations
>> into analysis without a clear reason (of which there are many good
>> examples, don't get me wrong).
>>
>>
>>> if, after analysis, i am modifying each Gaussian pulse and inverse DFT
>>> back to the time domain, i will have a Gaussian window effectively on the
>>> output frame.  by multiplying by a Hann window and dividing by the original
>>> Gaussian window, the result has a Hann window shape and that should be
>>> complementary in the overlap-add.
>>>
>>
>> So, a relevant distinction here is whether an STFT filterbank uses
>> matching analysis and synthesis windows. The PR condition is that their
>> product obeys COLA.
>>
>> In the vanilla case, the analysis and synthesis windows are constrained
>> to match (actually they're time-reversals of one another, but that only
>> matters for asymmetric windows). Then, the PR condition is COLA on the
>> square of the (common) window, and the appropriate window is of "square
>> root" type, such as cosine. This is a "balanced" design, in that the
>> analyzer and synthesizer play equal roles in the windowing.
>>
>> Note that this matching constraint removes many degrees of freedom from
>> the window design. In general, for mismatched analysis and synthesis
>> windows, the PR condition is very "loose." For example, you can 

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

Hi Ethan,


It's been a few years since I've ran or heard this FFT filterbank EQ.  I do
remember it being quite clean, indeed, I chose to work on it precisely
because I realized that it could be designed to be zero-phase (meaning no
phase distortion like you get from traditional FIR/IIR eqs).

The 'perfect reconstruction' dogma is tricky because you have to remember
that we are also discussing this in the context of audio coding and
compression, where the coefficients are necessarily changed in order to get
coding gain and also quantization noise (which is masked through
application of the psychoacoustic model, etc).

I urge you to take a look or even run the algorithm in my github with audio
if you want to hear whether or not there is quantization noise from this
FFT EQ or not (from changing the coefficients, etc).


cheers,
Eric Z
https://www.github.com/kardashevian

On Fri, Mar 13, 2020 at 6:18 PM Ethan Duni  wrote:

> On Thu, Mar 12, 2020 at 9:35 PM robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>  i am not always persuaded that the analysis window is preserved in the
>> frequency-domain modification operation.
>
>
> It definitely is *not* preserved under modification, generally.
>
> The Perfect Reconstruction condition assumes that there is no modification
> to the coefficients. It's just a basic guarantee that the filterbank is
> actually able to reconstruct the signal to begin with. The details of the
> windows/zero-padding determine exactly what happens to all of the block
> processing artifacts when you modify things.
>
> if it's a phase vocoder and you do the Miller Puckette thing and apply the
>> same phase to a entire spectral peak, then supposedly the window shape is
>> preserved on each sinusoidal component.
>
>
> Even that is only approximate IIRC, in that it assumes well-separated
> sinusoids or similar?
>
> The larger point being that preserving window shape under modification is
> an exceptional case that requires special handling.
>
> for analysis, there might be other properties of the window that is more
>> important than being complementary.
>>
>
> That's true enough: this isn't as crucial in analysis-only as it is for
> synthesis. Although, I do consider Parseval to be pretty bedrock in terms
> of DSP intuition, and would not want to introduce frame-rate modulations
> into analysis without a clear reason (of which there are many good
> examples, don't get me wrong).
>
>
>> if, after analysis, i am modifying each Gaussian pulse and inverse DFT
>> back to the time domain, i will have a Gaussian window effectively on the
>> output frame.  by multiplying by a Hann window and dividing by the original
>> Gaussian window, the result has a Hann window shape and that should be
>> complementary in the overlap-add.
>>
>
> So, a relevant distinction here is whether an STFT filterbank uses
> matching analysis and synthesis windows. The PR condition is that their
> product obeys COLA.
>
> In the vanilla case, the analysis and synthesis windows are constrained to
> match (actually they're time-reversals of one another, but that only
> matters for asymmetric windows). Then, the PR condition is COLA on the
> square of the (common) window, and the appropriate window is of "square
> root" type, such as cosine. This is a "balanced" design, in that the
> analyzer and synthesizer play equal roles in the windowing.
>
> Note that this matching constraint removes many degrees of freedom from
> the window design. In general, for mismatched analysis and synthesis
> windows, the PR condition is very "loose." For example, you can use
> literally anything you want for the analysis window, provided the values
> are finite and non-zero (negative is okay!). Then you can pick any COLA
> window, and solve for the synthesis window as their ratio. In this way you
> can design PR filterbanks with arbitrarily bad performance :P
>
> So for the mismatched case, we need some additional design principle(s) to
> drive the window designs. Offhand, there seem to be two notable approaches
> to this. One is that rectangular "windows" are desired on the synthesis
> side in order to accommodate zero-padding/fast convolution type operation.
> Then, the analysis window is whatever COLA window you care to use for
> analysis purposes. As discussed, this is only appropriate for when the
> modification is constrained to be a length-K FIR kernel.
>
> The other is like your Gaussian example where you want to use a particular
> window for analysis/modification reasons, and then need to square that with
> the PR condition on the synthesis side. The downside here is that the
> resulting synthesis windows are not as well behaved in terms of suppressing
> block processing artifacts. They tend to become heavy-shouldered, exhibit
> regions of amplification, etc. This can be worth it, but only if you gain
> enough from the analysis/modification properties.
>
>
>> > Rectangular windows are a perfectly valid choice here, albeit one 

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

On Thu, Mar 12, 2020 at 9:35 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>  i am not always persuaded that the analysis window is preserved in the
> frequency-domain modification operation.


It definitely is *not* preserved under modification, generally.

The Perfect Reconstruction condition assumes that there is no modification
to the coefficients. It's just a basic guarantee that the filterbank is
actually able to reconstruct the signal to begin with. The details of the
windows/zero-padding determine exactly what happens to all of the block
processing artifacts when you modify things.

if it's a phase vocoder and you do the Miller Puckette thing and apply the
> same phase to a entire spectral peak, then supposedly the window shape is
> preserved on each sinusoidal component.


Even that is only approximate IIRC, in that it assumes well-separated
sinusoids or similar?

The larger point being that preserving window shape under modification is
an exceptional case that requires special handling.

for analysis, there might be other properties of the window that is more
> important than being complementary.
>

That's true enough: this isn't as crucial in analysis-only as it is for
synthesis. Although, I do consider Parseval to be pretty bedrock in terms
of DSP intuition, and would not want to introduce frame-rate modulations
into analysis without a clear reason (of which there are many good
examples, don't get me wrong).


> if, after analysis, i am modifying each Gaussian pulse and inverse DFT
> back to the time domain, i will have a Gaussian window effectively on the
> output frame.  by multiplying by a Hann window and dividing by the original
> Gaussian window, the result has a Hann window shape and that should be
> complementary in the overlap-add.
>

So, a relevant distinction here is whether an STFT filterbank uses matching
analysis and synthesis windows. The PR condition is that their product
obeys COLA.

In the vanilla case, the analysis and synthesis windows are constrained to
match (actually they're time-reversals of one another, but that only
matters for asymmetric windows). Then, the PR condition is COLA on the
square of the (common) window, and the appropriate window is of "square
root" type, such as cosine. This is a "balanced" design, in that the
analyzer and synthesizer play equal roles in the windowing.

Note that this matching constraint removes many degrees of freedom from the
window design. In general, for mismatched analysis and synthesis windows,
the PR condition is very "loose." For example, you can use literally
anything you want for the analysis window, provided the values are finite
and non-zero (negative is okay!). Then you can pick any COLA window, and
solve for the synthesis window as their ratio. In this way you can design
PR filterbanks with arbitrarily bad performance :P

So for the mismatched case, we need some additional design principle(s) to
drive the window designs. Offhand, there seem to be two notable approaches
to this. One is that rectangular "windows" are desired on the synthesis
side in order to accommodate zero-padding/fast convolution type operation.
Then, the analysis window is whatever COLA window you care to use for
analysis purposes. As discussed, this is only appropriate for when the
modification is constrained to be a length-K FIR kernel.

The other is like your Gaussian example where you want to use a particular
window for analysis/modification reasons, and then need to square that with
the PR condition on the synthesis side. The downside here is that the
resulting synthesis windows are not as well behaved in terms of suppressing
block processing artifacts. They tend to become heavy-shouldered, exhibit
regions of amplification, etc. This can be worth it, but only if you gain
enough from the analysis/modification properties.


> > Rectangular windows are a perfectly valid choice here, albeit one with
> poor sidelobe suppression.
>
> but it doesn't matter with overlap-add fast convolution.  somehow, the
> sidelobe effects come out in the wash, because we can insure (to finite
> precision) the correctness of the output with a time-domain analysis.
>

Right, the rectangular windows are not being used for spectral estimation
in the fast convolution context, so their spectral properties are
irrelevant. They just represent a time-domain accounting of what the
circular convolution is doing.


> so you're oversampling in the frequency domain because you're zero-padding
> in the time domain.
>

Correct, zero-padding in the time domain is equivalent to upsampling in the
frequency domain.


> > Note that this equivalence happens because we are adding an additional
> time-variant stage (zero-padding/raw OLA), to explicitly correct for the
> time-variant effects of the underlying DFT operation. This is the block
> processing analog of upsampling a scalar signal by K so that we can apply
> an order-K polynomial nonlinearity without aliasing.
>
> where 

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 12, 2020 5:35 PM Ethan Duni  wrote:
> 
> 
> Hi Robert
> 
> 
> On Wed, Mar 11, 2020 at 4:19 PM robert bristow-johnson 
>  wrote:
> > 
> >  i don't think it's too generic for "STFT processing". step #4 is pretty 
> > generic.
> 
> I think the part that chafes my intuition is more that the windows in steps 
> #2 and #6 should "match" in some way, and obey an appropriate perfect 
> reconstruction condition.

i think we're supposed to multiply the analysis window with the synthesis 
window to get a net effective window, but i am not always persuaded that the 
analysis window is preserved in the frequency-domain modification operation.  
if it's a phase vocoder and you do the Miller Puckette thing and apply the same 
phase to a entire spectral peak, then supposedly the window shape is preserved 
on each sinusoidal component.  then i would use no synthesis window.  that's 
sorta what i was thinking in that Stack Exchange thing that i pointed to, but 
in a more general STFT process, i might want to use the Gaussian window, 
because the result of each sinusoidal component is a single peak with the 
Gaussian shape.  we can even measure the rate of change of frequency related to 
each peak.  being Gaussian, there shouldn't be side lobes to worry about.

> I think of STFT as intentionally wiping out any spill-over effects between 
> frames with synthesis windowing, to impose a particular time-frequency tiling.

yup.  and unlike wavelet, the tiles all have the same widths in time and 
frequency.

> Whereas fast convolution is defined by how it explicitly accounts for 
> spill-over between frames.

yup.  you don't even think of "windowing effects", even with overlap-add in 
which you are multiplying by 1 or 0, which is a rectangular window. but we 
consider the operation in the time domain, confirm linearity and can treat each 
frame as it's own linear-time output and add the FIR output from frame m to 
that of frame m+1.  and the end tail of frame end adds the beginning tail of 
frame m+1.  doesn't get affected by the windowing effects. 

> 
> My intuition isn't definitive, but that's what comes to mind. In any case, 
> "STFT processing" is a very generic term.

i think of it as the series of DFTs of windowed frames of audio.

> > 
> >  here is my attempt to quantitatively define and describe the STFT:
> >  
> >  
> > https://dsp.stackexchange.com/questions/45625/is-windowed-fourier-transform-a-synonym-for-stft/45631#45631
> >  
> 
> 
> Cool, that's a helpful reference for this stuff.

but i didn't account for both analysis and synthesis windows.  but whatever is 
the resultant window for the output grain y_m[n], you just add them up, 
properly positioned in time.


> In terms of "what even is STFT", it seems there is more consensus on the 
> analysis part. Many STFT applications don't involve any synthesis or 
> filtering, but only frequency domain parameter estimation.

that's right.

> For analysis-only, probably everyone agrees that STFT consists of some 
> Constant OverLap Add (COLA) window scheme, followed by DFT.

well, no, i don't agree.  for analysis-only, i don't know why you need 
complementary windows (which is what i think you mean by COLA).  it's in the 
synthesis where overlap-adding is done.  assuming the sinusoidal components in 
your output are phase aligned between adjacent frames, if you don't want a dip 
in the amplitude of each sinusoidal component you want their windows to add to 
1.  but for analysis, there might be other properties of the window that is 
more important than being complementary.

again, i like the Gaussian window for analysis (because it has smooth Gaussian 
pulses for each sinusoidal component in the frequency domain), but it's not 
complementary.  if, after analysis, i am modifying each Gaussian pulse and 
inverse DFT back to the time domain, i will have a Gaussian window effectively 
on the output frame.  by multiplying by a Hann window and dividing by the 
original Gaussian window, the result has a Hann window shape and that should be 
complementary in the overlap-add.

> Rectangular windows are a perfectly valid choice here, albeit one with poor 
> sidelobe suppression.

but it doesn't matter with overlap-add fast convolution.  somehow, the sidelobe 
effects come out in the wash, because we can insure (to finite precision) the 
correctness of the output with a time-domain analysis.

> Note that there are two potential layers of oversampling available: one from 
> overlapped windows, and another from zero-padding.
> 
> To summarize my understanding of your earlier remarks, the situation gets 
> fuzzier for synthesis. Broadly, there are two basic approaches. One is to 
> keep the COLA analysis and use raw (unwindowed) overlap-add for synthesis. 
> The other is to add synthesis windows, in which case the PR condition becomes 
> COLA on the product of the analysis and synthesis windows (I'd call this 
> "STFT filter bank" or maybe "FFT phase vocoder" depending on 

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

Hi Robert

On Wed, Mar 11, 2020 at 4:19 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
> i don't think it's too generic for "STFT processing".  step #4 is pretty
> generic.
>

I think the part that chafes my intuition is more that the windows in steps
#2 and #6 should "match" in some way, and obey an appropriate perfect
reconstruction condition. I think of STFT as intentionally wiping out any
spill-over effects between frames with synthesis windowing, to impose a
particular time-frequency tiling. Whereas fast convolution is defined by
how it explicitly accounts for spill-over between frames.

My intuition isn't definitive, but that's what comes to mind. In any case,
"STFT processing" is a very generic term.


>
> here is my attempt to quantitatively define and describe the STFT:
>
>
> https://dsp.stackexchange.com/questions/45625/is-windowed-fourier-transform-a-synonym-for-stft/45631#45631
>


Cool, that's a helpful reference for this stuff.

In terms of "what even is STFT", it seems there is more consensus on the
analysis part. Many STFT applications don't involve any synthesis or
filtering, but only frequency domain parameter estimation. For
analysis-only, probably everyone agrees that STFT consists of some Constant
OverLap Add (COLA) window scheme, followed by DFT. Rectangular windows are
a perfectly valid choice here, albeit one with poor sidelobe suppression.
Note that there are two potential layers of oversampling available: one
from overlapped windows, and another from zero-padding.

To summarize my understanding of your earlier remarks, the situation gets
fuzzier for synthesis. Broadly, there are two basic approaches. One is to
keep the COLA analysis and use raw (unwindowed) overlap-add for synthesis.
The other is to add synthesis windows, in which case the PR condition
becomes COLA on the product of the analysis and synthesis windows (I'd call
this "STFT filter bank" or maybe "FFT phase vocoder" depending on the
audience/application).

The first approach has immediate problems if the DFT values are modified,
because the COLA condition is not enforced on the output. For the special
case that the modification is multiplication by a DFT kernel that
corresponds to a length-K FIR filter, this can be accommodated by
zero-padding type oversampling, which results in the Overlap-Add flavor of
fast convolution to account for the inter frame effects. Note that this
implicitly extends the (raw) overlap-add region in synthesis accordingly -
the analysis windows obey COLA, but the synthesis "windows" have different
support and are not part of the PR condition.

As you point out, this works for any COLA analysis window scheme, not just
rectangular, although the efficiency is correspondingly reduced with
overlap. This system is equivalent to a SISO FIR, up to finite word length
effects. Note that this equivalence happens because we are adding an
additional time-variant stage (zero-padding/raw OLA), to explicitly correct
for the time-variant effects of the underlying DFT operation. This is the
block processing analog of upsampling a scalar signal by K so that we can
apply an order-K polynomial nonlinearity without aliasing.

The synthesis window approach is more general in the types of modifications
that can be accommodated (spectral subtraction, nonlinear operations,
etc.). This is because it allows time domain aliasing to occur, but
explicitly suppresses it by attenuating the frame edges. This is also
throwing oversampling at the problem, but of the overlap type instead of
the zero-padding type.

You can also apply zero-padding on top of synthesis windows to further
increase the margin for circular aliasing. However unlike fast convolution
you would still apply the synthesis windows to remove spill-over between
frames and not use raw OLA. This is required for the filterbank PR
condition. There is no equivalent SISO system in this case. The level of
aliasing is determined by how hard you push on the response, and how much
overlap/zero-padding you can afford. I.e., it's ultimately engineered/tuned
rather than designed out explicitly as in fast convolution.

We're all on the same page on this stuff, I hope?

Ethan
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 11, 2020 6:53 PM Ethan Duni  wrote:
> 
> 
> On Tue, Mar 10, 2020 at 8:36 AM Spencer Russell  wrote:
> > 
> >  The point I'm making here is that overlap-add fast FIR is a special case 
> > of STFT-domain multiplication and resynthesis. I'm defining the standard 
> > STFT pipeline here as:
> >  
> >  1. slice your signal into frames
> >  2. pointwise-multiply an analysis window by each frame
> >  3. perform `rfft` on each frame to give the STFT domain representation
> >  4. modify the STFT representation
> >  5. perform `irfft` on each frame
> >  6. pointwise-multiply a synthesis window on each frame
> >  7. overlap-add each frame to get the resulting time-domain signal
> 
> I don't think there is a precise definition of STFT, but IMO this is too 
> generic.

i don't think it's too generic for "STFT processing".  step #4 is pretty 
generic.

here is my attempt to quantitatively define and describe the STFT:

 
https://dsp.stackexchange.com/questions/45625/is-windowed-fourier-transform-a-synonym-for-stft/45631#45631
 

> The fundamental design parameters for an STFT system are the window shapes 
> and overlaps, but in fast convolution those degrees of freedom are eliminated 
> entirely.
> 

in most cases.  and while it's not as "fast", you *can* do overlap-add fast 
convolution with a Hann window (instead of rectangular) and have a frame hop of 
about 1/2 as the regular old overlap-add fast convolution.  it's only half as 
efficient, but i would still call it "fast convolution" and it is also a subset 
of STFT processing.  this is the "small intersection" of the Venn diagrams 
between the two that i meant earlier.

> The reason this distinction is important is that STFT is for cases where you 
> want to estimate the response in the frequency domain. If you can't apply a 
> useful analysis window, then there isn't much point.
> 

i think i agree with this, too.

--
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

On Tue, Mar 10, 2020 at 8:36 AM Spencer Russell  wrote:

>
> The point I'm making here is that overlap-add fast FIR is a special case
> of STFT-domain multiplication and resynthesis. I'm defining the standard
> STFT pipeline here as:
>
> 1. slice your signal into frames
> 2. pointwise-multiply an analysis window by each frame
> 3. perform `rfft` on each frame to give the STFT domain representation
> 4. modify the STFT representation
> 5. perform `irfft` on each frame
> 6. pointwise-multiply a synthesis window on each frame
> 7. overlap-add each frame to get the resulting time-domain signal
>

I don't think there is a precise definition of STFT, but IMO this is too
generic. The fundamental design parameters for an STFT system are the
window shapes and overlaps, but in fast convolution those degrees of
freedom are eliminated entirely.

The reason this distinction is important is that STFT is for cases where
you want to estimate the response in the frequency domain. If you can't
apply a useful analysis window, then there isn't much point.

If you already have your response expressed as length-K FIRs in the time
domain, then you don't need STFT. You just apply the FIRs directly (using
fast convolution if appropriate). STFT is not an attractive topology just
for implementing time-varying FIR, as such.


>
> This is just to make the point that fast FIR is a special case of STFT
> processing.


So, a useful distinction here is "oversampled filterbanks". The way that
fast convolution works is through oversampling/zero-padding. This creates
margin in the time domain to accommodate aliasing. You can apply
oversampling - in any amount - to an STFT system to reduce the aliasing at
the cost of increased overhead. Fast convolution is sort of a corner case,
where you can eliminate the aliasing entirely with finite oversampling, at
the cost of losing your analysis and synthesis windowing (and introducing
extra spill-over in the synthesis).


> > Right, but if you are using length K FFT and zero-padding by K-1, then
> > the hop size is 1 sample and there are no windows.
>
> Whoops, this was dumb on my part. I was not referring to a hop size of 1!
> Hopefully my explanation above is more clear.
>

But, the reason I made this point is you specified that the FFTs are length
K. If you are using length N+K FFTs, then the estimated response is length
N+K, and we are back to the original problem of ensuring that a DFT
response is appropriately time limited.

This can be done by brute force of course: length N+K IFFT => length K
window => length N+K FFT. But that is the same complexity as the STFT
signal path! So, we're back to smoothing/conditioning in the frequency
domain, windowing in the time domain, and accepting some engineered level
of time domain aliasing. The difference is that the oversampling (N+K vs N)
has given us additional margin to accommodate it (i.e., we can tolerate
sharper filters).

Fast convolution is for cases where filter design is done offline: then all
those filter computations can be done ahead of time,  there is no aliasing,
and everything is great! But if the filters get estimated at runtime then
you run into prohibitive costs. Since STFT is the latter case, in practice
fast convolution isn't much help. The two approaches are orthogonal in that
sense, despite their structural similarities.


>
> You could think of STFT multiplication as applying a different FIR filter
> to each frame and then cross-fading between them, which is clearly not the
> same as continually varying the FIR parameters in the time domain.


By linearity, cross-fading between two fixed FIRs is equivalent to applying
a single time-varying FIR with the coefficients cross-faded the same way
(at least for direct form). The synthesis window defines this cross-fade
behavior for STFT.

It's still not exactly equivalent, because the STFT is a time-variant MIMO
system that does not admit an exact SISO equivalent. However, the
difference is really more that it creates aliasing (which should be very
low level if properly designed), and not that you can't make an FIR with
comparable response. It's not trivial, but it is relatively straightforward
to take an STFT response, consider the window used to obtain it, and spit
out a corresponding FIR. These can then be interpolated according to the
synthesis windows to operate a comparable time-varying SISO FIR system.

Such a system might actually be preferable to the STFT synthesis chain,
since it wouldn't create circular convolution artifacts in the first place.
However, it is expensive - you're already running the STFT analysis chain,
converting the filter to the time domain is *more* expensive than the STFT
synthesis, and then you still have to run the time-varying FIR on top of
that.


> They do seem to have a tight relationship though, and when we do STFT
> modifications it seems that in some contexts we're trying to approximate
> the time-varying FIR filter.
>

Yeah, multiplying DFTs is 

Re: [music-dsp] FIR blog post & interactive demo

[Richard Dobson]

On 10/03/2020 19:45, Ethan Duni wrote:




On Mar 10, 2020, at 3:38 AM, Richard Dobson  wrote:

You can have windows when hop size is 1 sample (as used in the sliding phase 
vocoder (SPV) proposed by Andy Moorer exactly 20 years ago, and the focus of a 
research project I was part of around 2007). ...


That’s very interesting, I’d certainly like to read more.

Ethan


Our ICMC paper can be found here, along with a few beguiling sound examples:

http://dream.cs.bath.ac.uk/SDFT/

Richard Dobson
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

> On Mar 10, 2020, at 3:38 AM, Richard Dobson  wrote:
> 
> You can have windows when hop size is 1 sample (as used in the sliding phase 
> vocoder (SPV) proposed by Andy Moorer exactly 20 years ago, and the focus of 
> a research project I was part of around 2007). So long as the window is based 
> on sines and cosines, it can be done bin by bin as a frequency-domain 
> covolution. The SPV has been implemented in Csound for those cases where 
> single-sample control rates were being used. For larger block sizes it 
> reverts to the standard block-based streaming phase vocoder.

That’s very interesting, I’d certainly like to read more.

Ethan
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 10, 2020 11:34 AM Spencer Russell  wrote:
> 
>  
> Thanks for your expanded notes, RBJ. I haven't found anything that I disagree 
> with or that contradicts what I was saying earlier - I'm not sure if they 
> were intended as expanded context or if there was something you were 
> disagreeing with.

i think we're all on the same page.  i still view the Venn diagram of this 
having a very small intersection between the notions of "Fast Convolution" 
(that has two techniques called "Overlap-Add" and "Overlap-Scrap", a.k.a. 
"Overlap-Save") and STFT analysis/resynthesis processing, of which the Phase 
Vocoder is the most common application that i see.

> 
> On March 8, 2020 7:55 PM Ethan Duni  wrote:
> > 
> > Fast FIR is a different thing than an FFT filter bank.
> > 
> > You can combine the two approaches but I don’t think that’s what is being 
> > done here?

and that was my question, too.  but i think that we're all on the same page, 
but we might have semantic issues or maybe differences in details.

> 
> The point I'm making here is that overlap-add fast FIR is a special case of 
> STFT-domain multiplication and resynthesis. I'm defining the standard STFT 
> pipeline here as:
> 

i think i am in total agreement, but i want to point out where i see the small 
intersection on the Venn diagram between the STFT thingie and fast-convolution.

> 1. slice your signal into frames

(a) but, it some cases the frames are overlapping.  in the simple 
fast-convolution using overlap-add, there is no overlap and the rectangular 
window width, F, and frame hop, H, are the same number.

> 2. pointwise-multiply an analysis window by each frame

(b) but with fast-convolution using overlap-scrap (or "overlap-save") there is 
no windowing of any kind.  the frame width is F=N, but the frame hop is H 3. perform `rfft` on each frame to give the STFT domain representation
> 4. modify the STFT representation

(d) now right here, "modify" can mean a whole shitload of different things, 
depending on the application.  but, for conceptualizaion, if you take whatever 
the result of the modification is and complex divide it by whatever the 
spectrum was before modification, you can, assuming no divides-by-zero, think 
of that modification as a point-by-point multiplication or 
pseudo-multiplication by a "frequency response" or pseudo-frequency-response.  

**if** that frequency response is the DFT of an impulse response or 
pseudo-impulse-response that has non-zero length no longer than N-F+1 (so there 
are F-1 zeros at the end of the impulse response or pseudo-impulse response), 
there will be no time aliasing as a consequence of this modification operation. 
 however, if that modification is equivalent to multiplying by a frequency 
response that corresponds to an impulse response that *is* longer than N-F+1, 
then time-domain aliasing occurs, but we might hope that it's around the side 
tails of the synthesis window and will be attenuated.

> 5. perform `irfft` on each frame
> 6. pointwise-multiply a synthesis window on each frame

(e) now there is none of this synthesis window used for regular-old 
fast-convolution.  but in a phase vocoder there very well may be.  Miller 
Puckette and Jean Laroche mentioned using a Hann on the analysis window and 
another Hann on the synthesis window, they argue that the effect is Hann^2 and 
show with 75% overlap, that it adds to 1 (but i wouldn't call the Hann^2 
"complementary").

(f) but i am suspect of the preservation of the analysis Hann window after the 
modification step #4.  in my 2001 Intraframe Time-Scaling paper ( 
https://www.researchgate.net/publication/3927319_Intraframe_time-scaling_of_nonstationary_sinusoids_within_the_phase_vocoder
 ), my suggestion is to use a Gaussian window that gets very close to zero at 
the cutoff tails.  i show that that modification done in the frequency domain 
preserves the Gaussian window for each frequency component.  then when the iFFT 
is done, we know we have a Gaussian window, **but** that is not complementary.  
so then we multiply (in the time-domain) by a synthesis window that is Hann 
divided by Gaussian to change the window to complementary Hann.  (after that we 
overlap add.)

> 7. overlap-add each frame to get the resulting time-domain signal

(g) except for overlap-scrap fast convolution.  in that case, you output (or 
"save") the correct H samples (which is less than F=N), scrap the N-H samples 
that are contaminated by time aliasing, and move on to the next frame.

these are the "little details" that i am picking bones about.

but Spencer, i think that you and Ethan and i are all on the same page.  not 
picking on Zhiguang Zhang (not sure which is your "given name" and which is 
your surname or family name, and i wouldn't mind if you make it clear, of if 
you want us to use "Eric" instead) but i just want to make clear to him about 
these little details (and to correct a few actual falsehoods such as the DFT 
being TI).  i 

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

Thanks for your expanded notes, RBJ. I haven't found anything that I disagree 
with or that contradicts what I was saying earlier - I'm not sure if they were 
intended as expanded context or if there was something you were disagreeing 
with.

On March 8, 2020 7:55 PM Ethan Duni  wrote:
> 
> Fast FIR is a different thing than an FFT filter bank.
> 
> You can combine the two approaches but I don’t think that’s what is being 
> done here?

The point I'm making here is that overlap-add fast FIR is a special case of 
STFT-domain multiplication and resynthesis. I'm defining the standard STFT 
pipeline here as:

1. slice your signal into frames
2. pointwise-multiply an analysis window by each frame
3. perform `rfft` on each frame to give the STFT domain representation
4. modify the STFT representation
5. perform `irfft` on each frame
6. pointwise-multiply a synthesis window on each frame
7. overlap-add each frame to get the resulting time-domain signal

See below for more.

On Mon, Mar 9, 2020, at 5:44 PM, robert bristow-johnson wrote:
> 
> > On March 9, 2020 10:15 AM Spencer Russell  wrote:
> > 
> > 
> > I think we're mostly on the same page, Ethan.
> 
> well, i think that i am on the same page as Ethan.
> 
> > Though even with STFT-domain time-variant filtering (such as with noise 
> > reduction, or mask-based source separation) it would seem you could still 
> > zero-pad each input frame to eliminate any issues due to time-aliasing.
> 
> zero-padding is the sole technique that gets rid of time-aliasing.

Right - we're together here.

> let's say your FIR is of length L.  let's say that your frame hop is H 
> and frame length is F ≥ H and we're doing overlap-add.  then your F 
> samples of input (H samples are *new* samples in the current frame, F-H 
> samples are remaining from the previous frame) are considered 
> zero-padded out to infinity in both directions.  then the length of the 
> result of linear convolution is L+F-1.  now if you can guarantee that 
> the size of the DFT, which we'll call "N" (and most of the time is a 
> power of 2) is at least as large as the non-zero length of the linear 
> convolution, then the result of circular convolution of the zero-padded 
> FIR and the zero-padded frame of samples will be exactly the same.  
> that means
> 
>N ≥ L + F - 1

You are completely correct, and as far as I can tell we're in agreement here 
(again please correct me if this was meant to be a rebuttal). Specifically I'm 
talking about the case where F=H. You then perform a standard STFT with these 
parameters (Hop size H, rectangular window of size F = H, FFT length H+L-1), 
multiply each frame by the (r)FFT of your filter, then do the standard ISTFT 
with overlap-add.

Your STFT will have a height of `N/2-1` (integer division). You do the standard 
ISTFT with overlap-add, and the same hop size H. The frame size is now the full 
N. You use a "synthesis window" that's the full length N (in practice just 
taking each chunk with no windowing). Within the ISTFT process you took the 
`irfft` of each frame, which is now nonzero for some length longer than H, but 
not more than N (so there's no time aliasing).

That should be exactly the same thing as fast FIR convolution with a chunk size 
of F, but in the framework of STFT->multiply->ISTFT. The only thing that's not 
standard STFT processing is the zero-padding (to remove aliasing due to 
circular convolution, a now much-belabored point).

This is just to make the point that fast FIR is a special case of STFT 
processing. From a compute perspective this should be no less efficient than 
fast FIR (I mean, it's doing the same thing). If you do the whole STFT off-line 
then you wasted some memory materializing the whole STFT, but you could 
consider a streaming version, and at that point the implementation would look 
very similar to what you'd code up for fast FIR.

Are we all together here?

= Time Variant Filtering 

So this seems like it's the really interesting part, and usually why people 
work in the STFT domain in the first place. As RBJ mentioned, padding (ensuring 
N >= L+F-1) completely resolves time-aliasing is true whether the filter is 
stationary or time-varying.

> if it is a rectangular window, the frame length and frame hop are the 
> same, F=H, and the number of generated output samples that are valid is 
> H, and the most you can hope to get is:
> 
> H = F = N - L + 1

Right, this is the Fast FIR situation I described above.

> 
> if you cut your frame hop size, H, from F to nearly half (F+1)/2 (and 
> use a complementary window such as Hann), it is half as efficient, but 
> the crossfade is even smoother (and the frame rate is faster, so the 
> filter definition can change more often).
> 
> all of this is well-established knowledge regarding frame-by-frame 
> processing with windows and the FFT.

Yep, we're in agreement here as well. Applying a time-varying filter using 
non-overlapping rectangular windows seems like a 

Re: [music-dsp] FIR blog post & interactive demo

[Richard Dobson]

On 10/03/2020 00:41, Ethan Duni wrote:
...

Right, but if you are using length K FFT and zero-padding by K-1, then the hop 
size is 1 sample and there are no windows.



You can have windows when hop size is 1 sample (as used in the sliding 
phase vocoder (SPV) proposed by Andy Moorer exactly 20 years ago, and 
the focus of a research project I was part of around 2007). So long as 
the window is based on sines and cosines, it can be done bin by bin as a 
frequency-domain covolution. The SPV has been implemented in Csound for 
those cases where single-sample control rates were being used. For 
larger block sizes it reverts to the standard block-based streaming 
phase vocoder.


One possibly interesting aspect of the SPV then is that one sample of 
input generates one sample of output, though of course a full frame 
takes a while to develop. There are papers, some from ICMC of 2007, and 
others from various Csound and similar conferences. If people are 
interested, I can can probably find more details.


Richard Dobson
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

It is certainly possible to combine STFT with fast convolution in various ways. 
But doing so imposes significant overhead costs and constrains the overall 
design in strong ways. 

For example, this approach:

> On Mar 9, 2020, at 7:16 AM, Spencer Russell  wrote:
> 
> 
> if you have an KxN STFT (K frequency components and N frames) then then 
> zero-padding each frame by K-1 should still eliminate any time-aliasing even 
> if your filter has hard edges in the frequency domain, right?

Right, but if you are using length K FFT and zero-padding by K-1, then the hop 
size is 1 sample and there are no windows. 

This is just applying the raw IDFT of the response as an FIR, which is not 
appropriate for something estimated in a windowed filterbank domain. Deriving 
an equivalent FIR from, say, an estimated noise reduction mask is not trivial.

> 
> I understand the role of time-domain windowing in STFT processing to be 
> mostly:
> 1. Reduce frequency-domain ripple (side-lobes in each band)

Right, this is the “analysis” aspect, where the window controls the spectral 
characteristics (frequency selectivity, bandwidth, leakage, etc.)

> 2. Provide a sort of cross-fade from frame-to-frame to smooth out framing 
> effects

And that is the “synthesis” aspect, where the window controls the 
characteristics of the artifacts introduced by processing. Note that “framing 
effects” are by definition time-variant: this is a form of aliasing.

Ethan
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 8, 2020 7:55 PM Ethan Duni  wrote:
> 
> Fast FIR is a different thing than an FFT filter bank.
> 
> You can combine the two approaches but I don’t think that’s what is being 
> done here?

> On March 9, 2020 10:15 AM Spencer Russell  wrote:
> 
> 
> I think we're mostly on the same page, Ethan.

well, i think that i am on the same page as Ethan.

> Though even with STFT-domain time-variant filtering (such as with noise 
> reduction, or mask-based source separation) it would seem you could still 
> zero-pad each input frame to eliminate any issues due to time-aliasing.

zero-padding is the sole technique that gets rid of time-aliasing.

let's say your FIR is of length L.  let's say that your frame hop is H and 
frame length is F ≥ H and we're doing overlap-add.  then your F samples of 
input (H samples are *new* samples in the current frame, F-H samples are 
remaining from the previous frame) are considered zero-padded out to infinity 
in both directions.  then the length of the result of linear convolution is 
L+F-1.  now if you can guarantee that the size of the DFT, which we'll call "N" 
(and most of the time is a power of 2) is at least as large as the non-zero 
length of the linear convolution, then the result of circular convolution of 
the zero-padded FIR and the zero-padded frame of samples will be exactly the 
same.  that means

   N ≥ L + F - 1

this is always true whether the windowing is rectangular or something else.  
and, whether your FIR varies in definition or not, the length L must never be 
longer than N-F+1.  all frequency responses (which is what you multiply with in 
the frequency domain) must be the N-point DFT of an FIR limited in length to 
N-F+1.

if it is a rectangular window, the frame length and frame hop are the same, 
F=H, and the number of generated output samples that are valid is H, and the 
most you can hope to get is:

H = F = N - L + 1

now, if you want to window that input data with a complementary window, such as 
the Hann window, that's fine, but instead of having the frame hop equal to the 
frame length, the relationship between the two is

F = 2H - 1   or   H = (F+1)/2   (50% overlap)

so now, the number of valid output samples is about half as before.

H = (F+1)/2 = (N-L)/2 + 1

so the input buffer to the FFT will still be zero padded with N+1-F zeros, 
independent of the hop size.  but if you get a bigger hop size and more output 
samples per frame with a rectangular window.  and in both cases you get exactly 
the same results (up to rounding error) in either case.

now, if it is overlap-scrap (or "overlap-save") and a rectangular window (which 
is no window at all, because the data is not zero-padded), the output samples 
are "butt spliced" (no crossfade) if your FIR filter changes in frequency 
response, the new timbre of the filter is applied instantly with the new frame.

but if is is overlap-add then the F samples in the frame are zero-padded with 
N-F zeros and there is a form of crossfading, even with a rectangular window, 
from one frame to the next if the FIR filter definition changes.

if you cut your frame hop size, H, from F to nearly half (F+1)/2 (and use a 
complementary window such as Hann), it is half as efficient, but the crossfade 
is even smoother (and the frame rate is faster, so the filter definition can 
change more often).

all of this is well-established knowledge regarding frame-by-frame processing 
with windows and the FFT.

--
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

I think we're mostly on the same page, Ethan. Though even with STFT-domain 
time-variant filtering (such as with noise reduction, or mask-based source 
separation) it would seem you could still zero-pad each input frame to 
eliminate any issues due to time-aliasing. As you mention (paraphrasing), you 
can smooth out the mask which will reduce the amount of zero-padding you need, 
but if you have an KxN STFT (K frequency components and N frames) then then 
zero-padding each frame by K-1 should still eliminate any time-aliasing even if 
your filter has hard edges in the frequency domain, right?

I understand the role of time-domain windowing in STFT processing to be mostly:
1. Reduce frequency-domain ripple (side-lobes in each band)
2. Provide a sort of cross-fade from frame-to-frame to smooth out framing 
effects

In my mind doing STFT-domain masking/filtering is _roughly_ equivalent to a 
filter bank with time-varying response. In the STFT case though you're keeping 
things invariant within each frame and then cross-fading from frame to frame. 
This is a pretty intuitive/ad-hoc way of thinking on my part though - I'd love 
to see some literature that gives a more formal treatment.

-s

On Mon, Mar 9, 2020, at 12:52 AM, Ethan Duni wrote:
> 
> 
> On Sun, Mar 8, 2020 at 8:02 PM Spencer Russell  wrote:
>> In fact, the the standard STFT analysis/synthesis pipeline is the same thing 
>> as overlap-add "fast convolution" if you:
>> 
>> 1. Use a rectangular window with a length equal to your hop size
>> 2. zero-pad each input frame by the length of your FIR kernel minus 1
> 
> Indeed, the two ideas are closely related and can be combined. It's more a 
> difference in the larger approach. 
> 
> If you can specify the desired response in terms of an FIR of some fixed 
> length, then you can account for the circular effects and use fast FIR. Note 
> that this is a time-variant MIMO system constructed to be equivalent to a 
> time-invariant SISO system (modulo finite word length effects, as you say). 
> 
> Alternatively, the desired response can be specified in the STFT domain. This 
> comes up naturally in situations where it is estimated in the frequency 
> domain to begin with, such as noise suppression or channel equalization. 
> Then, circular convolution effects are controlled through a combination of 
> pre/post windowing and smoothing/conditioning of the frequency response. 
> Unlike the fast FIR case, the time-variant effects are only approximately 
> suppressed: this is a time-variant MIMO system that is *not* equivalent to 
> any time-invariant SISO system. 
> 
> So there is an extra layer of engineering needed in STFT systems to ensure 
> that time domain aliasing is adequately suppressed. With fast FIR, you just 
> calculate the correct size to zero-pad (or delete), and then there is no 
> aliasing to worry about. 
> 
> Ethan
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

On Sun, Mar 8, 2020 at 8:02 PM Spencer Russell  wrote:

> In fact, the the standard STFT analysis/synthesis pipeline is the same
> thing as overlap-add "fast convolution" if you:
>
> 1. Use a rectangular window with a length equal to your hop size
> 2. zero-pad each input frame by the length of your FIR kernel minus 1
>

Indeed, the two ideas are closely related and can be combined. It's more a
difference in the larger approach.

If you can specify the desired response in terms of an FIR of some fixed
length, then you can account for the circular effects and use fast FIR.
Note that this is a time-variant MIMO system constructed to be equivalent
to a time-invariant SISO system (modulo finite word length effects, as you
say).

Alternatively, the desired response can be specified in the STFT domain.
This comes up naturally in situations where it is estimated in the
frequency domain to begin with, such as noise suppression or channel
equalization. Then, circular convolution effects are controlled through a
combination of pre/post windowing and smoothing/conditioning of the
frequency response. Unlike the fast FIR case, the time-variant effects are
only approximately suppressed: this is a time-variant MIMO system that is
*not* equivalent to any time-invariant SISO system.

So there is an extra layer of engineering needed in STFT systems to ensure
that time domain aliasing is adequately suppressed. With fast FIR, you just
calculate the correct size to zero-pad (or delete), and then there is no
aliasing to worry about.

Ethan
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

Nowhere was it mentioned that there was an across the frame multiplication
with a scalar as far as manipulating the transform coefficients.  That
might make it time variant.  My concept was in the domain of audio
engineering which reads a side-chain signal to obtain attenuation factors
in the context of EQ.  Please see the Wavesfactory Trackspacer to get a
sense of what I mean.

On Sun, Mar 8, 2020, 11:02 PM Spencer Russell  wrote:

> On Sun, Mar 8, 2020, at 7:41 PM, Ethan Duni wrote:
>
> FFT filterbanks are time variant due to framing effects and the circular
> convolution property. They exhibit “perfect reconstruction” if you design
> the windows correctly, but this only applies if the FFT coefficients are
> not altered between analysis and synthesis. If you alter the FFT
> coefficients (i.e., “filtering”), it causes time domain aliasing.
>
>
> But you can avoid this by zero-padding before you do the FFT. In effect
> this turns circular convolution into linear convolution - the "tail" ends
> up in the zero-pading rather than wrapping around and causing
> time-aliasing. This is what overlap-add FFT convolution does.
>
> In fact, the the standard STFT analysis/synthesis pipeline is the same
> thing as overlap-add "fast convolution" if you:
>
> 1. Use a rectangular window with a length equal to your hop size
> 2. zero-pad each input frame by the length of your FIR kernel minus 1
>
> Then the regular overlap-add STFT resynthesis is the same as "fast
> convolution", and will give you the same thing (to numerical precision) you
> would get with a time-domain FIR implementation.
>
> On Mar 8, 2020, at 2:04 PM, zhiguang zhang 
> wrote:
>
> but bringing up traditional FIR/IIR filtering terminology to describe FFT
> filtering doesn't make sense in my mind.  I'm not in the audio field.  but
> yes, I do believe that the system is time invariant, but I don't have time
> to prove myself to you on this forum at this time, nor do I have any
> interest in meeting Dr Bosi at AES.
>
>
> I don't really understand this perspective - there's a tremendous amount
> of conceptual overlap between these ideas, and regimes where they are
> completely equivalent (e.g. implementing a time-invariant FIR filter in the
> frequency domain using block-by-block "fast convolution"). Certainly when
> you're doing time-variant filtering things are somewhat different (e.g.
> multiplying in the STFT domain with changing coefficients is doing some
> kind of frame-by-frame cross-fading, which will not give the same result as
> varying the parameters of an FIR filter on a sample-by-sample basis, in a
> pure time-domain implementation). That said, using the same terminology
> where we can helps highlight the places where these concepts are related.
>
> -s
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

On Sun, Mar 8, 2020, at 7:41 PM, Ethan Duni wrote:
> FFT filterbanks are time variant due to framing effects and the circular 
> convolution property. They exhibit “perfect reconstruction” if you design the 
> windows correctly, but this only applies if the FFT coefficients are not 
> altered between analysis and synthesis. If you alter the FFT coefficients 
> (i.e., “filtering”), it causes time domain aliasing. 

But you can avoid this by zero-padding before you do the FFT. In effect this 
turns circular convolution into linear convolution - the "tail" ends up in the 
zero-pading rather than wrapping around and causing time-aliasing. This is what 
overlap-add FFT convolution does.

In fact, the the standard STFT analysis/synthesis pipeline is the same thing as 
overlap-add "fast convolution" if you:

1. Use a rectangular window with a length equal to your hop size
2. zero-pad each input frame by the length of your FIR kernel minus 1

Then the regular overlap-add STFT resynthesis is the same as "fast 
convolution", and will give you the same thing (to numerical precision) you 
would get with a time-domain FIR implementation.

>> On Mar 8, 2020, at 2:04 PM, zhiguang zhang  wrote:
>> but bringing up traditional FIR/IIR filtering terminology to describe FFT 
>> filtering doesn't make sense in my mind. I'm not in the audio field. but 
>> yes, I do believe that the system is time invariant, but I don't have time 
>> to prove myself to you on this forum at this time, nor do I have any 
>> interest in meeting Dr Bosi at AES.

I don't really understand this perspective - there's a tremendous amount of 
conceptual overlap between these ideas, and regimes where they are completely 
equivalent (e.g. implementing a time-invariant FIR filter in the frequency 
domain using block-by-block "fast convolution"). Certainly when you're doing 
time-variant filtering things are somewhat different (e.g. multiplying in the 
STFT domain with changing coefficients is doing some kind of frame-by-frame 
cross-fading, which will not give the same result as varying the parameters of 
an FIR filter on a sample-by-sample basis, in a pure time-domain 
implementation). That said, using the same terminology where we can helps 
highlight the places where these concepts are related.

-s___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

so Ethan, what is your definition of time invariance?  because you say it's
not time invariant because of time domain aliasing but then you say there
is delay due to compute time.  delay due to window and compute time is
unavoidable and not to be factored into time invariance / variance.  coding
noise is to due quantization and actually the fact that coefficients
themselves are changed, because you have to decompose the digital signal
from, say, a cello string recording.  when you digitally alter the
transform coefficients, you get coding noise, which is unavoidable.
perfect reconstruction is purely theoretical and also mathematically
rigorous.

On Sun, Mar 8, 2020 at 7:51 PM Ethan Duni  wrote:

> No, MDCT TDAC is the same. Perfect reconstruction only obtains if the
> coefficients are not changed at all. Coding noise causes (uncancelled) time
> domain aliasing that is shaped according to the window design. Limiting
> this effect is a primary aspect of MDCT codec design.
>
> Ethan
>
> On Mar 8, 2020, at 4:45 PM, zhiguang zhang 
> wrote:
>
> 
> Audio compression by definition 'alters' the transform coefficients and
> they get perfect reconstruction with no aliasing due to the transform
> alone.  In fact 'TDAC' or time domain aliasing cancellation is a hallmark
> of the MDCT or DCT type IV which is ubiquitous in audio codecs.
>
> On Sun, Mar 8, 2020, 7:41 PM Ethan Duni  wrote:
>
>> FFT filterbanks are time variant due to framing effects and the circular
>> convolution property. They exhibit “perfect reconstruction” if you design
>> the windows correctly, but this only applies if the FFT coefficients are
>> not altered between analysis and synthesis. If you alter the FFT
>> coefficients (i.e., “filtering”), it causes time domain aliasing.
>>
>> So, the operation of such a system can’t be reduced down to an equivalent
>> LTI frequency response. We have the more basic issue of limiting the
>> aliasing to acceptable levels. This depends partially on the frame size,
>> overlap, and window shape, as these determine how any aliasing is
>> distributed in a time/frequency sense. But more fundamentally, you have to
>> put constraints on the response curves to limit the aliasing. I.e. the
>> steeper the transitions in the frequency response, the longer the implied
>> impulse response, and so the time domain aliasing gets worse.
>>
>> It is certainly possible to run any filter bank offline and compensate
>> for its latency, in order to get a “zero phase” processing. But
>> fundamentally they have framing delay given by the frame size, and
>> algorithmic latency given by the overlap. These are the delays that you’d
>> compensate when running offline.
>>
>> Ethan
>>
>> On Mar 8, 2020, at 2:04 PM, zhiguang zhang 
>> wrote:
>>
>> 
>> The system is memoryless just because it is based on the DFT and nothing
>> else, which is also why it's time-invariant.  unless you alter certain
>> parameters in real-time like the window size or hop size or windowing
>> function, etc, any input gives you the same output at any given time, which
>> is the definition of time-invariance.
>>
>> well, you're RBJ and I see that you used to work at Kurzweil until 2008.
>> that's cool and what have you been up to since then?  incidentally i was in
>> California until 2008.
>>
>> As you might be able to tell, i don't care too much about the fact that
>> time domain filtering theory is brought up often because I did my master's
>> thesis with this frequency domain FFT filter, which I believe was rather
>> novel at the time of completion.  I do know that the field is steeped in
>> tradition, which might be why I'm writing to the mailing list and to you in
>> particular.  but bringing up traditional FIR/IIR filtering terminology to
>> describe FFT filtering doesn't make sense in my mind.  I'm not in the audio
>> field.  but yes, I do believe that the system is time invariant, but I
>> don't have time to prove myself to you on this forum at this time, nor do I
>> have any interest in meeting Dr Bosi at AES.
>>
>> -ez
>>
>>
>>
>> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson <
>> r...@audioimagination.com> wrote:
>>
>>>
>>>
>>> > On March 8, 2020 3:07 PM zhiguang zhang 
>>> wrote:
>>> >
>>> >
>>> > Well I believe the system is LTI just because the DFT is LTI by
>>> definition.
>>>
>>> TI is nowhere in the definition of the DFT.  L is a consequence of the
>>> definition of the DFT, but the DFT is not an LTI system.  it is an
>>> operation done to a finite segment of samples of a discrete-time signal.
>>>
>>> > The impulse response of a rectangular window I believe is that of a
>>> sinc function,
>>>
>>> window functions do not have impulse responses.
>>>
>>> both window functions and impulse responses can be Fourier transformed.
>>> the Fourier transform of the latter is what we call the "frequency
>>> response" of the system.  i am not sure what they call the fourier
>>> transform of a window function.  what is done with the frequency response

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

> 
> If the system is suitably designed (e.g. correct window and overlap),
> you can filter using an FFT and get identical results to a time domain
> FIR filter (up-to rounding/precision limits, of course). The
> appropriate window and overlap process will cause all circular
> convolution artefacts to cancel.

Fast FIR is a different thing than an FFT filter bank.

You can combine the two approaches but I don’t think that’s what is being done 
here?

Ethan
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Greg Maxwell]

On Sun, Mar 8, 2020 at 11:41 PM Ethan Duni  wrote:
> FFT filterbanks are time variant due to framing effects and the circular 
> convolution property. They exhibit “perfect reconstruction” if you design the 
> windows correctly, but this only applies if the FFT coefficients are not 
> altered between analysis and synthesis. If you alter the FFT coefficients 
> (i.e., “filtering”), it causes time domain aliasing.

If the system is suitably designed (e.g. correct window and overlap),
you can filter using an FFT and get identical results to a time domain
FIR filter (up-to rounding/precision limits, of course). The
appropriate window and overlap process will cause all circular
convolution artefacts to cancel.

In fact, one particularly computationally efficient method to apply a
very long FIR filter (e.g. for reverbs) with low delay is to factor it
into a low delay portion and one or more longer delay chunks and use
naive convolution for the low delay portion and large overlapped FFTs
for the high delay portions.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

No, MDCT TDAC is the same. Perfect reconstruction only obtains if the 
coefficients are not changed at all. Coding noise causes (uncancelled) time 
domain aliasing that is shaped according to the window design. Limiting this 
effect is a primary aspect of MDCT codec design.

Ethan 

> On Mar 8, 2020, at 4:45 PM, zhiguang zhang  wrote:
> 
> 
> Audio compression by definition 'alters' the transform coefficients and they 
> get perfect reconstruction with no aliasing due to the transform alone.  In 
> fact 'TDAC' or time domain aliasing cancellation is a hallmark of the MDCT or 
> DCT type IV which is ubiquitous in audio codecs.
> 
>> On Sun, Mar 8, 2020, 7:41 PM Ethan Duni  wrote:
>> FFT filterbanks are time variant due to framing effects and the circular 
>> convolution property. They exhibit “perfect reconstruction” if you design 
>> the windows correctly, but this only applies if the FFT coefficients are not 
>> altered between analysis and synthesis. If you alter the FFT coefficients 
>> (i.e., “filtering”), it causes time domain aliasing. 
>> 
>> So, the operation of such a system can’t be reduced down to an equivalent 
>> LTI frequency response. We have the more basic issue of limiting the 
>> aliasing to acceptable levels. This depends partially on the frame size, 
>> overlap, and window shape, as these determine how any aliasing is 
>> distributed in a time/frequency sense. But more fundamentally, you have to 
>> put constraints on the response curves to limit the aliasing. I.e. the 
>> steeper the transitions in the frequency response, the longer the implied 
>> impulse response, and so the time domain aliasing gets worse.
>> 
>> It is certainly possible to run any filter bank offline and compensate for 
>> its latency, in order to get a “zero phase” processing. But fundamentally 
>> they have framing delay given by the frame size, and algorithmic latency 
>> given by the overlap. These are the delays that you’d compensate when 
>> running offline.
>> 
>> Ethan
>> 
 On Mar 8, 2020, at 2:04 PM, zhiguang zhang  
 wrote:
 
>>> 
>>> The system is memoryless just because it is based on the DFT and nothing 
>>> else, which is also why it's time-invariant.  unless you alter certain 
>>> parameters in real-time like the window size or hop size or windowing 
>>> function, etc, any input gives you the same output at any given time, which 
>>> is the definition of time-invariance.
>>> 
>>> well, you're RBJ and I see that you used to work at Kurzweil until 2008.  
>>> that's cool and what have you been up to since then?  incidentally i was in 
>>> California until 2008.
>>> 
>>> As you might be able to tell, i don't care too much about the fact that 
>>> time domain filtering theory is brought up often because I did my master's 
>>> thesis with this frequency domain FFT filter, which I believe was rather 
>>> novel at the time of completion.  I do know that the field is steeped in 
>>> tradition, which might be why I'm writing to the mailing list and to you in 
>>> particular.  but bringing up traditional FIR/IIR filtering terminology to 
>>> describe FFT filtering doesn't make sense in my mind.  I'm not in the audio 
>>> field.  but yes, I do believe that the system is time invariant, but I 
>>> don't have time to prove myself to you on this forum at this time, nor do I 
>>> have any interest in meeting Dr Bosi at AES.
>>> 
>>> -ez
>>> 
>>> 
>>> 
 On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson 
  wrote:
 
 
 > On March 8, 2020 3:07 PM zhiguang zhang  wrote:
 > 
 > 
 > Well I believe the system is LTI just because the DFT is LTI by 
 > definition.
 
 TI is nowhere in the definition of the DFT.  L is a consequence of the 
 definition of the DFT, but the DFT is not an LTI system.  it is an 
 operation done to a finite segment of samples of a discrete-time signal.
 
 > The impulse response of a rectangular window I believe is that of a sinc 
 > function,
 
 window functions do not have impulse responses.
 
 both window functions and impulse responses can be Fourier transformed.  
 the Fourier transform of the latter is what we call the "frequency 
 response" of the system.  i am not sure what they call the fourier 
 transform of a window function.  what is done with the frequency response 
 (multiplication) is *not* what is done with the fourier transform of a 
 window function (convolution).
 
 > which has ripple artifacts.
 
 there are no ripple artifacts in fast convolution using a rectangular 
 window.  you need to learn what that is.
 
 > Actually, the overlap-add method (sorry I don't have time to dig into 
 > the differences between overlap-add and overlap-save right now)
 
 what you need is time to learn the basics and learn the proper terminology 
 of things so that confusion in communication is minimum.
 
 > minimizes artifacts 

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

Audio compression by definition 'alters' the transform coefficients and
they get perfect reconstruction with no aliasing due to the transform
alone.  In fact 'TDAC' or time domain aliasing cancellation is a hallmark
of the MDCT or DCT type IV which is ubiquitous in audio codecs.

On Sun, Mar 8, 2020, 7:41 PM Ethan Duni  wrote:

> FFT filterbanks are time variant due to framing effects and the circular
> convolution property. They exhibit “perfect reconstruction” if you design
> the windows correctly, but this only applies if the FFT coefficients are
> not altered between analysis and synthesis. If you alter the FFT
> coefficients (i.e., “filtering”), it causes time domain aliasing.
>
> So, the operation of such a system can’t be reduced down to an equivalent
> LTI frequency response. We have the more basic issue of limiting the
> aliasing to acceptable levels. This depends partially on the frame size,
> overlap, and window shape, as these determine how any aliasing is
> distributed in a time/frequency sense. But more fundamentally, you have to
> put constraints on the response curves to limit the aliasing. I.e. the
> steeper the transitions in the frequency response, the longer the implied
> impulse response, and so the time domain aliasing gets worse.
>
> It is certainly possible to run any filter bank offline and compensate for
> its latency, in order to get a “zero phase” processing. But fundamentally
> they have framing delay given by the frame size, and algorithmic latency
> given by the overlap. These are the delays that you’d compensate when
> running offline.
>
> Ethan
>
> On Mar 8, 2020, at 2:04 PM, zhiguang zhang 
> wrote:
>
> 
> The system is memoryless just because it is based on the DFT and nothing
> else, which is also why it's time-invariant.  unless you alter certain
> parameters in real-time like the window size or hop size or windowing
> function, etc, any input gives you the same output at any given time, which
> is the definition of time-invariance.
>
> well, you're RBJ and I see that you used to work at Kurzweil until 2008.
> that's cool and what have you been up to since then?  incidentally i was in
> California until 2008.
>
> As you might be able to tell, i don't care too much about the fact that
> time domain filtering theory is brought up often because I did my master's
> thesis with this frequency domain FFT filter, which I believe was rather
> novel at the time of completion.  I do know that the field is steeped in
> tradition, which might be why I'm writing to the mailing list and to you in
> particular.  but bringing up traditional FIR/IIR filtering terminology to
> describe FFT filtering doesn't make sense in my mind.  I'm not in the audio
> field.  but yes, I do believe that the system is time invariant, but I
> don't have time to prove myself to you on this forum at this time, nor do I
> have any interest in meeting Dr Bosi at AES.
>
> -ez
>
>
>
> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>>
>> > On March 8, 2020 3:07 PM zhiguang zhang 
>> wrote:
>> >
>> >
>> > Well I believe the system is LTI just because the DFT is LTI by
>> definition.
>>
>> TI is nowhere in the definition of the DFT.  L is a consequence of the
>> definition of the DFT, but the DFT is not an LTI system.  it is an
>> operation done to a finite segment of samples of a discrete-time signal.
>>
>> > The impulse response of a rectangular window I believe is that of a
>> sinc function,
>>
>> window functions do not have impulse responses.
>>
>> both window functions and impulse responses can be Fourier transformed.
>> the Fourier transform of the latter is what we call the "frequency
>> response" of the system.  i am not sure what they call the fourier
>> transform of a window function.  what is done with the frequency response
>> (multiplication) is *not* what is done with the fourier transform of a
>> window function (convolution).
>>
>> > which has ripple artifacts.
>>
>> there are no ripple artifacts in fast convolution using a rectangular
>> window.  you need to learn what that is.
>>
>> > Actually, the overlap-add method (sorry I don't have time to dig into
>> the differences between overlap-add and overlap-save right now)
>>
>> what you need is time to learn the basics and learn the proper
>> terminology of things so that confusion in communication is minimum.
>>
>> > minimizes artifacts depending on the windowing function.
>>
>> again, there are no ripple artifacts in fast convolution using a
>> rectangular window.  none whatsoever.
>>
>> > A sine window ...
>>
>> i think you might mean the "Hann window" (sometimes misnamed "Hanning",
>> but that is an old misnomer).  i have never heard of a "sine window" and i
>> have been doing this for 45 years.  perhaps the classic Fred Harris paper
>> on windows has a "sine window".
>>
>> > ... actually sums to 1,
>>
>> that's what we mean by "complementary".
>>
>> > the proof of which can be found in audio 

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

FFT filterbanks are time variant due to framing effects and the circular 
convolution property. They exhibit “perfect reconstruction” if you design the 
windows correctly, but this only applies if the FFT coefficients are not 
altered between analysis and synthesis. If you alter the FFT coefficients 
(i.e., “filtering”), it causes time domain aliasing. 

So, the operation of such a system can’t be reduced down to an equivalent LTI 
frequency response. We have the more basic issue of limiting the aliasing to 
acceptable levels. This depends partially on the frame size, overlap, and 
window shape, as these determine how any aliasing is distributed in a 
time/frequency sense. But more fundamentally, you have to put constraints on 
the response curves to limit the aliasing. I.e. the steeper the transitions in 
the frequency response, the longer the implied impulse response, and so the 
time domain aliasing gets worse.

It is certainly possible to run any filter bank offline and compensate for its 
latency, in order to get a “zero phase” processing. But fundamentally they have 
framing delay given by the frame size, and algorithmic latency given by the 
overlap. These are the delays that you’d compensate when running offline.

Ethan

> On Mar 8, 2020, at 2:04 PM, zhiguang zhang  wrote:
> 
> 
> The system is memoryless just because it is based on the DFT and nothing 
> else, which is also why it's time-invariant.  unless you alter certain 
> parameters in real-time like the window size or hop size or windowing 
> function, etc, any input gives you the same output at any given time, which 
> is the definition of time-invariance.
> 
> well, you're RBJ and I see that you used to work at Kurzweil until 2008.  
> that's cool and what have you been up to since then?  incidentally i was in 
> California until 2008.
> 
> As you might be able to tell, i don't care too much about the fact that time 
> domain filtering theory is brought up often because I did my master's thesis 
> with this frequency domain FFT filter, which I believe was rather novel at 
> the time of completion.  I do know that the field is steeped in tradition, 
> which might be why I'm writing to the mailing list and to you in particular.  
> but bringing up traditional FIR/IIR filtering terminology to describe FFT 
> filtering doesn't make sense in my mind.  I'm not in the audio field.  but 
> yes, I do believe that the system is time invariant, but I don't have time to 
> prove myself to you on this forum at this time, nor do I have any interest in 
> meeting Dr Bosi at AES.
> 
> -ez
> 
> 
> 
>> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson 
>>  wrote:
>> 
>> 
>> > On March 8, 2020 3:07 PM zhiguang zhang  wrote:
>> > 
>> > 
>> > Well I believe the system is LTI just because the DFT is LTI by definition.
>> 
>> TI is nowhere in the definition of the DFT.  L is a consequence of the 
>> definition of the DFT, but the DFT is not an LTI system.  it is an operation 
>> done to a finite segment of samples of a discrete-time signal.
>> 
>> > The impulse response of a rectangular window I believe is that of a sinc 
>> > function,
>> 
>> window functions do not have impulse responses.
>> 
>> both window functions and impulse responses can be Fourier transformed.  the 
>> Fourier transform of the latter is what we call the "frequency response" of 
>> the system.  i am not sure what they call the fourier transform of a window 
>> function.  what is done with the frequency response (multiplication) is 
>> *not* what is done with the fourier transform of a window function 
>> (convolution).
>> 
>> > which has ripple artifacts.
>> 
>> there are no ripple artifacts in fast convolution using a rectangular 
>> window.  you need to learn what that is.
>> 
>> > Actually, the overlap-add method (sorry I don't have time to dig into the 
>> > differences between overlap-add and overlap-save right now)
>> 
>> what you need is time to learn the basics and learn the proper terminology 
>> of things so that confusion in communication is minimum.
>> 
>> > minimizes artifacts depending on the windowing function.
>> 
>> again, there are no ripple artifacts in fast convolution using a rectangular 
>> window.  none whatsoever.
>> 
>> > A sine window ...
>> 
>> i think you might mean the "Hann window" (sometimes misnamed "Hanning", but 
>> that is an old misnomer).  i have never heard of a "sine window" and i have 
>> been doing this for 45 years.  perhaps the classic Fred Harris paper on 
>> windows has a "sine window".
>> 
>> > ... actually sums to 1,
>> 
>> that's what we mean by "complementary".
>> 
>> > the proof of which can be found in audio coding theory. I suggest you 
>> > check out the book by Bosi.
>> 
>> i didn't even know Marina did a book, but i am not surprized.  i've known 
>> (or been acquainted with) Marina since she was with Digidesign back in the 
>> early 90s.  before the Dolby Lab days.  before her injury at the New York 
>> Hilton in 1993.  would 

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

The system is memoryless just because it is based on the DFT and nothing
else, which is also why it's time-invariant.  unless you alter certain
parameters in real-time like the window size or hop size or windowing
function, etc, any input gives you the same output at any given time, which
is the definition of time-invariance.

well, you're RBJ and I see that you used to work at Kurzweil until 2008.
that's cool and what have you been up to since then?  incidentally i was in
California until 2008.

As you might be able to tell, i don't care too much about the fact that
time domain filtering theory is brought up often because I did my master's
thesis with this frequency domain FFT filter, which I believe was rather
novel at the time of completion.  I do know that the field is steeped in
tradition, which might be why I'm writing to the mailing list and to you in
particular.  but bringing up traditional FIR/IIR filtering terminology to
describe FFT filtering doesn't make sense in my mind.  I'm not in the audio
field.  but yes, I do believe that the system is time invariant, but I
don't have time to prove myself to you on this forum at this time, nor do I
have any interest in meeting Dr Bosi at AES.

-ez



On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> > On March 8, 2020 3:07 PM zhiguang zhang 
> wrote:
> >
> >
> > Well I believe the system is LTI just because the DFT is LTI by
> definition.
>
> TI is nowhere in the definition of the DFT.  L is a consequence of the
> definition of the DFT, but the DFT is not an LTI system.  it is an
> operation done to a finite segment of samples of a discrete-time signal.
>
> > The impulse response of a rectangular window I believe is that of a sinc
> function,
>
> window functions do not have impulse responses.
>
> both window functions and impulse responses can be Fourier transformed.
> the Fourier transform of the latter is what we call the "frequency
> response" of the system.  i am not sure what they call the fourier
> transform of a window function.  what is done with the frequency response
> (multiplication) is *not* what is done with the fourier transform of a
> window function (convolution).
>
> > which has ripple artifacts.
>
> there are no ripple artifacts in fast convolution using a rectangular
> window.  you need to learn what that is.
>
> > Actually, the overlap-add method (sorry I don't have time to dig into
> the differences between overlap-add and overlap-save right now)
>
> what you need is time to learn the basics and learn the proper terminology
> of things so that confusion in communication is minimum.
>
> > minimizes artifacts depending on the windowing function.
>
> again, there are no ripple artifacts in fast convolution using a
> rectangular window.  none whatsoever.
>
> > A sine window ...
>
> i think you might mean the "Hann window" (sometimes misnamed "Hanning",
> but that is an old misnomer).  i have never heard of a "sine window" and i
> have been doing this for 45 years.  perhaps the classic Fred Harris paper
> on windows has a "sine window".
>
> > ... actually sums to 1,
>
> that's what we mean by "complementary".
>
> > the proof of which can be found in audio coding theory. I suggest you
> check out the book by Bosi.
>
> i didn't even know Marina did a book, but i am not surprized.  i've known
> (or been acquainted with) Marina since she was with Digidesign back in the
> early 90s.  before the Dolby Lab days.  before her injury at the New York
> Hilton in 1993.  would you like me to introduce you to her at the next AES?
>
> Eric, you gotta get the basics down right and you gotta learn the correct
> terminology if you're going to communicate with other people about this
> topic matter.  Neologisms are frowned on but people do them anyway.
> However you just cannot change the meanings of terms that have existed
> since the 1960s (and some as far back as the 1930s).
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

Well I believe the system is LTI just because the DFT is LTI by
definition.  The impulse response of a rectangular window I believe is that
of a sinc function, which has ripple artifacts.  Actually, the overlap-add
method (sorry I don't have time to dig into the differences between
overlap-add and overlap-save right now) minimizes artifacts depending on
the windowing function. A sine window actually sums to 1, the proof of
which can be found in audio coding theory.  I suggest you check out the
book by Bosi.

Thanks,
-ez

On Sun, Mar 8, 2020, 3:01 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> > On March 8, 2020 2:00 PM Zhiguang Eric Zhang  wrote:
> >
> > it is not causal because the zero-phase system does not depend on past
> samples
> >
> >
> > On Sun, Mar 8, 2020 at 1:58 PM Zhiguang Eric Zhang 
> wrote:
> > > the frequency response is a function of the windowing function
> > >
> > >
>
> what frequency response, Eric?  if the only sample the "zero-phase system"
> depends on is the present sample, not past nor future samples, then the
> system is a wire or simply a scaler (if it's linear) or some other
> memoryless function if it's nonlinear.  we normally mean linear systems
> when we discuss "frequency response".
>
> people here on this list are pretty competent about what linear system
> theory is, what makes systems linear or not, what makes them time-invariant
> or not, what makes for causal and acausal systems, what determines the
> frequency response of a linear system (it's the impulse response), what
> window functions are and their effect on the spectra of signals, what
> linear-phase systems are and what hypothetical zero-phase systems are.
> this is all in textbooks.
>
> one thing that needs to happen for anyone to truly assist anyone else
> here, is that communication is unambiguous and accurate.  that means we
> really have to agree on the definitions of terms.
>
> an FIR filter is a linear, time-invariant system.  it can be a
> linear-phase system, but it doesn't have to be.  that depends on the IR,
> which is F.  if and only if the IR is symmetrical, it's linear-phase.  a
> linear-phase FIR can be modeled as a hypothetical zero-phase FIR (so only
> magnitude response is in its description) followed or preceded by a delay
> of 1/2 of the length of the FIR.  the phase response of a delay is a linear
> function of frequency, hence "linear phase".  a hypothetical zero-phase
> filter is one with symmetry about the t=0 axis of the impulse response.
> that means that samples in the future of the IR are a mirror image of
> samples in the past.  add some delay and you can move all of the non-zero
> samples to the past (and one for the present input sample).
>
> using the FFT (and iFFT and frequency-domain multiplication of the
> frequency response) is an operation we often call "fast convolution".  fast
> convolution is used for very long (but still finite) FIRs.  for short FIRs
> we just do it the simple way, a dot-product of the IR against the most
> recent input samples.  fast convolution is performed using one of two
> techniques: "overlap-add" (OLA) and "overlap-scrap" (OLS).  the older lit
> will say "overlap-save" for OLS, but we mean the same thing.
>
> normally, the only windowing we do for fast convolution, is the
> rectangular window.  because of the overlapping and the linear-system
> nature of the operation, there are no windowing effects.  it *is* possible
> to do something like fast convolution FIR with overlap-add using a
> different window as long as it is complementary in the overlap (such as a
> Hann window), but it makes the operation less "fast".  if there is 50%
> overlap, the number of net output samples computed in each frame is 1/2
> that for using rectangular given both windows having the same non-zero
> length, so it would be half as efficient.
>
> lastly, this "overlap-add" method of fast convolution should not be
> confused with the overlap-add method of the STFT processing music DSP
> people often use for more general and sophisticated processing of audio
> (such as a phase vocoder).  generally more sophisticated than an FIR.  in
> that application, a rectangular window would be considered pretty bad.  but
> all this is not what "fast convolution" is, which we use to implement long
> FIR filters (like reverberators).
>
> i'm just trying to be helpful, but none of us can really be helpful if we
> cannot at least agree on the terminology.
>
> -- robert
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
>
> > > On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson <
> r...@audioimagination.com> wrote:
> > > >
> > > >
> > > >  > On March 8, 2020 10:05 AM Ethan Duni 
> wrote:
> > > >  >
> > > >  >
> > > >  > It is physically impossible to build a causal, zero-phase system
> with non-trivial frequency response.
> > > >
> > > >  a system that operates in real time. when processing sound files
> you 

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 8, 2020 2:00 PM Zhiguang Eric Zhang  wrote:
> 
> it is not causal because the zero-phase system does not depend on past samples
> 
> 
> On Sun, Mar 8, 2020 at 1:58 PM Zhiguang Eric Zhang  wrote:
> > the frequency response is a function of the windowing function
> > 
> > 

what frequency response, Eric?  if the only sample the "zero-phase system" 
depends on is the present sample, not past nor future samples, then the system 
is a wire or simply a scaler (if it's linear) or some other memoryless function 
if it's nonlinear.  we normally mean linear systems when we discuss "frequency 
response".

people here on this list are pretty competent about what linear system theory 
is, what makes systems linear or not, what makes them time-invariant or not, 
what makes for causal and acausal systems, what determines the frequency 
response of a linear system (it's the impulse response), what window functions 
are and their effect on the spectra of signals, what linear-phase systems are 
and what hypothetical zero-phase systems are.  this is all in textbooks.

one thing that needs to happen for anyone to truly assist anyone else here, is 
that communication is unambiguous and accurate.  that means we really have to 
agree on the definitions of terms.

an FIR filter is a linear, time-invariant system.  it can be a linear-phase 
system, but it doesn't have to be.  that depends on the IR, which is F.  if and 
only if the IR is symmetrical, it's linear-phase.  a linear-phase FIR can be 
modeled as a hypothetical zero-phase FIR (so only magnitude response is in its 
description) followed or preceded by a delay of 1/2 of the length of the FIR.  
the phase response of a delay is a linear function of frequency, hence "linear 
phase".  a hypothetical zero-phase filter is one with symmetry about the t=0 
axis of the impulse response.  that means that samples in the future of the IR 
are a mirror image of samples in the past.  add some delay and you can move all 
of the non-zero samples to the past (and one for the present input sample).

using the FFT (and iFFT and frequency-domain multiplication of the frequency 
response) is an operation we often call "fast convolution".  fast convolution 
is used for very long (but still finite) FIRs.  for short FIRs we just do it 
the simple way, a dot-product of the IR against the most recent input samples.  
fast convolution is performed using one of two techniques: "overlap-add" (OLA) 
and "overlap-scrap" (OLS).  the older lit will say "overlap-save" for OLS, but 
we mean the same thing.  

normally, the only windowing we do for fast convolution, is the rectangular 
window.  because of the overlapping and the linear-system nature of the 
operation, there are no windowing effects.  it *is* possible to do something 
like fast convolution FIR with overlap-add using a different window as long as 
it is complementary in the overlap (such as a Hann window), but it makes the 
operation less "fast".  if there is 50% overlap, the number of net output 
samples computed in each frame is 1/2 that for using rectangular given both 
windows having the same non-zero length, so it would be half as efficient.

lastly, this "overlap-add" method of fast convolution should not be confused 
with the overlap-add method of the STFT processing music DSP people often use 
for more general and sophisticated processing of audio (such as a phase 
vocoder).  generally more sophisticated than an FIR.  in that application, a 
rectangular window would be considered pretty bad.  but all this is not what 
"fast convolution" is, which we use to implement long FIR filters (like 
reverberators).

i'm just trying to be helpful, but none of us can really be helpful if we 
cannot at least agree on the terminology.

-- robert
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."


> > On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson 
> >  wrote:
> > > 
> > >  
> > >  > On March 8, 2020 10:05 AM Ethan Duni  wrote:
> > >  > 
> > >  > 
> > >  > It is physically impossible to build a causal, zero-phase system with 
> > > non-trivial frequency response.
> > >  
> > >  a system that operates in real time. when processing sound files you can 
> > > pretend that you're looking at some "future" samples. i guess that would 
> > > be acausal, so you're right, Ethan.
> > >  
> > >  --
> > >  
> > >  r b-j  r...@audioimagination.com
> > >  
> > >  "Imagination is more important than knowledge."
> > >  
> > >  
> > >  > 
> > >  > > On Mar 7, 2020, at 7:42 PM, Zhiguang Eric Zhang  
> > > wrote:
> > >  > > 
> > >  > > Not to threadjack from Alan Wolfe, but the FFT EQ was responsive 
> > > written in C and running on a previous gen MacBook Pro from 2011. It 
> > > wouldn't have been usable in a DAW even without any UI. It was running 
> > > FFTW.
> > >  > > 
> > >  > > As far as linear / zero-phase, I didn't think about the impulse 
> > > response but what you 

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

it is not causal because the zero-phase system does not depend on past
samples

On Sun, Mar 8, 2020 at 1:58 PM Zhiguang Eric Zhang  wrote:

> the frequency response is a function of the windowing function
>
> On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>>
>> > On March 8, 2020 10:05 AM Ethan Duni  wrote:
>> >
>> >
>> > It is physically impossible to build a causal, zero-phase system with
>> non-trivial frequency response.
>>
>> a system that operates in real time.  when processing sound files you can
>> pretend that you're looking at some "future" samples.  i guess that would
>> be acausal, so you're right, Ethan.
>>
>> --
>>
>> r b-j  r...@audioimagination.com
>>
>> "Imagination is more important than knowledge."
>>
>>
>> >
>> > > On Mar 7, 2020, at 7:42 PM, Zhiguang Eric Zhang 
>> wrote:
>> > >
>> > > Not to threadjack from Alan Wolfe, but the FFT EQ was responsive
>> written in C and running on a previous gen MacBook Pro from 2011. It
>> wouldn't have been usable in a DAW even without any UI. It was running FFTW.
>> > >
>> > > As far as linear / zero-phase, I didn't think about the impulse
>> response but what you might get are ripple artifacts from the FFT windowing
>> function. Otherwise the algorithm is inherently zero-phase.
>> > >
>> > >
>> > > On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson <
>> r...@audioimagination.com> wrote:
>> > > >
>> > > >
>> > > >  > On March 7, 2020 6:43 PM zhiguang zhang <
>> zhiguangezh...@gmail.com> wrote:
>> > > >  >
>> > > >  >
>> > > >  > Yes, essentially you do have the inherent delay involving a
>> window of samples in addition to the compute time.
>> > > >
>> > > >  yes. but the compute time is really something to consider as a
>> binary decision of whether or not the process can be real time.
>> > > >
>> > > >  assuming your computer can process these samples real time, the
>> delay of double-buffering is *twice* the delay of a single buffer or
>> "window" (i would not use that term, i might use the term "sample block" or
>> "sample frame") of samples. suppose your buffer or sample block is, say,
>> 4096 samples. while you are computing your FFT (which is likely bigger than
>> 4K), multiplication in the frequency domain, inverse FFT and overlap-adding
>> or overlap-scrapping, you are inputting the 4096 samples to be processed
>> for your *next* sample frame and you are outputting the 4096 samples of
>> your *previous* sample frame. so the entire delay, due to block processing,
>> is two frame lengths, in this case, 8192 samples.
>> > > >
>> > > >  now if the processing time required to do the FFT,
>> frequency-domain multiplication, iFFT, and overlap-add/scrap exceeds the
>> time of one frame, then the process cannot be real time. but if the time
>> required to do all of that (including the overhead of interrupt I/O-ing the
>> samples in/out of the blocks) is less than that of a frame, the process is
>> or can be made into a real-time process and the throughput delay is two
>> frames.
>> > > >
>> > > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
>> > > >  > > ... FFT filtering is essentially zero-phase ...
>> > > >
>> > > >  FFT filtering **can** be linear-phase (which is zero-phase plus a
>> constant delay) if the FIR filter impulse response is designed to be
>> linear-phase (or symmetrical). it doesn't have to be linear phase.
>> > > >
>> > > >  --
>> > > >
>> > > >  r b-j r...@audioimagination.com
>> > > >
>> > > >  "Imagination is more important than knowledge."
>> > > >
>> > > >  > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell 
>> wrote:
>> > > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
>> > > >  > > > Traditional FIR/IIR filtering is ubiquitous but actually
>> does suffer from drawbacks such as phase distortion and the inherent delay
>> involved. FFT filtering is essentially zero-phase, but instead of delays
>> due to samples, you get delays due to FFT computational complexity instead.
>> > > >  > >
>> > > >  > > I wouldn’t say the delay when using FFT processing is due to
>> computational complexity fundamentally. Compute affects your max throughput
>> more than your latency. In other words, if you had an infinitely-fast
>> computer you would still have to deal with latency. The issue is just that
>> you need at least 1 block of input before you can do anything. It’s the
>> same thing as with FIR filters, they need to be causal so they can’t be
>> zero-phase. In fact you could interchange the FFT processing with a bank of
>> FIR band pass filters that you sample from whenever you want to get your
>> DFT frame. (that’s basically just a restatement of what I said before about
>> the STFT.)
>> > > >  > >
>> > > >  > > -s
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>>
>> 

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

the frequency response is a function of the windowing function

On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> > On March 8, 2020 10:05 AM Ethan Duni  wrote:
> >
> >
> > It is physically impossible to build a causal, zero-phase system with
> non-trivial frequency response.
>
> a system that operates in real time.  when processing sound files you can
> pretend that you're looking at some "future" samples.  i guess that would
> be acausal, so you're right, Ethan.
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
>
> >
> > > On Mar 7, 2020, at 7:42 PM, Zhiguang Eric Zhang 
> wrote:
> > >
> > > Not to threadjack from Alan Wolfe, but the FFT EQ was responsive
> written in C and running on a previous gen MacBook Pro from 2011. It
> wouldn't have been usable in a DAW even without any UI. It was running FFTW.
> > >
> > > As far as linear / zero-phase, I didn't think about the impulse
> response but what you might get are ripple artifacts from the FFT windowing
> function. Otherwise the algorithm is inherently zero-phase.
> > >
> > >
> > > On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson <
> r...@audioimagination.com> wrote:
> > > >
> > > >
> > > >  > On March 7, 2020 6:43 PM zhiguang zhang 
> wrote:
> > > >  >
> > > >  >
> > > >  > Yes, essentially you do have the inherent delay involving a
> window of samples in addition to the compute time.
> > > >
> > > >  yes. but the compute time is really something to consider as a
> binary decision of whether or not the process can be real time.
> > > >
> > > >  assuming your computer can process these samples real time, the
> delay of double-buffering is *twice* the delay of a single buffer or
> "window" (i would not use that term, i might use the term "sample block" or
> "sample frame") of samples. suppose your buffer or sample block is, say,
> 4096 samples. while you are computing your FFT (which is likely bigger than
> 4K), multiplication in the frequency domain, inverse FFT and overlap-adding
> or overlap-scrapping, you are inputting the 4096 samples to be processed
> for your *next* sample frame and you are outputting the 4096 samples of
> your *previous* sample frame. so the entire delay, due to block processing,
> is two frame lengths, in this case, 8192 samples.
> > > >
> > > >  now if the processing time required to do the FFT, frequency-domain
> multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame,
> then the process cannot be real time. but if the time required to do all of
> that (including the overhead of interrupt I/O-ing the samples in/out of the
> blocks) is less than that of a frame, the process is or can be made into a
> real-time process and the throughput delay is two frames.
> > > >
> > > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > > >  > > ... FFT filtering is essentially zero-phase ...
> > > >
> > > >  FFT filtering **can** be linear-phase (which is zero-phase plus a
> constant delay) if the FIR filter impulse response is designed to be
> linear-phase (or symmetrical). it doesn't have to be linear phase.
> > > >
> > > >  --
> > > >
> > > >  r b-j r...@audioimagination.com
> > > >
> > > >  "Imagination is more important than knowledge."
> > > >
> > > >  > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell 
> wrote:
> > > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > > >  > > > Traditional FIR/IIR filtering is ubiquitous but actually does
> suffer from drawbacks such as phase distortion and the inherent delay
> involved. FFT filtering is essentially zero-phase, but instead of delays
> due to samples, you get delays due to FFT computational complexity instead.
> > > >  > >
> > > >  > > I wouldn’t say the delay when using FFT processing is due to
> computational complexity fundamentally. Compute affects your max throughput
> more than your latency. In other words, if you had an infinitely-fast
> computer you would still have to deal with latency. The issue is just that
> you need at least 1 block of input before you can do anything. It’s the
> same thing as with FIR filters, they need to be causal so they can’t be
> zero-phase. In fact you could interchange the FFT processing with a bank of
> FIR band pass filters that you sample from whenever you want to get your
> DFT frame. (that’s basically just a restatement of what I said before about
> the STFT.)
> > > >  > >
> > > >  > > -s
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwIGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=saJ0IC40JGWeOGaONJ6jTXPSJtWmpzejoo8nX3eSWs8=WXWL91lRoTbvxjpEmSd4HWZBuRlfWGw7fwG4xVWHIvI=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 8, 2020 10:05 AM Ethan Duni  wrote:
> 
> 
> It is physically impossible to build a causal, zero-phase system with 
> non-trivial frequency response.

a system that operates in real time.  when processing sound files you can 
pretend that you're looking at some "future" samples.  i guess that would be 
acausal, so you're right, Ethan.

--
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."


> 
> > On Mar 7, 2020, at 7:42 PM, Zhiguang Eric Zhang  wrote:
> > 
> > Not to threadjack from Alan Wolfe, but the FFT EQ was responsive written in 
> > C and running on a previous gen MacBook Pro from 2011. It wouldn't have 
> > been usable in a DAW even without any UI. It was running FFTW.
> > 
> > As far as linear / zero-phase, I didn't think about the impulse response 
> > but what you might get are ripple artifacts from the FFT windowing 
> > function. Otherwise the algorithm is inherently zero-phase.
> > 
> > 
> > On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson 
> >  wrote:
> > > 
> > >  
> > >  > On March 7, 2020 6:43 PM zhiguang zhang  
> > > wrote:
> > >  > 
> > >  > 
> > >  > Yes, essentially you do have the inherent delay involving a window of 
> > > samples in addition to the compute time.
> > >  
> > >  yes. but the compute time is really something to consider as a binary 
> > > decision of whether or not the process can be real time.
> > >  
> > >  assuming your computer can process these samples real time, the delay of 
> > > double-buffering is *twice* the delay of a single buffer or "window" (i 
> > > would not use that term, i might use the term "sample block" or "sample 
> > > frame") of samples. suppose your buffer or sample block is, say, 4096 
> > > samples. while you are computing your FFT (which is likely bigger than 
> > > 4K), multiplication in the frequency domain, inverse FFT and 
> > > overlap-adding or overlap-scrapping, you are inputting the 4096 samples 
> > > to be processed for your *next* sample frame and you are outputting the 
> > > 4096 samples of your *previous* sample frame. so the entire delay, due to 
> > > block processing, is two frame lengths, in this case, 8192 samples.
> > >  
> > >  now if the processing time required to do the FFT, frequency-domain 
> > > multiplication, iFFT, and overlap-add/scrap exceeds the time of one 
> > > frame, then the process cannot be real time. but if the time required to 
> > > do all of that (including the overhead of interrupt I/O-ing the samples 
> > > in/out of the blocks) is less than that of a frame, the process is or can 
> > > be made into a real-time process and the throughput delay is two frames.
> > >  
> > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > >  > > ... FFT filtering is essentially zero-phase ...
> > >  
> > >  FFT filtering **can** be linear-phase (which is zero-phase plus a 
> > > constant delay) if the FIR filter impulse response is designed to be 
> > > linear-phase (or symmetrical). it doesn't have to be linear phase.
> > >  
> > >  --
> > >  
> > >  r b-j r...@audioimagination.com
> > >  
> > >  "Imagination is more important than knowledge."
> > >  
> > >  > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  
> > > wrote:
> > >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > >  > > > Traditional FIR/IIR filtering is ubiquitous but actually does 
> > > suffer from drawbacks such as phase distortion and the inherent delay 
> > > involved. FFT filtering is essentially zero-phase, but instead of delays 
> > > due to samples, you get delays due to FFT computational complexity 
> > > instead.
> > >  > > 
> > >  > > I wouldn’t say the delay when using FFT processing is due to 
> > > computational complexity fundamentally. Compute affects your max 
> > > throughput more than your latency. In other words, if you had an 
> > > infinitely-fast computer you would still have to deal with latency. The 
> > > issue is just that you need at least 1 block of input before you can do 
> > > anything. It’s the same thing as with FIR filters, they need to be causal 
> > > so they can’t be zero-phase. In fact you could interchange the FFT 
> > > processing with a bank of FIR band pass filters that you sample from 
> > > whenever you want to get your DFT frame. (that’s basically just a 
> > > restatement of what I said before about the STFT.)
> > >  > > 
> > >  > > -s
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Ethan Duni]

It is physically impossible to build a causal, zero-phase system with 
non-trivial frequency response. 

Ethan

> On Mar 7, 2020, at 7:42 PM, Zhiguang Eric Zhang  wrote:
> 
> 
> Not to threadjack from Alan Wolfe, but the FFT EQ was responsive written in C 
> and running on a previous gen MacBook Pro from 2011.  It wouldn't have been 
> usable in a DAW even without any UI.  It was running FFTW.
> 
> As far as linear / zero-phase, I didn't think about the impulse response but 
> what you might get are ripple artifacts from the FFT windowing function.  
> Otherwise the algorithm is inherently zero-phase.
> 
>> On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson 
>>  wrote:
>> 
>> 
>> > On March 7, 2020 6:43 PM zhiguang zhang  wrote:
>> > 
>> > 
>> > Yes, essentially you do have the inherent delay involving a window of 
>> > samples in addition to the compute time.
>> 
>> yes.  but the compute time is really something to consider as a binary 
>> decision of whether or not the process can be real time.
>> 
>> assuming your computer can process these samples real time, the delay of 
>> double-buffering is *twice* the delay of a single buffer or "window" (i 
>> would not use that term, i might use the term "sample block" or "sample 
>> frame") of samples.  suppose your buffer or sample block is, say, 4096 
>> samples.  while you are computing your FFT (which is likely bigger than 4K), 
>> multiplication in the frequency domain, inverse FFT and overlap-adding or 
>> overlap-scrapping, you are inputting the 4096 samples to be processed for 
>> your *next* sample frame and you are outputting the 4096 samples of your 
>> *previous* sample frame.  so the entire delay, due to block processing, is 
>> two frame lengths, in this case, 8192 samples.
>> 
>> now if the processing time required to do the FFT, frequency-domain 
>> multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame, 
>> then the process cannot be real time.  but if the time required to do all of 
>> that (including the overhead of interrupt I/O-ing the samples in/out of the 
>> blocks) is less than that of a frame, the process is or can be made into a 
>> real-time process and the throughput delay is two frames.
>> 
>> > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
>> > > ... FFT filtering is essentially zero-phase ...
>> 
>> FFT filtering **can** be linear-phase (which is zero-phase plus a constant 
>> delay) if the FIR filter impulse response is designed to be linear-phase (or 
>> symmetrical).  it doesn't have to be linear phase.
>> 
>> --
>> 
>> r b-j  r...@audioimagination.com
>> 
>> "Imagination is more important than knowledge."
>> 
>> > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  wrote:
>> > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
>> > > > Traditional FIR/IIR filtering is ubiquitous but actually does suffer 
>> > > > from drawbacks such as phase distortion and the inherent delay 
>> > > > involved. FFT filtering is essentially zero-phase, but instead of 
>> > > > delays due to samples, you get delays due to FFT computational 
>> > > > complexity instead.
>> > > 
>> > > I wouldn’t say the delay when using FFT processing is due to 
>> > > computational complexity fundamentally. Compute affects your max 
>> > > throughput more than your latency. In other words, if you had an 
>> > > infinitely-fast computer you would still have to deal with latency. The 
>> > > issue is just that you need at least 1 block of input before you can do 
>> > > anything. It’s the same thing as with FIR filters, they need to be 
>> > > causal so they can’t be zero-phase. In fact you could interchange the 
>> > > FFT processing with a bank of FIR band pass filters that you sample from 
>> > > whenever you want to get your DFT frame. (that’s basically just a 
>> > > restatement of what I said before about the STFT.)
>> > > 
>> > > -s
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwIGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=Rfp1ozFiVA9OFrUgHnk8k4E7erWKoT0p7iI83xAoYEo=PQF0MzrvvmNpczp2_8SZoGEb7ojFOWxu-5BZ5mBpcb0=
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

if you are implementing an FIR filter using "fast convolution" which uses an 
FFT and overlap-add or overlap-scrap (often the latter is called 
"overlap-save"), then the window is *rectangular*, but if you do this right, 
there is no ripple artifact from the windowing of the time-domain data.  none 
at all.

all overlap-add or overlap-scrap (a.k.a. "overlap-save") is, is a method to 
make a circular convolution machine perform linear convolution.

now, if you're designing your FIR impulse response using the "windowing 
method", then of course, there are windowing artifacts.  i would suggest 
designing the FIR using the Kaiser window.

lastly, it appears to me that you need to get a copy of Oppenhiem and Schafer, 
because i think you are confusing the overlap-add or overlap-save methods of 
fast-convolution with the overlap-add method of using STFT for something like a 
phase vocoder.  these two different overlap-adds are not the same thing.

--
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."

> On March 7, 2020 10:42 PM Zhiguang Eric Zhang  wrote:
> 
> 
> Not to threadjack from Alan Wolfe, but the FFT EQ was responsive written in C 
> and running on a previous gen MacBook Pro from 2011. It wouldn't have been 
> usable in a DAW even without any UI. It was running FFTW.
> 
> As far as linear / zero-phase, I didn't think about the impulse response but 
> what you might get are ripple artifacts from the FFT windowing function. 
> Otherwise the algorithm is inherently zero-phase.
> 
> 
> On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson 
>  wrote:
> > 
> >  
> >  > On March 7, 2020 6:43 PM zhiguang zhang  wrote:
> >  > 
> >  > 
> >  > Yes, essentially you do have the inherent delay involving a window of 
> > samples in addition to the compute time.
> >  
> >  yes. but the compute time is really something to consider as a binary 
> > decision of whether or not the process can be real time.
> >  
> >  assuming your computer can process these samples real time, the delay of 
> > double-buffering is *twice* the delay of a single buffer or "window" (i 
> > would not use that term, i might use the term "sample block" or "sample 
> > frame") of samples. suppose your buffer or sample block is, say, 4096 
> > samples. while you are computing your FFT (which is likely bigger than 4K), 
> > multiplication in the frequency domain, inverse FFT and overlap-adding or 
> > overlap-scrapping, you are inputting the 4096 samples to be processed for 
> > your *next* sample frame and you are outputting the 4096 samples of your 
> > *previous* sample frame. so the entire delay, due to block processing, is 
> > two frame lengths, in this case, 8192 samples.
> >  
> >  now if the processing time required to do the FFT, frequency-domain 
> > multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame, 
> > then the process cannot be real time. but if the time required to do all of 
> > that (including the overhead of interrupt I/O-ing the samples in/out of the 
> > blocks) is less than that of a frame, the process is or can be made into a 
> > real-time process and the throughput delay is two frames.
> >  
> >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> >  > > ... FFT filtering is essentially zero-phase ...
> >  
> >  FFT filtering **can** be linear-phase (which is zero-phase plus a constant 
> > delay) if the FIR filter impulse response is designed to be linear-phase 
> > (or symmetrical). it doesn't have to be linear phase.
> >  
> >  --
> >  
> >  r b-j  r...@audioimagination.com
> >  
> >  "Imagination is more important than knowledge."
> >  
> >  > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  wrote:
> >  > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> >  > > > Traditional FIR/IIR filtering is ubiquitous but actually does suffer 
> > from drawbacks such as phase distortion and the inherent delay involved. 
> > FFT filtering is essentially zero-phase, but instead of delays due to 
> > samples, you get delays due to FFT computational complexity instead.
> >  > > 
> >  > > I wouldn’t say the delay when using FFT processing is due to 
> > computational complexity fundamentally. Compute affects your max throughput 
> > more than your latency. In other words, if you had an infinitely-fast 
> > computer you would still have to deal with latency. The issue is just that 
> > you need at least 1 block of input before you can do anything. It’s the 
> > same thing as with FIR filters, they need to be causal so they can’t be 
> > zero-phase. In fact you could interchange the FFT processing with a bank of 
> > FIR band pass filters that you sample from whenever you want to get your 
> > DFT frame. (that’s basically just a restatement of what I said before about 
> > the STFT.)
> >  > > 
> >  > > -s
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

Not to threadjack from Alan Wolfe, but the FFT EQ was responsive written in
C and running on a previous gen MacBook Pro from 2011.  It wouldn't have
been usable in a DAW even without any UI.  It was running FFTW.

As far as linear / zero-phase, I didn't think about the impulse response
but what you might get are ripple artifacts from the FFT windowing
function.  Otherwise the algorithm is inherently zero-phase.

On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
> > On March 7, 2020 6:43 PM zhiguang zhang 
> wrote:
> >
> >
> > Yes, essentially you do have the inherent delay involving a window of
> samples in addition to the compute time.
>
> yes.  but the compute time is really something to consider as a binary
> decision of whether or not the process can be real time.
>
> assuming your computer can process these samples real time, the delay of
> double-buffering is *twice* the delay of a single buffer or "window" (i
> would not use that term, i might use the term "sample block" or "sample
> frame") of samples.  suppose your buffer or sample block is, say, 4096
> samples.  while you are computing your FFT (which is likely bigger than
> 4K), multiplication in the frequency domain, inverse FFT and overlap-adding
> or overlap-scrapping, you are inputting the 4096 samples to be processed
> for your *next* sample frame and you are outputting the 4096 samples of
> your *previous* sample frame.  so the entire delay, due to block
> processing, is two frame lengths, in this case, 8192 samples.
>
> now if the processing time required to do the FFT, frequency-domain
> multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame,
> then the process cannot be real time.  but if the time required to do all
> of that (including the overhead of interrupt I/O-ing the samples in/out of
> the blocks) is less than that of a frame, the process is or can be made
> into a real-time process and the throughput delay is two frames.
>
> > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > > ... FFT filtering is essentially zero-phase ...
>
> FFT filtering **can** be linear-phase (which is zero-phase plus a constant
> delay) if the FIR filter impulse response is designed to be linear-phase
> (or symmetrical).  it doesn't have to be linear phase.
>
> --
>
> r b-j  r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
> > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  wrote:
> > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > > > Traditional FIR/IIR filtering is ubiquitous but actually does suffer
> from drawbacks such as phase distortion and the inherent delay involved.
> FFT filtering is essentially zero-phase, but instead of delays due to
> samples, you get delays due to FFT computational complexity instead.
> > >
> > > I wouldn’t say the delay when using FFT processing is due to
> computational complexity fundamentally. Compute affects your max throughput
> more than your latency. In other words, if you had an infinitely-fast
> computer you would still have to deal with latency. The issue is just that
> you need at least 1 block of input before you can do anything. It’s the
> same thing as with FIR filters, they need to be causal so they can’t be
> zero-phase. In fact you could interchange the FFT processing with a bank of
> FIR band pass filters that you sample from whenever you want to get your
> DFT frame. (that’s basically just a restatement of what I said before about
> the STFT.)
> > >
> > > -s
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwIGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=Rfp1ozFiVA9OFrUgHnk8k4E7erWKoT0p7iI83xAoYEo=PQF0MzrvvmNpczp2_8SZoGEb7ojFOWxu-5BZ5mBpcb0=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 7, 2020 6:43 PM zhiguang zhang  wrote:
> 
> 
> Yes, essentially you do have the inherent delay involving a window of samples 
> in addition to the compute time.

yes.  but the compute time is really something to consider as a binary decision 
of whether or not the process can be real time.

assuming your computer can process these samples real time, the delay of 
double-buffering is *twice* the delay of a single buffer or "window" (i would 
not use that term, i might use the term "sample block" or "sample frame") of 
samples.  suppose your buffer or sample block is, say, 4096 samples.  while you 
are computing your FFT (which is likely bigger than 4K), multiplication in the 
frequency domain, inverse FFT and overlap-adding or overlap-scrapping, you are 
inputting the 4096 samples to be processed for your *next* sample frame and you 
are outputting the 4096 samples of your *previous* sample frame.  so the entire 
delay, due to block processing, is two frame lengths, in this case, 8192 
samples.

now if the processing time required to do the FFT, frequency-domain 
multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame, then 
the process cannot be real time.  but if the time required to do all of that 
(including the overhead of interrupt I/O-ing the samples in/out of the blocks) 
is less than that of a frame, the process is or can be made into a real-time 
process and the throughput delay is two frames.

> > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > ... FFT filtering is essentially zero-phase ...

FFT filtering **can** be linear-phase (which is zero-phase plus a constant 
delay) if the FIR filter impulse response is designed to be linear-phase (or 
symmetrical).  it doesn't have to be linear phase.

--
 
r b-j  r...@audioimagination.com
 
"Imagination is more important than knowledge."

> On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  wrote:
> > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> > > Traditional FIR/IIR filtering is ubiquitous but actually does suffer from 
> > > drawbacks such as phase distortion and the inherent delay involved. FFT 
> > > filtering is essentially zero-phase, but instead of delays due to 
> > > samples, you get delays due to FFT computational complexity instead.
> > 
> > I wouldn’t say the delay when using FFT processing is due to computational 
> > complexity fundamentally. Compute affects your max throughput more than 
> > your latency. In other words, if you had an infinitely-fast computer you 
> > would still have to deal with latency. The issue is just that you need at 
> > least 1 block of input before you can do anything. It’s the same thing as 
> > with FIR filters, they need to be causal so they can’t be zero-phase. In 
> > fact you could interchange the FFT processing with a bank of FIR band pass 
> > filters that you sample from whenever you want to get your DFT frame. 
> > (that’s basically just a restatement of what I said before about the STFT.)
> > 
> > -s
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

Yes, essentially you do have the inherent delay involving a window of
samples in addition to the compute time.

On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  wrote:

> On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
>
> Traditional FIR/IIR filtering is ubiquitous but actually does suffer from
> drawbacks such as phase distortion and the inherent delay involved.   FFT
> filtering is essentially zero-phase, but instead of delays due to samples,
> you get delays due to FFT computational complexity instead.
>
>
> I wouldn’t say the delay when using FFT processing is due to computational
> complexity fundamentally. Compute affects your max throughput more than
> your latency. In other words, if you had an infinitely-fast computer you
> would still have to deal with latency. The issue is just that you need at
> least 1 block of input before you can do anything. It’s the same thing as
> with FIR filters, they need to be causal so they can’t be zero-phase. In
> fact you could interchange the FFT processing with a bank of FIR band pass
> filters that you sample from whenever you want to get your DFT frame.
> (that’s basically just a restatement of what I said before about the STFT.)
>
> -s
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote:
> Traditional FIR/IIR filtering is ubiquitous but actually does suffer from 
> drawbacks such as phase distortion and the inherent delay involved. FFT 
> filtering is essentially zero-phase, but instead of delays due to samples, 
> you get delays due to FFT computational complexity instead.

I wouldn’t say the delay when using FFT processing is due to computational 
complexity fundamentally. Compute affects your max throughput more than your 
latency. In other words, if you had an infinitely-fast computer you would still 
have to deal with latency. The issue is just that you need at least 1 block of 
input before you can do anything. It’s the same thing as with FIR filters, they 
need to be causal so they can’t be zero-phase. In fact you could interchange 
the FFT processing with a bank of FIR band pass filters that you sample from 
whenever you want to get your DFT frame. (that’s basically just a restatement 
of what I said before about the STFT.)

-s___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

Sorry I meant Alan :)

On Wed, Jan 15, 2020, 11:20 PM Alan Wolfe  wrote:

> probably pretty basic stuff for most people here but wanted to share a
> writeup and demo i made about FIRs.
>
> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
> 
> Demo: http://demofox.org/DSPFIR/FIR.html
> 
> Some simple ~175 lines of code C++:
> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

This is a very cool blog, I need to spend some time with it. It's also
interesting to draw parallels between the graphics stuff that Alex writes
about to the audio realm.

Traditional FIR/IIR filtering is ubiquitous but actually does suffer from
drawbacks such as phase distortion and the inherent delay involved.   FFT
filtering is essentially zero-phase, but instead of delays due to samples,
you get delays due to FFT computational complexity instead.

On Wed, Mar 4, 2020, 7:56 AM Spencer Russell  wrote:

> On Tue, Mar 3, 2020, at 4:21 PM, robert bristow-johnson wrote:
>
>
> Like a lotta things, sometimes people use the same term to mean something
> different.   A "phase vocoder" (an STFT thing a la Portnoff) is not the
> same as a "channel vocoder" (which is a filter bank thing).
>
>
> It’s maybe worth noting that the STFT _is_ a filter bank where each
> channel is sampled at the hop size and the bandwidth of each band pass
> filter is just the Fourier transform of the windowing function. There’s
> some phase twiddling you can do to convert between a modulated or
> demodulated filter bank.
>
> -s
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=wcymP5JMDQ6nmTKKb1JaORXexaD2h-9hKirDMKv6ThY=3MHKW5VQeMC3BYBKg0rjyq0ep3gs4iI56ewvG-XrTMI=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

On Tue, Mar 3, 2020, at 4:21 PM, robert bristow-johnson wrote:
> 
> Like a lotta things, sometimes people use the same term to mean something 
> different. A "phase vocoder" (an STFT thing a la Portnoff) is not the same as 
> a "channel vocoder" (which is a filter bank thing).

It’s maybe worth noting that the STFT _is_ a filter bank where each channel is 
sampled at the hop size and the bandwidth of each band pass filter is just the 
Fourier transform of the windowing function. There’s some phase twiddling you 
can do to convert between a modulated or demodulated filter bank.

-s___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

sorry, meant to write 'without' certain artifacts and drawbacks of FIR/IIRs

On Tue, Mar 3, 2020 at 4:36 PM Zhiguang Eric Zhang  wrote:

> I just remembered, have you heard of Trackspacer?  This plugin does what
> my code implements, but maybe with smearing and latency and other drawbacks
> of FIR/IIRs:
>
> https://splice.com/plugins/3463-trackspacer-au-by-wavesfactory
>
> -ez
>
> On Tue, Mar 3, 2020 at 4:30 PM Zhiguang Eric Zhang  wrote:
>
>> Hi RWJ,
>>
>> My code doesn't implement any 'telecom' application carrier-modulator
>> sort of filter bank.  the code implements a realtime C implementation of an
>> FFT EQ, sort of the STFT version of an IIR/FIR application in a plugin
>> whose name I can't remember right now.  without getting into semantics, i'm
>> quite sure that this is a valid implementation of the 'phase vocoder' - i
>> remember reading the original paper that coined the term.
>>
>> thanks,
>> eric
>>
>> On Tue, Mar 3, 2020 at 4:22 PM robert bristow-johnson <
>> r...@audioimagination.com> wrote:
>>
>>>
>>> Like a lotta things, sometimes people use the same term to mean
>>> something different.   A "phase vocoder" (an STFT thing a la Portnoff) is
>>> not the same as a "channel vocoder" (which is a filter bank thing).
>>>
>>>
>>> --
>>> r b-j r...@audioimagination.com
>>>
>>> "Imagination is more important than knowledge."
>>>
>>>
>>>
>>>
>>>
>>>  Original message 
>>> From: Alan Wolfe 
>>> Date: 3/3/2020 16:10 (GMT-05:00)
>>> To: A discussion list for music-related DSP <
>>> music-dsp@music.columbia.edu>
>>> Subject: Re: [music-dsp] FIR blog post & interactive demo
>>>
>>> Man that's neat. I've been wondering how a vocoder worked. I'm looking
>>> forward to reading through your work.
>>>
>>> BTW, there is also an IIR demo and blog post now.
>>> http://demofox.org/DSPIIR/IIR.html
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPIIR_IIR.html=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=X7y5DFBfNRVoyS7lKfy3p86uXFVEgRMP4eXlqiyUnuo=>
>>>
>>>
>>> On Tue, Mar 3, 2020 at 1:04 PM Zhiguang Eric Zhang 
>>> wrote:
>>>
>>>> this is cool, i can't believe I actually worked on FFT filtering (via
>>>> phase vocoder) before learning FIR/IIR filters ... ?
>>>>
>>>> if anyone's interested in that source code it's here:
>>>> https://www.github.com/kardashevian
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.github.com_kardashevian=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=bEbSHUqnAVXvE0ysrd9FWK9HOkLEMgHg3A6JF5u745U=>
>>>>
>>>> On Wed, Jan 15, 2020 at 11:20 PM Alan Wolfe 
>>>> wrote:
>>>>
>>>>> probably pretty basic stuff for most people here but wanted to share a
>>>>> writeup and demo i made about FIRs.
>>>>>
>>>>> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.demofox.org_2020_01_14_fir-2Daudio-2Ddata-2Dfilters_=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=4n5Ei4A0nKHFpsgBBVNUHMShfKCQuFVFRsCSs1pitks=>
>>>>> Demo: http://demofox.org/DSPFIR/FIR.html
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPFIR_FIR.html=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=jZbKU-U0MDb2zCIChqGIcXyhzWZ6omet01_BbnGD-3o=>
>>>>> Some simple ~175 lines of code C++:
>>>>> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Atrix256_DSPFIR_blob_master_Source.cpp=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=EFHcs34THi586AJu3OQhMvpori8eF0HPcNFhL0SSQ7Y=>
>>>>> ___
>>>>> dupswapdrop: music-dsp mailing list
>>>>> music-dsp@music.columbia.edu
>>>>>
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzb

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

I just remembered, have you heard of Trackspacer?  This plugin does what my
code implements, but maybe with smearing and latency and other drawbacks of
FIR/IIRs:

https://splice.com/plugins/3463-trackspacer-au-by-wavesfactory

-ez

On Tue, Mar 3, 2020 at 4:30 PM Zhiguang Eric Zhang  wrote:

> Hi RWJ,
>
> My code doesn't implement any 'telecom' application carrier-modulator sort
> of filter bank.  the code implements a realtime C implementation of an FFT
> EQ, sort of the STFT version of an IIR/FIR application in a plugin whose
> name I can't remember right now.  without getting into semantics, i'm quite
> sure that this is a valid implementation of the 'phase vocoder' - i
> remember reading the original paper that coined the term.
>
> thanks,
> eric
>
> On Tue, Mar 3, 2020 at 4:22 PM robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>>
>> Like a lotta things, sometimes people use the same term to mean something
>> different.   A "phase vocoder" (an STFT thing a la Portnoff) is not the
>> same as a "channel vocoder" (which is a filter bank thing).
>>
>>
>> --
>> r b-j r...@audioimagination.com
>>
>> "Imagination is more important than knowledge."
>>
>>
>>
>>
>>
>> ---- Original message 
>> From: Alan Wolfe 
>> Date: 3/3/2020 16:10 (GMT-05:00)
>> To: A discussion list for music-related DSP 
>>
>> Subject: Re: [music-dsp] FIR blog post & interactive demo
>>
>> Man that's neat. I've been wondering how a vocoder worked. I'm looking
>> forward to reading through your work.
>>
>> BTW, there is also an IIR demo and blog post now.
>> http://demofox.org/DSPIIR/IIR.html
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPIIR_IIR.html=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=X7y5DFBfNRVoyS7lKfy3p86uXFVEgRMP4eXlqiyUnuo=>
>>
>>
>> On Tue, Mar 3, 2020 at 1:04 PM Zhiguang Eric Zhang 
>> wrote:
>>
>>> this is cool, i can't believe I actually worked on FFT filtering (via
>>> phase vocoder) before learning FIR/IIR filters ... ?
>>>
>>> if anyone's interested in that source code it's here:
>>> https://www.github.com/kardashevian
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.github.com_kardashevian=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=bEbSHUqnAVXvE0ysrd9FWK9HOkLEMgHg3A6JF5u745U=>
>>>
>>> On Wed, Jan 15, 2020 at 11:20 PM Alan Wolfe 
>>> wrote:
>>>
>>>> probably pretty basic stuff for most people here but wanted to share a
>>>> writeup and demo i made about FIRs.
>>>>
>>>> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.demofox.org_2020_01_14_fir-2Daudio-2Ddata-2Dfilters_=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=4n5Ei4A0nKHFpsgBBVNUHMShfKCQuFVFRsCSs1pitks=>
>>>> Demo: http://demofox.org/DSPFIR/FIR.html
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPFIR_FIR.html=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=jZbKU-U0MDb2zCIChqGIcXyhzWZ6omet01_BbnGD-3o=>
>>>> Some simple ~175 lines of code C++:
>>>> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Atrix256_DSPFIR_blob_master_Source.cpp=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=EFHcs34THi586AJu3OQhMvpori8eF0HPcNFhL0SSQ7Y=>
>>>> ___
>>>> dupswapdrop: music-dsp mailing list
>>>> music-dsp@music.columbia.edu
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=laBYkNOprCxjvEiRMmth13ZBRo22UWYH9IwxeAHbbcQ=>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=laBYkNOprCxjvEiRMmth13ZBRo22UWYH9IwxeAHbbcQ=
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

Hi RWJ,

My code doesn't implement any 'telecom' application carrier-modulator sort
of filter bank.  the code implements a realtime C implementation of an FFT
EQ, sort of the STFT version of an IIR/FIR application in a plugin whose
name I can't remember right now.  without getting into semantics, i'm quite
sure that this is a valid implementation of the 'phase vocoder' - i
remember reading the original paper that coined the term.

thanks,
eric

On Tue, Mar 3, 2020 at 4:22 PM robert bristow-johnson <
r...@audioimagination.com> wrote:

>
> Like a lotta things, sometimes people use the same term to mean something
> different.   A "phase vocoder" (an STFT thing a la Portnoff) is not the
> same as a "channel vocoder" (which is a filter bank thing).
>
>
> --
> r b-j r...@audioimagination.com
>
> "Imagination is more important than knowledge."
>
>
>
>
>
>  Original message 
> From: Alan Wolfe 
> Date: 3/3/2020 16:10 (GMT-05:00)
> To: A discussion list for music-related DSP 
>
> Subject: Re: [music-dsp] FIR blog post & interactive demo
>
> Man that's neat. I've been wondering how a vocoder worked. I'm looking
> forward to reading through your work.
>
> BTW, there is also an IIR demo and blog post now.
> http://demofox.org/DSPIIR/IIR.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPIIR_IIR.html=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=X7y5DFBfNRVoyS7lKfy3p86uXFVEgRMP4eXlqiyUnuo=>
>
>
> On Tue, Mar 3, 2020 at 1:04 PM Zhiguang Eric Zhang  wrote:
>
>> this is cool, i can't believe I actually worked on FFT filtering (via
>> phase vocoder) before learning FIR/IIR filters ... ?
>>
>> if anyone's interested in that source code it's here:
>> https://www.github.com/kardashevian
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.github.com_kardashevian=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=bEbSHUqnAVXvE0ysrd9FWK9HOkLEMgHg3A6JF5u745U=>
>>
>> On Wed, Jan 15, 2020 at 11:20 PM Alan Wolfe  wrote:
>>
>>> probably pretty basic stuff for most people here but wanted to share a
>>> writeup and demo i made about FIRs.
>>>
>>> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.demofox.org_2020_01_14_fir-2Daudio-2Ddata-2Dfilters_=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=4n5Ei4A0nKHFpsgBBVNUHMShfKCQuFVFRsCSs1pitks=>
>>> Demo: http://demofox.org/DSPFIR/FIR.html
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__demofox.org_DSPFIR_FIR.html=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=jZbKU-U0MDb2zCIChqGIcXyhzWZ6omet01_BbnGD-3o=>
>>> Some simple ~175 lines of code C++:
>>> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Atrix256_DSPFIR_blob_master_Source.cpp=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=EFHcs34THi586AJu3OQhMvpori8eF0HPcNFhL0SSQ7Y=>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwMGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=laBYkNOprCxjvEiRMmth13ZBRo22UWYH9IwxeAHbbcQ=>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=MCaeQU6n-HJBdcqPwGQny3Xr_DasnmJQJckL81kti4I=laBYkNOprCxjvEiRMmth13ZBRo22UWYH9IwxeAHbbcQ=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

Like a lotta things, sometimes people use the same term to mean something 
different.   A "phase vocoder" (an STFT thing a la Portnoff) is not the same as 
a "channel vocoder" (which is a filter bank thing).--r b-j                     
r...@audioimagination.com"Imagination is more important than knowledge."

 Original message 
From: Alan Wolfe  
Date: 3/3/2020  16:10  (GMT-05:00) 
To: A discussion list for music-related DSP  
Subject: Re: [music-dsp] FIR blog post & interactive demo 

Man that's neat. I've been wondering how a vocoder worked. I'm looking forward 
to reading through your work.BTW, there is also an IIR demo and blog post 
now.http://demofox.org/DSPIIR/IIR.htmlOn Tue, Mar 3, 2020 at 1:04 PM Zhiguang 
Eric Zhang  wrote:this is cool, i can't believe I actually 
worked on FFT filtering (via phase vocoder) before learning FIR/IIR filters ... 
?if anyone's interested in that source code it's 
here:https://www.github.com/kardashevianOn Wed, Jan 15, 2020 at 11:20 PM Alan 
Wolfe  wrote:probably pretty basic stuff for most people 
here but wanted to share a writeup and demo i made about FIRs.Post: 
https://blog.demofox.org/2020/01/14/fir-audio-data-filters/Demo: 
http://demofox.org/DSPFIR/FIR.htmlSome simple ~175 lines of code C++: 
https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
 
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Alan Wolfe]

Man that's neat. I've been wondering how a vocoder worked. I'm looking
forward to reading through your work.

BTW, there is also an IIR demo and blog post now.
http://demofox.org/DSPIIR/IIR.html


On Tue, Mar 3, 2020 at 1:04 PM Zhiguang Eric Zhang  wrote:

> this is cool, i can't believe I actually worked on FFT filtering (via
> phase vocoder) before learning FIR/IIR filters ... ?
>
> if anyone's interested in that source code it's here:
> https://www.github.com/kardashevian
>
> On Wed, Jan 15, 2020 at 11:20 PM Alan Wolfe  wrote:
>
>> probably pretty basic stuff for most people here but wanted to share a
>> writeup and demo i made about FIRs.
>>
>> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
>> 
>> Demo: http://demofox.org/DSPFIR/FIR.html
>> 
>> Some simple ~175 lines of code C++:
>> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
>> 
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

this is cool, i can't believe I actually worked on FFT filtering (via phase
vocoder) before learning FIR/IIR filters ... ?

if anyone's interested in that source code it's here:
https://www.github.com/kardashevian

On Wed, Jan 15, 2020 at 11:20 PM Alan Wolfe  wrote:

> probably pretty basic stuff for most people here but wanted to share a
> writeup and demo i made about FIRs.
>
> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
> 
> Demo: http://demofox.org/DSPFIR/FIR.html
> 
> Some simple ~175 lines of code C++:
> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
> 
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp