AI HARNESS ENGINEERING · ETHICS & CULTURE

Transcultural Machine Learning in Music

Most music AI quietly assumes a piano. What happens to the seven-note octave of Thai classical music, the gliding ornaments of Carnatic song, the Guqin? A lesson on building models that respect the world's many musics — and on when not to ship one.

Prerequisites: curiosity about music + a rough idea of "a model trained on data." No music theory or ML background assumed.
9
Chapters
7
Interactives
15 min
of data is enough

Chapter 0: Technologies Carry Their Makers' Borders

This lesson follows a reflection by Lamtharn (Hanoi) Hantrakul, a researcher whose path into machine learning ran through an unusual doorway. Before the models, there was wood. He spent a gap year apprenticing with luthiers in his home country of Thailand, learning to build traditional Northern Thai Salo fiddles — documenting, in his words, "how to chop coconuts and carve wooden pegs exactly like my ancestors did hundreds of years ago."

That hands-on root matters, because it gave him a lens most ML engineers never pick up. When he later turned to AI music tools, he noticed something quiet but profound: "new technologies are often applied within the cultural boundaries of their inventors." A tool built by people steeped in Western music tends to assume Western music — not out of malice, but because the assumptions are invisible to the people who hold them.

Here's the thing about an assumption baked into a tool: it doesn't announce itself. It just silently fails for everyone outside the boundary. A music model that "works" might work only for the slice of the world's music it was shaped around — and the vast, gorgeous remainder simply falls off the edge of what the tool can even represent.

Before any technical detail, let's feel the boundary. The widget below is a crude map of the world's musical diversity. The shaded region is what a typical "music AI" — trained on Western pop and classical — can actually handle. Drag to explore how much falls outside it.

What Falls Outside the Boundary?

Each dot is a musical tradition with its own tuning, ornaments, and instruments. The teal circle is roughly what a Western-trained model "speaks." Drag the slider to widen or narrow that boundary — and watch how many traditions sit just outside it, fully formed and centuries old, simply unrepresented.

Breadth of the model's training narrow (Western-centric)
The thesis in one line. The goal isn't to add other musics to a Western-shaped tool as an afterthought. It's to question the shape itself — to build, from the start, technologies that "empower cultural pluralism at every phase of engineering and design." Hantrakul calls this transcultural machine learning, and over the next chapters we'll see exactly where the cultural assumptions hide and how to design around them.
What does it mean that "new technologies are often applied within the cultural boundaries of their inventors"?

Chapter 1: A Tale of Two Tunings

Let's make the invisible boundary concrete with the most fundamental example: how you cut up an octave. An octave is the distance between a note and the next note that sounds "the same but higher" — double the frequency. Every musical tradition divides that span into a set of usable pitches. But how many, and where, is a cultural choice — not a law of nature.

Western music divides the octave into twelve equal steps — the black and white keys of a piano. It's so familiar it feels inevitable. But Hantrakul points to his own tradition: "In Thai classical music, the same octave is divided into seven pitches." Not seven of the Western twelve — seven equal divisions, which land between the piano's keys. A Thai melody literally lives in the cracks of a piano.

Now watch the consequence ripple into ML. A model that represents pitch as "which of the twelve keys" has the seven-tone system baked out of its very vocabulary. As Hantrakul notes, "many of these models thus cannot be applied to Thai melodies" — not because they're bad models, but because the representation itself can't express the notes. The cultural assumption hid inside something as low-level as how pitch is encoded.

Twelve Keys vs Seven — the Octave, Two Ways

The ring is one octave. Toggle between the Western 12-tone grid and the Thai 7-tone grid — notice the seven divisions fall between the twelve. Then play a melody: under "snap to 12-tone," watch a Thai-tuned note get forced onto the nearest piano key, bending it out of tune. That forced snap is the model's cultural blind spot, made audible.

Misconception — "the 12-tone system is just more precise / more complete." It isn't a superset. The Thai seven-tone divisions are genuinely different frequencies, not a subset of the twelve. Forcing them onto twelve keys doesn't "round" them — it mistunes them, the way translating a poem word-for-word can destroy its meaning. There is no neutral, universal pitch grid; every grid encodes a culture.
Why can many standard music models not handle Thai classical melodies?

Chapter 2: Fidular — Building the Idea in Wood First

Before Hantrakul built transcultural software, he built transcultural hardware. The project was called Fidular: "a modular and cross-cultural instrument fusing classic woodworking with modern 3D printing." It earned international design recognition — but more importantly, it's a perfect physical metaphor for everything that follows.

