I'm a DJ/TUI nerd and as much as I want to like this, I don't think the keyboard will ever be the right input or mode for DJing. Maybe my mental model is an outlier, but multi-point physical controls are critical for so much of what's happening while DJing — the master level controls, effects, cueing, individual track controls, and even just being able to physically manipulate playing tracks. It just doesn't map to a TUI, or perhaps more importantly, it just doesn't seem fun. How does the TUI transition this? What makes a TUI the right interface?
some controls lend themselves well to a TUI, others not so much. buttons and pads: no problem. knobs and faders: passable but compromised. jog wheel for scratching: pretty much needs to be controller/midi.
No reason this project couldn't add midi controller support directly to the backend (not via TUI!).
I think for algorave stuff it's great because I'm already at the keyboard, but I totally agree with you otherwise. I was thinking (way too complex at this point) of adding control macros to be able to "turn" 2 knobs at once, because that's something real hands and knobs can do, but not this TUI atm.
I mean, you theoretically still could have that, USB decks send MIDI signals (even though I found it a bit obtuse trying to get my FLX4 to control anything except VirtualDJ - I was trying to map it to grandMA lighting controls). The TUI here could be primarily a presentation layer. I think the main benefits would be a) more hackable than VirtualDJ and b) it looks cool.
Regardless, you might be able to use my timestretch library: https://github.com/robmorgan/timestretch-rs - it's still very early, but it's working for alot of my use cases, and it's pure Rust.
the constraints of a TUI force you to be creative (in a good way) how to represent/encode information to the user.
In a DJ TUI, how to represent the track waveform? Encoding waveform amplitude in ascii blocks or dots is a pretty low fidelity representation. Instead, you can encode waveform amplitude in single row of blocks with 256 color/intensity averaging the backing sample peaks.
And's if you ever do stems separation you have 4 such rows for each track - efficient and dense!
As the track is playing, or user is zooming or jogging, this representation would give more of the feel that the playhead is moving through the track smoothly.
yeah it's pretty cool. you can also use it as a regular music player. if you toggle autoplay, it will automatically keep playing the next track in your track list. supports uploading local libraries and youtube, and recording, uploading and sharing mixes.
I guess this is a boring and predictable thing to say, but I miss seeing a project like this and being excited about it. Instead I looked at the codebase, see that it seems LLM-generated and assume it hasn't had much thought or care put into it, so I'm not really motivated to even try it out. Sorry. :-/
I'll come out and say it, heavily AI-assisted. First rust project, and wanted to dive on in with something that I'd been wanting to make. Lots of iteration, almost entirely free opencode tier models and agentic edits. I know what behavior I'm looking for though, and rust is pretty good at finding obvious errors (clippy too). It's not a production app, and it's just for fun, so ya. :)
Perhaps one needs to go a level up: if making the program is now semi-trivial, it remains to be proven if using the program to actually perform is. If I have a Star Trek replicator that can reproduce a perfect Stradivarius for me, is it any less impressive when I play a beautiful song on it?
If we want to get excited about a mixing board... we probably need to see someone using it in ways that traditional mixers don't facilitate.
exactly this. Id think the main thing for this would be to get midi controllers working. its a digital tool for digital djs. looks a bit niche ofc if you look at 'the market' etc. but as OP said for newer thigs like algorave and just for fun it looks pretty cool :D.
id love this workin on a phone with a little usb-c midi controller attached!
> assume it hasn't had much thought or care put into it
> I'm not really motivated to even try it out
That's a little uncharitable. I get where it's coming from, because I also still feel a tinge of (hypocritical) disappointment when I realize things are built with LLMs, but I truly think we need to start moving past this. It's not a giant corporation trying to scam you out of your hard earned money by passing slop off as a lovingly crafted product: it's somebody's pet project, somebody who clearly had a fun "what if" idea and was able to materialize it over time, with a TBD amount of care/iteration/refinement. I think it's something worth engaging with. Worst case scenario it sucks, like many cheapo projects do -- best case scenario it's awesome and/or it sparks a new interesting idea in somebody else.
Does it do what it says on the tin? If so, does it matter that it's made with an LLM?
In my own experience, LLMs+TUIs are surprisingly effective. They deal with the tedium of ncurses development much more than I can. It took an LLM about an hour to put a TUI over recutils so that I can monitor task progress. I doubt I could have done the same that shortly. My point is, 'that it works' is much more important to me than how it works.
