HOP is a musical connection visualizer for Scylfe, developed in collaboration with RTMKR. Its core principle: to take collaborations between artists—those moments where two distinct musical worlds collide for a single track—and transform them into an interactive, explorable, and dynamic map. Behind a deliberately minimalist interface lies a technical architecture designed for simplicity, speed, and scalability.
The central idea of HOP is that each collaboration creates a measurable link between two artists. These links, aggregated across an entire discography, form a network. And this network, visualized as a graph, reveals structures invisible to the ear: the pivots between scenes, the bridging artists, the stylistic clusters.
HOP offers three modes for exploring this network. The Explorer displays the interactive graph of an artist and their collaborators. The Chain automatically links collaborations one after another, like channel surfing guided by real-world connections. The Index allows alphabetical navigation to any artist in the database.
The first major question was storage. A relational database (MySQL, PostgreSQL) would have been the natural choice for managing relationships between entities. We deliberately ruled out this option for three reasons.
A flat-file project is deployed by copying files. No database server to configure, no migrations to manage, no credentials to secure. The entire project—data included—fits in a single folder. This is a tangible advantage for maintenance, backups, and hosting migrations.
Data that changes little and often in batches
The featured artists don’t update in real time. HOP’s database evolves through occasional additions—new artists, new collaborations—rather than continuous modifications. This batch writing pattern is precisely what flat files excel at: you update the CSV files, regenerate the cache, and that’s it.
Rather than querying a database with each request, HOP compiles all the data into a single JSON file at the time of the update. Reads are then simple file accesses—virtually instantaneous, without an internal network connection, and without SQL queries to parse.
HOP: From raw data to interactive graph
- CSVs as a source of truth : Each CSV file contains lines in the format: artist, partner, title, album, link, details. An artist can appear in multiple files. The structure is intentionally simple to facilitate manual or scripted contributions and updates.
- Compilation to cache.json : Every time a CSV file is modified, the caching engine recompiles all the data. The logic is symmetrical: if A collaborated with B, then B also appears in A’s connections. This symmetry is calculated at compile time, not read time, which avoids any redundancy in the source CSVs.
- The cache is intelligently invalidated : a comparison of the timestamps between the CSVs and the cache.json file determines whether recompilation is necessary. If the cache is more recent than all the CSVs, it is served directly.
- The local API : The cache.json file is exposed via a minimal PHP endpoint that supports two actions: listing all artists and the connections of a given artist. Server-side PHP pages read the cache directly from disk—without any HTTP round trips. Only the browser uses the API for dynamic graph expansions.
The viewer: a force-directed graph on HTML5 canvas
The Explorer is the most complex component of HOP. It relies on a force-directed graph drawn on an HTML5 canvas element, without any external visualization libraries. Everything—physics, rendering, interactions—is written in native JavaScript.
- Physical simulation : Each node is subject to three forces: a repulsion between all nodes (to avoid overlaps), an attraction along the edges (to group nearby collaborators), and a slight attraction toward the center (to keep the graph readable). These forces are calculated every frame for the first 400 iterations, after which the graph stabilizes.
- Adaptive rendering : The size of each node is proportional to its degree—the number of connections. The color ranges from light gray (few features) to black (many). The central node is always black and slightly larger. This visual scale allows for the instant identification of key artists within the network.
- User journey mapping : Each clicked node is added to a navigation path. This path is drawn over the graph: in olive green if a real connection exists between two consecutive steps, in burgundy if the user has jumped to an artist without a direct link. This provides an immediate way to distinguish coherent traversals from free explorations.
- Gradual expansion : The graph doesn’t load everything at once. It starts with the connections of the central node, then expands on demand: clicking on a node triggers the fetching of its own connections, which are dynamically integrated into the existing graph. The new positions are initialized around the parent node and stabilize through physical simulation.
The Chain: a passive, data-driven experience
The Chain is HOP’s simplest mode, but no less interesting. It selects an eligible artist (with at least three distinct partners), chooses a random feature from those not yet played in the session, displays the track, and moves on to the next artist after a configurable delay.
The session is managed server-side via PHP sessions. The page automatically reloads using a meta refresh tag—a deliberately simple choice, without WebSockets or JavaScript polling. The server is stateless between reloads: all the context is contained within the session.
The chain ends when all available features for the current artist have already been played, or when it loops back to the starting artist. A new chain then starts from a random artist.
HOP is designed to be generic. The data structure—artist, partner, track, album, link—doesn’t presuppose any musical genre. Adding a new scene is as simple as placing new CSV files in the source folder and regenerating the cache. No migration, no schema to modify.
The goal is to gradually expand the database to other genres and languages, while maintaining the same interface and philosophy: no algorithms, no opaque recommendations—just real connections, made visible.
