This might sound a bit elementary, but I’ve noticed a couple of comments in the past that makes me think it’s worth asking - so I will!
Is there a preferred way to load up the fonts onto an SD card?
When I’m building customers’ sabers, I generally build the complete folder on my compurer of all the fonts needed for that particular saber, along with the ProffieOS folder and config. Once it’s all built with everything in the right place, I simply drag and drop the whole lot onto the SD card in one go (having first formatted the SD card using the proper formatter). Then I go and have a cuppa while the files copy across, as it typically takes a minute or two to copy the 1.5 to 2gb of fonts onto the SD.
My question is, is this the right way to do it in terms of optimizing SD card read speed?
Or should I copy each font folder onto the SD one at a time?
That all seems fine, but there may be a few tweaks that might be helpful.
What kind of SD card reader do you use? A V30 card should take 66 seconds or less for 2Gb.
If you do a lot of sabers, you might consider an sd card image instead. This would combine formatting and copying into one step, and it would eliminate any variety between sd cards.
When it comes to optimizing for read speed, there recommendations can be found here:
One thing ive noticed on this “speeding things up” page…is the section that mentions ‘Overclocking pixel strips’ with an updated config parameter.
This updated parameter doesn’t work well with V2 KR strip pixel strip Neo- blades. For whatever reason using this line of code in conjunction with these kinds of pixel blades causes them to act all wonky, glitchy, wrong illuminations, etc.
Ive tested it on mine, and had to remove this Overclocking in the config to get these blades to work as normal. Just a heads up.
@BK_Saber Nice to know I wasn’t imagining that bit w the V2 strips. Glitchy sums it up, I see it when using not just that but a bigger style and you’ll see it glitch like the style code is reloading and it pauses for a split-second. At least now with the most current official OS6 as well as the new master the bladestyle doesn’t completely lock up in the rolling transitions anymore where the blade freezes up.
Thanks guys.
Prof, in terms of card reader, all I’m using is the slot on the back of my iMac (with a suitable adapter to make the micro SD a regular ‘large’ SD) and the SD card formatter software that I think Brian recommended to me.
I just timed a 1.5 gb transfer as I’m doing a small batch of hilts this morning, and it took around three minutes. That said, there are other variables in my system as the original folder was on an external Firewire drive, connected to the Mac via thunderbolt. Plus my internal MacHD is a Fusion Drive which is mostly mechanical but with 24 gb SSD. But apparantly MacOS Catalina and later (hwhich I’ve just upgraded to) is designed for SSDs and makes mechanical drives work slower (thanks Apple!), so there are lots of obstacles to light-speed performance inherent in my modest little setup.
But anyway it’s good to know that I’m in the right ballpark in terms of working practices. Interesting about the disk image thing too. I’ve never quite got my head around disk images, but it sounds like I should spend a little bit of time learning about them. Thanks as always for the tip.
If these are class 10 cards, that might be the time it takes.
V30 cards would be ~3 times faster in terms of write speed.
If these are in fact V30 cards (or better), then you might want to try a different SD card reader.
Initially I was using a Apple USBC to USB (Thunderbolt) into a basic Platinum brand read/write and just recently (since I was working remote for a bit and wanted/needed a good splitter w read/write) switched to a Satechi*. I can load about 60 fonts in 2 minutes tops now. So much smoother overall. Regarding your system, what year is yours? Note, I’m biased. My 2013 is dead and scrapped out and I gave the 2017 on OS Monterey to one of the kids so I could justify going to the new M1 machine. I’ve gotten accustomed to the changes…YMMV.
*They also make a hub adapter version but I prefer the flexibility of the cable version.
My Mac is a late 2015 iMac (2.8GHz, Quad i5, 16 GB RAM) which I bought new with El Capitan, then moved to Sierra. Being quite tight, if I don’t get 12 years out of a computer I get very grumpy! I only upgraded from Sierra to Catalina because Safari was increasingly incompatible with more and more websites. And I stopped at Catalina because that’s the newest system my daughter’s 2013 iMac can run, and it’s simpler if we’re both on the same OS. (Ironically hers runs much better on it as she has a 128GB SSD in her fusion drive compared to my 24GB. Thanks again Apple!).
Without wishing to get on my soapbox (sorry Prof., I’ll keep it brief) once I get a system working I want to leave it alone. Every upgrade breaks stuff which costs me money to fix and invariably leaves me two steps behind where I was before I started. For instance with Sierra I could access a shared folder on my main Mac using my ageing G4 iMac which is in the grage. This was great for accessing wiring diagrams and stuff. But I’ve only been able to make Catalina work the other way around, meaning lots of running in and out of doors and up the stairs that I didn’t have to do before. And don’t even get me started on Apple’s progressive dismantling of Mac Pages with each successive “upgrade”. You know it’s bad when you could do stuff with PageMaker in 1990 that you now can’t do with Pages in 2022!!!
Sorry - we’ve gone way off topic. LOL! Suffice to say, by and large my 7 year old iMac does what I need it to adequately quickly - I just get irritated at the outside world forcing me to break it with a supposed “upgrade” every five minutes. But that’s just me. LOL!
The good news, without wishing to blow smoke, is that ProffieOS upgrades are infinitely superior to the rest of the world’s IT upgrades. They genuinely provide new features that work without breaking old features, they don’t force you to spend hundreds of pounds to get back where you started, and of course are fully backwards compatible. Apple and Microsoft take note! LOL!
I tend to get grumpy because computers don’t get faster as quickly as they used to, so now I only get a new computer every 4-5 years instead of 2-3 years…
I still get 10+ years out of my computers though, because my hand-me-downs become file servers, or used by other family members.
Are you including the whole Proffie operating system? If so, why? The more things you write to a card, the more File Allocation Table (FAT) entries the OS needs to look through to find what it’s looking for. Also, as a customer, I would wonder why you would bother doing that when I can easily download the source myself. A slightly more sophisticated customer would wonder whether you have customizations in the OS code that would make it difficult for me to upgrade to a future release.
As a customer the things that would make my life easier:
Make a top level directory for Fonts, and put all the fonts in that directory/folder
Give the font folders names related to what font it is, like “General,” “Graflex,” “KrossGuard,” etc.
a. This does two things, first it tells me what the font is without me needing to do a bunch of detective work
b. It also means that if I want to reorder them in the config file it’s easier and more logical than having “Bank10” come before “Bank2,” not to mention having to remember which one is which
Inside a font directory if a certain type of sound has more than one file, but them in a directory (as Fredrik said upthread), but if it has only 1 file, do not put it in a directory (again, useless FAT entries are bad, not to mention confusing to the user)
In the ‘sd config’ directory put the ONE config file used for THAT INSTALL in there, clearly labeled, such as this_is_the_file_for_this_saber_using_proffieos_67_with_a_32_inch_blade.h (I exaggerate slightly, but you get the idea)
Put EVERY OTHER config file in a subdirectory (folder) called “History,” or whatever you think is appropriate, or just don’t include that information at all. Put a README.txt file with a link to your web site where they can download those other files if they want them
Eliminate exact duplicates of files as much as possible; put them in common, tracks, wherever it makes sense
If you include a folder like “Batt00,” or “common,” or “tracks;” also include a README.txt file indicating why that folder is there, what part of the config file it’s tied to, etc. That way if I change that config later I’ll know that I can safely delete that file and/or folder.
Include a copy of the blade style in a text file in the font folder so that if I delete a font from the config I can easily recreate it
Also include some kind of reference in the font folder to where the font came from so that if I want to get an updated version of it, or if I want more fonts from the same maker, I know where to look
These are all pretty simple changes that in the long run I think will make the sellers’ lives easier as well, but it will definitely make life easier for the customers when they open the SD card and see a nice tidy set of clearly labeled folders with explanatory text included as needed.
The reason is because I make a couple of subtle changes to the prop file. I also modify the const_char line in the Proffie.ino file so that when you type ‘version’ in serial monitor, you get a proper description of the config that’s loaded onto the board.
As for all your other points, I do most of them already. I don’t include blade styles as a separate text document on the basis that if people are going to make changes they would know enough to always work on a copy of the config file so they can retrace their steps if necessary. But if they do tie themselves in a knot, I keep an archive copy of every customer’s entire SD card contents on a hard drive at home, which I can send them on request.
In addition to the above, I provide a complete paper printout of every font on the saber, the order they appear, the default blade colours for each one (plus the 11 other colours available for each font - I’m not a fan of the infnite colour wheel), the blade effects associated with each font, including crystal chamber effects where applicable, the SD card filename for that font and the fontmaker’s credit and font name. It also details the music attached to each font and the ‘Force’ effect (which is usually a character quote).
Also also included is a magazine I produce for each saber which has a page explaining how users can replace the three ‘spare’ fonts on each saber with purchased fonts without needing to reprogramme the saber. And instead of ‘common’ I have a ‘Shared’ folder in which there is another folder called ‘Functions’ which has OS effects. Also in ‘Shared’ are lots of other options like, for instance, ‘Anakin’ which is all Anakin quotes named as Force effects and Boot effects.
This has all evolved over time. Obviously if customers have a particular preference for their setup, I’ll do it however they want. But the above is my standard way of providing buyers with all the resources they might need.
You’re correct of course when the data is first written to a newly formatted disk.
But the way that most people use storage is to delete files, write new files, delete, write, etc. As they do that, the sector tracking gets more and more complex because there are more fragments, more discontinuous files, etc. This is why old fashioned “defrag” programs worked to improve the speed on FAT drives. Partly for the writing of files to continuous blocks, but mostly for the rewriting of the FAT.
The more files and directories that the FS needs to track, the worse this becomes over time.
This is also why I always advise people to format the SD card, then write all the files in one go.
The Proffie.ino file change is probably harmless, but are you 100% sure you can’t do the prop file changes in the config.h file?
Either way, what I’d do in your situation is rather than include the entire source, create a folder in ‘sd config’ with just these customized files, and a good document on why they are there and how they are used.
And you are of course making your changes publicly available, right? (Per the terms of the GPL)
LOL! There are plenty out there that don’t even include the config! 