免费在 GitHub 公开

audio-math-explainer

Explains DSP math concepts to developers who need the theory behind an algorithm. Use whenever the user asks how a signal-processing concept works, wants intuition behind a formula, or hits a math-shaped bug. Trigger on phrases like "how does a Fourier transform work", "explain z-transforms", "what is convolution", "why does my biquad ring", "what is windowing for", "what causes aliasing", or "how do I convert gain to dB". Also trigger when the user pastes DSP code and asks why it behaves a certain way.

中文简介正在准备中。当前显示原文说明。

kunitoki/sonic-skills

查看安装方法

包含的文件（2）

SKILL.md3.2 KB
references/dsp-math-reference.md7.9 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Audio Math Explainer

The rule: DSP math is small and composable — each concept builds directly on the last. Start with what the user needs, then connect it to code they're writing.

Step 1 — Identify the concept

Topic	Core idea	Common "why"
Fourier transform / DFT / FFT	Decompose signal into frequency components	"Why does my FFT output look wrong?"
Convolution	Weighted moving average; LTI system response	"How does an IR reverb work?"
Z-transform	Frequency-domain analysis of discrete systems	"How do filter poles/zeros work?"
Biquad / IIR filters	Recursive difference equation with feedback	"Why does my filter ring / go unstable?"
FIR filters	Non-recursive weighted sum	"How do I design a linear-phase filter?"
Windowing	Reduce spectral leakage in DFT	"Why are FFT edges smeared?"
Sample rate / Nyquist	Highest representable frequency = sr/2	"What causes aliasing?"
Decibels	Log scale for amplitude/power ratios	"How do I convert gain to dB?"

If the user's question maps to multiple rows, start with the most fundamental one and build up.

Step 2 — Explain with three anchors

For each concept, give exactly these three things in order:

Intuition — one sentence a musician could understand
Math — the key formula (inline, no walls of derivation)
Code — one-line pseudocode or a real function call from common audio libraries

Keep each anchor to 1–3 lines. Cut anything that doesn't directly answer the question.

Step 3 — Connect to the user's code

After the three anchors:

Locate where the math appears in their implementation (coefficient calculation, loop structure, buffer size choice, etc.)
Name the exact variable or line where theory becomes code
If a value looks wrong, explain which part of the math it violates

Quick connection table

Math concept	Where it shows up in code
DFT basis frequencies	`bin_index * sr / N` — each FFT bin
Convolution sum	FIR tap loop: `y[n] = sum(h[k] * x[n-k])`
Z-plane pole radius	IIR feedback coefficients `a1`, `a2`
Nyquist limit	`if (freq > sampleRate / 2) clamp(...)`
Window function	Multiply `x[n] *= window[n]` before FFT
dB conversion	`gain_db = 20 * log10(amplitude)`

Output format

### [Concept name]

**Intuition:** [one sentence]

**Math:** `[formula]`

**Code:** `[one-liner]`

**In your code:** [where this appears and what it means for their specific question]

See references/dsp-math-reference.md for full formula tables, gotchas, and property lists.

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能

au-review

免费

Reviews AudioUnit v2/v3 plugin implementations for spec compliance, thread safety, and correctness. Use when the user asks to review an AudioUnit plugin, check an AUv3 app extension, audit property or parameter handling, or asks "is my AUComponent thread-safe?" or "why does my AU crash in Logic?". Trigger on phrases like "review my AudioUnit", "check my AUv3", "is my render block safe?", or when you see AURenderCallback, internalRenderBlock, kAudioUnitProperty_*, or AUAudioUnit in the code.

中文简介正在准备中。当前显示原文说明。