Tapechild

Inside the Product.

The first version of this case study described Tapechild as an audio-plugin storefront. That was true, but it described only the visible edge of the work. Tapechild required engineering across the entire path from the audio thread to the customer account.

Shipkit worked on that system as a product platform rather than a website: real-time C++ and JUCE development, DSP research and implementation, production hardening, licensing and activation flows, commerce infrastructure, and the customer-facing product experience around the software. That combination is what makes Tapechild one of the more technically unusual Shipkit projects.

Two Products Engineered Together

Selling desktop audio software is a different problem from selling access to a web application, because the product runs inside environments we do not control: different DAWs, sample rates, audio buffer sizes, host automation behaviour, operating systems, and online or offline machines. At the same time the customer expects the purchase to feel like buying any normal digital product.

The audio product must sound stable, behave deterministically where required, save and restore state, automate parameters safely, and avoid unsafe work on the real-time thread. The commercial product must turn a payment into a legitimate entitlement, deliver the software, activate the customer's machine, manage seats, and remain usable when a studio computer is offline. A broken entitlement flow becomes a support problem for the plugin; a blocking license request becomes an audio problem. We treated those boundaries as part of the same engineering job.

UDS-16: Synthesis Rather Than Sample Playback

Tapechild UDS-16 was designed around synthesised drum voices rather than a static library of recorded hits, which changes the implementation significantly. A sample instrument largely plays back known audio; a synthesizer has to produce the event in real time from oscillators, noise sources, envelopes, filters, nonlinear stages and voice state — while remaining stable across host conditions.

Development covered circuit-inspired drum architecture, multiple synthesis models, voice behaviour, saturation, tape and reverb stages, oversampling choices, presets and production testing. The goal was not simply to make it vintage. It was to create a controllable software instrument with its own sonic identity while keeping the implementation technically defensible.

Measurement Built Into the DSP Process

Audio code can sound correct in one DAW session and still contain structural problems, so deterministic rendering and stress testing were part of development and audit work. The engine was evaluated across sample rates, host block sizes, oversampling settings, repeated renders, trigger timing, voice choke and retrigger behaviour, long tails and model changes.

That exposed the class of issues manual listening alone misses: behaviour accidentally tied to sample count rather than time, tails changing when a processing mode changes, host-block-dependent event behaviour, discontinuities during model switches, and state that resets when quality or oversampling changes. The point was not to replace listening — it was to make the implementation measurable enough that listening tests compared intentional behaviour rather than hidden host-dependent bugs.

A Clean-Room Stereo DSP Architecture

The work also included a production-oriented stereo micro-pitch and dimension processor implemented as a legally independent clean-room design: a smoothed Linkwitz-Riley crossover, low-frequency bypass around the widening engine, multiple continuously running stereo styles, variable-delay pitch processing, overlapping read heads, asymmetric stereo taps, controlled style crossfades, saturation and spectral shaping, deterministic slow drift, and four-point Lagrange delay interpolation.

Keeping style engines continuously available was a practical decision: switching a mode in a live plugin should not mean abruptly recreating an entire algorithm and producing a stale buffer, click or discontinuity. The DSP was also structured so style-specific calibration could be changed centrally instead of scattering magic numbers through the implementation, which made measurement and future tuning substantially safer.

That expanded into a broader stereo-memory processing concept with modular sections — Dimension for stereo spread, Motion for time and transport instability, Tracking for read-path instability, Generation for nonlinear media character, Afterimage for recursive delay and ghost structures, and Space for reverb — each measurable, bypassable, tunable and recallable on its own.

Real-Time Code Cannot Behave Like Application Code

A desktop application can wait briefly for a network request or allocate memory during an interaction. The audio callback cannot, and a missed real-time deadline becomes something the customer hears.

That constrains the design: no blocking network calls on the audio thread, no file operations in the critical processing loop, no dynamic allocation in the inner path, predictable buffers, prepared DSP state, safe parameter changes. It affected not only the DSP but licensing and UI communication with the processor — the plugin had to remain an audio instrument even while the rest of the application behaved like commercial software.

Sounding the Same Across Host Conditions

The same plugin may be instantiated at 44.1 kHz in one project and a much higher sample rate in another, with buffer sizes ranging from tiny low-latency blocks to large offline-render blocks. DSP written around implicit sample assumptions changes audibly under those conditions.

