Party Mode: a 2014 d3.js browser visualiser, kept as a reference

An archive kept deliberately, not by accident

Party Mode is described as an experimental d3.js music visualizer from 2014, continued as vizz.fm, and the project page opens by saying it has evolved into vizz.fm, that it has been completely rewritten using Three.js and WebGL for next-generation real-time 3D music visualisation, and that this repository is kept around for reference but is no longer actively maintained.

The wording is important for anyone arriving from a search result. The banner is explicit: if you landed here looking for something to actually use, go to vizz.fm. What remains here is the 2014 code and, just as valuable, the 2014 write-up that explains what it does and why.

The release record supports that reading. There is a single tag, v0.1, named first real commit, dated 2014-08-18. The last push to the repository was on 2026-08-15, so the tree is still being touched, but that is housekeeping on an archived project rather than the development of a product.

The repository structure confirms the era. There is a Gruntfile.js, which was the build tool of that period, a manifest.json with background.js and contentscript.js, which are the pieces of a Chrome extension, an icomoon directory for the icon font, an mp3 directory for sample audio, and the source split into index.html, js/ and css/.

The manifest and the two extension scripts are also the reason for one of the ideas listed at the end of the original write-up, which is to make it a Chrome extension. The extension scaffolding was started and never finished.

How the original pipeline turned sound into SVG

The 2014 documentation includes a technical overview that is worth reading in full, because it describes the whole mechanism in one paragraph.

Using the Web Audio API, the author can get an array of numbers which corresponds to the waveform of the sound an HTML5 audio element is producing. Then, using requestAnimationFrame, with a little frame limiting for performance reasons, that array is updated as the music changes. The data is then normalized a bit, or transformed slightly depending on the visualisation, and the screen is redrawn based on the updated array. d3.js is used to draw and redraw SVG based on that normalised data.

The last part of that sentence is where the honesty is: each visualisation uses the data a bit differently, and it was mostly trial and error to get some stuff the author liked looking at.

Two consequences follow from the design. The frame limiting is a deliberate performance concession, because redrawing SVG geometry at full animation rate on every analyser update is expensive, and this project was written on a four year old MacBook whose CPU the author says the thing can easily strain. And the d3.js choice is what makes the theming approach possible.

Since D3 is just drawing SVG, everything could be styled in CSS, with no images used at all, including icons. There are a handful of differently coloured themes for each visualisation, and the CSS namespacing is rudimentary: a class applied to the html element, for example a theme_1 class, lets rules be overridden or substituted trivially, and pseudo selectors such as :nth-of-type can hide every nth SVG rectangle or give every odd child a different stroke-dasharray.

That is a clever trick for a 2014 web page, and it is the part of the project most worth studying today.

Eight fixed styles against dozens of controllable WebGL scenes

The project page contains a table that compares the two projects directly, and it is the fastest way to understand what changed.

On rendering, Party Mode uses SVG via d3.js, while vizz.fm uses WebGL via Three.js. On visualizers, Party Mode has 8 fixed styles, named circle, chop, icosahedron, grid, equal, spin, hexbin and voronoi, while the current project has WebGL scenes with dozens of variants, each fully controllable. On audio input, the 2014 version takes a local MP3 by drag and drop or the microphone, and the current one takes files, the microphone, stream URLs, system audio and screen share. On effects, the original has CSS colour themes and the current one has over 30 stackable post-processing effects. On presets, the original has none and the current one can save locally and share by link. And on status, one is no longer maintained and the other is actively developed.

The eight named styles are worth pausing on, because they are a good illustration of what the data can be made to do. Each of them takes the same frequency array and draws something different with it, and the differences between them are entirely in the transformation and the drawing, not in the input.

For the successor, the visualizers expose their own controls for colour, speed, intensity and geometry, and the audio side has controls for gain, noise gating, bass attenuation and spectrum remapping. The post-processing list includes kaleidoscope, bloom, CRT, ASCII, pixelate, glitch and tilt-shift, and the whole thing runs full screen for capture in OBS with an option to pop the controls out into a separate window.

The practical difference for a user today is that the current version is a product and the 2014 version is a technique.

Running the 2014 code needs an HTTP server

There is one installation note in the original write-up and it is easy to miss.

There will be issues running this app locally without a server. The recommendation is to change into the directory and run http-server from the command line, and if you do not have that command, to install it like so:

npm install -g http-server

The reason is the browser's security model rather than the application. An HTML5 audio element and the Web Audio API do not behave when the page is opened from the file system, so the visualizer has to be served over HTTP even for a local test.

That is a small thing now and it was a small thing then, but it is the whole installation process for the project: one global npm package and one local command. There is no compile step to run, because Grunt was set up for the surrounding tooling rather than for a build the project needs.

