Hello! I am getting deeper into the Organelle samplers — there are so many cool and fun ones. I just want to make sure I understand the process of saving and organizing my own samples.
It sounds like if I wanted to have, say, a few different samples I use with the arpeggiator sampler (just an example), I’d “save new” with each new sample, so I’d essentially have three copies of the arpeggiator sampler patch, one containing each of my samples.
Questions about this are:
Is there a good way anyone’s found of organizing these many copies of the same patch? Do you store the non-factory copies on a USB, or create sub-folders? Just looking for ideas, as I could see myself quickly getting overwhelmed and lost in a sea of sample patches.
Does saving new patches quickly eat up all the Organelle’s memory? It seems like saving entire new copies of patches, and not just the sample itself, could be a memory suck. But maybe the patches aren’t actually that memory-intensive?
As much as I love many of the patches available for the Organelle, I rarely end up adding my own samples to them exactly because of this limitation.
I’ve considered writing some sort of sample manager patch based on Rust that would let me move samples in and out of folders but the lack of a filename standard would make things a bit tricky.
One possible solution is to make copies of the patches and load each copy with a different sample selection but I don’t think it’s a scalable solution exactly because that list could end up getting way too long.
In terms of memory it shouldn’t be an issue since only one patch is loaded at the time, you’d only be consuming the storage on the SD.
Some patches do use shared kits and that’s already very helpful but I’d love to see either more patches that support that or some sort of sample management / selection on the device itself.
That’s a possibility - but the Organelle will default to using the USB drive if one is connected. You will have to eject the USB drive if you want to load patches from / saving patches to the SD card. The Organelle doesn’t care if you’re using the SD card or USB drive for patch storage - it’s just about how you want to manage the patches…
@icaroferre is correct - the Organelle only loads one patch at time so creating a copy of a patch will not eat up extra memory (RAM).
This is a good idea in theory, but it is not so simple unfortunately. @moosiqpipl has some good points here:
…and there’s also the functional difference of a patch loading samples into RAM vs. a patch that plays samples from the disk. Those patches that are using RAM are likely to use shorter samples so as not to use up RAM. Those patches that can stream samples from disk can use much longer samples. Any sample manager would have to know how to handle this difference so the patches would load correctly.
TLDR: Keeping the patches and their samples self-contained ensures that the patches work as designed.
The ‘stock’ Organelle M ships with a storage partition that is ~3.5GB. Once unzipped, most patches are probably less than 2MB so that’s about 1750 patches worth of storage. (Your mileage will vary if you’re duplicating patches that record or use large files…)
Yeah I did have in mind that any change to how samples are storage would mess up existing patches (tho I had not consider that RAM x disk streaming different).
It makes sense that you guys wouldn’t want to break a bunch of existing patches since the Organelle is great exactly because of the existing library.
Maybe an option would be to consider implementing a standard in the next OS version so new patches and updates could follow it and adopt that shared folder going forward without breaking compatibility for existing patches. It’d be more of a suggestion and a standard rather than forcing every existing patch to follow it.
This could end up confusing some people since some patches would work with the shared folder and others wouldn’t but I don’t think it’s much different from where we currently are.
Another idea would be to basically make a file browser / selector that would just copy files to a patch’s folder and replace the files using the name of the existing samples.
Not super elegant but could be a workaround.
@chrisk what would you guys consider the proper way of doing this as it is today? Would the ideal solution for now be to create a master folder for the patch and make copies within that master folder using different samples?
What has been putting me off of doing that is that, if a patch gets updated, I’d need to update every copy
Oh, that’s super helpful. Thank you! I really wasn’t sure how much of the SD card memory I was using storage I was using up. (If there’s a way to check on the device itself, I haven’t found it?)
