Make the Equalizer's analyzer the new Spectrum Analyzer

[unfa]

Wouldn't it be great?

I know I can use the Equaliser as an analyser, but the correction controls are obscuring the view of the graph - the tools isn't optimised for only looking at the spectrum, it's optimised for making changes.

[MaximumHarp]

I like that, would be a very useful feature.

[musikBear]

so a dead simple solution would be a method on the EQ "Use as Spectrum" and that would simply just hide every control -right?

[NotAFile]

Considering how much better the graphic EQ is now and how useless the base spectrum analyzer still is, this should really be done. How would you estimate the difficulty of this?

[he29-net]

Hi!

I found this thread somewhat randomly, while searching for a "better spectrum analyzer for LMMS". I'm new to LMMS, and music production in general, so I didn't know that the EQ has its own analyzer, let alone that it is better than the dedicated spectrum analyzer.

While the EQ analyzer satisfied my immediate needs, I agree that having a good separate spectrum analyzer may be still nice. Compared to the EQ analyzer, the dedicated plugin really feels more like a toy than a useful tool, I wasn't able to extract much useful information from it. Not to mention it is absolutely tiny on my 4K / 185 DPI screen (but so is the rest of LMMS bitmap-based GUI, so that would be for another discussion).

So I thought I would look around and see if I can implement the suggested change. That was actually a few weeks ago. And while it took only a day or so to implement most of the changes, the world is full of distractions and time is scarce.. :)

I will try to find some more time for it this week, but first I wanted to ask some questions about your preferences and project practices:

1. Should I outright replace / remove the old Spectrum Analyzer plugin, or should I keep it around for better backward compatibility and / or nostalgic users? Since it does not do anything to the sound, I guess it should not break anything, but as I said, I am new here..

2. Do you prefer one big commit, or multiple small, incremental steps? I have some more improvements in mind, so I'm thinking about implementing those first and polishing the whole thing at the end, instead of wasting effort on cleaning up mid-development snapshots.

3. How would you feel about ditching the bitmap-based interface? I never worked with Qt before, but it seems to have more than enough drawing functions to produce all that's needed. The great advantage would be that the analyzer window could be made resizable, allowing the user to get more detail if needed. It would also scale far better on high-DPI screens, whereas scaled-up bitmaps will always look ugly, no way around that.

P.S. While studying the code, I noticed you can actually hide the bottom EQ controls by double-clicking the background. Just in case you didn't know (I didn't). Could be useful in the mean-time. :)
Thanks,
Martin

[musikBear]

@he29-net -That sounds great! I think you should contact a dev directly on discord:
https://discordapp.com/invite/5kSc32Z
Contact anyone in #devtalk

[zonkmachine]

@he29-net Welcome!

I'll give my two cents.

1. Should I outright replace / remove the old Spectrum Analyzer plugin, or should I keep it around for better backward compatibility and / or nostalgic users? Since it does not do anything to the sound, I guess it should not break anything, but as I said, I am new here..

Drop the old one.

2. Do you prefer one big commit, or multiple small, incremental steps? I have some more improvements in mind, so I'm thinking about implementing those first and polishing the whole thing at the end, instead of wasting effort on cleaning up mid-development snapshots.

We usually squash pull requests down to one single commit, at least if they are for the same issue. I think dividing your work into reasonable chunks is a good idea.

A similar issue: #4395

[he29-net]

@musikBear I did not use Discord before, but I'll take a look, thanks.

@zonkmachine Thanks. I was afraid that pull request would behave like a branch merge, bringing the full commit history along. Squashing sounds nice. :)

I'm aware of the #4395 and since I'm already a familiar with the code, I may look into that next. But I think it would be better to bring most improvements to the dedicated analyzer first, and then decide what should be ported back to the EQ analyzer, so that the EQ interface does not become cluttered with many options unrelated to equalizing.

[he29-net]

