First post. Longtime lurker. Previous owner of Rytm. Current owner of Analog Heat and brand new to owning the M:S.
I’ve followed the manual’s instructions (Section 13 - Start-Up Menu) to enter the Start-Up Menu by holding [Func] while powering up… Then ‘To reformat the +Drive and make a factory reset, press [PATTERN] + [TRACK] + [TRIG 3].’
This appears to work and I get a little bubbly animation while it resets.
However, even after that, it still tells me I only have 87% of my sample storage left, despite me not having loaded anything on there.
… Is it possible to clear this to 100%, or is 13% taken up by system storage?
I read that the Factory Library is locked and cannot be deleted, but that 1 GB of storage still remains for the user library.
Maybe the 87% does equal 1 GB and I’m just wrongly assuming that 100% = 1 GB?
… Just concerned as I bought it used, so I’m fearing the unit might have a problem.
What’s the situation with other people’s M:S? can you get to 100% clear or does it also max out at 87% for you?
The M:S doesn’t display the space left on the +Drive. That percentage is the free RAM remaining in your Project (out of 64MB). This is a common and completely understandable misconception.
The only way to determine how much +Drive space is taken up by samples is to use Transfer to download them and calculate how much space the files take up on your computer.
Ahh, great stuff, that’s a big relief! I’ve been pulling my hair out here.
Thanks a lot for the clarification and the fast reply!
This is such great news… I’d initially assumed 13% was taken up by factory samples (though I’ve since read that was not the case) and was thinking I only had 870 MB to use. I’ve therefore been trying to limit my library I’ve prepped to be only that size… And now knowing I’ve got an extra 130 MB available is a huge boon as it gives me room to add stuff later.
ABSOLUTELY loving this machine so far. A real joy to use!
Hmmm, so, after a factory reset and +Drive wipe, I just tried to drop 896.9 MB of sample content onto the M:S.
All of that content was pre-prepped to mono 16 bit 48 kHz - so my expectation was that it would take up precisely 896.9 MB of the 1000 MB space.
However, it ran out of space before all the sample transfer could be completed. I’m now puzzled by this.
Non-transferred samples have the message ‘device failed with operation’ in their info field.
I am reasonably confident it’s an issue of space running out, as I can see the first file to fail was relatively large compared to the next few which got through, then another failed followed by a smaller one or two creeping through, then all following files failed.
Can anyone suggest possible reasons why I can’t fit 896.9 MB of mono 16 bit / 48 kHz files onto the 1 GB drive?
No, it doesn’t. This would only be true if the content is stored as a single extra large binary array of data.
To store multiple files a filesystem is required and filesystems don’t address single bytes of storage, but always use blocks of storage. Depending on the block size and the length of the file each one will waste an additional amount of bytes on the drive.
An example (not directly related M:S): if the blocksize is 1024 bytes and you want to store a file with 1025 bytes two complete blocks are used. So the 1024 bytes file will take up 2048 bytes on the drive.
Storing many (small) files increases the waste, because space may get wasted only in the very last used block of a file (more files -> more waste).
So when you compare how much space the samples take up on your computer drive this must not match how much space they will take up on the +drive (because of different block sizes).
Thanks for this answer, that’s a very clear explanation and I understand now!
Still a bit miffed about having much less storage than I expected. Que sera.
I’m just now getting back into music after a hiatus. I want to leave some space on the +Drive for me to grow into as I create and release new music - so I can perform any new songs I write live… I hope to avoid a situation where I need to be deleting things from my core M:S library and risk breaking projects. I guess ideally I’ll leave 10-15% of the space free, beyond the core library I’m starting out with.
Just eyeballing the Transfer software report, it looks like roughly 10% of my 897 MB failed to transfer.
Approximating… 897 MB x 0.9 = 807.3 MB maximum amount of usable data storage I’m achieving in the real world.
So if I want to leave 15% of that space free to grow into, then 807.3 MB x 0.85 = 686 MB maximum size for my core library… I’m going to round that up to 700 MB.
… That should leave me about 100 MB of storage available for future use.
So I’m going to need to cull my core library from 900 to 700 MB. Okay, doable. Just needs some extra discipline!
Are there any reports of any users swapping out Elekron +Drive storage for larger drives?
1 GB seems small in the current era, when I can buy a 500 GB SSD for £50… So am I correct in guessing the +Drive must be some ultra-high specification storage with an extremely low failure rate?.. I cannot find any specific details on the +Drive specifications, from a Google search.
… I know I should be appreciative… 1 GB is a heck of a lot compared to the 1.2 seconds of sampling time in an EMU SP12!
The +drive is just a chip on the PCB. AFAIK you won’t be able to replace it and I don’t think the board is designed to operate with larger chips (would need more address lines + changes to the firmware).
@tnussb His explanation is correct. I’ve wanted to write an article explaining this, but I’ve been waiting on the Elektron devs to get back to me to confirm my assumptions. They haven’t yet, so I’ve held off. But I’m 99% sure that this is the reason.
As he said, smaller files will increase the waste. I think the block size used on the +Drive is optimized for 2-3 MB files, which is the typical size for a one shot drum sample.
Here’s some examples from my sample library, compare my folder of one shots (which is mostly comprised of 2-3 MB files):
Note the ‘size on disk’, based on the block size chosen for that drive (which is a microSD card), the one shots take up about twice as much space as they should.
Now compare that my folder of single cycle waveforms, which are tiny files typically 1 - 3 Kb each (so about 1/1000th the size per file).
They take up far more space because of the inefficiency of the microSD card’s block size!
The problem is that we don’t know the block size of the +Drive on the Model:Samples, so we can just guess as to how much space these folders will take up. But in general, trust the ‘size on disk’ metric more than the ‘size’ metric.
That’s all really interesting.
Astonishing result with the single cycles!
Thanks for the further clarification.
To note though, in mono at 16 bit 48 kHz, I think the average sample size will be significantly smaller than the 2-3 MB files you mentioned in your post… I processed mine before transferring and a typical drum one-shot is now around 50kb, with longer ones (eg cymbals) at around 250kb.
I got my library down to around 720 MB before transferring and that all went on the MS. No idea how much space is left though. ¯_(ツ)_/¯
Well it’s not exactly smaller files that increase the waste, but how many of them are around. Each file may waste space in exactly one block: the last one. So in general it’s the amount of files and how well their sizes fit into multiples of the block size that determines the waste.
Nowadays block sizes are somewhere in the range of 8kB to 64kB. So even with just an 8kB block size single cycle waveforms with file sizes of 1 - 3 kB are very wasteful (but file sizes of, for example, 801 - 803 kB would be equally wasteful per file).
@tnussb
You are right of course. Thanks for the clarification. I’m assuming that the +Drive is NAND flash with something like 8kB block size, but I was hoping the Elektron devs would just tell us directly.
@Simonator Good point. I’ve been keeping my samples in their original format, which could be mono or stereo at whatever sample rate and bit depth, and letting the Elektron Transfer app convert the samples for me. I figure that at some point in the future I may have a sampler that can play stereo files, so I might as well keep them. But if you transfer a folder to the M:S, then transfer that folder back onto your computer, the resulting folder should all be mono, 48 kHz, 16 bit. So measuring the size of that folder should be fairly accurate. The tricky part is that ‘size on disk’ metric, since that’s really the key here, and we have no way of knowing if your computer’s drive has the same block size as the M:S +Drive. There’s a good chance that they are different, which renders the ‘size on disk’ inaccurate, or at least an inaccurate guide to how much free space you should have on your M:S.
To not over complicate things too much, I’ve just been aiming for a bit over 900 MB as the total size of all the samples I load on the M:S. And I’ve been a bit more picky about the single cycles that I load on there, since they paradoxically take up the most space! That’s generally been working. And around 900 MB is tens of thousands of samples, which, you know, is probably enough
That’s a really good point about my computer’s block size - I hadn’t considered that dynamic on this puzzle.
Personally, I’ve kept my original full-quality samples in original formats, but then also kept the 16/48 mono version in a parallel folder alongside them. Given the size of the latter, it doesn’t seem to wasteful on my computer’s drives.
After a lot of forum-reading and several false starts, I eventually found http://freshmeat.sourceforge.net/projects/audiomove to do my conversion… It’s GUI based (no coding in Terminal!) and works a charm. It has an option to split stereo channels and append them C1 (left) & C2 (right), while mono files are unchanged in that respect. You can then run a search in the folder and delete all C2 files.
This worked for me and really helped me to maximise the usefulness of what was going to fit onto my +Drive.
As mentioned above, I initially tried to transfer a 900 MB library to my M:S and there was not nearly enough room for this.
As we’ve now established, this ‘900 MB’ is actually 900 MB according to my laptop’s block size and then the space it takes on the M:S is dependent on the size of the individual samples.
I do have a folder of single cycle waveforms (6.3 MB on my laptop disc).
… Ultimately, I cut this folder down to 720 MB and then it transferred no problem. I have no idea how much room is left on my +Drive, but I feel reasonably confident that I have a little breathing-space to grow into, without needing to delete stuff off this core user library (and therefore risk breaking projects).
I think that in light of this chat I will give more scrutiny to my selection of single cycle waveforms and probably delete a chunk of them.
Thanks for everyone’s continued input. This has been a massively enlightening discussion.
This forum seems way more healthy, constructive and civilised than the one I’ve usually posted on in the past!
I’ve been paring down my single cycles also, I realized that most of them were duplicated as 44.1 kHz and 48 khH versions, so I just deleted all the 44.1 kHz versions. I couldn’t think of a reason to keep them (though I still have backups if I change my mind). Cut down the storage size by about 50%. I probably hosed some of my old patterns that used the 44.1 kHz ones, but oh well.
I’ll check out Audiomove, thanks for the rec! I’ve been using Resonic Player (Windows only) for general sample management, it is great! The pro version can do conversions and exports and such, but the basic version is just a super fast and attractive sample player (sort of like combining Windows Explorer/MacOS Finder and VLC in one program).
Also, on converting your stereo samples, the Elektron Transfer app strips away the right channel and just uses the left channel, just like you are doing with Audiomove. In other software, there’s also the option to create ‘summed mono’ samples, where both the L and R channels are added together to create a single waveform. For some samples this would be preferable, but for others it can cause phase interference and other problems. Probably not a big deal for 99% of samples out there.
I’m curious, if you convert a stereo sample that is split into separate L and R files (C1 & C2), then loaded them on two adjacent tracks on the M:S, say tracks 1 and 2, and have them always trigger simultaneously (perhaps using the NEI conditional trig), then effectively you’ve created stereo sound again, right? You could even pan them to widen the stereo field, or create ping-pong effects. Sounds like a fun thing to play with…maybe I’ll add a folder of ‘stereo pair’ samples to my M:S!
Yep… You would need to pan them hard left and hard right… If you had them centred the result would be a mono sound. But panning them in the way you describe would 100% definitely work and give you stereo sample playback from the M:S.
Yeah, I did look into merge options, but as you say phase is a big concern and this seemed the best option for batch processing a large bundle. My only concern was for ePianos with pan effects, but after previewing the results, the left channel versions all seem fine.
I’m planning to use other synths alongside my M:S - so I’m quite happy to get my wide chorused keys from those.
The downside of the M:S being mono only is well-compensated by the benefit of getting vastly more samples onto the allocated drive space.
