The Road Ahead

For those of you who missed it, Starship shut down on the 16th (two days late, whoops!). If you've still got data you forgot: don't fret, it isn't gone and won't be for another month. That being said, if you really do have missing data: please let me know now.

If you have no clue what any of that meant and what it has to do with Muzak, you don't have any missing data. If you're curious though, read my last blog post. Starship was a sort of open-source groupware-meets-social-network experiment that lasted 4 years.

Muzak

Right now, I have four things on my plate. If I had to break it down, I probably spend about 50% of the time I spend doing “work” on Muzak, 30% on my schoolwork, 10% on my game, Boing, and the last 10% on my responsibilities at the Linux User's Group.

Personally, I don't actually have a problem with this. But I'd like to be able to start working on the GPUI documentation I'd promised several times, and a couple people had expressed that they'd like to contribute to Muzak, so I've been cleaning up the code. The two goals have been to make the Muzak code easier to work with and to make it more reliable on more setups.

Here's everything I've done and plan to do in service of this:

I hope to have all of this done by the end of next week.

Muzak 0.1

My requirements for an 0.1 release are as follows:

The current release and listing views aren't generic: they can't be used outside of listing tracks in a release and listing albums in your library. Plus, they aren't that great in general: you can't change the sorting order in the album list, and you cant see track artists in the release list. My goal for 0.1 is that everything that makes it to the 0.1 release can stay for a while, so the track listing in the release view needs to be reusable by playlists, the album view needs to use a generic table component, and the usability of all of this ought to be a little better. Expect work on this bit to be started after the big refactor I mentioned before is done.

The mute button is simple, I just haven't decided if storing whether or not something is muted is the responsibility of the UI, playback thread, or the used DeviceProvider. It's not been fixed because I don't care much for mute buttons in audio players, but it's the first thing that almost everyone I've shown the player to has noticed, so clearly some people do care for them.

As for the other two, these are just the two things that are bothering me right now, and I'd like there to be less things that bother me in the stable release.

I hope to have a stable version of Muzak by the end of March. This isn't really a fixed goal, and I'm not sure I'll be able to hit it, but that's what I'd like to happen. The stable version won't mean that the latest release goes away, though.

Muzak 1.0

Obviously, 1.0 is a ways away. Everything in the README file's planned feature list should be done before 1.0 comes out, plus some smaller things like having a proper menu bar, the command palette, proper hotkeys, etc. I'd also like to do a design pass on the entire application, since there's some elements that I don't love but aren't a priority right now.

Post 1.0

I have some bigger ideas that cost a lot of money and require a lot of work and I don't have a job right now. One of them includes allowing you to losslessly stream files from your computer over the network to other Muzak users, so you can have a Spotify Jam type session but with music you made or something. TURN servers cost a lot of money, so don't expect that any time soon.

I also have a pipe dream of starting an open lyrics database (like Musixmatch), but I'm not sure of the legal feasibility of it.

GPUI Book

I really like GPUI. It's one of the best UI frameworks I've ever used, if not the best. I have a few complaints about it (image dropping and blur effects when) but they're mostly around it being pretty unfinished.

A lot of people use Muzak or Zed as GPUI references, and I'll be honest, neither are great references. Both programs have a lot of complex state and synchronization, and the Zed code base is massive. Most of what I've learned of GPUI is just pure brute force or from asking questions in the #gpui Discord chat, since the examples could never really cover the entire surface area of GPUI.

I see a lot of the same questions in the Discord server, so my goal is to cover the “basics” like Entities, Render vs RenderOnce, what the hell a “SharedString” is, and how to make an element (which there are no really good examples or documentation for but is actually really important), just to give you an idea.

I don't know when I'm gonna start this, because I already have a lot on my plate right now, but it's definitely something I hope to get the ball rolling on soon.

Boing

For those of you who don't know, I've been working on a game called Boing for a while. It's sort of a cross between Ricochet (the Valve game no one's ever played), Super Smash Bros., and Team Fortress 2, and it's been stuck in sort of development hell because I am (very predictably) incredibly unhappy with most of the game engine offerings right now. I think we're going to stick with this new version that I'm working on in Unreal Engine 5, though.

I haven't been making much progress on it lately because Muzak got much more popular than I thought it would much faster than I thought it would, and it's been my main time sink for a while. Once I get 0.1 done I hope to get a build out for play-testing (for those of you with access) of the new Unreal version, since the current Godot version is pretty deeply unstable. Unfortunately, starting the GPUI book comes first, so it'll be a while yet.