I picked up a collection of several hundred of his 4-part chorales. I like to flip through the pages and pick one seemingly at random and play it. While some hit me harder than others, nearly all of them express this "simplicity to depth" ratio.
This is amazing, I will def be playing with it (lossy is also my jam) and hi! I made pamplejuce, hope it worked ok for you, lemme know if anything was rough (its been growing up a bit lately)
One thing the article didn't mention is that a gaussian blur can be approximated with multiple passes of a box blur. Not sure how that would relate performance-wise to the discussed stack blur algorithm. The code would probably be a bit simpler, anyway.
I'm interested in this idea. I think I got confused at some point and mistakenly thought box blur was a 2D kernel and so it wouldn't perform great. vImage does contain a box blur but I haven't checked its performance (I did check the tent blur and it was so-so...) https://developer.apple.com/documentation/accelerate/blurrin...
std::deque will never beat your hand-rolled ring buffer. It's a container, it will spend time managing memory every time you walk off the end of a chunk. If it's implemented right*, it will hold onto a chunk which fell off, and will only allocate twice. If it's implemented wrong*, it will allocate after `chunksize` pushes, and free every `chunksize` pops (which might be handled properly by your allocator). But it's still going to need to shuffle those chunks around, adding unnecessary overhead because you're using a ring in a way that is a perfect fit for your application: you use the value you're popping every time you push.
* for your purpose! Therein lies the challenge of writing standard libraries... choices must be made.
My latest favorite: Oh God, Hear My Sighs: https://soundcloud.com/nick66/oh-god-hear-my-sighs-bach