SD Cards and the SP-404mkII

SD cards and samplers go together like chips and salsa. But the SP-404mkII handles card I/O a little differently from other hardware — and is sometimes quirky when it comes to card requirements. Let’s break down SD cards and the 404…

What card types are supported?

First thing’s first: use an SDHC card. These cards sport the SDHC logo and range in capacities from 2Gb to 32Gb.

This is the only card type supported by 404mkII running firmware versions previous to v3.0 — and even in a post-3.0 world, it’s still the only card type read by the 404’s bootloader.

That means, to install any new firmware update (regardless of version), we must use an SDHC card — SD and SDXC will not be recognized. So we can save ourselves some hassle by just using SDHC cards. Plus, they’re cheaper and 32Gb goes further than we might think for reasons I expand upon below.

But also, yes. As hinted above, with the arrival of firmware v3.0 Roland added support for reading SDXC cards of up to 1Tb in size. These are… fine? I guess? 64Gb SDXC cards seem to be pretty popular in other samplers, so if we have a bunch laying around or something, they’ll work as long as we’re on the latest firmware. We just need to remember to keep an SDHC card around for actually updating said firmware.

What does the 404 (not) use cards for?

The thing is, the 404mkII doesn’t actually use the SD card for nearly as much as we might think.

As mentioned above, an SD card is the (one and only!) method for installing new firmware.

It’s also the destination for any samples we export, and projects we back up. And it’s where we load projects we’ve previously backed up or are transferring from other devices.

But most often, it’s our main source of samples. These are stored on the card as wavs and imported into the 404 to be assigned to pads. Because we do this so often, the card can kind of become synonymous with our sample library, and this has lead to some misunderstandings. Like that wavs are streamed from the card. Or loaded from the card into the project when it’s opened. Or when the 404 is turned on. Or when we switch projects. Or…

None of these are the case. With respect to wavs, the 404mkII reads from the SD card exactly once: when we import a sample to a pad. At that point, the wav is copied entirely into internal memory and the card is never touched again. We can test this pretty easily by filling up a handful of projects with samples from a card, throwing the card away, then observing how the 404 behaves completely normally when we turn it on, off, switch projects, &c.

As such, the requirements on the SD card are pretty meager.

Do I need the fastest card?

Probably not.

Speed doesn’t really enter into anything the 404 does with cards. It doesn’t stream anything from the card, so you don’t have to meet any minimum threshold of performance to avoid dropouts, or anything like that.

Speeding up transfer times might be nice, but unless you routinely backup huge projects, most of your time will be spent importing samples. And as we’ve gone over, that happens exactly once. After that, it’s read from the 404’s super fast internal RAM.

If you have a particularly large card, building lists of files to browse can feel a little pokey. But the solution there is not really a faster card, but rather a smaller one. Speaking of which…

Do I need the largest card?

Probably not.

There are only two things that take up big space on 404 cards: sample libraries and project backups.

For sample libraries, if our curated collection of wavs is large enough 32Gb starts to look like table stakes from our card, it’s going to be a nightmare to browse through. Both in terms of indexing, but also just, like, the overwhelming length of the lists we’ll need to scroll through on the 404’s tiny screen.

One thing we could do to address this, of course, is to use our computer as our sample manager, wire up the 404 via USB, and transfer samples directly via the 404mkII App.

But if we want to stay OTB, remember the 404 isn’t looking at the card for any samples already imported into our project. So while browsing for a new sample to import, we can use whatever card we like. What if we split our gargantuan library across a number of smaller cards? Like, one for one shots and one for loops? Or one for techno-adjacent samples and one for jungle? Each individual card will be cheaper, faster, and better organized to boot!

As far as projects go, if we’re being super industrious and maxing out each pad’s 185Mb-worth of storage, it’s possible our project could be in the ~30Gb range. Most projects are much smaller, of course, but can still grow to be a Gb or two. So we need a huge card with room for our samples and backups, right?

But again, maybe just have a card dedicated to backing up projects? The 404 is basically never reading or writing to the card, so you can swap them in and out quite easily. And by having a dedicated backup card, you’re minimizing reads and writes to it (which can improve its longevity) and giving yourself a thing you can store safely, separate from the samples you carry around with you all the time. All positives things for backups.