Equalizer plugin, refinement to analysis display #3530
Conversation
plugins/Eq/EqSpectrumView.cpp
Outdated
| @@ -38,6 +38,21 @@ EqAnalyser::EqAnalyser() : | |||
| m_inProgress=false; | |||
| m_specBuf = ( fftwf_complex * ) fftwf_malloc( ( FFT_BUFFER_SIZE + 1 ) * sizeof( fftwf_complex ) ); | |||
| m_fftPlan = fftwf_plan_dft_r2c_1d( FFT_BUFFER_SIZE*2, m_buffer, m_specBuf, FFTW_MEASURE ); | |||
|
|
|||
| //initilise BalckmanHarris window, constants taken from | |||
| //https://en.wikipedia.org/wiki/Window_function#A_list_of_window_functions | |||
There was a problem hiding this comment.
spelling...
- //initilise BalckmanHarris window, constants taken from
+ //initialize BlackmanHarris window, constants taken from
There was a problem hiding this comment.
Also there's a dash there, Blackman-Harris
|
@michaelgregorius do you have time to test and approve this pull request? |
|
@tresf, @curlymorphic: I had a look at the changed code and also compiled the branch myself to test it with a simple sine wave at 110Hz again. First something that I noticed while looking at the code. It might be worthwhile to put the code that generates the window into a separate class in case we decide later to also implement other windowing functions. As for the practical test it seems that unfortunately the patch doesn't have a big effect in the tested case. Here's the EQ from master: And here's the same signal with the patch applied: For reference here's the same signal shown in the frequency analyzer from REAPER using a buffer size of 2048: Please note that LMMS cuts off the display at around -18 dB FS and that that's the reason why the plots don't look almost identical. Judging by the plots and looking at the changed code the implementation seems to be correct. However, it seems that the main culprit for the high leakage is the buffer size of 2048 that's used for the FFT. If I set the buffer size to 32768 in the REAPER frequency analyzer the peak for the test signal becomes very sharp and does not spill over. I think the following features might be interesting for the analyzer:
The reason for the last request is that some people mix with signals peaking at around -18 dB to have enough headroom. If you do this in LMMS and send such a channel through the EQ you will likely see almost nothing in the plot window. Sorry, for requesting all this here. I usually hate pull requests that request more and more features myself. 😉 If you want we can add separate issues for these requests. |
|
Thanks for the in-depth report. I will have to check the range on the display when I'm at my pc, but its alot more than the -18dB, its just squashed vertically when compared to reapers output. The +-18dB is the gain 'for the eq controls. It could be an idea to add the analysis scale on the right hand side. "First something that I noticed while looking at the code. It might be worthwhile to put the code that generates the window into a separate class in case we decide later to also implement other windowing functions" I would agree. The fft-helper class, but that would cause confusion, as there is already a function there, that's suposed to do the windowing, that iirc is used in the spectrum analyzer plugin. However there are some problems with it. It calculates the window incorrectly, it also calculates the window for each sample played, 2 trig functions and 2 divides per sample is just silly. "I think the following features might be interesting for the analyzer: The ability to switch the windowing function. These are all good ideas, I was tempted to add these to this pull request but i decided againt adding new features at this stage. I do think it would be a good idea to add these suggested features, but in a seperate pr aimed at master. I can do a mock up of the additional features, in the not to distant future, but i would prefer to fix current bugs first. "If you want we can add separate issues for these requests." Yes please. |
|
I think you should try out the von Hann window, it's the default in calf analyzer and works pretty good. When using the blackman-harris windowing in the calf analyzer it added a lot of weird harmonics to the sine waves, while the von Hann window really seemed like the best choice. |
Wouldn't that make the latency on the EQ go through the roof? |
Its the trade off between frequency and time resolution.
Thats a great idea, maybe for the update aimed after 1.2 release, we should collate a list of what windowing functions users would like, and any additional functionally required then plan and evaluate the expansion. I am keen to do this, could be a nice team project. |
Yes, bigger windows definitively introduce some latency. However, I assume that this would only affect the graphical display and not the processing of the signal itself.
I agree and I think that LMMS needs more of such team efforts/projects. Right now LMMS seems to be mainly developed by individual developers who contribute with pull requests. Obviously there is a limit to what a single developer can do and this keeps the project from implementing the bigger changes that are needed/wanted like a better separation between the core and GUI classes, realtime safe operations or the single window GUI. |
|
@Umcaruje I will remove the unused windowing function code, when a decision has been made as to what is preferred. |
|
Maybe it will be better to separate window initializing code to some new functions and implement switching between window functions. |
|
@curlymorphic I have added #3624, #3625 and #3626 to deal with the aforementioned features separately. @PhysSong I agree that it would be a good idea to have a class or a collection of functions that can generate different types of windowing functions that can be reused in different places. |
I have no preferred windowing function myself. I've tested this and it works fine. I think we can merge it as it is with a von Hann window and the commented out Blackman-Harris function and then get back to it after 1.2 is released. |
|
Some windowing functions(Hamming and von Hann) are already implemented in fft_helpers.h, and I think it is possible to reuse them. If someone needs other window functions, simply adds it into fft_helpers.h and use it in plugins. |
I think that can be fixed later here: #3625 @LMMS/developers Merge? |
|
Someone might want to see not windowed spectrum as before. I think windowing on/off button should exist. |
|
@zonkmachine I really want to hear from @michaelgregorius on which windowing function is better, so we can clean up the code before merging. |
|
@Umcaruje I don't think there is something like a "better" function. As can be seen here they all have certain tradeoffs: https://en.wikipedia.org/wiki/Window_function#A_list_of_window_functions It seems that the main lobe of the FFT is more pronounced with Blackman-Harris. So I'd use Blackman-Harris for now and then implement the switching of windowing functions as part of #3625. One option for the switching should be something like "Off (Rectangular)" so that it can also be turned off. |
|
If we can make a decision I will amend the pull request to suit. My vote would be Blackman-Harris, I would like to stick with the decision of not changing the fft_helpers class this close to a release. I do plan on implementing the windowing functions in the fft_helper class, but I shall aim that pull request at master due to changes affecting more than just this plugin. Changing the Equalizer plugin to use this code can then be handled in #3625. |
|
@curlymorphic Sound reasonable and good to me! |
The spectural analysis was using a rectangle window, leading to high spectural leakage. This pull request uses the Blackman-Harris window to give a display more representative of the audio.
|
Yeah, Blackman-Harris gets a 👍 from me as well then, this should be merged |
The spectural analysis was using a rectangle window, leading to high spectural leakage. This pull request uses the Blackman-Harris window to give a display more representative of the audio.
The spectral analysis was using a rectangle window, leading to high spectral leakage.
This pull request uses the Blackman-Harris window to give a display more representative of the audio.
Fixes #2703