Yeah I guess it wouldn’t hurt to do a little house cleaning on my 2.2 SD Cards.
Just constantly trying out blade fonts or getting/making more that I just leave the sound fonts on the SD Card & forget about them…
No, I NEED 90+ fonts. Long live the 3.9!
2 Likes
Do we really NEED lightsabers ? But we definitely WANT them.
I know I WANT all the fonts I can possibly cramfu on my saber till the memory is 99.999% full, the more the better.
1 Like
Wait, does more fonts affect read speed? I thought read speed was more down to file structure and it didn’t really matter how many fonts you had as long as the config fitted and there was room on the SD. I routinely have 40+ fonts on a saber, with. admittedly, blade styles that aren’t especially complicated. In the past I would get occasional glitches, but since I revised my file structure some time ago following recommendations and reading up on this site, those instances are now quite rare, even with 2.2s, and if they do happen, there’s usually another cause like power or overall SD corruption.
In case it’s useful on this thread, and based on what I’ve I’ve read here over the years, I’ve found that the following file structure works pretty well in terms of read speed and avoiding audio glitches:
- Make sure all file and folder names that need to be accessed ‘live’ by the system, have eight characters or fewer;
- Put the font folders in sub folders, with no more than 15 fonts per sub (allows one spare);
- Name the font subs early in the alphabet - that way when you drag and drop contents onto the SD card, the fonts get loaded up first onto the fastest parts of the SD;
- I also put expensive ‘premium’ fonts first, so they get the best possible chance of best performance;
This also helps keep the SD quite tidy, and since I try and build in as much flexibility for users to make changes by just shuffling files around on the SD without needing to reprogramme, that’s actually quite useful.
I only mention all this as experience has shown that it works pretty well. But naturally I’m always open to suggestions that might make things even better. 
2 Likes
Depends on how you count.
If we ignore “holes” in the file structure caused by deleting files or fonts, then this basically holds true:
- Adding a new font will never make existing fonts slower.
- A new font may[1] require one more “read block” operation every time ProffieOS opens a file. (compared to the existing fonts on the SD card.)
- A font that requires too many “read block” operations to open a file will have audible glitches. How many is too many? Well, it depends on the read speed. A V3 board will do better than a V2 board in this regard. Reading a block takes ~0.3ms on a V2 board, and a little over 0.2ms on a V3 board. The buffer is 11ms, but once you go over 4.5ms to open a file, you start getting issues. Normal file open times are in the 2-3ms range, so you may have ~5 extra reads before problems show up. Every subdirectory costs at least one extra read. Every time ProffieOS has to read 16 or more directory entries to find a directory, it needs an extra read.
- With clever directory structures, you can have hundreds of fonts before you get more than 5 extra reads.
tl;dr; more fonts don’t affect read speed, but more fonts requires slightly more read speed to work properly.
[1] Using a clever file structure mans that you can have more fonts before the number of read block operations become a problem.
2 Likes
Can you give an example of a clever file structure that ticks all the fast-read boxes?
Mine is kind of arrived at, so I imagine there will be at least one stick along the way that I grabbed firmly by the wrong end! LOL!
For the most part, I just recommend sticking fonts in a subdirectory, with 16 fonts per subdirectory. That gets you to 256 fonts with two reads, which should be enough for anyone.
We can also add 16 more fonts to the top directory, in directories after the ones that have subdirectories, these 16 fonts will also only have two reads. So 16 directories with subdirectories, and 16 directories without, for a total of 272 fonts.
With three reads things gets a little silly.
First we can have 16 directories where each directory have 272 fonts in it, arranged as specified above. After those 16 directories, we can have 16 directories with 16 fonts in each and finally 16 fonts with no subdirectories, this would be a total of 4624 fonts.
Basically each read can give us 17x as many fonts, but it’s easier to just do every font at the same “level”, which means that you get 16x instead of 17x.
2 Likes
This is great stuff - thanks Prof.
But, as is so often the case, it’s got me thinking (always a worry! LOL!)…
The 16 file cap - if we want to call it that - will presumably include hidden files like DS_store (for Mac users like me), .Trashes, Icon\r, Thumbs.db etc. wouldn’t it? If so, our 16 file cap wil be exceeded it we actually put 16 fonts inside a subdirectory, yes?
If so, it seems there are two ways to handle that:
- Don’t put more than, say, 12 fonts in a sub directory to allow for the invisibles.
or (and this is where I’m excited! LOL!)
- You can use the Restore Factory Defaults feature actually in your saber - which comes as part of the Sabersense prop file
- but which I can modify to include all of those invisible files as well as the Proffie-created temporary files which it was designed to delete. 
Currently with my prop, the system scans the top two folder levels of the SD card and, with a specific button press, deletes any files it finds with the following filenames:
“curstate.ini”,
“curstate.tmp”,
“presets.ini”,
“presets.tmp”,
“global.ini”,
“global.tmp”,
“arraysve.ini”,
“arraysve.tmp”,
I can simply add the following to the list:
“.DS_Store”,
“Icon\r”,
“Thumbs.db”,
“desktop.ini”
Plus any others that people know of that we should get rid of.
The first two folder levels is probably sufficient, since beyond that, font folders routinely have way more than 16 files and folders inside them so if I’ve understood it right, there wouldn’t be any real gain from deleting invisibles deeper in the file structure.
So first question - is this such a whizzo idea that there’s some part of it I haven’t properly understood which blows it out of the water?
For now I’ll assume the theory is sound and move forward to the rub…
I gather that files aren’t the only invisibles in file structures - there are folders too, like .Trashes, System Volume Information, $Recycle.Bin etc. Currently my prop won’t look for folders, only files, and deleting folders will be a little more involved since they’ll need to be done recursively. But if the consensus is that this idea has legs, then I’m sure that can be made to work.
Finally, I realise this is all marginal gains stuff, but since it’s relatively simple to do and comes at no cost in terms of processing, it seems to me it’s a case of might as well as not. As a BMX racer, I come at these things from the point of view that an extra inch over a whole race lap can be the difference between winning and losing, so if there are any extra inches you can gain without too much effort, you might as well do it.
What do we think? Sound idea or absurd waste of time? LOL!
No you can’t, because deleting files doesn’t help.
When you delete a file or directory, the entry for that file/directory is still present in the directory listing, but marked as deleted. Next time you add a file or directory, it will use the deleted entry.
You would need to compact the directory (something that “defrag” does) to actually help, but doing that may also put the files and directories in a different order, which you might not want.
Ah, Ok. I had a feeling there would be some little detail that would torpedo the idea. 
So it looks like 14 font folders per directory is the way forward then, as that leaves room for a couple of invisible files without exceeding our 16 folder limit and tipping us into extra reads.
It’s not actually a cap though.
You can have as many files/folders per folder as you want, as long as the ones that matter are in the first 16. So if the invisible files are created after the 16 directories, then it should be fine…
Not that it matters, 14*14 directories directories is still enough for most people.
1 Like
Wow! If anyone would like to summarize the conclusions regarding sd/font optimization and minimizing reads (and perhaps provide an example directory set up for clarity) on the POD, that would be very useful. 
It could be added to this page: ProffieOS Documentation: Faster performance of fonts and blade animations.
I’m happy to have a go at updating that page later this week if it helps (assuming my grasp of the theory is correct).
Will submit it as a PoD pull request when it’s ready.
Maybe I should just do the caching mentioned in the pod page.
With a little bit of creative software writing, it should be possible to make it so that the number of directories just doesn’t matter. (Except when changing font.)
Won’t that be a load of work?
It’s all relative.
Really the only reason I haven’t done it is because most people don’t need it.
1 Like
Well it’s certainly true that most people’s sabers work perfectly well without their giving it a second thought. I guess the only reason I geek out about these details so much is because if there’s tiny, simple things that can be tweaked for the best possible performance, then I don’t like leaving those stones unturned. But I certainly wouldn’t wish to create a whole load of work for anyone, especially when, as you say, the 3.9’s improved processor speed can probably ride out whatever minor wrinkles might have lingered with the 2.2.