Using Rust/Ratatui framework preferably.
Activity
30I mean it's open source so you can fork it and do whatever you want
I mean it's open source so you can fork it and do whatever you want
I mean it's open source so you can fork it and do whatever you want
Some UI (whether T or G) for actually turning the virtual "pots" and picking the effect would probably be interesting. Right now I just do it all manually.
But only something simple. This really isn't worth anything fancy.
Some UI (whether T or G) for actually turning the virtual "pots" and picking the effect would probably be interesting. Right now I just do it all manually.
But only something simple. This really isn't worth anything fancy.
Some UI (whether T or G) for actually turning the virtual "pots" and picking the effect would probably be interesting. Right now I just do it all manually.
But only something simple. This really isn't worth anything fancy.
Some UI (whether T or G) for actually turning the virtual "pots" and picking the effect would probably be interesting. Right now I just do it all manually.
But only something simple. This really isn't worth anything fancy.
A TUI or a UI (web interface) would be nice for this, like @SomeRandomCpu said, you can just create a fork after checking the license.
A TUI or a UI (web interface) would be nice for this, like @SomeRandomCpu said, you can just create a fork after checking the license.
A simple TUI sounds like a good fit here. Something that lets you select effects, tweak a few parameters, and maybe visualize basic levels or waveforms would already go a long way.
I’d strongly encourage keeping it minimal. This project doesn’t really need a big framework-heavy UI. A small Ratatui-based TUI that talks to the existing code and focuses on turning “virtual knobs” would be perfect.
If you decide to build it, the best path is to prototype it in a fork first, keep it clearly separated from the core DSP, and then open a PR once there’s something concrete to review. Starting with offline/file-based processing before worrying about real-time capture will probably make things much easier.
And yes, it’s cool to hear Ratatui can target the web too, but I’d personally treat that as an optional experiment rather than a goal for this repo.
Looking forward to seeing what you come up with.
A simple TUI sounds like a good fit here. Something that lets you select effects, tweak a few parameters, and maybe visualize basic levels or waveforms would already go a long way.
I’d strongly encourage keeping it minimal. This project doesn’t really need a big framework-heavy UI. A small Ratatui-based TUI that talks to the existing code and focuses on turning “virtual knobs” would be perfect.
If you decide to build it, the best path is to prototype it in a fork first, keep it clearly separated from the core DSP, and then open a PR once there’s something concrete to review. Starting with offline/file-based processing before worrying about real-time capture will probably make things much easier.
And yes, it’s cool to hear Ratatui can target the web too, but I’d personally treat that as an optional experiment rather than a goal for this repo.
Looking forward to seeing what you come up with.
A simple TUI sounds like a good fit here. Something that lets you select effects, tweak a few parameters, and maybe visualize basic levels or waveforms would already go a long way.
I’d strongly encourage keeping it minimal. This project doesn’t really need a big framework-heavy UI. A small Ratatui-based TUI that talks to the existing code and focuses on turning “virtual knobs” would be perfect.
If you decide to build it, the best path is to prototype it in a fork first, keep it clearly separated from the core DSP, and then open a PR once there’s something concrete to review. Starting with offline/file-based processing before worrying about real-time capture will probably make things much easier.
And yes, it’s cool to hear Ratatui can target the web too, but I’d personally treat that as an optional experiment rather than a goal for this repo.
Looking forward to seeing what you come up with.
A simple TUI sounds like a good fit here. Something that lets you select effects, tweak a few parameters, and maybe visualize basic levels or waveforms would already go a long way.
I’d strongly encourage keeping it minimal. This project doesn’t really need a big framework-heavy UI. A small Ratatui-based TUI that talks to the existing code and focuses on turning “virtual knobs” would be perfect.
If you decide to build it, the best path is to prototype it in a fork first, keep it clearly separated from the core DSP, and then open a PR once there’s something concrete to review. Starting with offline/file-based processing before worrying about real-time capture will probably make things much easier.
And yes, it’s cool to hear Ratatui can target the web too, but I’d personally treat that as an optional experiment rather than a goal for this repo.
Looking forward to seeing what you come up with.
If you intent on using @ratatui, maybe create a new repo specifically for the TUI. Adding yet a new language to the project might spiral dependencies out of control and make it harder and heavier to build. Ratatui have quite a bit of dependencies already.
C and Python already have TUI frameworks, if you want to merge the code, it might be better to stick with the current languages.
If you intent on using @ratatui, maybe create a new repo specifically for the TUI. Adding yet a new language to the project might spiral dependencies out of control and make it harder and heavier to build. Ratatui have quite a bit of dependencies already.
C and Python already have TUI frameworks, if you want to merge the code, it might be better to stick with the current languages.
If you intent on using @ratatui, maybe create a new repo specifically for the TUI. Adding yet a new language to the project might spiral dependencies out of control and make it harder and heavier to build. Ratatui have quite a bit of dependencies already.
C and Python already have TUI frameworks, if you want to merge the code, it might be better to stick with the current languages.
Гоооо друн
I mean it's open source so you can fork it and do whatever you want