I think the author is discounting their own design sense which is necessary to come up with the ideas! (Or even to take inspiration from other sites.)
Side note, better not animate with useState when you can use CSS animations, react renders are cheap but they add up and can't match the browser's layout/styling engine!
I am a full stack developer specializing in Typescript. I'm comfortable with bringing greenfield apps from conception/design to deployment, database and api architecture and implementation, web design, and even more niche tech-adjacent fields such as teaching and the arts.
I pride myself on initiative, curiosity and high productivity. I also like playing the viola and studying Chinese :)
Throat singing is just a band-pass filter. Having a rich set of frequencies can be helpful, but it's unnecessary for producing the overtones. Throat singing and "whistle singing" are effectively the same technique, except that in throat singing a wider collection of overtones is selected for (not necessarily wider band, but wider "matching partials" to the fundamental frequency)
Are we talking about the same thing? I mean the Mongolian throat signing in that YouTube link, which has crazy low fundamentals (I have a deep bass voice and it's much lower than I can sing).
No, you aren't, and it isn't vocal fry. Overtone singing is a distinct technique in Tuvan throat singing, and comparing it to a bandpass filter is accurate — as a whole, Tuvan throat singing is a set of techniques designed to induce vocal sounds with extremely rich harmonics, which can then be modulated and selected for by shaping the mouth.
What you're thinking of is called "Kargyraa", a particular subset of Tuvan techniques that involves singing with the vocal cords as normal, but also tightening the voicebox such that your "false vocal cords" (some flaps somewhere in your throat) are struck at a frequency an octave below the sung note — for every full cycle your vocal cords complete, the false vocal cords complete half of 1. It creates a rich sound which can be useful for the "bandpass" technique, but is fundamentally something different.
Take this with a small grain of salt, I came to this technique through the modern beatboxing community who independently discovered it as the standard "throat bass" and only bothered researching the Tuvan equivalent a long time ago.
There is a bass singing technique called "subharmonics" that uses something similar (identical?) to vocal fry to create interference with a sung note for a similar effect.
How do people usually backup their self-hosted docker services using postgres? I have been using docker-volume-backup [0] and just saving the postgres data directory, but I've found it requires a minute of downtime to backup properly.
pg_dump [0] (or pg_dumpall, linked there) sounds like what you want to use. You could docker exec into the postgres container, then copy the dump from the volume to your backup location on the host.
A bit more contrived than copying the volume but you don't need to shut down the server. There's probably some scripts out there for doing this in a structured way but I usually do it more or less manually/use a bash script.
Specifically in the case of paperless-ngx, I use their export facility from a cron job. The export is plaintext and contains all the information needed to recreate the postgres db and the learned identifiers. In case of a disk failure (and I've had one with my paperless store), I just reimported the previous days backup from my offline backup of paperless' export.
For now I only backuped some databases with a pg_dump one liner triggered from a cron job on the docker host (via docker exec or docker run --rm). No idea how this scales for big databases. But for your regular home server <10 GB databases this should just work.
restic container with all volumes mounted to /backup/<volumename> (and . to /backup/self - use named volumes, not binds) in my composefile with scale 0 and a backup.sh that's essentially
docker compose down && docker compose run backup && docker compose up -d
The restore procedure is the same, you restore the composefile through restic on the host and then `docker compose run backup restic restore latest --exclude "/data/self/*" --target /`
I find it's fast enough because restic is incremental, but if you can set this up on a filesystem with snapshots that would be a great option too.
Restic takes a bit of fiddling around too. I mount a prepared ssh config, a known hosts file and a private key.
Side note, better not animate with useState when you can use CSS animations, react renders are cheap but they add up and can't match the browser's layout/styling engine!
reply