rimio / specgram Goto Github PK

First sentence under Display Options reads You will notice that there isn't much difference between the output of the above command and the others which makes no sense, as the rx_sdr example has been added.

then you can use the -q -> then you can use -q

Fix these.

Unit testing for testable things like ColorMap, FFT, InputParser, InputReader, parts of Renderer, ValueMap, WindowFunction.

• ColorMap
• FFT
• InputParser
• InputReader
• Renderer
• ValueMap
• WindowFunction

Log info message when file is written to disk.

After some time, the output of tone.py generates a garbled set of outputs.

Command line:

python ../test/tone.py 11025 44100 s16 | ./specgram -lq

Output:

Run valgrind on a bunch of functional tests.

Header files should explain way better the purpose and workings of the module.

The jet colormap is a classic, but I have to admit it looks like crap for live (scrolling) spectrograms.

A cool but easy on the eyes colormap is required.

Command:

parec --channels=1 --device="stereo.A.monitor" --raw --latency-msec=4 | specgram -lq -y 4000 -f 10000 -sdBFS,-70,-20

Output:

This seems to be a default behavior in multiple CLI tools, so it should be supported by specgram as well.

If no input is provided via stdin, the live view window presents a garbled image, at least under picom. See attached image.

Mismatch:

project (specgram VERSION 1.0.0 LANGUAGES CXX)

# Version
set (VERSION_MAJOR 0)
set (VERSION_MINOR 9)
set (VERSION_PATCH 2)

Allow definition of custom scale strings using the -s, --scale options.

dBFS will remain a special case and default option, as it uses the dBFSValueMap which clamps the values to an upper limit of 0.

Add new LinearValueMap and dBValueMap value maps which map the values accordingly.

If the string begins with db or dB then it defaults to dBValueMap and the rest of the string is used for display purposes. Limits can be specified with, maybe, commas? I.e. -s dBm,20,-20 specifies the limits for a dBValueMap.

Otherwise it uses a LinearValueMap with the limits specified as above.

As per one user's request:

(also, I wonder if it would make sense for specgram to stop whenever the stream ends; I'm guessing around AsyncInputReader::ReachedEOF(). Since, once we get an EOF on stdin, there should be no way to get more data in... right?)

While good for latency during high throughput scenarios, it's not necessarily nice to keep a CPU at 100% while waiting for input.

Explore the ideas of:

• introducing std::this_thread::sleep_for in the two cases where we wait for input within the main loop
• introducing a flag for activating the above behavior (i.e. busywait by default, wait on flag set)

Allow dumping of PNG image data to stdout, where the user can display it with imagemagick. E.g.:

specgram -i infile - | display

• LiveOutput caches the Configuration object, but also caches ColorMap and ValueMap. Maybe split relevant stuff from Configuration?
  Renderer caches Configuration, maybe shouldnt?
• Renderer::*fft_area* stuff refer to the spectrogram fields, so should be named accordingly.
• const auto MustDumpToStdout() const -> auto MustDumpToStdout() const

On latest Gentoo install, using i3, Esc key does not close window.

Rename all factory methods to something like Build(...).

Command line:

./specgram -eq -f 8192 -y 4000 --bg-color=00000000 --fg-color=000000ff -i ../resources/clips/rammstein_dalai_lama example_file.png

Output:

The program's logging needs are rather simplistic, so there's no need to keep spdlog as a dependency, especially after the incompatibility issues with fmt 8.0.0.

Write own logging routine.

Build fails under ArchLinux, cannot find std::clamp().

Command line: ./specgram -lq -f 10000 -y 5000 -s dBFS,-80,-30

Scale:

Write functional tests that make sure the overall output to known inputs is correct.