Hello,
After working on Mixxx for 6.5 years, I am exploring the possibility of starting fresh with a new DJ application written in Rust. So far I have no code to show, only a placeholder repository with a roadmap. I am posting here to ask if anyone is interested in collaborating on this and how we can collaborate on the ecosystem across projects.
Mixxx was started 20 years ago by someone who still doesn’t consider himself a DJ and many bad technical decisions were made early on. That was before DJ controllers existed. Although the controller mapping system’s flexibility is great, it is also quite clunky because the design of the core application has evolved inconsistently (and I’ve been wanting to rewrite it since I first started using Mixxx 
).
Now, Mixxx is at a crossroads where the technical debt standing in the way of upgrading from Qt5 to Qt6 is enormous. Mixxx’s GUI rendering is very complicated, inefficient, and revolves around a deprecated API which was removed in Qt6. There were efforts to move to Qt’s newer API which were unsuccessful despite months of work. The only feasible path forward for Mixxx is to rewrite the entire GUI from scratch using QML instead of QWidgets. Progress has been made towards that, but there would still be a long way to go. Lots of Mixxx is coupled to the GUI, including the entire music library database system and Auto DJ feature, so those would have to be completely rewritten for Qt6. Although I have resolved compile errors with Qt6, finding boundaries to cut out code coupled to the legacy GUI so the application could link with Qt6 is a major challenge. Realistically I would anticipate it would take 1 - 2 years for Mixxx to make a release with Qt6.
So, I am now considering to invest those years into a new application built on a better foundation in Rust instead of continuing to rewrite Mixxx system by system. I have been exploring the existing Rust audio ecosystem and it looks like there are some nice libraries available to get started. In particular, creek and Symphonia look very useful. dasp looks like a great foundation which I hope gets widely adopted so we can build an ecosystem of easily interoperable crates. cpal looks useful as well, although it seems immature. I do want this application to be cross platform eventually, but for now I want to focus on Linux (unless some other early contributor wants to help with supporting another OS). If it turns out that cpal does not meet my needs, I might directly use the JACK bindings for now.
I think there is a lot of opportunity for collaboration with the RustyDAW project (ping @BillyDM). I don’t know if a DJ application would benefit from the complexity of rusty-daw-audio-graph because DJ applications have relatively fixed signal paths with typically only an effects system that is modifiable by the user at runtime. I think it could be really interesting to collaborate on rusty-daw-timeline, particularly the MusicalTime struct described in the Meadowlark design document. I am doubtful about the proposal in that design document to use MusicalTime as the basis for timing throughout the application. For a DJ application, the musical time data would come from automatic analysis which likely won’t be accurate in many cases. For a DAW, the musical timeline should not need to exist. For example, a musical timeline is useless if you’re editing a recording of speech. Instead, I suggest to use clock time (seconds) as the basis of timing throughout these applications.
As for the GUI, I plan to use SixtyFPS. While there are a handful of other cross platform Rust GUI projects, I think SixtyFPS is the most promising for a few reasons, despite its present immaturity. First and perhaps most importantly, it has two developers working on it full time who have a lot of experience from developing Qt (one of them was a lead engineer for QML). A cross platform GUI library is an enormous task and I doubt hobbyist projects will reach the maturity needed for something as complex as a DJ application. Also, I don’t want to create the GUI with Rust code; the declarative domain-specific language of SixtyFPS looks much more appealing to design and maintain IMO.
Let me know if you’re interested in collaborating. 
The first steps will be simply playing an audio file with creek and showing a slider for the playhead. Take a look at the roadmap for further plans.
Do you have any suggestions for the application’s name?
