wasm-audio-clipper VS Gooey

It works for me. Here's a wasm-ffmpeg solution I created trim audio.

https://wasm-audio-clipper.netlify.app/

Check the repo: https://github.com/marclundgren/wasm-audio-clipper. I ended up lazily registering the context. The memory footprint stays lower even after trimming multiple clips on the same session.

The name conflicts with a similar python module that allows one to turn any Python console program into a GUI with one line.

https://github.com/chriskiehl/Gooey

Hey! Cool project! I have a question: why do you dump out sys.argv to a local file in the CWD? [0] tmp.txt is hardly a unique name… or am I missing something and this never triggers?

[0] https://github.com/chriskiehl/Gooey/blob/be4b11b8f27f500e732...

This might be of interest to you:

> Gooey - Turn (almost) any Python 3 Console Program into a GUI application with one line

https://github.com/chriskiehl/Gooey

I love gooey: https://github.com/chriskiehl/Gooey

It allows me to quickly slap a GUI on an existing script that accepts command-line-arguments. In the end, I get the best of both world: Discoverability from the GUI, automation through the script, and automatic feature parity between the two.

Downside: Control over the GUI layout is basic, and only "standard" GUI features work, but I never felt limited when using it.

similar for local/individual usage:

https://github.com/chriskiehl/Gooey - take a python-CLI, make a TK-windows

and then probably even simple dashboarding like streamlit.

Like Gooey?

As for how I'd handle it, I would probably combine both into one command-line program, with all filepaths using pathlib and letting argparse handle the options. That way you could optionally generate a GUI with gooey with little extra effort, although this would also add a dependency.