sudara

Love the chorales, thanks for sharing that one.

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)

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...

Thanks for this!

OMG would have loved to do that instead.

Cache locality and specifically the vertical pass was top of my mind when trying to come up with good ways to vectorize. In the end (at least in my vector implementations) the difference between the passes weren't too large. But most of the them ended up having to do things like first convert the incoming row/col to its own float vector.

One main issue I never resolved is in the middle of the main loop, data has to be converted and written back to the source image and the incoming pixels have to be converted and loaded in. Even when doing all rows or cols in bulk (which was always faster somehow than doing batches of 32/64), that seemed pretty brutal.

I also wondered whether it might be more efficient to rotate the entire image before and after the vertical pass, but in my implementations at least, there wasn't a huge difference in the pass timings.

If you take a look at the video in my README, you'll see how bad it is.

Ahh, the video threw me off originally, I think because of the FPS glitches on the full width — but I see it now! Big bands of blue on the left and right edges. I'll have to cook up some examples to reproduce. Also curious what it means (if anything) in the drop shadow context.

I can say there is a huge performance tradeoff in using real division

Makes sense. It would also throw a wrench in my vector implementations, where the expectation is to perform the same operation efficiently across groups of pixels.

and that my library was therefore the best :)

Haha, well it was for me! I don't know Rust, but it helped me figure out my first C++ implementations!

Fixed! Sorry about that. The rustrepo stuff confused me!

My question is — was solving the edge bleed worth the (assumed) performance tradeoff? There were a couple vendor APIs that seemed to have smarter edge bleed options, but they performed worse. I never got around to actually visually comparing the images, though...

Thanks for all the great comments in your repo, they were quite helpful when trying to figure out how Stack Blur worked!

Thanks for the proofread! I had so much text juggling between this and the README that it was guaranteed some things would fall through the cracks! I updated the things you mentioned about `stackSum` and thanks for the catch on the `sumIn` definition.

It couldn't provide this if it was moving every value in the queue.

I actually don't remember anymore what std::deque does under the hood, I did look into it, but the only thing I remember is that it was quite slow!

You'd have to template the code on `radius` instead of passing it in as a runtime parameter so that the compiler could lower the divisions to bitshifts.

Yes, I really like this idea. Especially because radii only really vary between 1-48px for most drop shadow needs. It would be nice to have a handful of the common radii be ripping fast.

Probably! The dequeue implementation was just for fun, as I miss working in higher level languages :) Home cooked circular buffers is usually how one usually sees real-time audio code written... I haven't had much hands on experience with std::span, but seeing as it's a non-owning view, maybe it would be perfect?

Thanks! It's Figma, which I have some rudimentary proficiency in, really easy to make boxes and move em around.

ha!

Good q! I’m an audio dev who thought the general community might appreciate the project. It’s a cool effort (my primary beef with pd was always the UI)

Jason Shiga's Meanwhile and Leviathan are the ultimate choose your own adventure graphic novels. The latter is also getting a steam release:

https://store.steampowered.com/app/2128390/Leviathan_An_Inte...

Thank you! Good point.

This is great, thanks! I looked for existing unicode waveform representations before building, but didn't run into this. The unicode blocks the Julia REPL uses limits the output to magnitude (signed) vs. amplitude (unsigned), but it gets the job done!

OMG, I thought I was already using ×, but that was a different project. Good call!

STK is cool! I'm building a synth plugin, so that's why I'm in JUCE...

I want to hear more about the remote visualizer! I was using Jim Credland's buffer debugger (again, JUCE)[1]. It pops open a window, making it fairly easy to visualize buffers with one caveat: you actually have to tell it about the buffers you care about visualizing and then recompile. This means debugging can't really be on the fly (unless you only always care about the same buffer or two).

The other issue I ran into was viewing audio from my tests. I'd love to hear about the shared memory approach — real waveforms would be ideal!

1. https://github.com/jcredland/juce-toys/blob/master/jcf_debug...

