301 file organization

Is there a thread on the preferred file organization for the 301 somewhere? Now that I’m making more presets, what I had been doing (saving every file to my samples folder) is not really an efficient option. I tried to re-organize on the computer, but now the samples won’t load with the .lua files, and I’m finding sub directories on the card that might be better for some of this. Any advise or preferences? I’m also having trouble loading some downloaded custom units, and I’m sure it’s related to the file structure questions I have.

I find the file system structure a little disorganized. A map or description of an intended organizational scheme would be helpful, as would @NeilParfitt’s suggestion of an encapsulation method for samples and Lua files together.

1 Like

Agreed, on all of that. I’m glad to hear I’m not the only one. Thanks.

I second this, preferred working structure would be helpful here

I’m fine with it, but then again I’m completely used to dealing with far more complex setups!

Having said that, I’m all for improvements that make things easier, so yes please from me too :slight_smile:

I don’t necessarily mind whatever file system is implemented, but I’m still unsure of where to put things now that I’m using custom chains. I made a directory for my samples under 301, so it’s only one directory in when I need to select something. But that’s probably not the right place to save chains, since there’s a directory for those under sc/presets. Then there’s a pool directory on the card, and I’m not really sure what I should use that for. When I’m loading custom chainsI downloaded from the board, none of them load properly, so I’m wondering if Ihave to put the samples in one directory, and the .lua in another? Do you have a method that works reliably you could share?

Um, samples go in samples directory, .lua files in their respective directories, i.e. custom units in the custom-units folder!

If I end up in a pickle I’ll just edit the .lua file and adjust the paths for the files, it’s not that hard, although I do admit it is a bit of a faff. That is, until the promised update of introducing a PATH variable, which will prioritise this load process with hard coded, current directory and then a default folder as search locations, becomes available.

I wouldn’t overthink it until Brian releases the update that addresses this issue, I am confident he will do something nice :slight_smile:

If you’re having trouble loading up custom units or whatever, then ask questions on the relevant threads and I am sure help will come along soon enough!

I’ll do some research, thanks. One of the problems is that I have no “samples” directory, other than the one I created myself. The same with the “custom units” directory. They’re just not present in the file structure on my card, so I wasn’t sure where to put them, and ended up putting them where I thought they’d logically go. But that might be different than what the system is expecting. I’ll do more tests. Thanks.

Weird, I can’t remember creating a samples directory, but maybe I did… It never really occurred to me to think about this too much, I’ve just been using the default save locations and my own personal folder at the level just below the ER-301 directory where everything else is. That’s pretty much it!

1 Like

I’ll play around some more. Thanks for the suggestion about editing the .lua file. That’ll be useful, I’m sure.

1 Like

As a side note: I am totally treating this as a huge experiment that will one day stabilise into something coherent, nothing I am doing at the moment carries any sense of permanence and I fully expect to wipe the slate clean and start again at some point - that feels like a healthy approach to something that is still heavily under development :slight_smile:

1 Like

I realize that the current implementation follows an object-oriented pattern where multiple Lua presets might refer to a single sample file. I have been used to having a project directory per bank. I am pretty aware of my entropic tendencies, so with my music making I try and be as highly organized as I can–call it OCD or over-compensating. This business of the Lua file in its own file distinct from the sample frustrates me as it feels like I’ve left my beer downstairs, just as I was sitting down to watch a Youtube, and now I have to go get it.

Notwithstanding, I think the chooser folder is an excellent idea.

1 Like

I agree that file and meta data organization are quite discombobulated at the moment. The core issue is how to maintain links and references between the various resources. We already have quite a few and more will be added as time goes by:

  • sound files
  • slice files
  • unit presets
  • chain presets
  • 6-track recorder presets
  • quicksaves

Currently the linking system is quite brittle and relies on absolute paths encoded within presets. Although, starting with v0.2.0, the ER-301 will at least also be looking in the preset’s folder for any samples that it couldn’t find via the absolute path encoded within itself.


That sounds very useful. In the meantime, I believe I’m missing directories from my card. I’ve never had a “sample” or “samples” directory, or a “custom-units” directory, so I just made a “user” directory, and worked in there. But I’d like to recover the proper directory names and hierarchy. Is there somewhere I can download this, or see the directory structure, so I can add what I’m missing?

There never was a samples directory. That was something that @anon83620728 made up. haha. The ER-301 will always create any necessary “system” folders whenever you mount a card. So no need to worry about missing any of those.

The intention is that you put your samples where ever you want and point your presets to them as needed. This has made it hard to share presets because everyone will be organizing their samples differently. It is a problem that I need to solve. I feel strongly that people should be able to organize their samples on the card how they wish, so that aspect will not change. How the ER-301 goes about finding the samples referenced in a preset will evolve and improve.


Oops! Sorry for the confusion everyone - I don’t really remember doing this, but it must have just seemed like a completely natural thing to do :smiley:

I think I’ve written my instructions for loading up custom units based n this too :blush:

In very non-technical / over-simplified terms - maybe some export option which packages samples with preset files into 1 monolith file. Users can then import / extract the monolith, preset to usual place (?), sample part to their folder of choice (updating preset to point to that location).

Also, for the creators, exported files go to an “export” folder so you can get rid of unecessary files after you’ve shared them and want to tidy up.

1 Like

I guess the real decisions are where should the package contents be “installed” when imported? Otherwise you get a lot of questions like “Where should I put this file?” being asked to the user. Perhaps there should be a designated location for imported content?


Agree. Maybe you can set a default import folder in prefs, which you can change if you so desire.

I would probably import a package, make some changes and save the elements (or package, if this happens to become a feature) to my personal folder structure, at which point, I’d probably delete the original imported package, or, maybe keep it as an original starting point should I feel I might want to revisit it.

Also, maybe some view / list to see the dependencies between preset and samples might also help?

I’m not helping am I :slight_smile:

While we’re muddying the waters, I’m not always happy that there is a one-to-one correspondence between slice files and samples. Sometimes I’d like to use a different slice file for a particular sample without having to duplicate it.

This may be extraneous, but yaknow, grist for the mill.

I don’t envy the task, Brian. I appreciate your efforts. I spent some time with 0.2.1 last night and really enjoyed it. The OS is shaping up nicely. Very impressive, especially considering how close to metal you started.