good breakcore/drum’n’bass/beats for your bandcamp friday lists

Leave a reply

It’s been a while since my last Bandcamp friday posts, so here’s some stuff I bought since then that is worth checking out, if you’re into the harder kind of electronic music.

ENRO by DJ Ride album cover

Some beats I’ve been enjoying are First Light from Sleepnet and Enro from DJ Ride. These are on Vision, which is run by the lads from Noisia, so you know it’s going to be high quality. These too are a bit more on the experimental side of the beats spectrum, which is what makes them beautiful.

Let’s increase the speed a bit and enter the land of drum’n’bass.

The Words Below Remastered album cover

The Words Below Remaster by DJ Hidden is a gem if you also like his previous album The Later After. I apparently missed this one in 2009, so I’m glad I spotted this remastered version.
It’s DJ Hidden, so don’t expect him to stick to the strict rules of the genre. He’ll venture out into an ambient landscape or some hardcore pounding now and then, but it’s a fantastic ride to listen to.
Good stuff from DJ Hidden, as always.

Ronin Audio 02 album cover

Also heavy on the drum’n’bass influence is Ronin’s second release on his own label, Ronin Audio 02. This is a lot more of a dancefloor oriented release, with 4 tracks ranging between hard drum’n’bass, darkstep and breakcore. I like the Obese remix, which jumps out as being slower beats track, still in the same dark vein. Obese is another moniker for Ronin’s more breaks oriented material.

Choose Death by Duran Duran Duran album cover

Here’s another interesting one. Choose Death from Duran Duran Duran. This breakcore album is so heavy on the jungle influences, I’d almost call this a jungle album. There’s an FFF remix on it too, so that certainly takes it into nu-jungle territory (if that’s even a genre). There’s also a Ronin remix on there, you know, the one from the album above. I’m not sure about that album cover though. A hotdog?

Glamerous Cool Kids Stuff by Detest album cover

Now we’re getting closer to the hard & heavy stuff, Detest has the Glamerous Cool Kids Stuff LP out on PRSPCT, which is filled with that hardcore banging beats we know him for. On this album he’s showing off his skills and influences (check out Oldschool Trash) by creating a varied set of bangers. Movie Junkie XXL bring a more beat-like oldskool electro-ish vibe in the middle of the album, before getting back to the hardcore industrial style Sleep Knowledge.

Strange Arrival, Anticitizen album cover

Now we’re talking industrial style music anyway, we can’t overlook Strange Arrival’s recent Anticitizen EP on PRSPCT. Eerie soundscapes combined with banging beats is what Strange Arrival stands for. If you like his style, also check out his earlier releases. Borderworlds on Love Hz has a more sci-fi feel to it. Plastic Death on Heresy takes an environmental view on the plastic in the ocean, and finally there’s plain industrial crossbreed darkness on the Imposter Syndrome EP on Genosha recordings.

MERS, Mechanical Paradox album cover

To top it off, here’s some advanced beat-trickery I can only categorize as breakcore-fuck-yeah. Mechanical Paradox is an older release, but a beauty, by M.E.R.S. If I have to name some influences, I’d say Ruby My Dear for the melodies and Squarepusher for the beat mangling. Now we’re talking Ruby My Dear anyway, I missed his Phlegm release from 2019, apparently. It’s filled with more electronic sounding, atmospheric kind of breakcore goodness in his typical style. Love it.
Somewhat in the same vein as the releases above, is the Morphic EP from Anorak on Greymeta. Analog synth sounds and advance, fast-paced beat fuckery is what you can expect here.

darkstep 022 remix compilation

Leave a reply

This was a fun one. A remix compo on darkstep.org I joined a while ago, and got a drum’n’bass/crossbreed kinda track selected on called “Fist Fight”.

There’s more track on it by other artists, ranging from jungle, drum’n’bass to speedcore, breakcore and whatever is in between.

You can still send in your own remix if you like, it’s still open. Download the sample pack and get tracking!

.net core: could not load file or assembly runtime error

Leave a reply

Shortly after posting about my tips to fix broken builds, I was in for another bug hunt that took a few hours to resolve. This time it wasn’t the build itself that failed, but the package that came out of it. For some reason, the application crashed instantly on a missing DLL error you know and hate in .NET.
Usually it means a Nuget package conflict. Cleaning the build sometimes helps, but not in this case. We are talking about system DLL’s here, so you know you’re in trouble when that happens.

I was getting the following exception at runtime on a .NET Core app. It wasn’t always the same DLL. But every time it was a system DLL like System.Collections, System.Collection.Generic, System.Linq, etc.

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Collections, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Collections, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.Extensions.DependencyInjection.ServiceCollection..ctor()

