Get it on GitHub!

When I made Advanced Invasion I found myself spending an inordinate amount of time developing and polishing the various UI elements towards the end. Partly, my own perfectionism is to blame. Despite Advanced Invasion being - by design - an incredibly simple game, I wanted to include all sorts of bells and whistles including an achievements system, jukebox, and reasonably fully-featured options menu (although I neglected to include controls settings in the end because it was already taking too long (and there’s also an about menu for license compliance btw but that’s not as fun)).

These kinds of periphiral elements - at least I believe - add a lot of substance to a game. It gets even better when you include stuff like level editors, concept art menus, etc. Consequently, I’m quite keen on including at least a jukebox, achievements, and options screen in all my future games.

So, to save time, I want to create these various elements in advance so I can just drop them into future games. One of the first I wanted to tackle - primarily because it’s the most difficult - is a mod loader.

Now, this probably sounds a bit OTT considering that a perfectly good option already exists, and in fact I would recommend most people use that option instead. But, for an upcoming project I may or may not do, I’d like to have a few specific features. Specifically, I want a good way of distributing required asset packs separately from the source code, and this might as well hook into a modding system. This is good if, like me, you’re an open source game developer and, on occasion, you need to deal with proprietary assets.

Consequently, one of the main selling point of SV Mod Loader is the ability to configure checksums for official or required mods and verifying that you have the real deal before launching the game. Other than that, the system is pretty rudimentary. It just uses the normal methods for loading .pck files.

Other than that there’s a couple exxtra bells and whistles. The UI includes an inbuilt load order editor, with the ability for uses to create and manage multiple different mod lists. There’s an about menu you can use to show important information e.g. licenses before launching the game, and you can customise a lot of elements of the mod loader through exported variables.

Overall, I don’t really expect this to be that useful to anybody. There are much more stable and mature alternatives out there, after all. But, if your needs just happen to be similar to mine, you might find it interesting. In that case, it’s open source and you can get it on GitHub.

If you want to skip the spiel and just download it, you can get it on the GitHub page here (scroll down to the usage section).

As you may know I make MIDIs in REAPER, and you can make this process a little easier by loading in a reabank file. It’s basically a specification of all the instruments that your synth (or VST) supports. This allows you to select the right bank/program CCs a little easier without having to flip back and forth between your DAW and the manual.

Currently this reabank contains pretty much everything you should need for a normal MIDI, i.e. all capital instruments and variation instruments are represented, which means you should be covered for everything in the Roland GS standard as it existed when the SC-88 Pro came out.

I also added support for the default, SC-55 and SC-88 maps. I don’t use this, but I felt like adding them for completeness. Unfortunately I realised towards the end that I missed the native map (the default map, LSB 0, uses whatever map your device is set to, while the native map, LSB 3, overrides the device to force the native map). I’m not quite sure yet whether this is an issue. Would you typically wnat to use the default map or the native map when making a MIDI for the SC-88 Pro? You could argue both ways, since the default map allows the user to override the map if they so choose, but the native map allows you to force the MIDI to sound as intended. I checked just now and sending a GS reset doesn’t override whatever you’ve done with the map buttons on the front of your SC-88 Pro, so this is actually quite a consequential question for MIDI design.

Either way, adding the native maps is the next thing I’m doing when I get the chance. If only for completeness sake. Shouldn’t take too long since it’s mostly just a copy-paste job.

There’s also a few more features I want to add:

• CM-64 Map
• User Instruments
• Adding “(legato)” to the names of instruments that support it, to differentiate them from identically-named non-legato instruments.

Also, here’s a fun (or depressing) fact: I wrote out pretty much the entire reabank file by hand. I’m sure you could automate it, but given that I’m sourcing the instruments from a manual which is already littered with formatting errors - not to mention I’m not even sure how consistent the construction of the PDF is - I don’t think an automated process would necessarily be any less error-prone. And, of course, may I direct your attention to the relevant xkcd. It was pretty educational working through the instrument table manually (I got a feel for how the GS standard is laid out) and I don’t mind this kind of detailed work anyway (maybe that’s autism or something idk).

Anyway that’s pretty much it; check out the reabank file on GitHub here, or if you just want to go straight to the download go to the latest release page here.

PS: this is a blog post, so it’s liable to be out of date if I make updates to the reabank file. Go to the GitHub for info on the latest version. I’m currently deciding whether I want permanent pages for literally all my projects, or just blog posts for the small ones, but for now I’m just going for blog posts because it’s quicker than figuring out how I want to fit them into the layout of my website.

You may have noticed that I’ve done very little in the way of making MIDIs lately, and that’s because like most people, I’m getting sick and tired of Windows.

My previous workflow used Roland Sound Canvas VA - an official emulator for several SoundCanvas devices in VST form - which only worked on macOS and Windows. I’ve moved most other stuff I’m doing onto Linux, but getting Windows VSTs running on Linux is still a bit of a pain in the ass. I’m sure it’s possible, but I still haven’t cracked that nut yet.

So my music workflow had to remain on Windows, with me switching over to my Windows partition every time I want to write some music. Which I didn’t really end up doing because that felt like a bit of a headache. It’s a bit of a first-world problem, but ideally when inspiration strikes you want to be able to just fire up your music tools and go.

This problem was coupled with the fact that Roland has discontinued Sound Canvas VA. The music industry will not be satisfied until every software tool is a nightmare to use, it seems. Luckily, I bought Sound Canvas VA back when you could still get a permanent license, but it’s still a bit nerve-wracking to be using deprecated software that won’t be updated anymore. Especially since there’s a lot to update, seeing as it’s - in my experience - buggy and annoying to use.