Is there any resident Qt wizard around? :) I ran into a small problem with making the window resizable. In src/gui/widgets/EffectView.cpp there is a line that sets all "Controls" windows for effects to have a fixed size:
m_subWindow->layout()->setSizeConstraint(QLayout::SetFixedSize);
If I get rid of it, I can make the the window resizable. Since this is called after the window is created, any configuration I make in the constructor is ignored (I literally spent about two hours figuring out what is wrong, I assumed I simply used the Qt settings the wrong way).

Obviously I do not want to remove the line, since all the other effect plugins probably rely on it being there. But a resizable window would be quite useful for a spectrum analyzer, so: is there a way to prevent the parent from overriding the size constraint setting? I tried to change the setting back inside a showEvent(), but for some reason it did not work (and it would not be nice, anyway).

Or is it simply not desirable to have any resizable effect control windows?

[michaelgregorius]

@he29-net, for the changes made in pull request #2068 I also had to enable the resizing of certain effect windows. You can find the changes here.

I solved the problem by adding a new virtual method called isResizable to EffectControlDialog.h. Its default implementation returns false which means that all already existing dialogs will behave as before. The new dialog that's implemented by the PR returns true. The method is queried in EffectView.cpp to determine whether to set dialogs to fixed sizes or not (see here).

I think the code in some of these classes has changed a bit but the whole principle should still be applicable. Hope this helps!

[he29-net]

@michaelgregorius Nice! Just a while ago I noticed there is actually an old issue mentioning the same problem (#1904), so I thought of solving it more generally by adding some "resizability hint" variable that would be checked by EffectView -- essentially the same thing you already implemented in a cleaner way. So this saves a lot of time, thanks. :)

[he29-net]

Well, while it may take one or two more weeks to finish, it was quite a productive weekend -- apart from implementing resizable spectrum view and log./linear switching, I also managed to get a simple waterfall graph working. Here is a small example / teaser.. :)

(Blue / orange tint represents left / right balance.)

This was actually the main reason I looked for a "better spectrum analyzer" in the first place; I already encountered these real-time spectrograms while playing with software defined radios and when I saw @unfa use baudline in one of his videos about zynAddSubFx, I just knew I must have it. :))

To illustrate how is this useful: the top half of the waterfall shows spectrogram of a church bell sample. The bottom half shows my attempt to create a similar sound in zynAddSubFx, using just my ears and a spectrogram of the original opened in Audacity. Even though it sounded like striking a metal, I could not figure out what was I missing. Here I can instantly see all the problems and differences -- I was not even remotely close. :)

Also, I may be getting a little bit out of scope of this issue. Sorry about that. I can make a new one if needed.

[NotAFile]

Wow, that's awesome! Do you have a branch pushed somewhere where I can try it out?

[he29-net]

Yes, at https://github.com/he29-net/lmms (master branch).
But the waterfall diagram currently does not scale and draws just first 512 bands of the 2048-band FFT. Also, there is some flicker, probably because I'm drawing the image even while the underlying data are being updated. And so on; you have been warned. :)

[he29-net]

Nearly done. :)
I will tweak few more things, try to prepare a testing binary by the end of the week to get some feedback and then open a PR if there are no major issues. It took a while longer than I initially thought to work out all the details, but I think the result does not look too bad. ^^

[he29-net]

Whew.. as always, the last 20 % take 80 % of the time; the signal processing stuff was a cakewalk compared to the Qt wizardry required to make it do what I want.

I still need to finish cleaning-up the code before making a PR, but the plugin should be ready to use in case anyone wants to try it out and provide some feedback. As mentioned above, it's on a master branch at https://github.com/he29-net/lmms/tree/master (no binaries in the end, sorry). I'm mainly interested in crashes or unexpected behavior and whether it works on platforms other than Linux. But any other remarks are also welcome. Thanks.

[JohannesLorenz]

@he29-net resolved this by implementing the new spectrum analyzer (#4950) 🎉