Shipping a sample library

Imagine someone has just downloaded your instrument. They've never heard it, never seen your session, and they'll decide in about thirty seconds whether to keep it. Be that person for a moment: play the instrument below as if you'd just opened it.

You probably played a few notes in the middle, tried a chord, then went looking for the top and bottom. Did you find out it has a soft and a hard layer? That it's built from just two recordings? Probably not, unless something on the page told you to look.

That's the problem with shipping your own instrument. You know which keys sound best, which touch avoids the seam, which preset to start with. A new player knows none of it. Shipping isn't saving your project. It's making the first minute work for someone who only has the file.

Choose the first sound on purpose

The preset an instrument opens with is an invitation. It should sit in the instrument's best range, at a comfortable level, showing off whatever makes your recordings special.

Name it for what it sounds like: "Soft mallet, short tail" tells a player more than "Preset 03". A playful name is fine if a short description says how to play it.

Don't lean on effects to make the basic sound work. If the first preset only sounds good through a big reverb, either build that into the instrument or say so; a bank doesn't automatically carry the effects you had around it in your project.

Check the first sound at a quiet level and a loud one, and hit the hardest velocity at least once. A gentle middle C won't reveal a harsh top layer three octaves up.

Write the first three actions

Before you export anything, write down the three things you'd want a new player to do. Then you can test whether the instrument makes them easy.

Then turn the best of them into one line of instruction for the player: "Start in the middle octave; play soft and hard to hear two different recordings." If there are keyswitches, say which keys do what and which articulation plays first. If part of the keyboard is empty on purpose, say where the instrument lives. Keep the full technical map for a reference section; lead with what a player can hear.

Keep a source ledger

For every recording in the bank, write down where it came from, who made it, what lets you share it, and what you changed. Do it while you build, not the night before release.

Source	Who made it	Permission or licence	What you changed
Your own mallet notes	You, session date	Your own recording	Trimmed, tuned, two takes
A friend's cello notes	Their name	Their written OK to share	Looped, shortened
A downloaded drum hit	Creator and link	The exact licence it came with	Downmixed to mono

Two things trip people up. First, editing a recording doesn't make it yours: trim it, pitch it, loop it, and the original licence still applies. Second, a licence to use samples in your music isn't always a licence to pass the samples on in a library. Read the actual terms.

Know what the common licences ask

• CC BY 4.0 lets anyone share and adapt the material, commercially too, as long as they credit the creator, link the licence and say what was changed, without implying the creator endorses them.
• CC BY 3.0 is similar, with its own wording. Keep the credit exactly as the source supplied it; the versions aren't interchangeable.
• CC0 gives the material away as completely as the law allows. Credit isn't required, but keeping the source in your ledger still helps anyone who asks where it came from.

If your bank mixes sources, it carries all of their conditions. A bank with one CC BY recording isn't CC0 because the rest is.

Export the whole instrument

A playable bank is more than a folder of WAV files. It's the samples, the map of which sample plays where, the presets, any artwork, and the credits.

In Maru Studio you can export a Sampler bank as a ZIP or MAS file, and it can write a CREDITS.md from the source details you entered. It writes what you told it, so read it: a missing creator in your metadata is a missing creator in the credits.

Open a fresh copy

Here's the test that catches most problems: import your exported bank into a brand-new, empty project and check it from scratch. Your working project hides things (a sample still loaded from last week, a setting you never saved). A fresh copy doesn't.

Watch the import report closely. If something was skipped or changed, it'll say so; "import complete" doesn't mean every behaviour survived. Importing into hosted Studio also copies the samples into that project, so treat it as uploading, not just a local test.

Promise only what you tested

An instrument that plays perfectly in one place may lose features somewhere else: keyswitches, velocity crossfades or release sounds aren't supported everywhere. Say where you tested it and what it needs. If it relies on something a player's setup might not have, simplify it or say so plainly.

Watch someone else's first minute

If you can, hand the fresh copy to a friend with your three-line instructions and watch. Don't explain. Where do they hesitate? Do they find the soft and hard layers? Do they stumble on an empty octave?

Write down what happened, and keep preferences separate from problems. "Too bright for my song" is taste. "Nothing plays above C5" is a bug.

Same idea, different place: familiarity fools your ears the way loudness does. A fresh listener is the "hide the label" test applied to your own instrument. See Listening and comparing.

Make it yours

Gather a small bank you've built, even if it's just one octave. Fill in the ledger:

Then export, open a fresh copy, run the steps above and follow your own three actions. Keep the exported bank, the ledger, the credits and a one-line note ("all recordings present; starts on Soft mallet; tested C2 to C6") together. That bundle is your release: someone else can play it, and you can rebuild it when it's time for version two.

Quick check

1. You pitched, reversed and heavily filtered a CC BY recording. Do you still need to credit it? Yes. Processing doesn't remove the licence. Credit the creator, link the licence and say what you changed.
2. The bank sounds perfect in your project, but a friend says two keys are silent. What test would have caught it? Importing the export into a fresh, empty project and playing every key. Your project still had something loaded that the export didn't include.
3. Studio wrote a tidy CREDITS.md. Does that mean the bank is cleared to share? No. It lists what you entered. Check each source against its real licence or permission before you publish.

Next steps

• Explore the chapter: Designing and publishing. Plan the demos, story and ongoing maintenance around the library.
• Go deeper: Composing with a sampled library. Your library works. Now write music that shows off what it can do.
• Use it: Rights and maintenance. What to plan for after the first release.