DARK TR0JAN: Building a Website Around a Live Music System
How I developed an animated music platform that connects my creative work, social content, equipment catalogue, and live performance system.
- Role
- Design and frontend development
- Context
- Personal music and performance platform
- Core stack
- React · TypeScript · Vite · Firebase

- 6 routes
- Structured content
- 2 feeds
- Automated social content
- Static
- Production delivery
Homepage, artist, system, control, visuals and privacy
YouTube and Instagram refreshed outside the browser
Cached assets deployed through Firebase Hosting
On this page
DARK TR0JAN began as a home for my music production hobby, but the website grew with the project. It now has to introduce the artist identity, bring together content from several platforms, document an evolving live-performance rig, and still feel distinctive enough to belong to the music.
That made it more than a promotional landing page. I treated it as a product with its own content architecture, data-refresh pipeline, motion system, accessibility decisions, and deployment process.
The brief#
The initial requirement was simple: create one place where people could discover my YouTube videos, Instagram loops, Twitch performances, equipment and musical background. The more interesting requirement was emotional. The site needed to feel like DARK TR0JAN rather than a generic portfolio with different colours.
I set four design goals:
- Establish the identity quickly through the Trojan logo, video, typography and a restrained cyan-and-purple visual system.
- Keep media current without exposing API credentials or making every visitor wait for third-party services.
- Explain the performance rig clearly to musicians who might want to understand or recreate parts of the setup.
- Use ambitious motion responsibly so the experience remains usable on mobile devices, lower-powered hardware and reduced-motion configurations.
How the site evolved#
The earliest version behaved like a conventional single-page portfolio. That worked while the content was shallow, but the performance setup and artist story soon needed more space than a homepage section could provide.
I kept the homepage as the visual introduction and divided the deeper material into dedicated routes:
- The Artist Story explains the progression from piano and Cubase into hardware production and live looping.
- The Performance System provides the main audio, MIDI and control overview.
- Software and Signal Routing documents the Ableton, ClyphX, Bome and MIDI-control layer.
- Cameras and Synced Visuals covers Loopy Pro, camera feeds and the visual-performance workflow.
- A separate privacy route supports consent-aware embedded content.
This change made navigation a content-design problem as well as a UI problem. Desktop dropdowns expose the deeper pages without crowding the main bar, the active state follows the current route or homepage section, and the mobile menu presents the same hierarchy in a touch-friendly form.
Frontend architecture#
The production site is a static React application. React Router handles the route structure, Motion coordinates interface animation, and Embla provides the media carousels. Vite compiles the application for Firebase Hosting.
| Area | Production technology | Responsibility |
|---|---|---|
| Interface | React 19.2.8 and TypeScript 5.9.3 | Component structure and type-safe application code |
| Routing | React Router DOM 7.18.1 | Homepage, story, system and privacy routes |
| Motion | Motion 12.42.2 | Coordinated entrances, transitions and interactive feedback |
| Styling | Tailwind CSS 3.4.19 and custom CSS | Responsive layout and the neon visual language |
| Media UI | Embla Carousel and Intersection Observer | Auto-scrolling panels, visibility control and edge treatments |
| Build and delivery | Vite 6.4.3 and Firebase Hosting | Static production output, CDN delivery and SPA rewrites |
Inter, Space Grotesk and Roboto Mono are hosted locally. Social images are also copied into the project during its refresh process. This reduces dependence on third-party assets during a visit and helps keep the visual result predictable.
The intro and hero#
The opening animation turns the logo into part of the navigation rather than showing an unrelated loading screen. The same SVG Trojan mark is drawn in the centre, held briefly, and then moved towards the measured position of the navigation logo. Once docked, the main interface takes over.
The intro runs once per browser session and is skipped when the visitor prefers reduced motion. That balance was important: the sequence creates identity on a first visit, but repeating it on every route change would make the interface feel slow.
Behind it, the hero combines a video background, animated title, short introduction, social links and a primary route into the content. As the visitor scrolls, the hero is progressively covered and darkened rather than simply disappearing. The video pauses when it is outside the viewport or when the document is hidden, avoiding work that cannot be seen.
Navigation as an interaction system#
The floating navigation bar became one of the most technically detailed components. It includes:
- active states for both routes and homepage sections;
- desktop dropdowns for the artist and system content;
- a compact mobile navigation pattern;
- a waveform-style shortcut into the media section;
- a cyan-to-purple edge glow that responds to pointer proximity; and
- scroll and pointer updates coordinated through animation frames.
These details make the navigation feel integrated with the visual identity, but each has a practical job. Visitors can see where they are, reach the long-form system pages quickly and use the same information architecture on touch devices.
A safer social-content pipeline#
An earlier approach fetched social content from the browser. That coupled page speed and reliability to external APIs, exposed more implementation detail to the client, and would have made quota management harder.
The current site refreshes content ahead of time instead:
The refresh script retrieves the latest YouTube and Instagram data during GitHub Actions runs, normalises it, processes remote images into local WebP assets with Sharp, and writes static JSON for the frontend. YouTube refreshes through its data API, while Instagram data is collected through Apify.
The pipeline preserves the last known good data when a provider fails. That means a temporary API problem does not leave an empty section on the live site. It also keeps credentials out of the browser and gives quota usage a predictable relationship with scheduled builds rather than visitor traffic.
On the homepage, YouTube and Instagram appear as separate carousel panels. They use consistent card heights, directional entrances, edge fades and clear channel links. Auto-scroll pauses on interaction, keyboard focus remains visible, and Intersection Observer prevents inactive carousels from doing unnecessary work.
Twitch is handled differently. Schedule information can be presented directly, while the live embed is only loaded after the visitor provides the relevant consent. This keeps the default page lighter and gives visitors control over third-party content.
Turning a gear list into system documentation#
The equipment section started as a catalogue and developed into two complementary views.
The homepage remains useful for discovery. Visitors can filter gear by category and open accessible modal reviews containing ratings, strengths and limitations. The catalogue includes the instruments and infrastructure that shape the current setup, such as the Yamaha Montage, MPC Key 61, Korg Wavestate, mioXL MIDI interface, paired Quantum HD 8 interfaces, Mac, iPad, monitors and microphones.
The performance routes explain how those individual products become one system. Rather than presenting a single diagram without context, they separate:
- physical audio and MIDI connections;
- Ableton Live control through ClyphX and Bome;
- Auracle X and mioXL routing;
- Loopy Pro control and loop capture;
- camera and Resolume visual workflows; and
- Keysight measurement equipment used during configuration and testing.
This is more valuable than a simple equipment inventory because it documents decisions, relationships and responsibilities. Someone can understand why an item exists in the rig and what would be affected if it changed.
Artist story and visual continuity#
The Artist Story gives the technical material a human context. It follows the route from a Yamaha P-515 and Cubase-based setup towards live looping, an RC-505, the MPC Key 61 and the current Ableton-centred system.
The homepage About area now acts as a visual gateway to this story and the performance documentation. Laser borders, star fields, a Hans Zimmer quotation and a black-hole footer carry the same visual language through the transition. As with the hero, video and animated background effects are paused when they are no longer visible.
Performance and accessibility#
Animation-heavy sites can become impressive on the developer's computer and frustrating everywhere else. I therefore built a shared adaptive-effects decision around signals including:
- the visitor's reduced-motion preference;
- browser-reported logical processor count;
- available device-memory information where supported; and
- the data-saving preference.
The application can reduce decorative work when those signals indicate that full effects are inappropriate. Routes and substantial homepage sections are lazy-loaded, off-screen animations are paused, touch interactions have dedicated controls, and dialogs restore focus correctly.
Other small decisions also matter: the scrollbar remains stable between routes, local assets reduce layout surprises, edge fades make horizontal content boundaries clear, and visible focus states are retained throughout interactive areas.
Deployment, caching and security#
The deployment workflow runs from the master branch:
- install the locked dependencies;
- refresh social data and local media;
- build the Vite application; and
- deploy the resulting static files to Firebase Hosting.
A separate scheduled workflow can refresh social data without waiting for a feature release. Hashed application assets receive long-lived cache headers, while changing JSON content is served with a revalidation strategy so new posts can appear promptly.
The hosting configuration also sets a Content Security Policy, Referrer Policy, X-Content-Type-Options and Permissions Policy. Firebase rewrites application paths to the SPA entry point so direct visits to the artist and system routes work correctly.
Problems that changed the implementation#
Too many competing motion systems#
Combining several approaches to scroll and entrance animation created lifecycle, focus and rendering problems. Consolidating motion behaviour made it easier to reason about what should run, when it should stop, and how reduced-motion behaviour should work.
External services are not a dependable runtime database#
YouTube and Instagram are useful content sources, but a visitor should not receive a broken page because one of them is slow or unavailable. Moving refresh work into automation and retaining cached data produced a much more resilient boundary.
Visual effects need ownership#
Video, stars, carousels and pointer effects each need an explicit lifecycle. Observing visibility and document state made the site calmer for the browser without removing the visual result when it matters.
Detail creates trust#
Focus restoration, clear dividers, carousel edge fades, active navigation and a stable scrollbar are small individually. Together, they make a highly styled interface feel intentional rather than fragile.
What I would improve next#
The current site is a strong base, but the content and rig will continue to change. My next priorities are:
- replace the remaining placeholder or lower-resolution gear photography;
- keep signal-flow documentation synchronised with the physical rig;
- expand the camera and performance-visual material;
- monitor the social refresh integrations as provider behaviour changes; and
- continue performance and cross-browser testing on real devices.
Conclusion#
DARK TR0JAN became a useful lesson in building around real subject matter. The React interface matters, but the strongest parts of the project came from understanding the content: how somebody discovers the music, how a live rig should be explained, when motion adds identity, and where automation can make an external integration more dependable.
The result is both a music platform and living technical documentation. It gives my creative work a coherent home while demonstrating frontend architecture, responsive interaction design, API integration, build automation, accessibility and performance-aware animation.