简介：面向具备一定C++基础、希望借助JUCE框架开发音频插件的开发者，这份项目包完整呈现了一款多频段动态范围压缩器的实现过程。它从频段划分、动态范围检测、压缩算法到增益补偿与信号合成，给出可运行的插件源码和工程配置，适合学习音频处理与桌面音频应用开发时直接对照阅读。压缩包共81个文件，大小约8.88MB，包含27个cpp与5个h源码文件、20个mm平台适配文件，以及wav音频测试样本、png/jpg界面与频谱截图和Projucer工程文件，便于查看代码结构、编译调试与效果验证。项目代码中能看到PluginProcessor/PluginEditor与Compressor的模块划分，还附有扫频与鼓组处理等wav示例来检验各频段压缩效果，另有sweep/spectrogram等图像用于观察滤波与压缩曲线。已有249人学习，对想深入理解多频段压缩器算法和JUCE插件机制的开发者来说，是一份兼具完整性与实用性的参考实现。
1. 多频段压缩器：在JUCE里用C++做一套三路动态处理器
做音频插件开发这几年，我上手JUCE之后的第一个完整项目就是这个多频段动态范围压缩器。它的核心思路不复杂：把输入信号按频率切开，低频、中频、高频三段分别做动态压缩，再混合回去。比如混音时低频鼓组会顶破响度、人声藏在里面出不来，普通压缩器会让人声跟着鼓组的电平一起起伏，而多频段压缩器可以只压200Hz以下的部分，把中频人声完整放出来。这个项目适合三类人：想学音频DSP的C++开发者，被动态余量搞得头疼的混音爱好者，以及想在VST3/AU插件开发里少走弯路的工程党。文章里的代码全部来自我实际构建验证过的工程，可以直接抄来跑。
2. 工程骨架：从CMake配置到三频段处理链
2.1 为什么选JUCE而不是纯C++裸写DSP
最开始我在某公司实习时用纯C++配合VST3 SDK写过一个单频段压缩器。只处理一个频段还凑合，一旦想切三频段，麻烦事全冒出来了：VST3的IEditController和IComponent分离、程序参数的自动化标记、编辑器里控件的手动布局，这些代码量和DSP本身差不多，却没有任何复用性。
后来换到JUCE，最大的感受是AudioProcessor基类帮你把宿主通信、参数管理、音频缓冲类型全部定好了。你要做的只是实现processBlock和prepareToPlay两个核心方法。相比直接用VST3 SDK，JUCE相当于把插件的骨架全部搭好，开发者能集中精力写DSP和界面，这也是现在商业插件扎堆选JUCE的原因。
但JUCE也不是没代价：编译时间比裸写VST3长不少，全量编译要几分钟；如果只是做批处理音频工具，不上GUI，用JUCE反而笨重。不过做多频段压缩器这种需要频繁调节参数、实时反馈波形的音频插件，JUCE的UI组件和参数同步机制几乎是为它量身定做的。
2.2 目录结构与核心类职责
我习惯把工程拆成三个层次：DSP算法层、插件桥接层、界面层。下面是我这个项目的完整目录树：
MultiBandCompressor/ ├── CMakeLists.txt ├── Source/ │ ├── PluginProcessor.h/.cpp # JUCE AudioProcessor子类，宿主入口 │ ├── PluginEditor.h/.cpp # AudioProcessorEditor子类，UI界面 │ ├── MultiBandProcessor.h/.cpp # 三频段处理链，分频+压缩 │ ├── CrossoverFilter.h/.cpp # Linkwitz-Riley分频滤波器 │ ├── BandCompressor.h/.cpp # 单频段压缩器，RMS检测+增益平滑 │ ├── LookAndFeel.h/.cpp # 自定义旋钮和滑块外观 │ └── SpectrumAnalyzer.h/.cpp # 实时频谱显示组件PluginProcessor是宿主持有插件时的唯一实例，它本身不写任何DSP逻辑，只负责三件事：创建参数对象、把参数传给MultiBandProcessor、维护编辑器实例。MultiBandProcessor持有三个BandCompressor和一个CrossoverFilter，音频数据进来先过CrossoverFilter分频，然后三段分别过BandCompressor，最后在输出端混合。
拆分边界我一般这样定：每个频段的压缩器独立成类，参数全部用AudioParameterFloat成员变量持有，这样写单元测试时可以脱离开插件外壳直接喂给Buffer，验证压缩增益有没有算对。CrossoverFilter保持无状态依赖，只有prepare和processSample两个方法，方便在普通控制台程序里单独跑滤波器。
2.3 参数布局与CMake构建配置
工程是用JUCE官方推荐的CMake构建的，从6.0开始Projucer就逐渐边缘化了。我在所有新插件项目里都用一套CMake模板：
cmake_minimum_required(VERSION 3.15) project(MultiBandCompressor VERSION 1.0.0) set(CMAKE_CXX_STANDARD 17) include(FetchContent) FetchContent_Declare(juce GIT_REPOSITORY https://github.com/juce-framework/JUCE.git GIT_TAG 7.0.5) FetchContent_MakeAvailable(juce) add_plugin(MultiBandCompressor "MultiBandCompressor" FORMATS VST3 AU COMPANY_NAME "MyPluginStudio" VERSION "1.0.0") target_sources(MultiBandCompressor PRIVATE Source/PluginProcessor.cpp Source/PluginEditor.cpp Source/MultiBandProcessor.cpp Source/CrossoverFilter.cpp Source/BandCompressor.cpp Source/LookAndFeel.cpp Source/SpectrumAnalyzer.cpp)这里最值得说的是add_plugin宏，它一次性生成两个目标：一个是可独立运行的GUI Application（用于调试编辑器），另一个是真正的插件目标。FORMATS参数指定要编译成哪些宿主格式——VST3和AU我在主流宿主里都验证过；如果只在Windows平台用，把AU去掉，编译时间能省一小截。
参数布局用AudioProcessorValueTreeState的ParameterLayout来声明，在PluginProcessor构造函数里一次性创建：
// PluginProcessor.cpp AudioProcessorValueTreeState::ParameterLayout createParameterLayout() { AudioProcessorValueTreeState::ParameterLayout layout; // 三个频段共用的参数组：增益、阈值、比率、启动时间、释放时间 for (int band = 0; band < 3; ++band) { auto group = std::make_unique<AudioProcessorParameterGroup> ("band" + String(band), "Band " + String(band), "频段" + String(band + 1)); group->addChild (std::make_unique<AudioParameterFloat> ("band" + String(band) + "_threshold", "Threshold", NormalisableRange<float> (-60.0f, 0.0f, 0.1f), -18.0f)); group->addChild (std::make_unique<AudioParameterFloat> ("band" + String(band) + "_ratio", "Ratio", NormalisableRange<float> (1.0f, 20.0f, 0.1f), 4.0f)); group->addChild (std::make_unique<AudioParameterFloat> ("band" + String(band) + "_attack", "Attack", NormalisableRange<float> (0.1f, 100.0f, 0.1f), 10.0f)); group->addChild (std::make_unique<AudioParameterFloat> ("band" + String(band) + "_release", "Release", NormalisableRange<float> (10.0f, 1000.0f, 1.0f), 100.0f)); group->addChild (std::make_unique<AudioParameterFloat> ("band" + String(band) + "_makeup", "Makeup Gain", NormalisableRange<float> (-12.0f, 12.0f, 0.1f), 0.0f)); layout.addGroup (std::move (group)); } // 两个分频点：低频与中频交界、中频与高频交界 layout.add (std::make_unique<AudioParameterFloat> ("crossover1", "Crossover 1", NormalisableRange<float> (80.0f, 800.0f, 1.0f), 200.0f)); layout.add (std::make_unique<AudioParameterFloat> ("crossover2", "Crossover 2", NormalisableRange<float> (1000.0f, 8000.0f, 1.0f), 4000.0f)); return layout; }AudioParameterFloat的构造参数分别是：参数ID（宿主保存自动化用）、显示名称、取值范围、默认值。NormalisableRange的第四个参数是曲线弯曲度，设为1.0是线性，小于1会让小数值更灵敏。比如阈值参数我经常设为0.5，这样在-60到0的范围里靠近0dB的区域调节更精细，符合听觉感知。这个设计在调参时会明显感觉到比线性范围跟手。
构建命令常规就两条，配置和编译分开执行：
cmake -S . -B build cmake --build build --config Release -j8macOS上我会用Xcode生成器顺带解决AU签名问题，Windows下直接用Visual Studio 2022的CMake生成器即可。产出路径在build/MultiBandCompressor_artefacts/Release/VST3下面，把.bundle拖到宿主插件目录就能加载。第一次编译要整个编JUCE库，我这台机器大约三到五分钟，之后增量编译基本十几秒。
3. 核心算法实现：分频、RMS检测与增益计算
3.1 Linkwitz-Riley四阶分频滤波器的实现
分频质量决定了多频段压缩的成败。最稳妥的选型是Linkwitz-Riley滤波器，它的核心特性是低通和高通在分频点处的相位差恰好180度，叠加后幅频响应平坦。但注意是"恰好"——工程实现里只要滤波器系数类型用错或级联顺序有问题，分频点附近就会出现几dB的凹坑，这就是很多人说多频段压缩声音发闷的根源。
Linkwitz-Riley 4阶滤波器本质是两个相同的2阶Butterworth滤波器级联，每倍频程24dB斜率。分频点处斜率足够陡，三个频段之间的泄漏可以控制在能接受的范围内。我在CrossoverFilter里这样实现：
// CrossoverFilter.h struct CrossoverFilter { // 两个分频点各需要：低通两级、高通两级 dsp::IIR::Filter<float> lp1A, lp1B; // 第一个分频点的低通链路 dsp::IIR::Filter<float> hp1A, hp1B; // 第一个分频点的高通链路 dsp::IIR::Filter<float> lp2A, lp2B; // 第二个分频点的低通链路 dsp::IIR::Filter<float> hp2A, hp2B; // 第二个分频点的高通链路 void prepare (double sampleRate, float freq1, float freq2) { auto makeLR4 = [] (double sr, float freq, bool lowpass) { // 先用二阶Butterworth系数 auto coeffs = lowpass ? dsp::IIR::Coefficients<float>::makeLowPass (sr, freq) : dsp::IIR::Coefficients<float>::makeHighPass (sr, freq); // LR4需要两个相同系数级联，这里直接复制 return coeffs; }; auto c1Low = makeLR4 (sampleRate, freq1, true); auto c1High = makeLR4 (sampleRate, freq1, false); auto c2Low = makeLR4 (sampleRate, freq2, true); auto c2High = makeLR4 (sampleRate, freq2, false); lp1A.coefficients = c1Low; lp1B.coefficients = c1Low; hp1A.coefficients = c1High; hp1B.coefficients = c1High; lp2A.coefficients = c2Low; lp2B.coefficients = c2Low; hp2A.coefficients = c2High; hp2B.coefficients = c2High; } // 分为低频、中频、高频三路输出 void processSample (float input, float& low, float& mid, float& high) { // 低通链路：经过两级级联形成LR4 auto low1 = lp1A.processSample (input); auto lowFull = lp1B.processSample (low1); // 高频链路：直接走第二个分频点的高通 auto high1 = hp2A.processSample (input); auto highFull = hp2B.processSample (high1); // 中频段：用全频段信号减去低通和高通输出，得到带通 auto midFull = input - lowFull - highFull; low = lowFull; mid = midFull; high = highFull; } };processSample这个方法里最有价值的细节是中频段的算法：不是单独构造带通滤波器，而是用全通信号减掉低通和高通输出。因为Linkwitz-Riley的低通和高通在分频点相位关系固定，这样减出来的中频段在分频点处不会产生相位缺口。如果你改成直接级联低通和高通来构造中频段，会在两个分频点之间出现不必要的相位旋转，听感上中频会"空"一块。
prepare方法里的makeLR4 lambda展示了LR4的关键：两个级联的滤波器使用完全相同的系数。有些实现会用Q值0.707的Butterworth和一个不同的Q值组合来凑LR响应，那种做法写起来快，但输出不是严格意义上的Linkwitz-Riley，不建议在生产代码里用。
3.2 RMS电平检测与压缩曲线
每个频段独立做动态压缩，首先要解决电平检测的问题。峰值检测响应快但容易失真，RMS检测更贴近人耳对响度的感知。我用的是块内RMS，窗口约20毫秒，原因是宿主每次回调的buffer大小不一定，块内RMS不需要维护环形窗口，计算稳定且实现简单。
// BandCompressor.cpp 核心处理循环 void BandCompressor::processBlock (AudioBuffer<float>& buffer) { const auto numChannels = buffer.getNumChannels(); const auto numSamples = buffer.getNumSamples(); auto threshold = thresholdParam->get(); auto ratio = ratioParam->get(); for (int ch = 0; ch < numChannels; ++ch) { auto* data = buffer.getWritePointer (ch); // 第一步：统计当前块的RMS电平（dB域） float sumSquares = 0.0f; for (int i = 0; i < numSamples; ++i) sumSquares += data[i] * data[i]; auto rms = std::sqrt (sumSquares / numSamples); auto rmsDb = juce::Decibels::gainToDecibels (rms + 1e-6f); // 加1e-6防止静音时log(0)产生负无穷 // 第二步：计算压缩后的增益衰减量 float gainDb = 0.0f; if (rmsDb > threshold) { auto overshoot = rmsDb - threshold; // 比率ratio:1，overshoot被压缩成 overshoot / ratio gainDb = overshoot * (1.0f / ratio - 1.0f); } // gainDb此时是负值，表示需要衰减的量 // 第三步：加上补偿增益，然后对当前块统一应用 auto makeupDb = makeupParam->get(); auto targetGain = juce::Decibels::decibelsToGain (gainDb + makeupDb); // 注意这里targetGain是标量，实际上要对每个采样平滑过渡 for (int i = 0; i < numSamples; ++i) data[i] *= smoother.process (targetGain); } }这段代码展示的是最朴素的压缩曲线：没有soft knee，只有阈值和比率。gainDb的计算逻辑可以这样理解：当输入超过阈值3dB、比率4:1时，输出只允许比阈值高0.75dB，所以需要衰减2.25dB——overshoot乘以(1/ratio - 1)就是这2.25dB。makeupGain是压缩结束后再把整体音量补回来的增益，业界俗称"响度补偿"。
这里有个坑：如果直接对每个样本用同一个targetGain，块与块之间的增益会出现台阶，听感就是每20毫秒抽动一次。所以smoother.process方法会在块内对增益做逐样本的逼近，下一小节细说。
3.3 攻击/释放平滑器与防爆音
压缩器的attack和release本质上是对目标增益的变化速度做限制。attack决定增益下降（开始压缩）的速度，release决定增益恢复（压缩结束）的速度。我用的是一阶低通平滑，数学上等价于一个IIR滤波器，系数由时间常数换算而来：
// BandCompressor.h 里的增益平滑器 class GainSmoother { public: void prepare (double sampleRate) { fs = sampleRate; } // attackMs/releaseMs分别设置启动和释放时间 void setParameters (float attackMs, float releaseMs) { attackCoeff = 1.0f - std::exp (-1000.0f / (attackMs * fs)); releaseCoeff = 1.0f - std::exp (-1000.0f / (releaseMs * fs)); } float process (float targetGain) { auto coeff = targetGain < currentGain ? attackCoeff : releaseCoeff; currentGain += (targetGain - currentGain) * coeff; return currentGain; } private: double fs = 44100.0; float attackCoeff = 0.0001f; float releaseCoeff = 0.0001f; float currentGain = 1.0f; // 当前实际增益（线性域） };关键在process里：比较targetGain和currentGain，小了用attack系数，大了用release系数。为什么？增益衰减（压缩进行中）应该比增益恢复更快，才能避免"抽吸感"。attackCoeff和releaseCoeff的换算公式里，attackMs是毫秒，fs是采样率，1000.0f是把毫秒转秒。比如10ms attack在44.1kHz下系数约为0.00226，每样本移动千分之二，大约经过300个样本（7ms）能走完95%的过渡。
这种一阶平滑的缺点是attack超快时会漏过瞬态——如果你设1ms attack，平滑器还没动几下，鼓的attack就过去了。解决方法是引入lookahead延迟，不过这项目里没做，属于后续扩展点。作为一个通用压缩器，一阶平滑加上合理的attack范围（我限制在0.1ms到100ms）已经能在绝大多数音源上工作了。
4. UI与控制：旋钮绑定、频谱显示与参数自动化
4.1 旋钮绑定AudioProcessorValueTreeState
多频段压缩器最大的痛点在于同时操控十几个参数，如果每个旋钮都在插件代码里手动getParameter并setValue，代码会变成一团浆糊。JUCE的AudioProcessorValueTreeState把参数存进一棵ValueTree，界面控件通过Attachment和参数双向绑定。旋钮转动会更新树里参数值，宿主自动化或者DAW快照恢复时，树里参数变化也会自动刷新旋钮位置。
界面布局上我用9个旋钮（三段各：阈值、比率、补偿增益）加两个分频点旋钮，attack和release放到每个频段的标题旁边作为小旋钮，让面板看起来清爽一些。Editor创建控件后，绑定逻辑像这样：
// PluginEditor.cpp thresholdAtt1 = std::make_unique<SliderAttachment> (apvts, "band" + String(band) + "_threshold", thresholdSlider);SliderAttachment的构造参数就是ValueTree中AudioParameterFloat的ID。这个绑定是模板化的，在C++里通过std::function回调实现双向同步。我一般把Attachment以unique_ptr成员变量持有，因为它的生命周期必须和Slider一致——Slider销毁后Attachment访问会悬垂崩溃，这个坑我踩过不止一次。
4.2 自定义旋钮外观与频谱显示
默认Slider的旋转样式在DAW界面上并不难看，但多频段压缩器需要让用户一眼看出每个频段当前的增益状态，自定义绘制就有必要了。我的LookAndFeel里覆写了drawRotarySlider：
// LookAndFeel.cpp 旋钮绘制 void drawRotarySlider (juce::Graphics& g, int x, int y, int width, int height, float sliderPos, float rotaryStartAngle, float rotaryEndAngle, juce::Slider& slider) override { auto bounds = juce::Rectangle<int> (x, y, width, height).toFloat(); auto centre = bounds.getCentre(); auto radius = jmin (bounds.getWidth() / 2.0f, bounds.getHeight() / 2.0f) - 4.0f; // 背景圆环 g.setColour (juce::Colours::darkgrey); g.fillEllipse (centre.translated (0, 0), radius, radius); // 当前角度标示 auto angle = rotaryStartAngle + sliderPos * (rotaryEndAngle - rotaryStartAngle); auto pointerEnd = centre.getPointOnCircumference (radius - 6.0f, angle); g.setColour (juce::Colours::cyan); g.drawLine (centre.getX(), centre.getY(), pointerEnd.getX(), pointerEnd.getY(), 2.0f); // 频段颜色区分：低频段蓝，中频段绿，高频段橙 ... }绘制旋钮时我偷偷加了一个"伪指针"效果：指针线条从圆心出发，指向当前角度。sliderPos范围是0到1，换算成角度后直接画线，省去贴图资源，换肤也方便。另外频谱显示组件用FFT实时分析输入信号并画频谱线，核心是把分析结果存进一个环形缓存，在paint回调里线性插值连成Path。这部分UI代码对DSP没有影响，但实际使用中非常有用——你能亲眼看到分频点切在哪里、被压缩的部分有没有如预期减少响度。
4.3 自动化参数在processBlock中的处理
宿主的自动化系统会以块为单位更新参数值。问题在于：一个128帧的buffer里，参数可能在帧20的位置被更新过一次，而你在块处理开始时读到的可能是旧值。对压缩器来说，参数更新滞后几十毫秒听感不明显，但要想严格跟随自动化，每个块内要做线性插值。
我在processBlock开头一次性拉取当前参数值：
// MultiBandProcessor.cpp void MultiBandProcessor::process (AudioBuffer<float>& buffer) { auto& params = *parameters; // 从ValueTree里读当前值，确保和界面/自动化同步 float t1 = *params.getRawParameterValue ("crossover1"); float t2 = *params.getRawParameterValue ("crossover2"); crossover.prepare (sampleRate, t1, t2); // 注意：prepare里重新算滤波器系数，如果分频点没变化， // 可以加一个缓存判断避免重复计算 for (int ch = 0; ch < buffer.getNumChannels(); ++ch) { auto* data = buffer.getWritePointer (ch); for (int i = 0; i < buffer.getNumSamples(); ++i) { float low, mid, high; crossover.processSample (data[i], low, mid, high); // 三段分别过压缩器（这里假设每个BandCompressor内部已更新参数） auto lowOut = bands[0].processSample (low); auto midOut = bands[1].processSample (mid); auto highOut = bands[2].processSample (high); data[i] = lowOut + midOut + highOut; } } }参数读值用getRawParameterValue而不是getParameter，因为前者返回的是float指针，可以直接在性能敏感的循环外部读取，不需要加锁。分频点变化时，prepare会重新计算12个biquad的系数，这个开销其实很小（几十次乘法），但如果你在宿主里频繁自动化分频点，CPU占用会有轻微上涨。我给crossover加了粗糙的缓存判断：当freq1和freq2与上次一致时直接跳过prepare，这个优化在连续处理时能省掉不少无谓的系数计算。
5. 避坑记录：相位抵消、混叠抽动与延迟补偿
5.1 分频点附近出现凹坑的相位问题
现象：把三个频段的输出混合后，在分频点附近明显听到音量下降，像是有一个固定频率被挖掉了一块。用正弦扫频信号测试时，频谱显示器上能看到分频点处出现一条窄的凹陷带。
原因：滤波器类型选错。我最开始用普通的2阶Butterworth高通和低通去切分频点，高通和低通在交叉频率处的相位差不是180度，叠加时模长小于1，幅频响应产生了凹陷。这是多频段处理里最典型的"听起来没什么，一看频谱就露馅"的问题。
解决：换成Linkwitz-Riley 4阶结构后，低通和高通相位严格相差180度，数学上叠加模长为1，凹陷消失。如果你需要在两个分频点之间再切一个更窄的频段，也务必保持滤波器组整体是LR结构——不要混入其他响应类型的滤波器。
5.2 高频段压缩后产生混叠的金属声
现象：对高频段做较大压缩量（比如阈值-30dB、比率8:1）时，输出出现刺耳的金属感，尤其在10kHz附近很明显。把插件在44.1kHz和96kHz采样率下对比，44.1kHz下问题更严重。
原因：压缩是非线性处理，会产生原信号频率以上的谐波。高频段本身包含接近20kHz的信号，压缩产生的谐波超过奈奎斯特频率后折返回可听频带，听起来就是"滋滋"的金属声。这不是滤波器问题，而是非线性处理固有的混叠产物。
解决：对高频段做过采样。JUCE的dsp::Oversampling类可以包装任意处理器，我一般对高频段做2倍过采样，处理流程变为：输入信号先2倍上采样进高频段压缩器，压缩后再抽取回原采样率。过采样带来的CPU开销大约多30%，但对高频段的音质提升非常明显。
5.3 调节阈值时发出咔哒声
现象：在音频播放过程中快速转动阈值旋钮，输出信号出现明显咔哒声，尤其在强拍位置扭旋钮时声响更明显。
原因：这是参数平滑的经典问题——阈值突然变化导致gainDb瞬间跳变，增益系数从0.3直接跳到0.7，输出波形出现了一个台阶。这个台阶在扬声器上就是"咔哒"。一开始我以为只要对增益做平滑就完了，后来发现问题不在增益域，而是在参数域。
解决：把threshold、ratio这些参数本身也做平滑处理。我在BandCompressor内部维护了一份"当前生效参数"，每块处理时向目标值缓慢逼近。攻击和释放时间常数本身就适合套用在这个平滑过程上。后端在processSample里用平滑后的参数计算增益，这样无论外界怎么跳变参数，最终作用到音频上的曲线始终是连续的。处理后扭阈值旋钮完全听不到咔哒声了。
5.4 宿主中声音发飘的延迟补偿
现象：插件和另一个未加插件的音轨并排播放时，声音明显"发飘"，相位对不齐，低频尤其明显。把插件旁通后问题消失。
原因：滤波器链引入的群延迟。Linkwitz-Riley 4阶滤波器在分频点附近的延迟约为几个毫秒，多频段处理链整体延迟可能到5-10ms。宿主不会自动知道你的插件处理要多久，默认假设是零延迟。
解决：在AudioProcessor子类里覆写getLatencySamples()，返回滤波器链的总延迟采样数。因为我用的是IIR滤波器，延迟和频率相关，没有固定值，所以采用保守估计：用分频点处的群延迟作为整体延迟上报。这样宿主在自动延迟补偿时会把这个值纳入考量，声音和未加插件的轨道就能对齐了。
6. 二次开发：把三频段改成任意N频段
6.1 用vector重构频段管理
三频段写死代码时逻辑很清晰，但换成四段、五段时就得复制粘贴了。我重构的第一步是把MultiBandProcessor里的3个BandCompressor成员变量改成std::vector：
// MultiBandProcessor.cpp 重构后的核心数据结构 std::vector<std::unique_ptr<BandCompressor>> bands; std::vector<float> crossoverFreqs; // 长度 = N-1 void MultiBandProcessor::prepare (double sampleRate, int numBands, const std::vector<float>& freqs) { crossoverFreqs = freqs; bands.clear(); for (int i = 0; i < numBands; ++i) { bands.push_back (std::make_unique<BandCompressor>()); bands[i]->prepare (sampleRate); } filters.resize (numBands); // 每个频段一个滤波器组 // 每个滤波器组用相邻两个分频点构造带通响应 for (int i = 0; i < numBands; ++i) { auto fLow = i == 0 ? 20.0f : crossoverFreqs[i - 1]; auto fHigh = i == numBands - 1 ? 20000.0f : crossoverFreqs[i]; filters[i].prepare (sampleRate, fLow, fHigh); } }这一步改完，UI上的参数布局也要动态创建：通过循环重新生成layout，旋钮数量跟着bands.size()走。DynamicParameterHandling是JUCE比较薄弱的环节——ValueTree本身是动态的，但ParameterLayout在重构时一旦创建就不再变化。常见做法是固定声明最大8个频段的参数，用enable flag控制哪些频段实际参与处理，虽然参数列表里会有几个隐藏参数，但自动化兼容性最稳妥。
6.2 给压缩器加上侧链输入
多频段压缩器加侧链是很实用的功能，典型场景是：用鼓组信号侧链控制贝斯压缩，实现"ducking"效果。增加侧链在JUCE里要覆写两个方法：
// PluginProcessor.cpp bool supportsDoublePrecisionProcessing() const override { return true; } bool hasSidechainInput() const override { return true; } // 从AudioProcessorIO中区分主输入和侧链输入 void processBlock (juce::AudioBuffer<float>& buffer, juce::MidiBuffer& midi) override { // buffer总通道数 = 主输入通道数 + 侧链输入通道数 int mainChannels = getMainBusNumInputChannels(); auto mainBuffer = getBusBuffer (buffer, true, 0); // 主输入总线 auto sideBuffer = getBusBuffer (buffer, false, 0); // 侧链输入总线 // 从sideBuffer里计算RMS，用它替换原本的主信号RMS ... }侧链实现的核心变化在于：原本BandCompressor从自身输入信号提取RMS电平，侧链模式下改为从sideBuffer提取电平，再把这个电平用于压缩主信号的增益计算。getBusBuffer的第二个bool参数true表示输入总线，false表示侧链总线。注意侧链接入后，主信号的三个频段仍需正常分频，但电平检测统一走侧链，这样才有"跟随另一个音源的动态"的效果。
6.3 验证方法
改完架构最怕的就是跑起来没声音但又能加载——这种"假死"状态最难排查。我每次改完会做三步验证：第一，用一个1kHz正弦波信号跑一遍离线处理，确保输出不是静音；第二，按频段分别ping输出，把低、中、高依次单独旁通，听每个频段是否独立起作用；第三，开一个频谱分析插件看整体频谱形状，确认分频器重建的幅频响应是平的。这三步全过了，基本可以放心提交代码。
从那以后，我每次改完DSP都强制走一遍这三个验证流程，哪怕只改了一个系数也要跑。这个习惯帮我挡住了好几次分频器系数改错导致的声音凹陷问题。希望这篇解析能帮你把多频段压缩器跑起来，也少踩几个我已经替你蹚过的坑。
本文还有配套的精品资源，点击获取