The idea: many cultures across the Asia-Pacific and Middle East have bowed fiddles — the Thai Salo, the Persian setar's cousins, and many more. They differ in their resonators (the body that amplifies the sound), their strings, their necks. Fidular made these parts modular and interchangeable, so a craftsperson could "quickly build a hybrid fiddle made from resonators and strings from across" these traditions. Mix a Thai resonator with strings from another tradition and a 3D-printed neck, and you get a genuinely new, genuinely cross-cultural instrument.

Why does a 3D-printed fiddle belong in a machine-learning lesson? Because Fidular embodies the design principle we're chasing: respectful interoperability. It doesn't melt traditions into a bland average; it keeps each part recognizably itself while letting them combine. That's the exact stance transcultural ML aims for — not a homogenized "global music model," but a toolkit where distinct traditions retain their identity and can meet on equal footing.

Assemble a Hybrid Fiddle

Pick a resonator, strings, and neck from different traditions and watch a hybrid instrument come together — each part keeping its own character. This is the physical version of the design goal: combine without erasing.

ResonatorThai Salo
StringsPersian
Neck (3D-printed)Chinese
The bridge to software. Fidular kept the woodworking and added the 3D printing — tradition and new technology, side by side, neither erasing the other. The question for the rest of this lesson is whether we can do the same in code: a machine-learning tool that honors a tradition's actual sound rather than flattening it into the nearest familiar shape. The answer turned out to hinge on a specific technique — DDSP.
What design principle does Fidular illustrate that carries over to transcultural ML?

Chapter 3: Why DDSP Is the Right Tool

Transcultural ML faces a brutal practical wall: data scarcity. The internet overflows with Western pop, but recordings of, say, the Shehnai — cleanly labeled, high quality, in volume — are rare. A data-hungry model that needs thousands of hours simply cannot be built for an under-represented tradition. The tool that needs the most data is exactly the wrong tool for the musics that have the least.

This is where DDSP — Differentiable Digital Signal Processing — changes the game. (We cover its mechanics in depth in the DDSP Veanor; here we just need its superpower.) Because DDSP bakes the physics of sound — oscillators, filters — directly into the model, the network doesn't have to learn what sound is from scratch. It only has to learn how a particular instrument shapes it. That makes it astonishingly data-efficient.

The numbers are the whole point. A DDSP model can be trained on as little as 15 minutes of recordings — the kind of small, commissioned dataset you can realistically gather for a tradition that isn't all over the web. And the resulting models are tiny: fast and lightweight enough to run in the browser, on-device, which also means the audio never has to leave the user's phone — a quiet privacy win. As Hantrakul puts it, "DDSP models thrive in low-data environments typical of underrepresented music."

Data Hunger vs. What a Tradition Can Provide

The teal bar is how much training audio a tradition can realistically supply (a commissioned session). The other bars are how much different model families demand. Drag the available data down to a few minutes — watch every data-hungry approach fall short while DDSP stays in reach. The technique you choose decides which musics you can even serve.

Audio a tradition can provide15 min
Concept → realization. Data-efficiency isn't a footnote here — it's the enabling condition for the whole project. The choice of DDSP over a giant autoregressive model is itself an ethical-design decision: it's what makes serving low-resource traditions possible at all. The right inductive bias doesn't just save compute; it decides whose music gets a seat at the table.
Why is DDSP especially well-suited to under-represented musical traditions?

Chapter 4: The Meend — Capturing What a Tradition Treasures

Tuning is only the first layer of cultural assumption. The next is ornamentation — the expressive gestures that are the music, not decorations on top of it. In Indian Carnatic music, the soul of a melody often lives in the meend: the continuous slides and "melodic twists and turns" that connect notes, bending pitch smoothly rather than stepping between fixed keys.

Here's the trap. A model built around discrete notes — "play key, hold, play next key" — treats a meend as noise or error to be cleaned up. It hears a glide and tries to quantize it into staircase steps, destroying exactly the gesture a Carnatic musician would call the heart of the phrase. The default representation doesn't just miss the meend; it actively fights it.

This is where DDSP's design shines for transcultural work. Because it controls a continuous fundamental frequency directly (not a piano-key index), it can follow a pitch curve exactly. Hantrakul's favorite demo in the Tone Transfer tool: take an Indian Carnatic singer and "re-render a Western concert flute to exactly follow the meend." The flute — an instrument with no native concept of Carnatic ornamentation — is made to speak the meend, because the system tracks the continuous pitch the singer actually produced.

