In 1969 a soul band called The Winstons released "Amen, Brother". In the middle, their drummer, Gregory Coleman, played a few bars on his own. Producers lifted those bars from the record, and the "Amen break" went on to drive hip hop, then jungle and drum and bass, chopped and sped up on thousands of tracks. According to Winstons member Richard Spencer, the band never received royalties for any of it.
Try making a sample the way those producers did. Below is a drum break. Trim it down to one bar you'd want to play from a pad.
Move Start and End until you have one clean bar that loops. Then ask: whose playing is this?
Cut one bar
Drag the S and E handles, or focus one and use the arrow keys. The original take is never changed.
It takes a minute, and the bar you have is still someone else's playing. You may be allowed to put it in your track. Are you allowed to sell it, inside an instrument, to other people who'll put it in theirs?
That question sits under every sample-based instrument ever made. Every key on a Mellotron plays a strip of tape with a real musician on it: the flutes at the start of "Strawberry Fields Forever", the strings on "Nights in White Satin". When you play one, you're playing someone's recording. When you sell one, you're handing that recording to everyone who buys it.
Two permissions: play it, or ship it
Permission to make music with a sound and permission to hand that sound to other people are different permissions.
Most sample packs give you the first. You can use the sounds in your songs, release those songs and earn from them. Far fewer give you the second: putting the original sounds, or lightly changed versions of them, inside a product that other people download and play.
One recording, two permissions
Pianobook, a community that shares free sampled instruments, draws this line plainly in its FAQ: you can use its packs in your compositions, but you can't sell or redistribute libraries whose copyright you don't own. It also notes that it can't guarantee the rights of every uploader. That's one publisher's arrangement, not a rule for every pack, which is exactly why you read the terms of each source you use.
If you're sampling from a record, there's a second layer. A released song usually carries two sets of rights: one in the composition (the melody and words) and one in the recording itself. The Amen break is a recording question: the drumming on that record.
This guide covers general principles, not advice for your situation. When a permission is unclear, ask the rights holder, or a lawyer who works in music, before you ship.
Free isn't the same as yours to ship
"I downloaded it for free" tells you the price, not the permission. Free sounds come with all kinds of terms, and two that look alike can differ a lot.
Take Creative Commons. "CC" is a family of licences, not one licence. The CC BY-NC 4.0 summary asks you to credit the creator, limits use to non-commercial purposes, and points to the full legal text for the details. A paid instrument containing BY-NC sounds would run straight into that non-commercial condition. So write down the exact licence and version, not "Creative Commons".
Two more things that are easy to mix up:
- A credit isn't permission. Naming the creator doesn't make a use allowed. Sometimes the permission requires a credit, and then the credit has to travel with the product.
- One download can hold several licences. A project might put its code, its recordings, its trained model and its artwork under different terms. Give each its own line.
Keep a source ledger
A source ledger is a list with one row for everything in your instrument that you didn't make from scratch: every recording, code library, model and image. It's the most boring page in your project and the one you'll be most glad of later.
For each row, note where it came from, which exact version you have, what you want to do with it, and what permission you have for that. Keep a copy of the terms you read, because pages change. Anything you can't answer yet is unresolved, with the next step written beside it: "Ask the uploader whether the samples can ship inside a paid instrument" is far more useful than a tick beside a licence name you haven't read.
For each thing in your instrument you didn't make yourself: where did it come from, what will you do with it, and what lets you?
Source ledger
0 of 4 done · saved in this browser
Add your own work too. "Recorded by me in my flat" is a row. If a session player, photographer or co-writer contributed, their row points to what you agreed. A file checksum can pin down exactly which file you used, which is handy when versions multiply, but it says nothing about whether you're allowed to use it.
Credits travel with the sound
Put credits next to the sounds they describe, not only on a launch page. If the credit lives only on your website, someone who moves or re-shares the instrument loses it. If it's copied onto five pages, an update fixes one and leaves four wrong.
In Maru's Sampler, each bank carries its credits alongside its recordings, so exporting the bank takes them along. Whatever tools you use, aim for the same shape: the instrument file knows where its own sounds came from. Before you ship, open the exported credits and check they describe what's actually inside, including anything you changed.
And trace each source separately. Two sounds from the same big collection can have different origins and different terms, so don't copy one licence onto its neighbour.
Agree before you describe
Collaboration is where good projects get awkward later. Before you write about a collaborator in public, agree in writing:
- who contributed what, and how each person is credited
- whether their name or image appears in the launch
- which demos they've approved
- any money arrangement
Keep contribution and endorsement apart. Someone who recorded a source may never have played the finished instrument. Someone who tested a prototype may not want to appear in your launch video. An exact, agreed credit is worth more than an exciting story your collaborator doesn't recognise.
A voice raises the stakes. Once a model has learned a singer's recordings, anyone can perform in that voice, so recording a source turns into lending an identity. Voices, cloning and consent covers the extra permissions and labels a voice model needs.
Maintenance: a promise that the song will reopen
Picture this: a player opens a track from two years ago. The bass comes from your instrument. Since then you've released an update that changed the filter's range, so the same saved setting now sounds darker, and the track is quietly different. Nobody's song should change because you shipped an update.
Mellotron owners know a version of this: tapes stretch, mechanics drift, and the instruments needed regular upkeep to keep sounding like themselves. Software doesn't wear out the same way, but the computers, music apps and operating systems around it change every year.
So write down what you promise:
- Which setups you support: the plug-in formats, the apps and the operating systems you've actually tested. "Works everywhere" can't be tested.
- What must still open after an update: saved songs, presets, every control's setting, and the sounds they point to. A saved setting that points to a missing sample isn't really saved.
- A short test you'll repeat for each release: open an old project, play the same phrase, compare by ear, save again, and see what happens when a file is missing.
- How people tell you about problems: ask for the version, the app they use and the steps to reproduce it. A two-bar example is enough; you shouldn't need their whole private song.
If an update has to change what a setting means, decide on purpose whether old projects are converted, kept as they were or flagged, and test that choice before you release it. A version number doesn't do it for you.
Where it breaks
The ledger stops at launch. You add a new bank in an update and skip the row. Treat every new sound as a new row, before it ships.
The credit outlives the permission. A source changes its terms, or a collaborator asks to be removed. Your ledger tells you which instruments and pages that touches.
The test only covers your machine. It opens perfectly where you made it, then fails on another system with a different folder layout. Test each setup you promise, not the one you happen to own.
Make it yours
Choose one sound in your instrument and give it a full row in the ledger above: where it came from, the exact version, what you want to do with it, and the permission you have. Then do the rest, one row at a time, and don't ship anything still marked Unresolved. Finish with a one-page update plan: the setups you support, what must reopen, your repeatable test, and how players reach you.
To see what a finished set of credits looks like, open Sampler, load any bank and read where its recordings came from.
Quick check
-
A sample pack says "royalty-free for use in your music". Can you put its samples inside a paid instrument? Not on that wording alone. "Use in your music" covers making tracks with the sounds; putting them inside an instrument hands the sounds themselves to other people. Look for terms that cover redistribution, or ask the publisher. It's tempting to read "royalty-free" as "free to do anything with", but it only says you won't pay per use.
-
You credit the creator of every sound on your launch page. Are you covered? A credit isn't permission. If the licence allows your use and asks for a credit, the credit is part of meeting it. If the licence doesn't allow your use, a credit won't fix that.
-
An update makes your filter sound better but changes its range. What happens to a player's song from last year? It reopens with the same saved number meaning a different sound, so the song changes. Before release, decide how old projects are handled (converted so they sound the same, or kept on the old behaviour) and test it with a real saved project.
Next steps
- Go deeper: Presets, state and automation. Your update plan names what must survive. How do you test those promises in code?
- Use it: Shipping a sample library. Carry recordings, mappings and credits into a package someone else can open.
- Sideways: Planning and recording samples. The simplest ledger row is "recorded by me". Here's how to make recordings worth playing.
