Another thing I'd like to mention is that Axoloti create a folder for each patch on the SD-card. It has got the tendency to make the card reader mode a bit slow. The more track folders created on the sd-card, the slower card reader mode gets.
Sometimes, when I havent cleaned out the sd-card for unwated files for a week or two, loading the sd-card, using card reader mode, can take several minuts to load. Anyway, just wanted to let you know.
if the SD card is not inserted, axoloti wont save every patch to SD, its a work around ...but it works...
Ahh yes. I think I'll just keep my sd-card adapter for the macbook at hand at all times and just use it that way for now. And I use samples/wavetables in almost every patch I make, so for me it is a bit rough not to be able to use sd-card. Anyway, Ill just use sd-card adapter for now 
I just thought a little bit about this and how it could be solved temporarily, cause if you make a lot of patches and versions of patches, this does very quickly become a bigger deal than you want it to be. And also having to go back and delete folder all the time, worries me, that I might delete wrong folder one day and delete all my wavetables or something similar. That would be catastrophic....
....So...
My suggestion is add a feature in settings, where yo can select a folder on the sd-card where all the track folders are saved, instead of being saved in the root of the sd-card. So they are saved in one folder together. It would be much easier deleting the unwanted folders and also I am pretty confident this will fix the loading time of Sd-card reader mode. If it doesnt have to show 100s of patch folders from the root of the sd-card, I am sure it will load quicker...
@johannes @thetechnobear what do you think?
note: I've moved this to its own topic, as 1.0.11 is now the production release
Ive just tested this, on Mac OS X 10.11.6 and really don't see an issue
so I initially had about 80 files on the root directory , and it took about 5 seconds to mount, and about 1-2 seconds to display the listing.
I then increased this to over 200 files in the root directory, still took 5 seconds to mount, and about 3 seconds to display listing...
to me this is 'reasonable'... whereas your 'can take several minuts to load' is obviously not.
this is pretty consistent with what I've seen with other USB mass storage devices over USB 1.x
(I only really see much better when using USB 3.0)
note: the new 'formatting' procedure as axoloti remote is removed in 1.0.11, above thread details how to do in 1.0.11
putting all patches in a sub directory is possible, (perhaps even desirable) but it wont help if you then have to browse that directory. But it would help IF you are manually uploading samples/data to a shared directory in the root directory.
the only downside I see, is it breaking patches if users have used relative addressing for samples from the patch directory e.g. ../samples/samp01.raw, it would be ok if they used absolute address e.g /samples/samp01.raw
cause if you make a lot of patches and versions of patches, this does very quickly become a bigger deal than you want it to be. And also having to go back and delete folder all the time
this is an interesting 'use-case' , I think the principle of the patch directory on the sdcard is that the patch is name doesn't change that frequently, so you don't end up with 100's of directories.
BUT that clearly is not true, if you start adding version numbers to the patch name..
this kind of highlights an area that could be improved... clearly you don't need many versions on the SDCard but you might want backups on your hard drive.
(note: Ive not had this issue, as I use a private repo, so my patches are named the same, but Ive got backups in the repo should i want to go back, so I don't end up with many copies, named differently)
one solution might be to have a 'patch name' which is NOT the same as the filename, but perhaps linked to file operation e.g. Save As... will set the patch name, but Save As Copy does not.
(the SD card directory is then the patch name, not the patch filename)
Its not perfect, as having differences between filename and patch name could lead to confusion...
but it would at least help clean up the SDCard a bit (which I'm also in favour of)
Thank you for the reply 
The 3 requests:
- Osx 10.10.5
In the root, when all unwanted files are deleted, I have around 50 files and folder. But each folder has got a lot of files and folders inside.
I will do the tests on my sd card and see what comes up. As you say, maybe it is my sd-cards speed that is the issue. It has been formattet using Axolotis old format thingy. Will get back to you on this one.
I think i just deleted like 2-300 folders from my sd-card today.... From patch versions... Like Grain patch 1, Grain patch 2, Grain patch 3... etc.... Everytime you save a new one with a higher number in the end.............. it is considered a name change and it creates a new folder on the sd.card...
And if you actually use the patch folder system, you would probably have to mount the sdcard with the sdcard reader and manually copy .raw files, etc. to the new patch folder..... ANd it has to be done verytime you change a number or letter in your patch. This is to me a bit frustrating and it creates a mess on sd-card.
. I just want to get rid of all those unwanted files and keep my sd-card fairly clean from unwanted stuff. As is now, it is a little bit hard to do.
About using the save copy as instead of saving copy:
What if you want to revert to one of the earlier saved copies. How would that work in reality? It is only the filename changed but not the filereference from the patch folder on the sd-card? If I understand it correct?
if you want to share raw files across patches (or versions) then you should use a shared folder...
then use /resources/myraw.raw or whatever.
simple.
imagine a new (untitled) patch.... you Save As Grain.axp, its patch name is also now called Grain.
then you edit it, and use Save Copy As , saving it as Grain1.axp, but the patch name remains Grain!
then you edit it, and use Save Copy As , saving it as Grain2.axp, but the patch name remains Grain!
so now regardless, if you load Grain.axp, Grain1.axp or Grain2.axp all will use /Grain on the SDCard.
IF you need to have a different variation, that you want to co-exist on the SDCard with Grain, then you use Save As e.g. Save As FilteredGrain.axp, which changes the patch name to FilteredGrain.
(so now you have /Grain and /FilteredGrain)
... we could either do this using the current File commands, or potentially move patches to using a similar mechanism we do with the object libraries, which 'hides' this organisation a bit, and allows for a bit more flexibility in the future. (e.g. meta info like tagging patches)
Yes this is how I do it, and I really dunt understand why anyone would like to copy everything to a patch folder, unless maybe as last step before sharing it with someone else. Even in this case i'd prefer to copy raw/wt/etc into the shared folder and calling them up form there.... But I guess we all have our own "Systems" we follow I like flexibilty.
Got it, thanks
Anyway, I guess I can live with the folders on my sd-card for now.. But I am just really worried that one day Ill by mistake delete one important folder when I am mass-deleting unwanted stuff from sd-card. We will see what happens For now I have marked all the folder that need to be there with red colour, so avoid accidents.
Shared folders vs patch , as you say depends.
I've wavetable patches where I want the wavetable to be part of the patch, this way when I connect any of my axolotis it just works, I don't need to start manually copying stuff around.
( similarly I have a few sample based patches where the patch is a piano, the sample is just part of it)
The thing is, for me, the Mac/PC is where the organization ( source) is, the sdcard in the axoloti is 'invisible' , it's just a temporary storage which allows a patch to work.
( a bit like, say the CF card in an octatrack or spectralis )
We do have a way to go yet, as we do want the sdcard tidy/manageable.
For shared resources, I think something like the 'kit' on an octatrack is the way to go, basically this will allow for explicit shared resource dependancies.
But I'm sure always different folks will want to work differently.
Yes, I also think it is good to have different approaches available. In some cases one way is better than the other and so on.
Gonna check octatrack kit function out. I have never played with one in real time
I think Axoloti is okay with sharing resources. The index object makes it pretty easy to have a lot of wav files or wavetables etc. available, without having to make the patch unlive and live again.
About the Sd-card again, I guess best is to clean up more regular than I do. Will see what time brings.