Convolution Graphing

[ElliottBridge]

Maybe put a lower limit on the scaling for the graph? The phase numbers are very much off the chart. Just a visual aid. I understand E- numbers, but not everyone does. Plus, all those decimals are probably not necessary. Not important, but figured best to point it out

[ElliottBridge]

Also, is phase analysis limited to a given amount of taps by any chance? E.g. It looks at the first few thousand?

[HEnquist]

I haven't tried plotting a filter where the phase is close to zero everywhere like that,and I agree it doesn't look great. The plotting library I use (chart.js) allows setting a lower limit for the automatic y-scale. I'll just set that to -+1 degree. Doing the same for the dB scale is probably also a good idea.

The phase plot uses the entire impulse response. But the trace is drawn with a limited number of points to speed things up. Right now it's 300 points, which was ok before but is a bit low now when zooming is available. I'll experiment a bit to see what the number should be.

[ElliottBridge]

I haven't tried plotting a filter where the phase is close to zero everywhere like that,and I agree it doesn't look great. The plotting library I use (chart.js) allows setting a lower limit for the automatic y-scale. I'll just set that to -+1 degree. Doing the same for the dB scale is probably also a good idea.

The phase plot uses the entire impulse response. But the trace is drawn with a limited number of points to speed things up. Right now it's 300 points, which was ok before but is a bit low now when zooming is available. I'll experiment a bit to see what the number should be.

Ah, I also have a crossover built into a convolution, which is why I asked. Large changes at low frequencies require a large number of taps, and so although the gain/frequency part is displayed correctly, the phase is out by +/-150° on my 14000 tap combined roomEQ/crossover convolution filters. That's the benefit of this program, it can be used on devices with plenty of processing power, allowing for large numbers of taps to be used and therefore low frequency linear phase corrections to be used.

Also, for things like crossovers, it's best not to have an upper limit. Maybe it's possible to have lower limits set to the graphing, whilst leaving upper limits wide open? (With phase wrapping of course)

Edit: I know analysis of that many taps is a lot, but since it's only done during configuration my thought is it should be alright.

Maybe to allow for long tap convolutions to be read fully without freezing up lower end devices, maybe it could be possible to read the number of taps and analyse to that given amount of taps? You know how in the GUI it displays the number of taps used? Maybe just use that variable in deciding how to read the data from the graphs?

[HEnquist]

The analysis is always done on the full impulse response. Then the resulting tables are scaled down to a lower number of points. This is meant to avoid making the GUI sluggish. The plotting library recently got some speed improvements. I haven't investigated since then, perhaps the scaling down isn't actually needed any longer.

Your troublesome filter sounds like a very good one to use while working on improving the plotting. Would you mind sending it to me? A screenshot of how it's supposed to look would be helpful. You can find my email in my GitHub profile. Thanks!

[ElliottBridge]

The analysis is always done on the full impulse response. Then the resulting tables are scaled down to a lower number of points. This is meant to avoid making the GUI sluggish. The plotting library recently got some speed improvements. I haven't investigated since then, perhaps the scaling down isn't actually needed any longer.

Your troublesome filter sounds like a very good one to use while working on improving the plotting. Would you mind sending it to me? A screenshot of how it's supposed to look would be helpful. You can find my email in my GitHub profile. Thanks!

Of course, I'll have to get it to you tomorrow though (I'm running on timezone: GMT)

[HEnquist]

Of course, I'll have to get it to you tomorrow though (I'm running on timezone: GMT)

Thanks! But don't stress, I won't have any free time to work on this the next couple of days anyway.

[ElliottBridge]

Tweeter-mid with correction and 300Hz 48dB/oct linear phase Linkwitz riley high-pass: Woofer with correction and 300Hz 48dB/oct linear phase Linkwitz-Riley low-pass:

Both are configured for a 48kHz sample rate. Impulse delay, etc are shown in green at the bottom. Each are 64bit mono wave files. Configured for a max delay of 115ms. 125ms of delay is the upper limit before delay has to be added to video due to lip-sync cohesion, so figured 115ms (11000 taps) is a reasonable maximum for 48kHz Both are optimised for phase and linearity above -150dB noise floor. Which is well beyond human perception even at the pain threshold of hearing at listening level (should be enough for the most upstanding audiophiles). I'll email the files over

[HEnquist]

There is a bug somewhere in the analysis part of the gui! It works for short filters, but gives bad results for long ones. Unfortunately I won't have any time to spend on this the coming week or so. I'll work to fix it as soon as I have a little free time.

[ElliottBridge]

There is a bug somewhere in the analysis part of the gui! It works for short filters, but gives bad results for long ones. Unfortunately I won't have any time to spend on this the coming week or so. I'll work to fix it as soon as I have a little free time.

No worries, no rush at all. I think we're all just happy this project is actively worked on by you. You're doing an amazing job! Thank you!

[HEnquist]

Should be solved now. The problem was that the frequency scale got displayed wrong when the filter length wasn't a power of 2. Please update pycamilladsp-plot to 1.0.1, and use the 1.0.0-rc5 release of the gui.