captbaritone

Site author here. These types of comments make my day. Is this the one? https://skins.webamp.org/skin/ca2270b3513a831fb566b0867b0466...

Author here, thanks for (re)posting!

Happy to answer any questions.

My GtiHub repo for Webamp (the interactive, in-browser Winamp clone) can be found here: https://github.com/captbaritone/webamp

Thanks for pointing that out. I just added it a few weeks ago. I wonder if it’s not visually obvious enough.

I wrote a blog post on the compiler I wrote to help make it fast, in case you are interested: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

That was true for "classic" skins, but starting with Winamp 3, Winamp supported free form "modern" skins that were defined in XML and had a custom scripting language so that the author could define their own behavior.

We have those working at https://webamp.org

For Spotify, someone has! Check out: https://winampify.io

Setting up Webamp with the visualizer is sadly not any easier. If you’re still interested, come join our Discord https://Webamp.org/chat and we can help you figure it out. This example would be a good start: https://github.com/captbaritone/webamp/blob/master/examples/...

You can drag in audio files from your hard drive if you want.

Thanks! The list is ordered by the most number of likes/retweets from the @winampskins twitter bot I run.

I wrote a post about the design of the site here: https://jordaneldredge.com/blog/winamp-skin-musuem/

And then gave a meetup talk based on that post which can be found here: https://www.youtube.com/watch?v=jEUr_NzP6xg&t=2s

Yeah, this. Iframes or webworkers would have had too much overhead to work inside an animation loop.

Ah, thanks for catching. It’s 72.6%. I’ll update.

I also built https://skins.webamp.org which might be helpful for this.

Is it one of these? https://skins.webamp.org/?query=Yaxay3

Yes, it's already its own project and the developer who built it helped integrate it into Webamp.

https://github.com/jberg/butterchurn

If you want to visualize audio coming from the browser (Spotify etc) check out his browser extension: https://chrome.google.com/webstore/detail/butterchurn-music-...

Safari does not currently support WebGL2, which is the blocker. They support it behind and flag, and it seems to work there, but until they enable it by default, Butterchurn will not work on Safari.

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

I'm a bit lucky here in that the number of characters on the screen at any given time is bounded, so at max we have maybe 50 spans, which should not be a big deal.

I'm not sure how it would scale. In general, if you employ windowing all UI rendering issues are bounded by the number of items visible at a time which can let you get away with a lot of craziness, but if the number of items on the screen is as much as the number of characters on the screen... that could end up being a bit much.

I know a lot of things like that end up using shaders to render text, but that is a lot of added complexity.

Probably good advice

Try opening one of the folders.

As a novelty, we actually already tried that: https://desktop.webamp.org/

Note: Nobody thinks this is actually a good idea, but it's kidna fun.

We recently took on a project to use Wasm to speed it up a bit. Blog post here: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

Hey! Project author here! Happy to answer any questions.

This project is open source and the code, and instructions to use it on your site, can be found here: https://github.com/captbaritone/webamp

Webamp's ability to render classic Winamp skins led to a collaboration with the Internet Archive where we preserved ~70k (and counting) classic Winamp skins.

I also built the Winamp Skin Museum (https://skins.webamp.org/) where you can infinite scroll through those 70k skins and try them out in your browser with one click.

Most recently I've been experimenting with improving the visualizer's performance with an in-browser Eel-Wasm compiler. Blog post here: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

The project has given me lots of enjoyment over the years, and I'm glad to see that others are enjoying it as well.

Great questions! There are a number of different performance tradeoffs to balance here:

1. Rendering performance (how efficient is rendering) 2. Startup speed (how large is our compiler) 3. Preset transition speed (if our compiler is slow, we might drop frames when switching between presets)

I would love to explore compiler optimizations (after all, this project was motivated by an interest in learning about compilers!) but I don't think it's the right thing to pursue yet. Moving Eel evaluation into Wasm was such a large win, that the actual Eel evaluation (the part which we could optimize in our compiler) is now a very very tiny slice of rendering. Most of the remaining time is still spent in WebGL and JavaScript.

Adding optimization passes would slightly increase our bundle size leading to slower startup. If the bundle size increase is minimal, that's probably fine, but trying to pull `wasm-opt` into the browser would probably be a significant increase.

Finally, as you watch the visualizer, it transitions from preset to preset every several seconds. This means that we are running the compiler at the same time as rendering. If optimization passes significantly increase cost of compilation, compiling could cause us to drop frames.

We could avoid this risk by trying to chop compilation up into smaller async tasks, or moving compilation to a web-worker, but that would involve adding some extra complexity to the system.

In summary, if we can speed up the other aspects of rendering to the point where executing the compiled Wasm is the bottleneck optimizations would be an interesting next step, but we would have to weigh them against the potential costs of slower startup and slower compilation.

A cron job that runs on a server and sends me a daily digest email. It’s composed of a number of modules that each check one thing and report a message and a “severity”. The glue code then orders them and send the email. Currently it checks:

Twitter follows/unfollows for me, my wife, and my Twitter bot

Stock movements for the few stocks (RSUs) I have

Confirmation that several daily backups (db dumps etc) were successful

Upcoming SSL cert and domain expirations

New GitHub stars

Disk space left on my personal server (running out tends to make it crash)

I know that looks like a lot of stuff, but the goal is for the script to programmatically determine which ones cross the threshold into being actionable/important and to hide/de-prioritize the unimportant ones for me so I can confidently ignore them and focus on any important ones.

_poof!_ did someone say “Winamp”?

I recently put together a museum of ~68k Winamp skins if you want to feel that nostalgia a bit more: https://skins.webamp.org/

I am indeed! Thanks for the kind words Paul!

If anyone is interested Webamp is open source and can be found here: https://github.com/captbaritone/webamp

They are not supported in most browsers. Most users are going to have a bad experience if they load a page with Flash, and it makes sense to down-rank pages that will deliver a bad experience.

Should be fixed now.

If you know of any ones we are missing, please send them my way. I'd love to add them here and to the collection we maintain at the Internet Archive.