When checking the package files, the wrong version of the DLL was in the output, compared to the version number I was seeing in the solution, so the error message was correct. The problem was, why does the build pick the wrong DLL version? My local build output was fine however, so that just adds to the mystery.

The special bit about this project is that it also used a .NET Framework DLL. It was doing some .NET Standard magic in the build.

The symptoms

  • The project has a mix of .NET Core / .NET Standard / .NET Framework projects or Nuget packages.
  • You are building a self contained application (so all DLL’s are copied in the output folder).
  • Seemingly random 0x80131040 errors when I try to run my deployed .NET Core app on system DLL’s.
  • Different builds give errors on different DLL’s, but they are always system DLL’s.
  • A local dotnet publish works, but the output from the build server doesn’t run.

The fix

The fix turned out to be stupefyingly simple. I was build the .sln file for my project in the CI pipeline, instead of the .csproj file for the console application itself.
Apparently things go wrong at build time and the wrong DLL’s are copied into your output folder, giving you the exceptions above on startup.
The reason why the same dotnet publish command works locally is probably because I have version 5 of the dotnet tool on my local machine, due to Visual Studio. On the build server version 3.1 is installed, from the 3.1 SDK. My guess is that the 3.1 version handles mixed solutions differently than the dotnet 5 version.

tips on fixing a broken build

Leave a reply

When builds break on the build server, it can be hard to figure out what the problem is. I’ve been doing this a lot of times, and so here’s a collection of tips that can help you in fixing that weird error that keeps breaking the build. Build systems are pretty similar, so whether you’re using TeamCity, Azure Devops, Gitlab, Jenkins, Circle CI or whatever, these should pretty much work everywhere.

Make sure it builds locally.

This has to be the “Did you try turning it on and off again?” of build fixing. Sometimes that build really is broken. A file might not have been checked in, or a merge might have gone wrong, but what you have on your local machine, might not be what’s in source control.
Get a clean copy of your repo in a separate folder, and build that to check if it builds OK. At least you’ll be 100% sure it’s nothing trivial before you start your investigation.

Try a clean build.

Another “try turning it on and off again” tip, I guess. On most build servers, you can opt to run a clean build. This means the agent will set up a fresh checkout folder for the new build. This way you make sure no leftovers from a previous build are causing the problem. Sometimes things go wrong with source control and getting the latest version, messing with your build. This also fixes that issue.

Does it fail everywhere?

Sometimes build agents are not installed in exactly the same way, and builds might break on a single or a few build agents only. This is good. Now you know you can always get a build on a good agent, so you aren’t stuck when you want to produce some build artifacts, and you know there’s something on that machine that’s not quite right where it’s failing.
The error will usually give you a clue on what’s missing, but most of the time you’ll only understand why after you resolved the issue. Ah, the joys of software development.
My tip here is to compare the machines and see what build tools are missing or different from the one where it does work. Make sure your SDK and build tool versions are the same, and can be found. Check your shell versions, like PowerShell and if they are running in x32 or x64 mode, and if all PS modules are installed in the mode you’re using.
If you have an automated way to quickly produce a build agent, you might want to ditch the failing one, in favor of a brand new one if your build works there.

Check the logs.

It sounds trivial, but the log files of your build server contain a lot of details you’re not looking at when things are working. Now that things are broken, it’s time to dig in and see if you can find a few clues. Most build systems also have settings to change how detailed those logs are. Setting this to verbose can be what you need to find that final clue to solve the puzzle.

Get into the machine.

When things should work, but appear broken on the build server, you’ll sometimes have to dial into the build agent and see what things look like in there. Paths might not be what is expected, files might actually be missing, and tools might be different. There you can open a shell, check if anything is missing, check if build tools are available, or try and run the same command that’s failing yourself. This doesn’t always work as build systems sometimes wrap your SDK calls, and you’re not always sure you’re running the same statement, but it might give you a hint of what’s going wrong anyway.
Look around on the machine, and you might find the problem. Can’t access the machine? Try the next tip.

Get into the machine, without getting into the machine.

You might not be able to access the build agent itself. Pesky admins, or it might even be a cloud machine you don’t own. Luckily you can edit the build itself right? In most cases, you can run some arbitrary shell commands as a build step for whatever fancy stuff that isn’t covered by default.
Well, nothing is stopping you from running an ls or type nuget.config command to find out what is really happening during your build. The output of those commands will normally appear in your build logs. You might have to check the more detailed full log files, but it should be there. This can be a tedious process, but it saved my butt a few times when things didn’t work for an at the time unknown reason.