We treated sample-rate and block-size behaviour as production requirements. Envelope timing, modulation, event handling, nonlinear stages, smoothing and effect tails all had to be expressed and tested in a way that survives host variation.

Quality and Model Changes Need Transition Design

Oversampling and quality switches require internal processor reconfiguration, and a naive implementation simply resets the DSP graph. That is technically convenient and musically wrong if the user changes a setting while a long cymbal, delay or reverb tail is sounding. The difficult part is deciding what state must persist, what can safely be rebuilt, and where transitions need smoothing or crossfading.

A model selector is one UI control, but underneath it may exchange one nonlinear or stateful processor for another — producing clicks, discontinuities, abruptly cut tails, stale delay state or unexpected gain changes. For stereo algorithms, continuously running style engines and controlled crossfades avoid some of those transitions; for synthesis models the answer depends on voice state and what should happen to already-triggered sound. This is a DSP architecture decision, not a cosmetic UI detail.

Presets Are a Long-Term Compatibility Contract

Once users save projects with a plugin, parameter identity becomes part of the product. Renaming a knob is easy; changing the underlying parameter IDs, ranges, normalisation rules or state model can break old sessions.

We therefore treated parameter and state architecture as infrastructure: stable identities, controlled defaults, explicit value ranges, host automation behaviour, preset recall and module state. That gives future visual redesigns room to move without forcing the audio state to change with them.

Licensing Off the Audio Path, and Offline

A commercial plugin needs to know whether the user is entitled to run it, but the audio thread must never depend on whether a licensing server responds in 80 milliseconds or eight seconds. The activation architecture separates entitlement state from time-critical processing: commercial flows handle online activation, device and seat assignment, account state, offline activation and license refresh, while the processor consumes a safe local authorisation state.

Offline activation changes the entitlement model entirely. Music production machines are often deliberately kept off the internet, so a licensing system that assumes permanent connectivity creates friction for exactly the customers most likely to buy professional desktop audio software. That requires a verifiable exchange without a live session to the backend, raising questions about machine identity, signed activation data, replay and tampering, seat assignment, deactivation and support recovery — considered alongside online activation rather than bolted on afterwards.

A Successful Payment Is Not the End of the Transaction

For downloadable software, payment is only one event. The useful transaction is payment, entitlement, license, delivery, activation, usable product — and each step needs a clear owner and recoverable state.

If payment succeeds but license generation fails, the system should know what happened. If the customer signs in on another device, seat rules should be understandable. If an activation has to be recovered manually, the administrator needs enough state to support the customer. We connected the storefront and the licensing model so the commercial flow represented the real product lifecycle, with the website built around the same product language as the plugin itself.

Engineering and Marketing Had to Agree

Audio software is especially vulnerable to technically impressive but unsupported claims. Terms like circuit model, analog model, exact emulation and hardware recreation carry technical meaning.

Part of our DSP audit work was separating what the implementation could substantiate from what was only an inspiration or a design lineage. That discipline is commercially important: a stronger product story is one the engineering can actually defend.

The Result

Tapechild became more than a product website wrapped around a downloadable binary. The sound is produced by custom real-time code, the plugin behaves as a host-integrated product, the customer can buy it through a conventional checkout, that purchase becomes a software entitlement, the entitlement can be activated and managed, and the product supports studios that need an offline workflow.

For Shipkit, the case demonstrates that we can work below the browser. The engagement required product decisions at the level of individual DSP samples and at the level of customer accounts, payments and licenses — and those layers had to meet in one commercial product. A software studio can build an excellent marketing site and still be unable to ship the product being marketed; the release succeeds only when the storefront, the DSP and the licensing system all work together.

Tech Stack

C++20 and JUCE carry the audio layer — custom DSP modules, synthesis voices, variable-delay and pitch processing, nonlinear stages, oversampling and real-time parameter smoothing — validated by deterministic offline rendering with sample-rate, host-block-size, event-timing and state-transition tests over centralised DSP calibration. The plugin ships as VST3, Audio Unit and Standalone with host automation, preset and state recall, meters and an advanced module UI, while Stripe, customer authentication, generated licenses, online and offline activation, and seat management carry the commercial side.