💾 Archived View for nanako.mooo.com › gemlog › 2024-08-20-a.gmi captured on 2024-08-25 at 00:21:29. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Well, the release of Benben v0.5.0 seems to have gone really well. No tickets yet, and I only found one post-release bug (and it was so minor that I didn't feel it warranted a v0.5.1). So woo hoo! 🎉🎉🎉 Here's hoping the luck lasts while I work on v0.6.0 ^_^ Speaking of which, I wanted to go over some of the points in the now-updated v0.6.0 milestone that's in the wiki:
Let's start by getting the painful stuff out of the way. HTTP and Gemini support will be removed in v0.6.0, meaning you can't directly play files from an HTTP/HTTPS or Gemini link. This was technically only available for VGM files anyway, so it isn't a major removal, but one I'm rather sad about. Unfortunately it's necessary. The way it was implemented before would never have worked with most (all?) of the other formats, was not extensible, and was clumsy as heck. I'm sure support for HTTP and Gemini will appear again in a future version, but they've been cut in v0.6.0. This is already reflected in the trunk code.
Again, this only impacts VGM files, which was the only format that supported HTTP/HTTPS and Gemini links. You can still load local files just fine.
There are three new formats that I want to add during this development cycle, one of which is already done: Quite OK Audio (QOA), WavPack, and C64 SID. QOA support is already done, and you can check it out by building the trunk code, or getting the recent v0.6.0-dev AppImage. It's a pretty interesting format that appears geared towards things like game engines or other places where super-fast and low-latency decompression are key. While I don't foresee this being used much by people, I also haven't noticed support for the format in other players, and I'm sure someone will eventually come across a QOA file and want to listen to it. Plus, I kinda fell in love with the format. So, it's been implemented in Benben.
Releases, including the v0.6.0-dev AppImage
The other two formats will arrive in the coming weeks and months. WavPack seems easy enough to add since I can just bind the official C library, which looks to have a nice and clean API. I was a _little_ worried about WavPack files that are in hybrid mode and have a sidecar file (.wvc), but it looks like the API already handles this seamlessly. So adding support for it won't be a problem, and I may just split the WavPack bindings off into their own library like I did with RemiXMP and RemiMpg123. After all, more Crystal libraries are a good thing these days, especially for audio ^_^
C64 SID files are another story, and will take a bit more work. All of the existing libraries (at least those that give good audio) are written in C++ instead of C, including the one I've chosen to use, libsidplayfp. Since I can't directly bind against a C++ library due to the name mangling that goes on in that language, writing bindings for libsidplayfp implies first writing C bindings for it, and then writing Crystal bindings against those C bindings. Joy. Plus I'll have to handle an external database file for the song lengths since .sid files don't actually store this. Given all of this, I'll probably do just the bare minimum bindings needed for Benben and keep them internal to the program, at least for now.
Either way, all of these are guaranteed to be implemented for v0.6.0.
One small, but significant, improvement I want to implement for v0.6.0 is support for monaural files. So far I've only supported stereo, mainly because the vast majority of files that will be played are stereo, and it was simple. But I've since needed to play some monaural files. Handling of these should be as easy as upconverting them to stereo on-the-fly in the `PlayableFile#render` methods, which is a very fast operation. It's also only needed for some of the formats since others, such as VGM and modules, are always rendered in stereo anyway.
I'm also planning to add seeking support for Ogg Vorbis, Opus, and FLAC files. I left this off from v0.5.0 for two reasons: Vorbis and Opus files are both encapsulated in Ogg streams, and I'm not 100% sure how I'll add support for seeking to my custom Ogg demuxer yet; and FLAC is implemented with my own from-scratch FLAC decoder via RemiAudio that never considered streaming to begin with, so adding it to that is somewhat more invasive than I wanted for v0.5.0. But, this development cycle seems like a good time to tackle both of these, especially since 0.5.0 is proving the existing code to be solid. I may also implement seeking for VGM files, which is a whole different beast altogether.
One new change already in the trunk code is how the theme can be specified in the config file. If you just specify a single theme, then only that one is loaded and used. Simple and straight forward. But, now you can also specify an *array* of themes in the config file. When you do this, a random theme from the array will be chosen at startup. A small, but fun, change.
Speaking of themes, adding them was kind of a last-minute idea with v0.5.0, but it's one that I'm VERY glad I implemented in the end. Unfortunately, writing themes is somewhat of a pain right now because you have to edit an external YAML file, leading to an Edit -> Start Benben -> Quit Benben -> Make Changes loop. Long-term I would like to have some sort of dedicated theme editor, either built-in to Benben or external to it. But for now, I'm thinking of adding support for theme reloading in Benben itself. This will essentially act like song-specific config reloading does now, where you hit a key and the theme is reloaded from disk and is immediately applied. But I'm also somewhat on the fence about this because of the internal changes that would be required, and how those will impact future UI decisions. If I can figure out a good way to implement this, both from user and programming perspectives, and in a way that will work with the vague plans I have for the UI in future versions, then I'll go ahead and add it.
Oh, and there will be a new theme option for themes in v0.6.0: the colors of the flashing bars above/below the banner. This will be backwards compatible with existing themes, so no need to worry about that.
Moving on, one thing I would really like to have in Benben is a spectrum visualization of the audio. It already has VU meters, sure, but having a proper spectrum analyzer (logarithmic, not linear!) would just be awesome and fun. I *kinda* sorta know how to implement one, though certain details are still a mystery to me. I'm also not 100% sure where in the UI to place it. My current favorite idea is, at startup, the banner animation plays and is shown for X amount of seconds. After that, the banner disappears and is replaced with the spectrum analyzer. Buuuut... not all of the banners are the same size... so do I resize the UI when the spectrum gets shown? Or do I display it elsewhere? An alternate idea is to have a separate view/window, where you'd hit a key and the UI would disappear and be replaced with a full-screen spectrum analyzer. But I don't exactly like this because it would hide UI elements that I really want to keep on screen. Anyway, if I figure out a good idea as to where to place it in the UI, and I learn the specifics on implementing one, a spectrum analyzer will appear in v0.6.0. A nice, sexy, colorful text-based one 😁
Finally, I'd like to revisit the song queue box that appears at the bottom of the UI. Right now, your currently playing file is always displayed as the top or next-to-top song in the queue, and there is no way to scroll through the queue without changing songs. This works, but is kinda clumsy. Adding a way to actually scroll through your play queue without changing songs would be AWESOME, and let you go to a different song that's in a way different position without having to continually hit `n` or `p`. It would also open the door for additional functionality, like a "queue next song" function similar to what's found in Audacious, reordering songs at runtime, removing songs at runtime, and (down the road, not in v0.6.0) adding songs at runtime. This will basically necessitate a complete rewrite of the song queue box. Getting it to at least scroll, remove songs, and the "queue next song" is likely going to appear in v0.6.0, but I can't 100% guarantee it just because of the work needed, and how my mental health is. Let's say it's 90% going to appear in v0.6.0.
Not much is changing with rendering. There's been a small change in the trunk that's improved performance when normalizing the output files (basically it happens while rendering instead of during a separate step so that it takes advantage of the parallelism), but that's about it. Buuuut... a lot of these formats that I added in v0.5.0 were via libraries that already include compression functionality. How cool would it be if you could render directly to Vorbis or Opus instead of PCM? Or how about FLAC? Or QOA? I may add such functionality in v0.6.0, in part or in whole, depending on how time and mental health go. QOA would be the easiest to add, by far, since there's no options, and it's already implemented in RemiAudio. FLAC would be the most difficult since my original implementation only ever had decoding support to begin with, so I'd have to write an encoder from scratch. So we'll see what time brings. Probably rendering to QOA at the very least.
Internally (that is, stuff that won't affect users, but might be of interest to devs who want to contribute), I've been going through and cleaning up various bits of the design of Benben. Some of this was started in v0.5.0, but most of the planned cleanup is taking place in v0.6.0.
To start, I've split up the `OrigUI` class into what are essentially widgets. This should improve maintenance of the UI going forward. The bits that have been turned into widgets are the tag/info display fields (each of which are `TagField` widgets, which were introduced in v0.5.0), the play queue box, the progress bar, and the banner (which was already widget-fied in v0.5.0).
Also, the `PlayableFile` and `VirtualFile` classes have been merged into one, so now there are only `PlayableFile`s. This merge was done because the two classes were overlapping in functionality.
Input handling has been moved out of the `ProgramManager` class and into the `OrigUI` class, where it makes a lot more sense to have it. Having input handled by `ProgramManager` was an oversight left over from my early versions of the program, and actually wasn't even being handled by S-Lang. Now it's in `OrigUI`, and handled by S-Lang. This will help if there's ever an additional UI added to Benben (*cough* Nuklear or GTK+2 or whatever).
So yeah, quite a few changes are coming in v0.6.0. The changes this time around feel more subtle from a user's point of view, at least to me, but I feel they'll greatly improve the user experience. I have zero idea of when this will get released... let's say December for now.
--------- Page served by Aya https://nanako.mooo.com/fossil/aya/ Aya is under the GNU Affero GPLv3 license