busybee fluffy rambles

The difference

Basically, Blamscamp is a web GUI that lets you bundle up a bunch of already-encoded mp3 files into a .zip bundle that can then be uploaded to itch.io (or any other webpage). It’s a pretty great start for things! But it’s only the very last step of publishing an album on itch.

pyBlamscamp, in contrast, does the complete encoding and tagging pipeline for the album, shoves it into a highly modified version of the Blamscamp player, and can also automatically upload everything to itch.io if you have butler set up.

Basically, pyBlamscamp handles all of the tedious bits for you! But it’s also kind of a pain to use right now. My intention was to always build a GUI of some sort for it to make the whole process much easier (and so you don’t have to know Python and so on).

GUI notions

My preferred way to build a GUI would be to have a standalone executable that you can install locally (with builds for macOS, Linux, and Windows, of course), because that makes a lot of the file-management stuff a lot easier, and doesn’t have all of the big dangerous security and privacy implications of having people upload arbitrary files to a server (not to mention the expense of handling lots of files and needing to worry about, like, expiration policies or whatever).

Building it as a web thing is basically just one step removed from building an entire replacement for bandcamp, and that’s just, like, a lot, y'know?

(And yes I realize that blamscamp runs as a webpage but everything runs in-browser; it doesn’t actually handle any files server-side, it’s all just a very thin local GUI around an HTML template and a .zip packer, more or less.)

Running it locally means that you can keep track of where all of the encoded files go and don’t have to worry about your stuff being, like, leaked and stolen and whatever.

That said, a web GUI could certainly be built around pyBlamscamp. But it just opens up so many questions about shit I, frankly, don’t want to think about right now.

My intended path for the local GUI would be to build something in tkinter or some other reasonably lightweight/portable Python GUI toolkit, and then to use one of the Python bundlers to make self-contained builds for the target platforms.

I also want to eventually have pyBlamscamp include the media encoders directly, although the ecosystem for that stuff is a bit… weird right now. For now I’m fine with it just shelling out to the various encoder tools. And of course it will always have to shell out to butler.

Naming things is hard

Anyway. The name has been a huge source of confusion, and also one of my plans is to replace the player itself with something else, meaning it’s no longer at all related to Blamscamp anyway. For example, there’s Scritch which works similarly to Blamscamp but has some nicer features, but also there’s a few other things I want to support such as per-track art (which pyBlamscamp’s modifications support already) and a lyrics display and so on, which means I’m very tempted to just write my own when I have nothing better to do.

But I really suck at naming things! So I’d love to take some suggestions.

An ideal name would make it obvious that it’s intended to support selling music on any number of platforms, and honestly I don’t think it really needs to evoke Bandcamp itself. I’m just building a thing to make it plausible to sell my music on any storefront, not just on Bandcamp, and that it does way more than just making a player.

For example, I’ve been using the encoder output to also sell the files on ko-fi and Gumroad, and those don’t support any sort of inline player at all. For now I’m just embedding appropriate YouTube videos for previewing, but I’ll probably eventually upload my album previews to my own website (which really needs to be redone too) and then hand off the actual commerce to one of those other storefronts. Or invest in building my own cart system, or something. I don’t know.

Anyway. Yeah. Name suggestions would be good, especially ones which keep possibilities open.