Hi everyone! I'm Max, and this is my first Ludum Dare. Following the advice of the pinned post, I'm introducing myself with a blog post.

My friend Ashley and I are making a game where you catch packages with a baseball glove and throw them back at delivery drones. Hopefully we'll be able to finish - we're Feature Complete but not Content Complete, and certainly not polished! Still, trying to stay relaxed & chill about it all - it's not like I'm in the compo, anyway :)

Despite our game being based pretty much entirely around music, all that music got thrown together at the very end in a bit of a rush, and we were worried that it wasn't actually, uh... any good. So imagine our shock when we logged on and saw this!

First of all, thank you; it's extremely flattering to us not only that we got first in audio, but that we didn't do too shabby anywhere else either! (Seriously, I consider anything sub-50 as a massive win)

That being said, I imagine our high audio score probably had something to do with the track mixing system, where you get to mix these tracks together on the fly. So as my way of saying thanks (and because I have nobody else to share this with), I wanted to talk a bit about it!

So what's the deal?

If you haven't played our game, it's a game where you mix together different songs in order to satisfy a bunch of alien ravers' beat requests. You load songs into a 'Left' and 'Right' mixer track, adjust their BPM to match, and then blast away!

Easier said than done though - what's happening under the hood is both more complex than you'd think and simpler than it looks.

The Mixer

The game heavily leverages Godot's built in Mixer and its related plugins to achieve everything we do in game. Here's what that looks like:

You might notice the 'Left Mix' and 'Right Mix' channels, and that's exactly what they are - the dedicated mixer track for the Left and Right songs respectively.

We wanted to mimic actually DJ'ing two songs together, and thus creating the BPM adjustment system was a must. Every song has a target BPM that's stored in their song file. In order to get a successful mix, the current BPM of the song on the right needs to match the target BPM of the song on the left.

We chose to do it this way for simplification - managing the BPM of two different songs seemed like more than people could handle, so we just made it to where the left track controls the target and you can only adjust the right track. Given that the most common point of feedback was that the game was too complex as-is, I think this was a good call.

Under the hood, the game stores a 'Current BPM' value for the right track, that the player themselves controls with the scroll wheel. We use this value to calculate what the playback rate should be for the right song based on its default BPM, and then we feed an inverse value into the Pitch Shift on its respective Mixer, in order to keep it at the same pitch no matter how fast or slow it's playing. If the 'Current BPM' of the right track matches the 'Target BPM' of the left track, we snap the two songs to the closest common measure so that they line up.

Here's the absolutely incomprehensible code for applying the current BPM to the right track's Mixer. Can you count all the bodges???

Syncing the Tracks

Wait, you said something about 'snapping the songs to the closest common measure'? That's you talking, by the way.

Yes, just lining up the BPM's isn't enough - we also need to make sure that those beats are hitting at the same time! For this, we used Nhlaha's Godot-Midi library which I'm just now realizing I forgot to link to on the game page whoops hold on fixing that.

Anyway, underneath all the songs is this MIDI click track.

It contains a MIDI note for every individual beat in a song, plus an ascending sequence from C0 - G2. The MIDI is tracked alongside each song's playback, and we read data from the MIDI notes in order to control in-game effects to the beat, like the lights pulsing on the gun or the agent's head bobbing in the HUD.

The ascending sequence, however, keeps track of which measure a song is on - every song has exactly 32 measures, and every time a note on this sequence is passed, we store it to denote which measure the song is currently on.

When two songs have matching BPM, we read which measure the left track is on, then snap the right track to that measure as well so that they both play in sync.

'But wait, why don't you just set the playback position of the right track to the playback position of the left track and skip all this MIDI nonsense?'. That's you again, by the way. And you're right - we totally could have done that.

This system was built when the songs were all being exported from the DAW at different BPM's to further mimic real mixing, and just setting the playback position directly wouldn't have synced them up. Furthermore, we originally wanted both tracks to just snap back to their previously played measure, and not necessarily snap to the same measure - lining the beats up, but offsetting where the songs were playing so that the process of mixing would sound more natural.

Turns out, BOTH OF THESE SOUNDED BAD! So we changed them. All the songs get exported at 150 BPM and retimed in-game, and all the songs will snap to the same measure as each other when their BPM's line up. So, technically, this entire system is unnecessary and overengineered for what we actually ended up going with. There's a version of this game where we didn't use Godot-Midi at all, and that actually would have allowed us to create a web build as well as Godot-Midi is a DLL, but ultimately we were still relying on the MIDI track for in-game effects and ripping and re-doing all of this on submission day would have probably been a terminally unwise move. So it remained.

The Songs

For 90% of development all of the songs were just a square wave that pulsed in an ascending tone on every beat and it slowly drove us insane. Obviously, this would be the worst DJ set of all time, so at some point we actually had to make music.

To give the best possible results, all of the songs were composed within the same file, were all actively compared against each other as they were being made, are all in the key of C Major, and all have exactly 32 measures. Yes, I know this is not how real DJ'ing works - but we were crunched for time and I didn't wanna risk anything sounding super bad.

I created all the melodies, basslines, etc myself - and then Maeve went back through and created all the drum tracks (which she did a killer job on, by the way!) in a different project file. Then, in-game, these tracks all got loaded into a unified song file, along with some other important info:

In order to not flood the player with competing drum beats, which drum beat is playing is entirely controlled by the Left track - the right track's drums simply get muted.

As mentioned before, every song was supposed to be exported at its 'Target' BPM - which they're named after in the files. So we were exporting one song at 125, another song at 150, another at 170, etc. However, when we got it in game, everything sounded... off, somehow. In a way we couldn't quite put our finger on. The BPM's and notes matched up, everything worked correctly, but it just sounded like they were somehow out of sync. At this point we entered full hands on deck panic mode and put our heads together to figure out what was going on.

Turns out, exporting things at wildly different BPM's and then retiming them had a nasty effect that we weren't prepared for: the ADSR (Attack, Decay, Sustain, Release) of every synth I was using was getting squashed and stretched! This meant that songs exported at high BPM's and then slowed down would have their synths sound all wacky, often with their attack fading in just subtly off from everything else, making it sound like it was ever-so-slightly lagging behind the other track, even though it was technically in sync.

In order to fix this we, well, went with the stupid & simple option of simply exporting everything at 150 and manually re-timing it in game. This meant that it didn't really matter if the ADSR's got streched, as the other track's ADSR's were getting stretched in the exact same way, and it would still sound like things were lining up.

As for the ending track - that actually came together on submission morning 'cause I figured, what the hell, we're basically done and I have some time. It doesn't have anything fancy or dynamic going on - I just spliced some drum beats from elsewhere and re-incorporated all the synths I was using in the other tracks to make it. Took about 30 minutes all in all.

At some point, I may mix all these tracks together properly and post them on my soundcloud. No promises though! You can find the soundtrack (or rather, the individual stems) in the download either way.

That's pretty much it!

If you read this far, thanks for reading my chickenscratch recount of how the audio works in this game, and more importantly, thank you for playing our game! Getting 1st in a category really means a lot to us, and we appreciate each and every person who played, rated, and commented to make that happen.

See you next time!