Hi Zachary,

"Mechvibes and Klack [...] both have some shortcomings: [...] large, [...], lags, [...] closed-source "

Did you check out Bucklespring? Tiny (15kb binary), open source, runs on linux, macos and windows:

https://github.com/zevv/bucklespring

on Debian or Ubuntu just "apt install bucklespring" and you're good to go.

I don't know it. I just checked, and it is indeed smaller. However, I found its customizability to be weaker. I think providing a good GUI to offer more audio options is a feature I want.

Are you saying that I can make my MacBook Pro sound like an IBM Selectric II with a negligible performance hit? I will attempt to hide your identity from my wife for as long as possible, but I make no promises.

The secret's safe—just don't pin any noise complaints on me.

Let's us know

What would further reduce the size is to ditch the JS-frontend completely. Unless the purpose was to test and showcase Tauri, this is a waste of CPU and memory.

In terms of application size, I think around 5MB is great since it provides more convenient GUI features.

Regarding CPU and memory usage, if you don't open the Tauri program window, its CPU and memory usage is negligible.

KeyEcho's usage scenario only involves opening the window for necessary settings. After closing the window (or starting in the background by default), all window resources will be released.

If it is only used for audio playback, I think using the lower-level cpal instead of rodio built on top of it may provide better performance.

I'll check it out. Thanks for the tip.

Are you only going to include 2 audio files, might want to provide an easier way to add more in the dashboard.

Of course, this is already in the update plan. I will add more audio options in the next version!

On macOS, I get the message that the disk image is corrupted.

Not the same error. It seems like the arm64 dmg is indeed broken/corrupted. The amd64 build works (with Rosetta) - after bypassing the security warning.

Thanks for the feedback. I will start looking into it.

For a settings-only frontend, I would personally just run a web server and leave it to the user to open it, so you don't have a webview using up memory. Ehh, works either way.

It's a good choice indeed. But it adds complexity. Maybe I will choose to do this in the future.