These Aren't Translations

When you learn a human language, you don't just memorize word for word translations. You learn to think in that language: its idioms, its grammar, its ways of structuring ideas that don't map 1:1 to your native tongue.

The documents that follow work the same way. They don't tell you "in Pure Data you use [metro], in MayaFlux you use Kriya::metro." That's missing the point.

They tell you: "Pure Data taught you that time is discrete ticks at control rate. MayaFlux asks: what if time is just another processing precision you choose, like sample rate or frame rate or whatever computational resolution your idea requires?"

The shift isn't about syntax. It's about possibility space.

What You're Actually Unlearning

Every tool you've used made architectural decisions that became invisible to you:

Pure Data: Separated audio rate from control rate because that's how analog hardware worked. Digital computation has no such boundary.

SuperCollider: Separated the language from the server because network audio was the goal. Your code doesn't need that boundary.

p5.js: Made you clear and redraw every frame because that's how display hardware worked in 1985. Modern GPUs process data pipelines, not draw calls.

openFrameworks: Built on OpenGL because that was the graphics API available. OpenGL is deprecated. Your creative ideas aren't.

Max/MSP: Made everything visual because WYSIWYG was revolutionary in 1988. Text is actually more precise for complex logic.

None of these were wrong choices. They were brilliant solutions to the constraints of their time.

But you don't have those constraints anymore.

MayaFlux doesn't exist because those tools are "bad." It exists because computational substrate has evolved, and new paradigms become possible when you're not maintaining backward compatibility with architectures from decades ago.

This Is About Mental Models, Not Features

You don't need to "learn MayaFlux" before reading these. You need to be willing to question assumptions you didn't know you had.

When Pure Data made you think "audio and control are different domains," that became invisible. It's just "how things work." These documents make those invisible assumptions visible, then ask: "is that actually true, or just true for Pure Data?"

When SuperCollider made you write SynthDefs that got sent to a server, that separation became natural. "Of course synthesis happens on the server, control happens in the language." These documents ask: "what if everything just... runs where you write it?"

When p5.js made you write a draw() loop, that became "how graphics work." These documents ask: "what if you never draw anything, and instead define how data should flow to the GPU?"

The "features" are just consequences of different mental models.

Once you see why your current tools work the way they do, and recognize that those reasons were historical accidents, not computational laws, the MayaFlux API becomes obvious. You're not memorizing a new syntax. You're thinking in a paradigm where those old boundaries don't exist.

How to Read These

Pick the tool that shaped your thinking the most. Not the one you're "most expert" in. The one whose patterns feel most natural to you.

That's the tool whose assumptions are most deeply embedded in how you think about creative computing.

Read that document. Not to memorize mappings, but to watch your own assumptions surface and dissolve.

You'll recognize patterns: "oh, I always thought X was necessary because..." And then you'll see: "...but that was just Y's architecture, not a computational requirement."

That moment: that's what these documents are for.

Once you've had it, the MayaFlux API isn't something you "learn." It's something you recognize as the obvious way to express ideas you already had but couldn't fully articulate in tools that weren't built for them.

You Already Know How to Do This

Every creative practitioner does this constantly.

A painter trained in oil learns watercolor: not by finding "oil equivalents" in water based media, but by recognizing which techniques were paint specific and which were about light, form, composition.

A jazz musician learning classical doesn't just "translate" their improvisational vocabulary. They recognize which patterns were jazz specific (call and response, swing feel) and which were music universal (harmonic progression, melodic contour).

You already know how to distinguish tool specific patterns from domain truths.

These documents just make that process explicit for creative computation.