eozd / libreguitar Goto Github PK

• Unit tests + linting via github actions
• Linux Docker image
  • Might omit the desktop component at first

GameLogic sometimes picks DSharp octave 2 note although it is outside the range (just below E2 note). Might be an off-by-one error somewhere.

Currently planned stats:

1. Average time to find a note
2. Notes ordered by the time it takes to find them.
3. NPM (notes per minute)

Need to do some research on how this can be done. It seems that it might be trickier than finding the frequency via FFT. If all else fails, some ML approaches might be worth looking at.

Currently signal reading from audio device and audio processing is done on the same thread. This causes the thread to miss some audio blocks on systems with slow CPUs, as the audio processing is being performed synchronously. We might instead perform the audio processing on a separate thread so that we don't miss any parts of the input signal.

Release pipeline should create flatpak images for linux binaries. Further, we can create multiple binaries for linux, one with GUI and one without. Considering the amount of dependencies the GUI component pulls in, this might result in compact CLI binaries.

Currently sample rate and buffer size are hardcoded into the library. We need to allow users to choose these values

Maybe look for crates that make argument parsing easier.

Similar to Windows build, we need to test the application on MacOS.

Visualization and game logic parts should be made optional. It is enough to make the GUI part optional at this stage.

We need logging capabilities to log errors/missed frames/etc. Writing to STDERR should suffice for the moment.

• Show guitar fretboard (either on console or on the frame buffer).
• Ask the note to be played on a specific string (asking for the specific octave is not very useful)

Frequency detection seems to not work so well on lower frequency ranges. This might be due to the wrong usage of rustfft library. The main reason for this argument is that the same detection algorithm seems to have almost perfect accuracy with its previous Python implementation.

See https://github.com/BurntSushi/ripgrep/blob/master/.github/workflows/release.yml for inspiration.

The part in GameLogic main loop where the code waits for the target note to be detected sufficiently many times by the analyzer blocks the GameLogic thread. This part might be better done

• either on a separate thread
• or via non-blocking calls.

Find a way to provide the application as a simple-to-run Windows binary.

Currently the detection algorithm hardcodes certain constants. We need to expose them as a simple config file (toml or yml).

#45 enables Windows builds for libreguitar. However, ASIO support is currently disabled for reasons discussed in the MR description. We should enable it once the issues are resolved.