Sample Folder Structure


#1

Is it possible to store recordings/samples in one folder on the SD card, rather than having them inside the patch folder that they relate to?

If so, what would the folder structure be for the wave/play/fn stereo object?

Say I have a folder called "samples" would the path be "../samples/samplename.raw" ? Been playing around with this but Axoloti seems to be fixed looking in the patch folder for the sample.


#2

see : https://sebiik.github.io/community.axoloti.com.backup/t/axoloti-test-release-1-0-8/1086/37

im not sure its 1.0.8 (it was in 1.0.6) , and I'm not sure if its been put in dev yet (not checked)

but also its worth reading the motivation behind this...

whilst the wish to have a folder with all your samples is quite reasonable, and we want to support, one thing we are kind of 'concerned' about, is making it so patches 'just work' i.e. without faffing about copying additional files. there is also the hope, that people could in the future copy patches between SD cards, and not then be in fear that the patch wont work, as they forgot to copy a wavetable/sample.
lets face it musicians don't really want to have to faff with file management most of the time, even if they used to doing it...

anyway, low level will be available, but its worth thinking about...


#3

I see, that makes sense... So if I wanted the startup patch on the SD to play a sample, would the sample need to sit at root level? The start.bin file doesn't sit inside a folder like the others.


#4

This works in 1.06 but not in 1.08. I hope it works in 1.09, with the fallback to sd.card function that Johannes would implement. Or else I cannot update beyond 1.06. I need that feature. It has worked like that uptil now and it must work in 1.09.

To be honest I dont understand those concerns at all. To begin with, it was all about possibilities and now a really big and important feature has been removed. I really hope that this works again in 1.09.

Anyway, I am pretty sure, that if people used advanced functions of Axoloti, they also know how to copy the content of a patch to a friend, along with the patch. I really dont understand why you are so worried about that!

There are many reasons for having every thing in 1 folder and not spread out in every track folder on the sd-card. And I dont understand why you want to "force" people to use that set up. I have no intention of using Axoloti like that. I have no plans to copy everything to individual folders. I want to have all tab files, wavetable files, etc. saved in ONE general folder(with subfolders of course for each filestype) named wt000 to wt999, or tab000 to tab999 for example and call them up with string/index or string/c objects..... as it works now...... And in 1.08, that does not work. You cannot use the string/index objects or the string/c object in 1.08, unless you copy all files(wt000 to wt-999, tab files, etc) to each track folder...... It is going to get messy...... And important concerns is here; how can you test which files you want to use without having to copy everything(all tab files, all wavetables, etc) to every individual track folder?

I told you before; this will make a huge mess on sd-card. And it will fill up the Sd-card with a lot of duplicates of the same files pretty quickly. The "create a track folder on sd-card" feature should be optional. I dont see the need for having loads of copies of the same files, when you can have them in one general folder and call them up at will with string/index or string/c object. Maybe this feature could be handy after working on a patch for a wehile and you want to release it into the contr. lib.; then you could use a feature called " save everythin related to patch". BUt I dont understand why this has to be "forced" on users.

I am really hoping that the "fallback to sd-card" feature, that Johannes have implemented in 1.09 will fix this issue, so we can use a general folder on sd-card. Also Axoloti does not copy any files called up with the string/index objects nor the string/c object to track folders..... So for using these two objects, we have to be able to use a general filepath, you have to be able to call up samples from outside the track folder. So basicly if you use Axoloti and samples, "the smart way", using string/index & string/c, with a well organised system, you are left out in the cold.

For those few times I had opened 1.08 my Sd-card have become a huge mess. And nothing works, because of the string/index & string/c issue. So have only opened it and learned library structure, how to upload patches to the contributor library etc. Have not really build anything in 1.08 yet. Waiting to see how 1.09 works out. Or else, back to 1.06.


#5

Maybe a test release 0f 1.09 could be released soon, so we can test all these new things out?

Btw is it still possible to get the latest version from github as it was before 1.08? Can I just download it and install developer version as before?

Thanks :smile:


#6

It has already been clearly stated we are not going to force anything...
I understand with your viewpoint, even if i don't necessarily agree with it - but I don't think the two approaches are necessarily mutually exclusive, so its not a big issue.

it will be released when its ready.

yes, you can build the current development version from github at any time.


#7

Hm. Where? DIdnt see that. But, if it is not optional do "save track folders to sd-card", it is kind of "forced", right? I have actually asked if it could be optional and got the answer that it would be "confusing" for the user. I dont understand why that would be confusing.

Saving everything to Sd-card is something you do at last stage of making a patch intended for the contr. lib., for example, and I dont understand why, everytime you save a patch, it has to do that procedure.

And yes it is a bit of an issue, cause it will create chaos on Sd-card, with all those track folders, as mentioned above. You should have the option to "save all to sd-card", if you want to share your patch. No ones shares all their patches anyway. It should not be forced, but be an option.

But for me biggest issue is the string/index & string/c issue. And I know you also have a lot of Adventure Kid waveforms, that you probably organised so they can be looked up with those objects. It is really important to be able to do that or else those objects are not of much use. And also the whole idea of making a need system for them is lost.

But, yeah, I think also both things should be an option, that I agree on.


#8

i think your partially confusing things...

what was confusing for the user, was not having a patch folder on the SD card, and that wont change, as we have quite a number of reasons for going that route.

the fallback methods, means you can place the files on your sd card wherever you like. and this will solve your 'biggest issue' - string/index string/c , (i call these dynamic filenames)

these things are not done without thought, theres usually a few things going on, and often some mid/long term ideas/objectives, as I said previously....


#9

I think it is fine to have the option of a patch folder in the Sd-card. But it should only be an option, not "forced".

Great :smile: Anyway, it is not just my issue, but an issue for anyone using the dynamic filenames/string objects.


#10

I can see merit in the arguments on both sides. But if both methods are supported, surely it's a non-issue.

a|x