Steven made the Whacko AVS packs for Winamp back in the day under the name UnConeD, which were easily the most impressive visualizations I ever saw in AVS.
He has them all for download on the website[1].
You could always see the source code, and I remember as a teenager trying to pick them apart to see how they worked. It seemed so much more advanced than what everyone else was doing. Other packs would have pretty waveforms. Whacko AVS had, as just one example, a spaceship flying through hyperspace in a storm - and it still reacted to the music!
Justin Frankel, the creator of AVS (and Winamp itself), now
makes Reaper, one of the world's best DAWs.
Just in case it helps anyone else struggling to understand this comment (let alone the blog post)
AVS was an addin for WinAmp, a Windows MP3 player app.
AVS stands for "Advanced Visualization Studio".
More info on [Wikipedia](https://en.wikipedia.org/wiki/Advanced_Visualization_Studio) but it seemed to be plugin that supported other plugins that in turn did fancy graphical "visualisations" (moving screensaver-like visual effects) based (?) on the currently-playing music.
Since the site has gone and the new Winamp site is content-free chrome, it's hard to say more.
"DAW" means Digital Audio Workstation but honestly even the Wikipedia articles are so full of references that one is assumed to already know that I am not sure what the phrase means. As far as I can glean, a very fancy sound editor program.
If anyone could ELI5 the whole web link in the style of my comment above, I'd really appreciate it, because I am curious but I can get nothing at all out of it. I do not really understand any of it.
WebGPU?
Reactive?
Declarative?
It's... some kind of Javascript thing (?) that lets you program (?)... fancy animated (?) graphics (?) in a web page (?) that are hardware accelerated?
That is about all I can get, and I don't think I am all that dim.
I got the Arrested Development reference, and almost nothing else.
Hi, sorry yeah DAW a.k.a. Digital Audio Workstation is just a fancy name for audio recording and mixing software. A bit like an old control room with mixing desk and tape machine and outboard audio hardware, but all on a PC in software.
Other examples are Pro Tools, Ableton Live, Ardour, Cubase etc.
Thanks for explaining the rest. My comment was very targeted at people who might have already used Winamp and AVS 20 years ago.
----
One funny thing - even though the Winamp website is long gone and changed completely, the original forums are still running: http://forums.winamp.com
They're up to nearly two million posts. Many people there have been posting for two decades.
I'd really really like to see 3d content start making it's way into the DOM. (Ideally in manners far far far far beyond showing one lone hovering item, as per Apple's <model> proposal.)
Seeing Steven use his Live library to provide such an implementation should be utterly unsurprising. His past works have been so exemplary & leading-edge: mathbox, TermKit, Live itself, & others. Live was an interesting exploration of what grounds really lay underfoot the latest emerged React patterns (hooks), with lots of new capabilities, and seeing it applied to such a holy grail of an idea (3d via dom) is thrilling to see.
> Live goes far beyond the usual React semantics, introducing continuations, tree reductions, captures, and more
There's a ton of incredible wonkery here. As usual for Steven, he's chased incredibly far reaching frontiers, applying this hyper-advanced computing toolkit to 3d, then hunting down a series of hard problems/demos to make expident work out of. The article talks to a lot of specific frontiers, but the "general" work of the underlying Live library (and it's tour-de-force proof-of-value by creating Use.GPU out of it) is quite the distillation of computing into a consolidated, clear form:
> The result is a tree of functions which is simultaneously: 1. an execution trace 2. the application state 3. a dependency graph of that state
Hardly the point, but one thing I'd like a little more affirmative on, to see more clearly- where my desires & Steven's intents might be mis-aligned is- what would it look like rendering environments & spaces here? Can this "dsl for dsls" help us craft landscapes, houses, & actors inside? What do situated spaces look like in this environment, if we can pull that off? Can we represent space in the DOM?
I was trying to use A-frame a bit back, another contender. https://aframe.io/ Somewhat ashamed to admit, I fell on my face a couple times trying to get the legacy cjs modules building with a couple toolchains & put my 3d web projects back in deep-freeze. https://github.com/aframevr/aframe/issues/3732
Briefly, it does make me a bit sad that React isn't the real dom. I doubt very much any of these solutions make the content actually available in view-source. Which, like, 10 years ago would get you 20 lashings for bad behavior. Now-a-days? Normal, react & elsewhere. Un-page content is anti-user.
The problem imho is bandwidth. Unless you are iq or similar, creating geometry and textures from thin-air with pure math is just not possible, so you need to load 3d models, which are much heavier than their html/png counterparts.
For individual models, like if you browse sketchfab, it's not such a big deal if the artist optimized things to be "game-ready", but for full environments, it's a problem, especially as audience expectations are influenced by what they see with multi-gigabyte assets on standalone games and simulations.
I don't think this is a complete showstopper, like 10-20 years ago we had the same problem with 2d games and Flash, but as long as the experience was compelling enough and the preloader wasn't completely boring, people waited, but there has been a shift towards wanting things to be instantaneous on the web (e.g. video with adaptive bitrate switching, blurry but instant > sharp but buffered)
Anyway, I guess my point is I don't think it's exactly a technical limitation of programming, as much as a conflict between audience expectations and wait time
Not just that: few people are Steve Wittens or Farbrausch vetted, most are bewilderingly contented with the ugly and deformed. Even among professionals, and with decades long evidence. See for example the adoption of 3d in online maps, that brought from "good as expected" to "utterly unwatchable, unusable" (and it is fortunate that you can still access the past versions). And that is the big 'G', with nobody able to note, "look - and do look -, this is an unacceptable result".
Normally you need good illustrators and artists: with some approaches you need much better illustrators, artists and taste.
Related: a few weeks ago StackOverflow came out with a visual filter that made the page psychedelic, in the wrongest way. ...As a feature.
Most consumer machines have a literal supercomputer sitting mostly idle as you browse the web.
Css is slow because it was designed for cpus and css doesn't map to gpus very cleanly. But Webgl/webgpu enable some incredible things.
But representing the DOM etc inside a 3D space is useful so you don't loose access to the world of 2D information. However there are no good solutions to this at present the Immersive Web Workgroup in W3C are looking at Layers or DOM Overlay which is for AR modes but might support 2D navigation but it seems low down on the priority list due to CORS and other security challenges.
> Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images.
Your negative bias is showing. That's, just, like, your opinion man. One built around disdain & dislike, and not generally shared. There's no books that publish that opinion. You don't find that limited view abundant in trade publications.
Use.GPU is here to enable 3D via the DOM, and is proof positive that this declarative setup is highly powerful. The heirarchical/acyclic-graph structure more than passingly resembles a scene-graph, which is ultra-common in 3d. Since the hierarchy is apparent, bindings all just work:
> The shader snippets will end up inlined in the right places with all the right bindings, so you can just go nuts.
This is just Use.GPU. It's a huge step up the vast amounts of rote work required to set up bindings in modern vulkan & 3d in general. Barely the tip of the ice-berg. As I said, Use.GPU is a tour-de-force demonstration of the value of Live, which is a much more general & competent way of representing compute on the DOM. Steven calls Live a DSL for DSLs; a small language which can keep representing more, all with common structure & form of the DOM language underneath, a much higher level base for computing that escapes much reinvention along the way. Steven touches numerous times across Live write-ups & this article about how the shape of the DOM is ultra-close to that of Lisp, another blissfully homoiconic computing representation known for it's flexible means of assembling compute.
> Along the way Live has gained actual bona-fide <Quote> and <Unquote> operators, to drive this recursive <Reconcile>. This means Use.GPU now neatly sidesteps Greenspun's law by containing a complete and well-specified version of a Lisp. Score
I think it's under-ambitious to stop at just Space, and that the DOM's S-exp like nature is a powerful & advanced tool for representing all manners of things. Outside of Steven's work, there's plenty of other material. Work like React-Router are extremely clear & direct means of expressing routing/addressability concerns, far cleaner than any other toolkit I've seen. I invite everyone to keep an open mind, and try to use their brain to escape the limited preconceptions they already know, & to explore openly & with active regard, looking for potential. I think the potential for the DOM is high.
> I'd really really like to see 3d content start making it's way into the DOM.
There's a lot of overlap w/ HTML5-native game development. If you're interested in that, pay https://github.com/hmans a visit and take a look at his projects (RenderComposer, ShaderComposer, VFXComposer etc.). Nothing short of amazing!
(spoilers, I highly recommend Arrested Development - there's only a few seasons and it's very funny. So if you want to see the payoff of the joke live and unspoiled, skip my comment and watch the show)
It's a running joke from Arrested Development - a comedy about a family running a property empire that was heavily involved on fraud and in the process of collapsing. The (jailed) patriarch of the family - George Bluth - made some seemingly off-hand references to a frozen banana stand the family still operated - saying "There's always money in the banana stand". These were misunderstood as meaning "The banana stand still makes some money" and dismissed, when they were meant to mean "I have hidden $250,000 in the walls of the banana stand"
The show’s main protagonist, Michael, burns down the banana stand as a symbol of no longer putting up with his father’s influence. His father then told him of the cash in the walls of the banana stand.
It's a reference to the second episode of the TV show Arrested Development. A recurring line about a boardwalk stall the company owns: "There's always money in the Banana Stand."
I don't really see the point of making something so low level accessible from HTML. Or maybe I underestimate how much React made people love using declarative/reactive programming for everything ?
React and Vue integration of ThreeJS or BabylonJS seems more suitable for people wanting to simply add some 3D things to their page using DOM elements and the react/vue syntax.
But this project is still really cool ! Maybe I'm just old and it will find a great user base.
Readit News
He has them all for download on the website[1].
You could always see the source code, and I remember as a teenager trying to pick them apart to see how they worked. It seemed so much more advanced than what everyone else was doing. Other packs would have pretty waveforms. Whacko AVS had, as just one example, a spaceship flying through hyperspace in a storm - and it still reacted to the music!
Justin Frankel, the creator of AVS (and Winamp itself), now makes Reaper, one of the world's best DAWs.
[1] https://acko.net/blog/avs/
AVS was an addin for WinAmp, a Windows MP3 player app.
AVS stands for "Advanced Visualization Studio".
More info on [Wikipedia](https://en.wikipedia.org/wiki/Advanced_Visualization_Studio) but it seemed to be plugin that supported other plugins that in turn did fancy graphical "visualisations" (moving screensaver-like visual effects) based (?) on the currently-playing music.
Since the site has gone and the new Winamp site is content-free chrome, it's hard to say more.
AVS was made FOSS in 2005: https://web.archive.org/web/20051102072333/http://www.nullso...
"DAW" means Digital Audio Workstation but honestly even the Wikipedia articles are so full of references that one is assumed to already know that I am not sure what the phrase means. As far as I can glean, a very fancy sound editor program.
WebGPU? Reactive? Declarative?
It's... some kind of Javascript thing (?) that lets you program (?)... fancy animated (?) graphics (?) in a web page (?) that are hardware accelerated?
That is about all I can get, and I don't think I am all that dim.
I got the Arrested Development reference, and almost nothing else.
Other examples are Pro Tools, Ableton Live, Ardour, Cubase etc.
Thanks for explaining the rest. My comment was very targeted at people who might have already used Winamp and AVS 20 years ago.
----
One funny thing - even though the Winamp website is long gone and changed completely, the original forums are still running: http://forums.winamp.com
They're up to nearly two million posts. Many people there have been posting for two decades.
https://en.wikipedia.org/wiki/Cthugha_(software)
Dead Comment
Seeing Steven use his Live library to provide such an implementation should be utterly unsurprising. His past works have been so exemplary & leading-edge: mathbox, TermKit, Live itself, & others. Live was an interesting exploration of what grounds really lay underfoot the latest emerged React patterns (hooks), with lots of new capabilities, and seeing it applied to such a holy grail of an idea (3d via dom) is thrilling to see.
> Live goes far beyond the usual React semantics, introducing continuations, tree reductions, captures, and more
There's a ton of incredible wonkery here. As usual for Steven, he's chased incredibly far reaching frontiers, applying this hyper-advanced computing toolkit to 3d, then hunting down a series of hard problems/demos to make expident work out of. The article talks to a lot of specific frontiers, but the "general" work of the underlying Live library (and it's tour-de-force proof-of-value by creating Use.GPU out of it) is quite the distillation of computing into a consolidated, clear form:
> The result is a tree of functions which is simultaneously: 1. an execution trace 2. the application state 3. a dependency graph of that state
Hardly the point, but one thing I'd like a little more affirmative on, to see more clearly- where my desires & Steven's intents might be mis-aligned is- what would it look like rendering environments & spaces here? Can this "dsl for dsls" help us craft landscapes, houses, & actors inside? What do situated spaces look like in this environment, if we can pull that off? Can we represent space in the DOM?
https://docs.pmnd.rs/react-three-fiber/getting-started/examp...
https://twitter.com/0xca0a (the creator, who has some examples as well)
I was trying to use A-frame a bit back, another contender. https://aframe.io/ Somewhat ashamed to admit, I fell on my face a couple times trying to get the legacy cjs modules building with a couple toolchains & put my 3d web projects back in deep-freeze. https://github.com/aframevr/aframe/issues/3732
Briefly, it does make me a bit sad that React isn't the real dom. I doubt very much any of these solutions make the content actually available in view-source. Which, like, 10 years ago would get you 20 lashings for bad behavior. Now-a-days? Normal, react & elsewhere. Un-page content is anti-user.
For individual models, like if you browse sketchfab, it's not such a big deal if the artist optimized things to be "game-ready", but for full environments, it's a problem, especially as audience expectations are influenced by what they see with multi-gigabyte assets on standalone games and simulations.
I don't think this is a complete showstopper, like 10-20 years ago we had the same problem with 2d games and Flash, but as long as the experience was compelling enough and the preloader wasn't completely boring, people waited, but there has been a shift towards wanting things to be instantaneous on the web (e.g. video with adaptive bitrate switching, blurry but instant > sharp but buffered)
Anyway, I guess my point is I don't think it's exactly a technical limitation of programming, as much as a conflict between audience expectations and wait time
Once you have your primitives, it becomes basic math and union, subtraction, intersection for the most part.
I made this shader a few days after learning the basics -> https://twitter.com/LeapJosh/status/1494417750395179012
If glsl ever got function pointers or similar, you'd see simple SDF DSLs and frameworks bloom overnight and many of them would be easy and awesome.
Normally you need good illustrators and artists: with some approaches you need much better illustrators, artists and taste.
Related: a few weeks ago StackOverflow came out with a visual filter that made the page psychedelic, in the wrongest way. ...As a feature.
Why would you want to represent this in DOM, of all places? It's uniquely unsuited for anything that's not a few paragraphs of text with a few images.
https://github.com/immersive-web/navigation
Your negative bias is showing. That's, just, like, your opinion man. One built around disdain & dislike, and not generally shared. There's no books that publish that opinion. You don't find that limited view abundant in trade publications.
Use.GPU is here to enable 3D via the DOM, and is proof positive that this declarative setup is highly powerful. The heirarchical/acyclic-graph structure more than passingly resembles a scene-graph, which is ultra-common in 3d. Since the hierarchy is apparent, bindings all just work:
> The shader snippets will end up inlined in the right places with all the right bindings, so you can just go nuts.
This is just Use.GPU. It's a huge step up the vast amounts of rote work required to set up bindings in modern vulkan & 3d in general. Barely the tip of the ice-berg. As I said, Use.GPU is a tour-de-force demonstration of the value of Live, which is a much more general & competent way of representing compute on the DOM. Steven calls Live a DSL for DSLs; a small language which can keep representing more, all with common structure & form of the DOM language underneath, a much higher level base for computing that escapes much reinvention along the way. Steven touches numerous times across Live write-ups & this article about how the shape of the DOM is ultra-close to that of Lisp, another blissfully homoiconic computing representation known for it's flexible means of assembling compute.
> Along the way Live has gained actual bona-fide <Quote> and <Unquote> operators, to drive this recursive <Reconcile>. This means Use.GPU now neatly sidesteps Greenspun's law by containing a complete and well-specified version of a Lisp. Score
I think it's under-ambitious to stop at just Space, and that the DOM's S-exp like nature is a powerful & advanced tool for representing all manners of things. Outside of Steven's work, there's plenty of other material. Work like React-Router are extremely clear & direct means of expressing routing/addressability concerns, far cleaner than any other toolkit I've seen. I invite everyone to keep an open mind, and try to use their brain to escape the limited preconceptions they already know, & to explore openly & with active regard, looking for potential. I think the potential for the DOM is high.
There's a lot of overlap w/ HTML5-native game development. If you're interested in that, pay https://github.com/hmans a visit and take a look at his projects (RenderComposer, ShaderComposer, VFXComposer etc.). Nothing short of amazing!
Dead Comment
react-three-fiber is a really nice way to build 3-d scenes on the web for those of us who aren't skilled in graphics and GPU programming.
Looks like Three.js supports WebGPU rendering now. Naively, I wonder how performance differs between UseGPU and R3F with Three's WebGPU renderer.
[1]: https://github.com/pmndrs/react-three-fiber
I have a feeling that this is a joke that’s either extremely clever or a reference I have not been exposed to. Can anyone help me out?
It's a running joke from Arrested Development - a comedy about a family running a property empire that was heavily involved on fraud and in the process of collapsing. The (jailed) patriarch of the family - George Bluth - made some seemingly off-hand references to a frozen banana stand the family still operated - saying "There's always money in the banana stand". These were misunderstood as meaning "The banana stand still makes some money" and dismissed, when they were meant to mean "I have hidden $250,000 in the walls of the banana stand"
The show’s main protagonist, Michael, burns down the banana stand as a symbol of no longer putting up with his father’s influence. His father then told him of the cash in the walls of the banana stand.
Highly recommend the show.
Deleted Comment
React and Vue integration of ThreeJS or BabylonJS seems more suitable for people wanting to simply add some 3D things to their page using DOM elements and the react/vue syntax.
But this project is still really cool ! Maybe I'm just old and it will find a great user base.