sudara
Show HN: I made an additive synth with 10k oscillators
It's called Sine Machine and it has 20 voices of 511 (don't ask) time-domain oscillators.By "time-domain," I mean actual oscillators. A lot of additive synths are essentially iFFT engines and offer "partials" whereas Sine Machine literally provides 10,000 free running oscillators (and 20k lfos to control pitch/vol of each).Having this kind of full control over these offers a lot of fun ability...
Dev Therapy, part 4: Tending the narrative gardens
500 Harmonics, each with a different pitch lfo rate
Code Signing on Windows with Azure Trusted Signing
An expressive, quasi-Ptolemaic semi-modular synthesizer
Doing my synthesizer homework: The quirks of MIDI Velocity
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.
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!
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!
> 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.
How to code sign Windows installers with an EV cert on GitHub Actions
Dev Therapy Part II: Recoveries
Dev Therapy, part I: How to not get stuck (as a solo dev)
How to implement a web-based rich text editor in 2023
Reviving an Analog Polysynth with an Arduino, Ghidra, and Python
Pure Data as a plugin, with a new GUI
https://store.steampowered.com/app/2128390/Leviathan_An_Inte...