Samples are global and no they don’t back up with the project. They’re project agnostic. Whatever is in those 64 slots at any time will be played by all projects.
Numerize the samples on the ST (via Elektron Transfer):
01-
02-
03-
.
.
.
64-
and then, when you backup all the samples, they’ll slot in right where they were. Otherwise, you have to reassign everything from scratch, if the order is scrambled.
Thank you both - this is a little more involved on the backend than I expected.
And just so I get it -
I have to backup both the project AND the samples. Before I back up the samples, they need to be renamed so that they read 1, 2, 3…64 so that when I import the project and samples back into the ST, the samples drop into their original slots.
Got it!
Thanks y’all!
Curious. Is all this in the manual?
As a side note/request - it’d be nice if the ST could tell us which samples were being used in a project. That way I don’t have to replace them all when I want to load new samples. I could just replace the slots that aren’t being used.
The things is that when you drop a load of files into Transfer you don’t know the exact order they’ll be uploaded. They can get mixed up, it depends on your OS.
The file numbers let you see the ones that aren’t in the correct slots.
I have devised a strategy where I only “recycle” the first 32 sample slots, the last 32 slots are reserved for “global” samples and will never be changed once “finalized”. This allows you to have at least some bread and butter sounds (like 909 OH) always, regardless of project and the samples it uses.
Feel free to devise a sample allocation strategy that suits your workflow best! recycling all 64 samples for every project might not be the best idea, IMO…
I was excited about the ability to add samples and just went for all 64 slots. Made some jams and now want to move on and found myself in this situation.
But yea, a few “go-to-all-the-time” samples and a few flexible slots seems like the ticket.