Open mincequi opened 2 years ago
Although I am officially the owner of this repository, my complete goal for this (as stated in the Readme) was to port the original program to QT5, so this is just an opinion of one user.
- Remove the Excitation Generate button and do not write excitation file to disk. Instead, generate Excitation in-memory, when pressing "Start recording". This is easily fast enough.
That seems like an improvement to me if the implementation can, for example, re-use an unchanged excitation.
- Integrate the Plot view into the main ui, so that there are no extra windows floating around.
That depends on the actual implementation (see below).
- To save space for 2., I would like to create some top-level taps like "Settings", "Measure", instead of having that all on one single page.
I would have to see a mock-up, but doesn’t this just exchange “extra windows floating around” with “some top-level taps” instead of reducing complexity?
- Reduce the Measurement sets table to a single column (Description) to save space for plot integration. The details could be shown elsewhere on the ui. I do not believe, someone is interested in "Uses excitation" and "Max. level" in advance of selecting a measurement.
In my most recent measurements (mainly distortion-related), I have been using the “Max. level” information regularly for selecting a measurement.
- Add Material icons: https://github.com/sthlm58/QtMaterialDesignIcons
As there are currently no icons, where are these supposed to go?
- Add possibility to load microphone calibration files (in "Settings" tab).
Probably an improvement too (although I don’t own any calibrated microphones).
I would like this project to catch up with https://www.roomeqwizard.com/ and do a general modernisation.
Actually, I prefer KISS and Unix philosophy, so I would prefer, say, ten applications that interface nicely for the functionality that REW seems to offer.
That seems like an improvement to me if the implementation can, for example, re-use an unchanged excitation.
Sure, the excitation(s) can be cached
I would have to see a mock-up, but doesn’t this just exchange “extra windows floating around” with “some top-level taps” instead of reducing complexity?
Regarding complexity: i am a minimalist and always try to reduce (UI )clutter as far as possible. Actually, i rewrote the whole UI using QtQuick / QML (see screenshot). It already exceeds a mock-up. :)
Actually, I prefer KISS and Unix philosophy, so I would prefer, say, ten applications that interface nicely for the functionality that REW seems to offer.
Well, i do not believe this philosophy also fits to an (integrated) GUI application. I prefer something that integrates the needed tools for speaker development into one package. Consider other apps like 3dsmax, Android Studio, QtCreator. They all offer an integrated UI for several (sub-)tasks and keep that sub-tasks in a dedicated view. However, this is subjective.
Long story short: i rewrote the whole app utilizing modern approaches and design, but please see yourself. This is not finished yet, but measuring already works. I just wanted to keep you posted :)
If you are interested: i got a basic version of "qLouder" up and running: https://github.com/mincequi/qLouder
That looks very nice. I don’t have to measure anything right now, but I would probably have some questions if I did (e.g. measuring beyond 20 kHz). Unfortunately, I couldn’t get so far as running the program: qLouder seems to depend on PulseAudio (which I try to avoid). Maybe it’s just an Arch packaging issue, but qt5-quickcontrols2 seems enough to compile but not run the program (I can’t find a package for qt5-quick). Obviously, cmake is needed now too.
Nice to get some feedback. Well, measuring beyond 20 kHz is pointless (at least for consumer hardware and even semi-professional hardware). I guess you heard about the famous quote: "wer misst, misst Mist" ;) The thing is, that most hardware simply does not provide "sane" data beyond 20 kHz. Some hardware makes you believe it can sample up to 96 kHz, but this is in most cases just noise. Anyhow, if there are still reasons to do so, i could change that. qLouder itself does not depend on PulseAudio. It is Qt's Multimedia package that depends on it. You need the following Qt packages: Core Quick QuickControls2 Multimedia Charts Svg Xml. And yes, CMake is now the golden standard of C++ build systems. Qt will drop qmake in favour of cmake: https://www.qt.io/blog/qt-6-build-system
Looking forward to get some further feedback if you ever intend to use qLouder for speaker measurement. My intention is to revive the original qloud using modern approaches. One thing still to consider: my main platform is macOS. The linux port might need some tweaking and hopefully, i find the time to do so very soon.
Since I have been using qloud for purely electrical measurements (active crossover, microphone preamp, …), I doubt that measuring beyond 20 kHz is pointless in general. Current ADDA chips are quite capable above 20 kHz (semiprofessional ones easily go up to 192 kHz, so a limit of 96 kHz minus filtering) as far as I know. I would be more worried about the lower corner frequency with arbitrary windowing in the time domain.
Just to check, this is a Focusrite 18i6 (which I would consider semiprofessional at best) ADDA loopback: samplerate-test.pdf
Ah ok, you are really measuring electrical components other than mics, speakers and consumer soundcards... Ok, this goes beyond my use-cases are intended for.
What do you mean with arbitrary windowing in the time domain? Currently, i considered a -200ms to +800ms window at maximum and also respecting this paper: https://www.conforg.fr/euronoise2015/proceedings/data/articles/000420.pdf
I’m not really qualified to answer your question; my basic signal processing courses were a long time ago. From the screenshots, it seems like you can adjust left and right windows in the time domain, which would have an effect on the lowest measurable frequency, frequency resolution, ringing, etc. So “a data windowing targeted to the specific application of the measured impulse response should be applied, in order to optimize the results and avoid possible computation errors.” Since you don’t know the specific application, you could either try to explain the effects and “possible computation errors” to the user, or you could just extend the range way beyond what you actually want to measure.
Hey there,
as I am working with this App extensively, I would like to come up with some UI improvements:
I would like this project to catch up with https://www.roomeqwizard.com and do a general modernisation.
What are your thoughts? I would continuously provide PRs for that rework.
P.S.: I know, that the PortAudio integration is holding us back. However, things should improve, when the platform-specific issues are done.