You found the Achilles' heel of the project! I don't mind the fonts being different sizes or not monospaced, but the fact that there's a difference in height in the font rendering between ⎺ and ‾ on different platforms is a bummer. I have a flag in the C++ implementation so they can still be rendered "correctly" in IDEs like Xcode [1].

I felt doomed to Unicode in this case because of the number of places I wanted them to show up (CLion lldb integration, GitHub actions output, terminal). I would have loved to actually render graphics! I actually never thought about how they would render on a blog article, I wouldn't generally wouldn't use them for blogging...

1. https://github.com/sudara/melatonin_audio_sparklines/blob/ma...

Thanks for the constructive feedback! It's nice to have some new ideas.

In the audio contexts I'm working in, it is a feature to have the zero crossings and errors jump out. It's less "pretty" but is as data-dense as I could get just with unicode.

why not use color when available?

You are right, color would increase data density. In both my test context and in my debugger, color is unfortunately unavailable...

Silence should be easy to spot, not crammed behind numbers!

The condensed 0(256) notation is ugly, it's true. However, you can't miss it, and it's information dense. This was the toughest element to design and I tried a few other styles before this, because yes, it's ugly :)

I'm often working with buffers with 256+ zeros, so zeros had to be condensed to stay legible. Simultaneously, it's often necessary to know the exact number of empty samples (they could occur at the start, middle or end of the block). A dash - for a 0 such as in [----0(256)] might have some ambiguity with a quiet part of a signal (it's important to differentiate true zeros) but your post has me thinking!...

Nice! I became obsessed with rendering sparkline representations of chunks of audio for the same reason: to inspect failures when writing tests / refactoring. I wrote a JUCE module (C++) and integration with lldb to make it quick to inspect chunks of audio in the IDE: https://github.com/sudara/melatonin_audio_sparklines

Pretty sure that is the old rule:

"Feature only the most current Apple products in the following finishes or colors: iPhone 5s in silver or space gray, iPhone 5c in white or blue, iPad Air in silver or space gray, and iPad mini in silver or space gray. If multiple Apple products are shown, display them in the correct relative sizes."

http://9to5mac.com/2013/10/31/apple-to-devs-gold-iphone-not-...

Agreed with all of that! Especially the poor sap who is reading the code wondering WTF...

So — my thinking for those two methods is to purposefully encourage being imprecise. We are always so obsessed with being exact in programming. And typically for good reasons. But in some cases, perhaps it doesn't matter if it's 50% of the time or 20% or 10% of the time. Just sometimes, not all of the time.

That being said, you bring up a fantastic point: what the hell does 'sometimes' mean? Half the time? What does rarely mean? It's certainly going to depend on the individual. No answers here, except I'm leaning towards redefining "sometimes" to mean between 15-50% of the time.

"Lifelike responses" — nice.

I like that "action potential" idea – I was trying to think of a good implementation for "do something twice a month per user" — decaying counter is a nice idea.

I'm with you on willy nilly making parts of your UI random — my use case is for changing up the text in greetings, general play with copy, and once in a while showing something like a tip or a "welcome back" message. Basically, small touches that convey a small sense of variety (vs. RANDOMLY DONT SHOW THE NAV!)

So, the code is like 15 lines and tossed together (currently using both Kernel.rand and Random, which is silly) — but I'd love ideas on how to make it better, how else to encourage unpredictable or more "human" behavior, other libs, etc!

Still working on it, but: https://www.dropbox.com/s/a0rx9c28euwokaz/cheatsheet-pdf-ver...

Here's a first version, still working on it though: https://www.dropbox.com/s/a0rx9c28euwokaz/cheatsheet-pdf-ver...

Here's a work in progress, still needs some loooovvvee: https://www.dropbox.com/s/a0rx9c28euwokaz/cheatsheet-pdf-ver...

YES, this is all part of my master plan to be THE KING OF DEVOPS!!11one.

This is exactly how I use it. A time saver for mundane "whups" moments.