So I basically needed to migrate my workflow to something else. The obvious answer would have been to use physical hardware instead, but I was short on both money and time (due to studying, graduating, and starting a new job) so that had to wait.

Anyway, since then my circumstance have stabilised quite significantly, so I’ve been able to order some physical hardware. Behold, the SC-88 Pro:

Well, that’s the second one I bought, because the first one unfortunately died in transit. The ebay seller assured me that they had tested it so I guess we can chalk this up to a freak accident of nature that happened in the cargo hold of a plane.

I don’t have a recording of the first one not making any sound (for fairly obvious reasons - there’s nothing to record), but here’s a nice view of a failed memory test:

(I assume the NG stands for “Not Good” or something)

Anyway, I had to settle for a partial refund from the seller, so I still have the first unit. Audio technicians in the area are generally reluctant to touch synthesizers, so I cracked it open to figure out if I could find the problem myself:

So it seems I have a few leaky capacitors (two of the three are pictured above). These are on the audio board, so I’m not sure if that explains the memory failure, but it definitely explains the lack of audio output. It could be some king of glue, of course, but the colour makes it suspicious enough that it’s probably worth just replacing them and seeing what happens.

I have all the supplies now, so I just need to find the time to have a crack at the repair. Although it might take me a while to get around to it; seeing as I now have a working SoundCanvas there’s not much urgency to it.

Speaking of that working SoundCanvas, I’ve been playing around with it and testing all my old MIDIs on it to see if they sound the same. If you’ve been following my socials, you’ve probably already seen me posting about this. I’ll probably be uploading a few more renders of my old MIDIs with a camera pointed at the LCD panel in the coming weeks.

There are some subtle differences, of course, but it’s hard to say whether they’re caused by poor emulation by Sound Canvas VA, or by me forgetting or otherwise failing to export some of the automation correctly to the MIDI files.

It’s also made me realise - because I’m now using just the one external synth instead of a VST that resets every time I load a new project - that I completely forgot to add reset messages to the beginning of all my MIDIs. So that’s something I’ll have to keep an eye on in the future.

I’ve also been setting up REAPER on my Fedora Linux install, and faffing about with the audio drivers to get it actually working. Long story short, as of today I can now properly make music on my daily driver operating system. This means I’ll be getting back into making music again, although I imagine I’m a bit rusty (Was I ever not rusy?)

But watch this space anyway!

In the meantime I’ve also been doing some game dev stuff, which you might have seen on my GitHub, but I think that’s best saved for another blog post.

Until next time!

(NB: I’ll by uploading source materials for the single releases onto their pages at https://speedyvelcro.com/music - CC BY 4.0 of course - if you want to reproduce any of this).

So basically the story starts with trying to put together a generic video splash screen for my music videos that are part but of some larger album. I wanted to keep it simple - none of this after effects malarkey - so I decided the splash screen would be created in GIMP and kdenlive would be used only for attaching the audio (tbf I could probably save even more time by just going straight to ffmpeg for this, which I might do in future).

I also have a fresh new 4K monitor, which I know is a bit overkill for displaying this kind of content, but still I wanted something that would look nice and crisp and clean.

So after a bit of faffing about with the align tool I created this lovely image:

I’ve always liked the look of a vignette over a solid colour background. It’s minimalistic and aesthetically pleasing in a way that tickles my brain. But this is where the problems start, because what sounds like a simple setup is actually a massive pain-in-the-ass to get right.

First problem is the banding. This happens because the colour space of the image doesn’t have enough shades of grey to show a smooth transition, but it can be fixed by just applying a spread blur to the vignette layer:

Much better. Not perfect - you can still kind of see it if you stand far enough away from the image - but I felt like it was good enough for the time being (and by the time I’d noticed this I’d already rendered out all my backgrounds and couldn’t be bothered to go back and redo it).

So that’s it solved, right? Well not so my friend.

When I uploaded the final video to YouTube the result was horrendous:

This is pretty much where the story ends unfortunately because everything I tried didn’t work, including all the tips to reduce banding that people suggest for YouTube uploads such as:

• Adding a subtle noise to the entire video (idea being it tricks YouTube to compress static areas less because it think there is motion)
• Rendering in ProRes format
• Actually that’s all I can remember right now but I’m pretty sure there are more things I tried

It might be that this YouTube wisdom is more applicable to live-action video. I think I have to accept that a smooth gradient or vignette over a solid background just isn’t possible with YouTube’s compression. So in the end I just got rid of the vignette.

You can download the template here (it also includes the vignette as an invisible layer). Licensed under CC BY 4.0 of course.

To be honest the no-vignette look has actually grown on me. And without the banding, that actually gets my the “crisp and clean” look I was going for in a way that survives YouTube compression.

As an aside, while I was doing this I found a neat trick that saves time uploading your videos if they’re just a static images: render your video at 1fps.

So that was disappointing. Not really any usable finding here, other than the moral of the story being “don’t bother”. But hopefully this article saves someone else several wasted hours of trying to upload a gradient to YouTube.

Anyway, this is a long-ass blog post for such a rudimentary issue, but the point is more to flex my blogging muscles and get into the habit of documenting my processes. I’ll likely have more interesting stuff upcoming. In particular, look out for upcoming blog posts on my MIDI setup and on music composition in general.

By the way, this blog is RSS-enabled. You can access the RSS feed here. (Well, technically it’s an atom feed, but that’s more or less the same thing.) Or if that sounds too complicated for you, there’s always my social media accounts. But I any time I make a post it’s guaranteed to show up on the RSS feed, so that’s really the best way.