Reply to thread

Message: [QUOTE="Shamiso, post: 92463, member: 160"] JUCE can build VST3, AU, AUv3, AAX, and LV2 plug-ins from one codebase, so format labels need not imply different DSP. A developer can put the same processor behind several host-facing versions, compile each one for its target, and ship them in the same installer. The format handles communication with the DAW, while the audio algorithm can remain the same. This matters because format debates get weird fast. People hear one AU instance as wider, one VST3 as punchier, or an AAX build as somehow more professional, then blame the letters on the file. Usually the comparison has picked up another variable along the way. The useful baseline is simple. If two builds run the same DSP code with the same settings, sample rate, inputs, channel layout, and processing state, there is no built-in rule making AU warmer or VST3 cleaner. The [B][URL='https://goldmidi.com/community/resources/what-are-plug-ins-in-music-software.467/']plug-in formats used by music software[/URL][/B] mainly define how the processor and host talk to each other. [HEADING=2]The format wraps the processor rather than voicing it[/HEADING] Modern plug-in frameworks make this separation pretty obvious. One project can contain the actual filter, compressor, synth, or reverb code once, then add format-specific layers that expose parameters, audio buses, MIDI, presets, and the editor to different hosts. The [B][URL='https://webaudioconf.github.io/papers/iplug2-desktop-plug-in-framework-meets-web-audio-modules.pdf']cross-platform audio plug-in framework work[/URL][/B] behind iPlug 2 describes the same core C++ code being used across different plug-in and application targets. JUCE follows a similar model, letting developers build several plug-in formats from a single codebase. None of this forces every developer to keep every build identical, but it kills the idea that the wrapper itself has a secret tone. Format specifications do have different capabilities. VST3 has its own parameter, bus, event, process-mode, and host-context systems, while Audio Units use Apple’s APIs and AAX targets Pro Tools. Those differences can change how a plug-in integrates with the host without changing the maths inside its EQ curve or distortion stage. A good example is MIDI output. Ableton Live can receive direct MIDI output from VST3 plug-ins on macOS, while Audio Units have different limitations in that workflow. Same product name, potentially different workflow. Nothing about that difference means one version has better audio fidelity. [HEADING=2]AU and VST3 can still behave differently[/HEADING] Real differences are possible, just not for the lazy reason people usually give. A developer might ship one format a version behind, expose a feature differently, use different defaults, or hit a bug in only one wrapper. Host behavior can add another wrinkle through automation timing, sidechain routing, bus layouts, suspension, or how a processor is initialized. Parameter matching can fool you too. Two knobs showing the same rounded number do not prove the internal values are identical if the builds map or scale a parameter differently. Presets can also carry format-specific state, so loading something called “Default” in both versions is not automatically a controlled test. Randomized processors are another trap. Analog-style drift, free-running modulation, noise generation, random voices, and per-instance component variation can make two renders differ even inside the same format. Run the same VST3 twice, and you may already get a residual, which makes a VST3-versus-AU residual much less dramatic than it first appears. Offline rendering can muddy things further. VST3 explicitly lets a processor know whether it is running in real time, prefetch, or offline mode, so a plug-in can legally choose a different internal quality path during export. Comparing one real-time capture with one offline bounce is therefore a bad format test before AU even enters the room. [HEADING=2]A null test needs boringly strict conditions[/HEADING] A useful comparison starts with the same audio file, same host, same sample rate, same channel configuration, and the same plug-in version. Match every parameter numerically, disable random or free-running behavior where possible, render both paths the same way, line them up sample for sample, flip polarity on one, and listen to what remains. Silence means the two rendered outputs cancel under those conditions. A residual means something differed, but it does not identify the cause by itself. Gain, latency, modulation phase, unreported state, oversampling, routing, or a genuine format-specific implementation bug can all leave audio behind. Even a clean null has limits. It proves equivalence for the tested signal and settings, not every automation move, sidechain configuration, preset recall, buffer size, or host interaction the plug-in supports. A format problem usually shows up at those edges first, where the wrapper has actual work to do. [/QUOTE]

Name