Adopt Git LFS to optimise cloning speed
mishushakov opened this issue · 3 comments
Cloning the repository takes a while
mish@ushakov Projects % git clone git@github.com:mishushakov/PedalNetRT.git
Cloning into 'PedalNetRT'...
remote: Enumerating objects: 68, done.
remote: Counting objects: 100% (68/68), done.
remote: Compressing objects: 100% (54/54), done.
remote: Total 278 (delta 28), reused 36 (delta 10), pack-reused 210
Receiving objects: 100% (278/278), 85.06 MiB | 1.48 MiB/s, done.
Resolving deltas: 100% (124/124), done.
Updating files: 100% (32/32), done.consider adopting git-lfs to host the .wav samples remotely
https://git-lfs.github.com
I've been thinking about this one, and you can test this with PedalNetRT, but for the SmartAmpPro, no changes are needed to the code to work with 16 bit PCM data. I'd be happy with swapping out the 32FP wav for 16PCM, and then each wav is only about 15MB. Sound quality seemed fine, and 16PCM is what CD quality is anyway. Just need to make sure the data is loaded as float32 numpy array.
Hey Keith,
sure, but i was talking more about how it shouldn't be in version control
i can't make a pull request, because GitHub does not support adding files to Git LFS for forks
once you've got git-lfs, run
git lfs install
git lfs track "*.wav"
git add .gitattributeswhat will happen next is the files will be uploaded to GitHub's LFS and the repository will only have symlinks instead of actual files
update: files from previous commits could also be migrated
https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.1.ronn
Yes that sounds like a good idea, the 16PCM would be in addition to using Lfs.