Staircase vs. Slide — Draw a Meend

The dark line is a sung Carnatic phrase — gliding, continuous. Toggle "quantize to fixed notes" to see what a discrete-note model does to it: a staircase that loses the slides. Then drag on the canvas to draw your own meend and watch the continuous (DDSP-style) renderer follow it faithfully, while the quantized one mangles it.

The deeper lesson. "Capturing the ornamentation indigenous to a tradition" is a design requirement, not a nice-to-have. Whether your model represents pitch as discrete keys or a continuous curve decides whether an entire tradition's expressive vocabulary survives the trip through your software. The meend either lives or dies in your data representation — the same place the Thai seven-tone system lived or died in Chapter 1.
Why does a discrete-note model struggle with the Carnatic meend, and how does DDSP handle it?

Chapter 5: Sounds of India — Who Is the Audience?

Principles meet reality in deployment, and the Sounds of India project is where the transcultural stance got tested at scale — on millions of phones at once. Every choice in it was a design statement about respect.

First, the data. Rather than scraping whatever existed online, the team commissioned fresh recordings of three specific instruments — the Bansuri (bamboo flute), the Shehnai (a reed instrument), and the Sarangi (a bowed string instrument). Commissioning matters: it means consent, quality, and players from the tradition itself, rather than found data of murky provenance.

Second — and this is the subtle part — the intended audience. The models of Indian instruments "were aimed at local audiences familiar with their original sounds." That's a deliberate inversion of the usual default, where non-Western music is packaged as exotic novelty for a Western listener. Here the people most able to judge whether the Bansuri sounds right — people who grew up with it — were the primary audience. They are the quality bar.

Third, the framing. The team "launched the experience on Indian Independence Day in partnership with Prasar Bharti, India's public-sector broadcaster." The timing and the partner placed the tool inside the culture's own institutions and moments, as a celebration from within, not a product beamed in from outside.

1 · Commission
Fresh, consented recordings of Bansuri, Shehnai, Sarangi — players from the tradition, not scraped data.
↓ train tiny, data-efficient DDSP models
2 · Aim at the right audience
Designed for listeners who know the original sounds — they set the quality bar, not a Western ear.
↓ deploy on-device, to millions of phones
3 · Launch from within
Indian Independence Day, with Prasar Bharti — placed inside the culture's own institutions and moments.
Every default, reconsidered. Scrape → commission. Exotic novelty for outsiders → made for insiders. Generic global launch → a culturally specific moment with a local partner. None of these are technical choices — they're the process wrapped around the technology. Transcultural design lives as much in how you build and ship as in the model architecture.
What was notable about the intended audience for the Sounds of India models?

Chapter 6: Two Kinds of Bias — Where It Hides

We've seen cultural assumptions sneak in through tuning and ornamentation. Let's now name the two precise channels through which any ML system absorbs them. Hantrakul, drawing on his mentor Jesse Engel, splits bias cleanly in two:

Model bias
"Choices a researcher makes which encode properties about the data." Example: deciding pitch is one-of-twelve keys. The architecture itself assumes a worldview.
Dataset bias
"How the data was collected and its composition." Example: training on a corpus that's 95% Western pop. The data itself tilts the model.

The crucial, humbling point is that you cannot simply remove bias. As Engel puts it, "while these choices are essential to make a model work, they bake in limitations by definition." Every architecture encodes some assumption (you must choose a pitch representation); every dataset has some composition (you must collect something). Bias isn't a bug you patch out — it's an inherent property of having made any choices at all. The work is not to eliminate bias but to see it, name it, and choose it deliberately and responsibly.

This reframes the whole engineering task. Instead of chasing a mythical "neutral" model, you ask: which assumptions did I encode, whose music does my data represent, and are those choices ones I can stand behind? Naming the two biases is what turns invisible defaults into visible, accountable decisions.

Trace Where Each Bias Enters

Follow a tradition's music through the pipeline. Dial in model bias (how Western-centric your architecture's assumptions are) and dataset bias (how skewed your training data is). Watch the output drift away from the true tradition — and see that zeroing either dial alone isn't enough; both must be chosen with care.

Model bias (architecture assumptions)60%
Dataset bias (data skew)70%
Misconception — "a good engineer builds an unbiased model." There is no such thing — every representation and every dataset embeds choices. The honest, expert move is not to claim neutrality but to surface your assumptions: state what your model encodes and what your data contains, so the limitations are visible to you and to your users. Hidden bias is the danger; acknowledged bias is just engineering.
According to the lesson, what's the right goal regarding bias in a music model?

