I have a pretty full patch bank using almost all memory slots. Some of the patches use the supplied wavetables. I tried loading the second waves pack and so I deleted the current waveforms (emptied the trash) and loaded the other pack but copying it back tot he Super 6 could not finish and I got an “out of space” error message…
Is this something we need to be aware of or is there something else going on? I notice that the “drive” space only contains 5.5mb of storage.
I deleted some of my patches and then loaded the waveforms and everything is fine but it seems weird that there is so little storage that it couldn’t even support all the possible patch slots.
I hesitate to bombard UDO with a new features wishlist, so thought would tuck in this under your heading. What I find is it is near impossible to de-construct another person’s patch, due to there being no screen. That’s no criticism, as Super 6 is kind of a purist design, which makes it unique. I opened a patch file on my computer’s text editor, and as expected, it is gobldygook. Maybe UDO already have this for development purposes, but a piece of software that would graphically show the patch file as maybe a spreadsheet? This would avoid the need to make the synth connect to the miriad of OSs and versions out there, with all the vexation. I do get why UDO decided to make their synth futureproof, as an external drive. What do people think?
Great idea! If we could get how to parse patch files it could for example be presented on a webpage with knob and slider positions. I was thinking about something similar with exporting svg graphics to image/pdf. Someone did something similar for Moog Matriarch to show patches.
Okay solved it!
I was also experiencing this issue on macOS, and it was pissing me off!
When copying files from macOS to the SUPER6 drive which is a FAT12 volume, macOS stores the extended attributes of each file as hidden files. This is done automatically when the destination file system does not support extended attributes: Extended file attributes - Wikipedia.
The way to I solved this, is by first deleting any such hidden files from the SUPER6 drive:
WARNING: The following is performed using the command line, so only do this if you are comfortable using it!
- Open a terminal
- Change directory to the SUPER6 drive:
- Find extended attributes using the command (if you have any they will be listed):
find . -type f -name '._*'
- Find and delete extended attributes using the command (only do this if files/folders were listed previously):
find . -type f -name '._*' -delete
This should free up any space currently used by these extend attribute files. In my case, quite a lot, taking into consideration the limited space available.
Then, I removed the extended attributes from the folders and files I wish to copy. This is done like so:
- Open a terminal
- Remove all extended attributes using the command (be careful with the path):
xattr -rc /PATH/TO/YOUR/FILES
- Copy files as normal using finder or the terminal
Now I am able to store the full amount of patches, sequences and waveforms!
If you are simply saving patches directly on the synth, then you won’t face this problem. However if you are in the habit of copying patches, sequences, waveforms from macOS over USB, you likely will.
Anyway, hopefully this is of some help to others facing this problem. It worked for me.
Brilliant! That worked for me as well.
UDO support confirmed that they were able to reproduce this issue and that it will be fixed.
Bumping for UDO to fix - thanks!
As far as I know theres a cleanup routine built into the synth these days.
So if you delete stuff in the normal file manager way (not using terminal commands) and then find that not enough space is reported to store all the files that should fit on the synth, switch the synth off. Then when you switch it back on in ‘patch storage writeable’ mode, I believe it deletes any troublesome hidden files that are wasting space, possibly while flashing lots of lights on the panel during this process, and then you can copy files successfully.
It’s a bit embarrassing for UDO / patch developers that we have to do this. I deleted all my patch banks to load up the Jexus patches and only 14 of the 16 banks loaded properly due to lack of space. As a ‘workaround’ I had to delete all my sequences in order to have space for the other 2 banks to load (even though the Jexus pack also comes with sequences). Will try your method.
A very, very simple application could manage this. It just needs to have to columns, bank, and patch selection, and the ability to move the patches between.
It’s an incredibly annoying system. And as cheap as storage is, for probably a dollar more, it could have been avoided.