Один движок, четыре плагина: что общего у Nectar, Neutron и RX

Общий фундамент

Nectar и Neutron используют один и тот же класс DSP::Dynamics::DynamicsCore. У них совпадают части вычислительного ядра, включая логику переключения режимов. Neutron строит вокруг этого ядра многополосный процессор: сигнал делится по частотам, полосы получают собственные настройки, затем результат собирается обратно. У вокального компрессора Nectar другая конфигурация и свой набор режимов.

У Nectar, Neutron и RX повторяется и механизм загрузки. В оболочке AU есть файл iZCore.path, указывающий на библиотеку обработки. Для трёх семейств это iZNectar4Core.bundle, iZNeutron5Core.bundle и iZRX12Core.bundle. Оболочка обращается к библиотеке через функции PluginCoreCallback и PluginCoreInterfaceVersion.

Один код, разные плагины

Внутри семейства Nectar файлы iZNectar4Core у компонентных плагинов Auto-Level, Backer и Breath Control совпадают побитно. При этом для хоста это отдельные плагины. В Nectar Advanced 13 компонентных плагинов можно использовать самостоятельно, а в основном Nectar модули собраны в одну цепочку.

У iZotope есть Inter-plugin Communication, позволяющий совместимым экземплярам передавать данные для анализа маскирования и управления уровнями. Например, Nectar может работать с Neutron или Relay на конфликтующей дорожке.

Что это значит для пользователя

Общий код не делает плагины одинаковыми. В изученной сборке основной Nectar открывает хосту 689 параметров автоматизации. В Nectar Assistant параметр Intensity связан с четырьмя настройками Compressor 1: порогом, отношением компрессии, атакой и восстановлением. В Optical-режиме компрессора Nectar Ratio фиксирован на 4:1, а диапазоны атаки и восстановления отличаются от других режимов.

Библиотека Glass Properties опубликована как демонстрационный код, но не может быть собрана вне системы сборки iZotope и зависимостей.

Что будет дальше

В ближайшие 6–12 месяцев iZotope, скорее всего, продолжит переиспользовать общий код в новых версиях плагинов. Это снижает затраты на разработку и упрощает поддержку. Но возможен и другой сценарий: компания может разделить кодовые базы, если потребуется более глубокая специализация. Сигналом для пересмотра прогноза станет появление новых плагинов с заметно отличающейся архитектурой. Для пользователя практический вывод прост: не стоит ожидать, что общий код гарантирует одинаковое звучание или поведение — важнее конкретные настройки и режимы.