Chapter 7: The Guqin — Knowing When Not to Ship

The most important chapter in Hantrakul's reflection isn't about a model that worked. It's about one they chose not to release — and why that restraint is the deepest expression of transcultural design.

The team had trained a model on the Guqin, a revered Chinese zither with more than two thousand years of history and a profound place in Chinese classical culture. Technically, it worked. Then Hantrakul played it for a Chinese colleague — and her reaction, "a priceless mix of skepticism and aversion, made me reevaluate my position entirely."

The worry was specific and serious: "non-Chinese listeners hearing the Guqin for the first time through our technology could form incorrect impressions of the instrument and, in turn, Chinese classical music." A model is a compression of a tradition — necessarily lossy. If that lossy version becomes many people's first and only encounter with the Guqin, the compression artifacts become their mental image of an entire art form. So the team made a choice rarely celebrated in tech: "We decided not to open source these models in Tone Transfer."

The framing that justifies it is the heart of the whole lesson: "Like other artefacts of culture such as national anthems, fabrics and symbols, models are cultural distillations that should be treated with care and respect." A trained model isn't a neutral utility; it's a distilled representation of someone's heritage. Released carelessly, the same DDSP magic that empowers a tradition could enable "a new form of AI-powered cultural appropriation." The power to render any timbre is also the power to misrepresent it.

The Shipping Decision

Walk the decision the team faced. Adjust who hears the model first, how faithful it is, and how it's released — and see the risk of forming "incorrect impressions" rise or fall. Some regions of this space are where you don't ship, no matter how good the tech.

First exposure is to…unfamiliar listeners
Model faithfulness to the traditionrough
Release opennessfully open
Restraint as a feature. Engineering culture rewards shipping. This story rewards the opposite: a working model held back out of respect. "This level of technological-cultural sensitivity is paramount to ensuring we do not appropriate, cause cultural harm, or implant users with wrong expectations." Sometimes the most responsible output of a project is a model that stays in the lab.
Why did the team decide not to open-source the Guqin model, despite it working technically?

Chapter 8: Transcultural by Design

Let's gather the threads. Hantrakul distinguishes a deeper idea from mere cross-cultural borrowing — surface-level pollination, sampling an exotic sound into your track. Transcultural technology is more demanding: it "empowers cultural pluralism at every phase of engineering and design." Not borrowing at the end, but participation throughout — in the representation, the data, the audience, the release.

Trace how that played out across this lesson. The representation had to hold seven-tone tunings and continuous meend, not just twelve keys (Ch. 1, 4). The technique had to be data-efficient enough to serve low-resource traditions at all (Ch. 3). The data had to be commissioned with consent, the audience chosen as the people who know the real sound, the launch placed inside the culture's own institutions (Ch. 5). The bias had to be named and owned, not wished away (Ch. 6). And sometimes the most respectful move was not to ship (Ch. 7). Cultural care entered at every phase — that's what makes it transcultural rather than cross-cultural.

The cheat sheet — transcultural ML in seven moves.
  • Representation: can it express tunings/ornaments beyond 12-TET and discrete notes?
  • Technique: is it data-efficient enough for low-resource traditions? (DDSP: ~15 min.)
  • Data: commissioned and consented, from players of the tradition?
  • Audience: designed for people who know the original sound?
  • Bias: model & dataset assumptions named and owned, not hidden?
  • Release: would first-time listeners form a wrong impression? If so, reconsider.
  • Throughout: cultural participation at every phase — not borrowing at the end.

The reason this matters far beyond music: every one of these questions generalizes. Any ML system — for language, faces, names, law, medicine — carries its makers' boundaries, encodes model and dataset bias, distills something precious into a lossy artifact, and reaches an audience who may meet that subject through your tool first. As Hantrakul writes, "systemic themes of gender, race and cultural representation affect all areas of AI research." Music is just where the cultural assumptions are unusually audible.

Connections

The takeaway. Transcultural ML isn't a checklist you run at the end — it's a posture you hold from the first design choice to the decision of whether to release at all. The technology (DDSP) made it possible to honor traditions on little data. The care — in representation, data, audience, bias, and restraint — is what makes it right. "The context of a model's creation matters."

Press Teach Mode and explain, from memory, the two kinds of bias and why the Guqin model wasn't shipped. If you can defend that restraint as a design decision, you've understood transcultural ML.