5 ms·

Hey! I run webamp.org which uses Butterchurn. It's not yet mentioned in the Butterchrun readme, but we recently built compiler that compiles the visualizer pre

Hey! I run webamp.org which uses Butterchurn. It's not yet mentioned in the Butterchrun readme, but we recently built compiler that compiles the visualizer preset code to Webassembly in your browser and got a 73% improvement in rendering performance. Blog post here: https://jordaneldredge.com/blog/speeding-up-winamps-music-visualizer-with-webassembly/ https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

leetrout 5y ago
This sentence in your post By that metric rendering with the new Wasm version is ~72.6 faster than the JavaScript approach. Seems like it should says “72.6 times” or “72.6 percent”
- captbaritone 5y ago
  Ah, thanks for catching. It’s 72.6%. I’ll update.
- artifact_44 5y ago
  73% improvement reads like "almost twice as fast", to me. 100% faster would be twice as fast.
Frost1x 5y ago
This was a fun trip down memory lane, lots of nostalgic good-feels. I wasn't aware of either effort and this brought back the sense of an era of computing I once loved. It reminds me how transparent (perhaps moving towards ubiquitous computing) certain applications are becoming. I couldn't tell you how many times when listening to background music and working, I'd occasionally switchover to appreciate my current Winamp skin and even take a small break staring off into Milkdrop and then shift back to work. Now, I rarely take time to even look at my music application, it's just a means to an end--really a different era of computing where modern software just doesn't seem to give the same sense of personalization or character. Thank you for your work!
modeless 5y ago
That's super cool! Interesting that WASM provides a way to sandbox untrusted code. Did you consider sandboxing JS with iframes as an alternative?
- hackcasual 5y ago
  Going to be hard to do real-time audio analysis over postmessage
  - captbaritone 5y ago
    Yeah, this. Iframes or webworkers would have had too much overhead to work inside an animation loop.
    - rektide 5y ago
      The article talks about using WebAssembly.Global to avoid message passing overheads / delays. One could almost certainly use SharedArrayBuffer to do a very similar shared mutable memory overhead-lowering optimization with webworkers or iframes, and see the same outcome. I haven't looked in a while but SharedArrayBuffer used to be a core way to communicate with wasm, albeit it seemed super gnarly: if I remember you have to load your wasm program into a SharedArrayBuffer, then run that SharedArrayBuffer to do anything. I still have some hope that some day, some year, some decade, wasm workers might be able to have more than a single Memory at a time, such that we could work with SharedArrayBuffers far more elegantly/slickly, but please no one hold your breath. And of course, Safari doesn't support SharedArrayBuffer nor SharedWebWorker nor like 50% of the other awesome little platform capabilities that just seem so technically excellent. Makes me very very sad they make such great devices so technically maimed. To be fair, the spectre/meltdown global freak out ~3 years ago did cause a huge amount of slamming on the breaks & rapidly withdrawing really good standards. SharedArrayBuffer is only just making it back[1]. Would that we ever have a chance of having high resolution time again too, but that's basically never going to happen. [1] https://developer.chrome.com/blog/enabling-shared-array-buffer/ https://developer.chrome.com/blog/enabling-shared-array-buff...
  - 5y ago
mycall 5y ago
Does webamp currently randomly load MilkDrop Presets from archive.org collection? I was getting many of the same effects trying it out.

leetrout 5y ago

This sentence in your post By that metric rendering with the new Wasm version is ~72.6 faster than the JavaScript approach. Seems like it should says “72.6 times” or “72.6 percent”

captbaritone 5y ago
Ah, thanks for catching. It’s 72.6%. I’ll update.
artifact_44 5y ago
73% improvement reads like "almost twice as fast", to me. 100% faster would be twice as fast.

Frost1x 5y ago

This was a fun trip down memory lane, lots of nostalgic good-feels. I wasn't aware of either effort and this brought back the sense of an era of computing I once loved. It reminds me how transparent (perhaps moving towards ubiquitous computing) certain applications are becoming. I couldn't tell you how many times when listening to background music and working, I'd occasionally switchover to appreciate my current Winamp skin and even take a small break staring off into Milkdrop and then shift back to work. Now, I rarely take time to even look at my music application, it's just a means to an end--really a different era of computing where modern software just doesn't seem to give the same sense of personalization or character. Thank you for your work!

modeless 5y ago

That's super cool! Interesting that WASM provides a way to sandbox untrusted code. Did you consider sandboxing JS with iframes as an alternative?

hackcasual 5y ago
Going to be hard to do real-time audio analysis over postmessage
- captbaritone 5y ago
  Yeah, this. Iframes or webworkers would have had too much overhead to work inside an animation loop.
  - rektide 5y ago
    The article talks about using WebAssembly.Global to avoid message passing overheads / delays. One could almost certainly use SharedArrayBuffer to do a very similar shared mutable memory overhead-lowering optimization with webworkers or iframes, and see the same outcome. I haven't looked in a while but SharedArrayBuffer used to be a core way to communicate with wasm, albeit it seemed super gnarly: if I remember you have to load your wasm program into a SharedArrayBuffer, then run that SharedArrayBuffer to do anything. I still have some hope that some day, some year, some decade, wasm workers might be able to have more than a single Memory at a time, such that we could work with SharedArrayBuffers far more elegantly/slickly, but please no one hold your breath. And of course, Safari doesn't support SharedArrayBuffer nor SharedWebWorker nor like 50% of the other awesome little platform capabilities that just seem so technically excellent. Makes me very very sad they make such great devices so technically maimed. To be fair, the spectre/meltdown global freak out ~3 years ago did cause a huge amount of slamming on the breaks & rapidly withdrawing really good standards. SharedArrayBuffer is only just making it back[1]. Would that we ever have a chance of having high resolution time again too, but that's basically never going to happen. [1] https://developer.chrome.com/blog/enabling-shared-array-buffer/ https://developer.chrome.com/blog/enabling-shared-array-buff...
- 5y ago

mycall 5y ago

Does webamp currently randomly load MilkDrop Presets from archive.org collection? I was getting many of the same effects trying it out.