For the visual check, the original write-up points at a working demo hosted at preziotte.com/partymode, and tells you to try dragging in an mp3 from your desktop. That drag and drop is still the canonical interaction: an audio file on disk becomes the analyser source, the analyser array becomes geometry, and the geometry is redrawn at animation rate.

The browser notes in the same passage are the other practical detail. The project was developed primarily in Chrome, WebKit seems to have the most competent implementation of SVG according to a link the author gives, and Chrome seems to play the nicest with the HTML5 audio element. The project also carries an epilepsy warning, which for a visualiser that flashes in time with music is a responsible inclusion rather than boilerplate.

The successor is not open source, and the licence split is explicit

The licensing situation is stated plainly in the project page, and it is not the usual arrangement.

Party Mode is open source under the licence below. vizz.fm is not currently open source.

So the code you can read, modify and reuse is the 2014 version, and the code you actually want to use today is closed. That is an unusual thing for a project to say about its own successor, and it is worth taking at face value rather than assuming the successor's repository will open up later.

There is a related asymmetry in what you can do with each. The 2014 project has a MIT-style header with the author and year in the source, and the repository's own licence field is listed as unknown in the repository metadata, so the terms of reuse are the ones in the LICENSE file rather than something the platform can classify. For vizz.fm, there is no licence to read, which means no rights to reuse, no rights to modify and no rights to redistribute the code, only the right to use the service.

For a person who wants to understand the technique, this arrangement is fine. The 2014 code is a complete, small, readable implementation of analyser data to SVG, and the write-up explains the approach in a page.

For a person who wants to ship a visualiser, the choice is between the closed successor and building something on the 2014 code, and those are very different amounts of work.

Audio sources and browsers decide what the successor can do

The successor's documentation is where the practical constraints are stated, and they are specific enough to plan around.

On audio sources, the answer is your microphone, local files in MP3, WAV, FLAC and other formats, stream URLs, or your system audio captured via screen sharing. Everything is processed in the browser, and no audio is uploaded to a server.

That last point is the one an engineer will care about. A visualiser that runs entirely client side has no bandwidth cost, no latency and no privacy question about what you are listening to.

The system audio capture has a browser limitation attached. In Chrome, Edge or Brave you can share audio from any application and the visualiser reacts to the direct feed of whatever is playing, with per-app guides for Spotify, YouTube, Apple Music, SoundCloud, Amazon Music and Tidal, and an OS level route documented through a virtual audio device.

On browsers, Chrome on Mac and Edge on Windows are described as the best experience, Firefox, Opera and Brave all work well, Safari has performance issues rendering WebGL, and only Chrome, Edge and Brave can capture system audio directly. On phones it works, though it is much better on a computer, because some visualizers are graphically intensive and benefit from a real GPU.

For streaming, DJing or a party, which is what the documentation says most people use it for, the OBS capture path and the system audio capture are the features that decide whether it works for you, and both have a documented browser requirement.

What to read, and what to run

The clearest way to describe this repository is as documentation that happens to contain code.

The preserved original write-up is the substance: a technique explained from first principles, with the honest note that the eight visual styles were arrived at by trial and error, the CSS theming trick that let an SVG-only visualizer look like a designed product, and the performance caveat that comes with redrawing vector geometry on every frame.

The comparison table and the successor documentation are the other half. They tell you what the state of the art looks like today, with WebGL instead of SVG, dozens of controllable scenes instead of eight fixed ones, thirty post-processing effects instead of CSS themes, and system audio capture instead of a dragged in mp3.

The stack the original project used is worth noting too, because it is a period marker. d3.js for the drawing, the Web Audio API for the analysis, Mousetrap.js for the keyboard shortcuts, jQuery because it made life easier, requestAnimationFrame with frame limiting for the render loop, and Grunt for the build. Nothing here is exotic, and the reason it was written that way is that the browser platform of 2014 offered no better primitives for any of it.

The one thing to avoid is treating the archive as a live project. The banner at the top exists to prevent exactly that, and the last push date on a repository whose product has moved elsewhere should be read the same way.

Editorial conclusion

Party Mode suits two kinds of reader: someone who wants to understand how a browser visualiser was built with the Web Audio API and d3.js before WebGL took over, and someone who wants to reuse or modify a small 2014 codebase. It is the wrong choice for anything you intend to run today, because the project itself redirects you to vizz.fm, and it is the wrong choice if you need system audio capture or shareable presets, neither of which existed in the original. Verify three things before you build on it: that the effects you want are CSS themes rather than post-processing, because that is all the 2014 version had, that the machine you target can handle SVG redraws at animation frame rate, and that the licence question is settled, because the project is open source while its successor is not.

Frequently asked questions

Official sources

1. Issues
2. preziotte/party-mode on GitHub
3. Project website
4. README
5. Releases