Communitygithub.com

VST Maker

Verwenden Sie diese Fähigkeit beim Entwurf, Schreiben, Review, Verpacken oder Veröffentlichen von Audio-Plugins (Synths, Effekte, MIDI-Controller-Plugins) in C++/JUCE für VST3 auf Linux, macOS und Windows. Deckt Echtzeitsicherheit, Parameter, CPU/RAM/GPU/Latenz, Klangqualität, Instrumenten-, Filter-, Effekt- und Preset-Design, UI-Standards, Offline-Installateure und Handbücher, Signieren, Testen und Sicherheit ab.

Was ist VST Maker?

Dies ist eine inoffizielle Community-Fähigkeit für die Entwicklung von Audio-Plugins mit C++ und JUCE, mit Schwerpunkt auf VST3. Sie bietet detaillierte Richtlinien zu Echtzeitsicherheit, Parametermanagement, Leistungsoptimierung, Latenzberichterstattung, Klangqualität (einschließlich Anti-Aliasing und Filterdesign) sowie zum Synthesizer- und Effekt-Design. Die Fähigkeit betont messbare Ergebnisse vor subjektiven Behauptungen, enthält projektspezifische Vertrauens-Tags zur Quellenüberprüfung und unterstützt die Entwicklung für Linux, macOS und Windows. Sie ist für KI-Agenten konzipiert, die in der Plugin-Entwicklung unterstützen, und deckt sowohl den Code als auch das Deployment (Offline-Installateure, Signieren und Testing) ab.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/SpeakingColors/claude-skills/tree/HEAD/skills/vst-maker

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht VST Maker?

Inoffizielle Community-Fähigkeit. Nicht erstellt oder unterstützt von einem hier genannten Plugin-, Synthesizer- oder Framework-Anbieter.

So lesen Sie Vertrauens-Tags:

  • (V: Quelle) überprüft anhand der genannten Quelle.
  • (R) Faustregel oder Geschmackssache. Ein Startwert, der durch Messen und Zuhören getestet werden sollte, niemals ein Gesetz.

Wenn eine Tatsache kein Tag hat, handelt es sich um eine Standardpraxis, die Sie dennoch überprüfen sollten, bevor Sie sich für eine Veröffentlichung darauf verlassen.

0. Grundregeln

  • Fragen Sie vor dem Bauen: Plugin-Typ (Synth, Effekt, Controller), Ziel-OS (Linux, macOS, Windows), Formate (VST3 zuerst; CLAP oder LV2 optional), Farbpalette (niemals eine annehmen; bieten Sie eine neutrale Standardpalette an, falls der Benutzer keine hat), Lizenz (siehe 1).
  • Kostenlose und Open-Source-Plugins müssen offline funktionieren: kein Konto, kein Lizenzserver, kein Download bei der Installation oder zur Laufzeit. Alles, was das Plugin benötigt, ist gebündelt.
  • Behaupten Sie niemals, dass ein Klang nach Gehör gut ist. Messen Sie ihn (siehe 12) und lassen Sie die Ohren des Benutzers das endgültige Urteil fällen.
  • Zitieren oder testen Sie jede Zahl. Sagen Sie "unbestätigt", wenn ein Wert eine Faustregel ist.
  • Machen Sie einen Schritt nach dem anderen, wenn der Benutzer kein Programmierer ist. Zuerst kurze Antworten, Details auf Anfrage.

1. Projekt-Setup und Lizenz

  • JUCE ist dual lizenziert: die JUCE-Lizenz und AGPLv3. Ohne einen kostenpflichtigen JUCE-Plan müssen Sie JUCE unter AGPLv3 verwenden, und AGPLv3 verlangt mehr als nur die Veröffentlichung des Quellcodes (V: JUCE-Forum, Mitarbeiterantwort). Lesen Sie die aktuelle JUCE-Lizenz für die Version, die Sie verwenden, bevor Sie sich entscheiden, und teilen Sie dem Benutzer mit, welche zutrifft. Geben Sie keine Preisstufen oder Umsatzgrenzen aus dem Gedächtnis an.
  • Verwenden Sie CMake. Halten Sie DSP-Code frei von JUCE-GUI-Typen, damit er ohne Fenster getestet werden kann.
  • Bauen Sie zuerst VST3. CLAP und LV2 sind optional: Überprüfen Sie die aktuellen JUCE-Dokumente und clap-juce-extensions, bevor Sie eines von beiden versprechen.
  • Wo Hosts nach VST3 scannen (V: Steinberg VST 3 Developer Portal, Plugin-Standorte):
    • Linux: $HOME/.vst3/ zuerst, dann /usr/lib64/vst3/, /usr/lib/vst3/, /usr/local/lib64/vst3/, /usr/local/lib/vst3/.
    • macOS: ~/Library/Audio/Plug-ins/VST3/ (Benutzer), /Library/Audio/Plug-ins/VST3/ (global).
    • Windows: C:\Program Files\Common Files\VST3\ (global), %LOCALAPPDATA%\Programs\Common\VST3\ (Benutzer, hauptsächlich für die Entwicklung).
    • Hosts verwenden das erste Plugin, das für eine bestimmte Processor-UID gefunden wird, und scannen in der Prioritätsreihenfolge.

2. Echtzeitsicherheit

processBlock läuft auf einem hochprioren Audio-Thread mit einer harten Deadline. Die JUCE-Dokumente sagen, dass jede Interaktion mit der UI dort ausgeschlossen ist und der Code mit variablen Blockgrößen umgehen muss (V: JUCE AudioProcessor-Dokumente).

Niemals im Audio-Thread:

  • Speicher allokieren oder freigeben (new, delete, malloc, wachsende Vektoren oder Strings, Erstellen von juce::String)
  • Eine Sperre nehmen, die ein anderer Thread halten könnte (std::mutex, CriticalSection)
  • Datei-, Netzwerk- oder Konsolen-I/O
  • Die UI oder den MessageManager aufrufen
  • Ausnahmen auslösen oder etwas mit unbekanntem Echtzeitverhalten aufrufen

Stattdessen:

  • Allokieren Sie in prepareToPlay (die Abtastrate bleibt konstant, bis die Wiedergabe stoppt; die Blockgröße ist nur ein Hinweis und die Dokumente sagen, defensiv zu programmieren, falls ein Host sie überschreitet) (V: JUCE-Dokumente). Freigeben in releaseResources oder dem Destruktor.
  • Kommunizieren Sie mit anderen Threads über sperrfreie Warteschlangen (juce::AbstractFifo) oder Atomics. Die UI fragt Atomics mit einem Timer ab; oder lösen Sie AsyncUpdater vom Audio-Thread aus.
  • Setzen Sie juce::ScopedNoDenormals an den Anfang von processBlock; es bleibt aktiv, bis die Funktion zurückkehrt, sodass Helfer es nicht wiederholen müssen (V: JUCE-Forum-Konsens, nicht offizielle Dokumente). Gestalten Sie auch Rückkopplungspfade so, dass sie nicht zu Denormals verfallen können.
  • Empfohlene Lektüre: Ross Bencina, "Real-time audio programming 101: time waits for nothing" (hier nicht zitiert, konnte beim Schreiben dieser Fähigkeit nicht abgerufen werden).

3. Parameter und Zustand

  • Verwenden Sie AudioProcessorValueTreeState: Host-Automation, Undo und Zustandsspeicherung sind damit abgedeckt.
  • Glätten Sie jeden Parameter, der eine Verstärkung, Frequenz, Mischung oder Verzögerungszeit erreicht (juce::SmoothedValue), sonst erhalten Sie Zipper-Geräusche und Klicks.
  • Lesen Sie Werte einmal pro Block in lokale Variablen, es sei denn, der Wert wird pro Sample geglättet.
  • Geben Sie jedem Parameter eine stabile String-ID. Benennen Sie IDs nach der Veröffentlichung niemals um oder ordnen Sie sie neu: Dies zerstört gespeicherte Projekte und Automation. Fügen Sie neue Parameter mit neuen IDs hinzu und führen Sie eine Zustandsversionsnummer.
  • Validieren Sie alles, was aus Zustand oder Presets geladen wird: Clampen Sie Bereiche, ignorieren Sie unbekannte Schlüssel, vertrauen Sie niemals Größen oder Anzahlen.
  • Halten Sie den Prozessor (DSP und Zustand) strikt vom Editor (UI) getrennt. Der Prozessor muss einwandfrei laufen, wenn das Editor-Fenster geschlossen ist. VST3 selbst teilt ein Plugin in einen Prozessor und einen Controller auf (V: Steinberg VST3-Tutorial, "Code your first plug-in").
  • Wissenswerte VST3-Fakten, auch wenn JUCE sie kapselt (V: selbiges Tutorial): Parameter sind immer auf 0.0 bis 1.0 normalisiert; setzen Sie das automatable-Flag, damit Hosts automatisieren können; ein Verarbeitungsblock kann mehr als eine Änderung für denselben Parameter enthalten, daher muss ein handgeschriebener Prozessor die Warteschlange korrekt handhaben (das Tutorial wendet nur die letzte Änderung an, was eine Vereinfachung ist); wenn die Eingabe stumm ist, setzen und beachten Sie die Silence-Flags und löschen Sie die Ausgabepuffer; lehnen Sie nicht unterstützte Bus-Layouts ab, anstatt zu raten; wenn keine Eingaben oder keine Samples vorhanden sind, wenden Sie dennoch ausstehende Parameteränderungen an.

Weitere VST3-Architektur-Fakten (V: Steinberg VST 3 Developer Portal, API-Dokumentation):

  • Der Prozessor muss ohne geladenen Controller funktionieren, daher hängt der DSP-Zustand niemals vom Editor ab.
  • process() und setProcessing() können auf dem Audio-Thread laufen: keine Allokation. Initialize und Terminate laufen auf dem UI-Thread.
  • Bus- und Lautsprecheranordnungen können sich nur ändern, während das Plugin inaktiv ist. Stellen Sie Puffer für alle Busse bereit, auch für inaktive. Eingabe- und Ausgabepuffer können sich Speicher teilen, daher löschen Sie Ausgaben nicht blind.
  • Noten treffen als Ereignisse in process() ein. Parameteränderungen treffen samplegenau über Parameterwarteschlangen ein. Tempo und Transport treffen im Prozesskontext ein.
  • GUI-zu-Host-Bearbeitungen verwenden beginEdit, performEdit, endEdit in dieser Reihenfolge, nur auf dem UI-Thread.
  • Bei der Zustandswiederherstellung wird zuerst der Prozessor wiederhergestellt; der Controller empfängt dann den Komponentenzustand und darf keine Handler-Callbacks auslösen.
  • Senden Sie keine privaten Prozessor-zu-Controller-Nachrichten von process() aus; verwenden Sie den UI-Thread oder die Data Exchange API.
  • Units gruppieren Parameter; die MIDI-Mapping-Schnittstelle bildet MIDI-CCs auf Parameter ab.
  • Portal-Seiten, die bei Bedarf gelesen werden sollten: Parameters and Automation, Workflow Diagrams, Multiple Dynamic IO (Seitenkette), VST 3 Units, Data Exchange.

4. Leistung: CPU, RAM, GPU

  • Messen Sie vor der Optimierung (siehe 12).
  • CPU (R): Verarbeiten Sie in Blöcken, berechnen Sie Koeffizienten vor, wenn sich ein Parameter ändert, vermeiden Sie Pro-Sample-Verzweigungen und virtuelle Aufrufe in inneren Schleifen, vermeiden Sie std::pow, std::exp, std::sin pro Sample, wo eine Rekursion oder Tabelle funktioniert und schneller misst.
  • RAM: Allokieren Sie einmal vor, teilen Sie Wellentabellen und Tabellen zwischen Stimmen, geben Sie große Puffer in releaseResources frei.
  • GPU und UI: Zeichnen Sie nur, während der Editor sichtbar und im Vordergrund ist. Pausieren Sie Timer, Messgeräte und Canvas-Animationen, wenn versteckt; Audio, Automation und MIDI laufen weiter. Begrenzen Sie die Neuzeichnungsrate und zeichnen Sie nur schmutzige Bereiche neu (R). Verwenden Sie GPU-Rendering nur, wenn es klar benötigt und auf Linux getestet wurde.
  • Ein versteckter oder geschlossener Editor darf keine Pro-Frame-Arbeit am Laufen halten.

5. Latenz

  • Melden Sie die tatsächliche Latenz mit setLatencySamples ("die Anzahl der Sample-Verzögerung, die es einführt", V: JUCE-Dokumente), wann immer das Plugin Audio verzögert: Lookahead-Limiter oder -Kompressoren, linearphasige Filter, Oversampling-Filter. Überprüfen Sie in einem Host, ob die Meldung angewendet wird.
  • Instrumente fügen ab Note-On null Latenz hinzu.
  • Linearphasige Oversampling-Filter fügen Latenz hinzu; minimalphasige tun dies nicht, ändern aber die Phase. Wählen Sie zielgerichtet und dokumentieren Sie es. juce::dsp::Oversampling meldet seine Latenz; melden Sie sie.
  • Halten Sie getTailLengthSeconds für Hall und Delays korrekt, damit Hosts keine Ausläufer abschneiden.

6. Klangqualität

Aliasing

  • Naive Sägezahn- und Rechteckwellen haben Oberschwingungen über Nyquist, die als unharmonisches Rauschen zurückfalten. Behebungen: bandbegrenzte Schrittmethoden (BLEP-Familie), differenzierte Polynom-Wellenformen, bandbegrenzte Wellentabellen pro Oktave oder Oversampling.
  • Eine veröffentlichte Methode: differenzierte Polynom-Wellenformen; die Hörermodell-Bewertung der Autoren ergab, dass eine Methode vierter Ordnung über den gesamten Bereich eines Flügels wahrnehmbar aliasfrei ist (V: Välimäki, Nam, Smith, Abel, IEEE TASLP Vol. 18 Nr. 4, 2010).
  • Jede Nichtlinearität (Verzerrung, Sättigung, Wellenfaltung, Hard Clip) erzeugt neue Oberschwingungen, die aliasen. Übersample um nichtlineare Stufen herum oder verwenden Sie Anti-Aliasing basierend auf Stammfunktionen. Zavalishin behandelt Anti-Aliasing von Wellenformung (V: "The Art of VA Filter Design", Abschnitt 6.13).
  • Testen Sie Aliasing durch Messung (siehe 12), nicht durch Betrachten des Oszillatorkodes.

Filter

  • Für modellierte Analogfilter verwenden Sie Zero-Delay-Feedback (Topologie-erhaltende Transformation) Strukturen. Das Buch behandelt sie in Kapitel 3 (Abschnitt 3.9, Zero-Delay-Feedback), den Moog-artigen Ladder in Kapitel 5 und die Rückkopplungsschleifensättigung in Kapitel 6 (V: Zavalishin, "The Art of VA Filter Design", Rev. 2.1.0, Inhaltsverzeichnis).
  • Für einfache EQ- und Utility-Filter verwenden Sie Biquads. Das Audio EQ Cookbook (R. Bristow-Johnson, W3C Working Group Note 2021) gibt Tiefpass, Hochpass, Bandpass, Notch, Allpass, Peak-EQ und Shelves an (V).
  • Glätten Sie Cutoff- und Resonanzänderungen, clampsen Sie Cutoff unter Nyquist, halten Sie die Resonanz an den Extremen stabil und kompensieren Sie den Pegel, sodass hohe Resonanz die Lautstärke nicht springen lässt.

Glatt statt scharf (R, aus der Praxis von Produzenten; testen Sie jedes)

  • Schärfe kommt normalerweise von Aliasing, Hard Clipping, starken Resonanzspitzen in den oberen Mitten und zu viel ungefilterten Höhen.
  • Ein Lead mit vollständig geöffnetem Tiefpass kann zu hell klingen. Ein Start-Cutoff um 12 kHz für helle Leads ist ein benutzergemeldeter Geschmackswert, keine Regel.
  • Sättigung in der Filterrückkopplungsschleife ist ein häufiger Grund, warum analoge Filter glatt klingen (V: Zavalishin behandelt Rückkopplungsschleifensättigung; die Wahrnehmungsbehauptung ist R).
  • Sehr kleine, langsame Modulation hält statische Töne lebendig, zum Beispiel eine Tonhöhendrift von einigen Cent. Rechnen Sie vor der Wahl um: 0.1 Prozent sind etwa 1.7 Cent, 1 Prozent sind etwa 17 Cent, und 17 Cent sind deutlich hörbare Verstimmung. Bleiben Sie am unteren Ende, es sei denn, Verstimmung ist das Ziel.
  • Dicke Klänge entstehen durch Layering, Unison mit Detune-Spread, einem Sub-Oszillator und Stereobreite. Überprüfen Sie die Monokompatibilität (L und R summieren, auf hohle oder auslöschende Klänge hören).

Gain-Staging und DC

  • Führen Sie die interne Kette in Float mit großzügigem Headroom. Clippen Sie niemals innerhalb der Kette. Setzen Sie den einzigen Clipper oder Limiter absichtlich am Ausgang.
  • Entfernen Sie DC nach asymmetrischen Nichtlinearitäten mit einem sanften Hochpass im niedrigen einstelligen bis zu zig Hertz-Bereich (R); überprüfen Sie mit der DC-Messung in 12.
  • Gleichen Sie die Preset-Lautstärke an, damit das Umschalten von Presets den Pegel nicht springen lässt.

7. Synth-Design

  • Stimmen: Allokieren Sie jede Stimme vor, allokieren Sie niemals bei Note-On. Machen Sie Polyphonie zu einer Konstanten oder Benutzereinstellung. Stehlen Sie Stimmen mit einem kurzen Fade, niemals einem harten Cut.
  • Hüllkurven: Verwenden Sie einen minimalen Attack und Release von einigen Millisekunden, um Klicks zu vermeiden; starten Sie bei erneuter Auslösung vom aktuellen Pegel, nicht von Null.
  • Unison: Zufällige oder gespreizte Startphasen, eine Detune-Spread-Kurve, Stereobreite und eine Pegelkompensation, die nicht mit der Stimmenanzahl wächst.
  • Supersaw: Der Roland JP-8000 Super Saw wird als sieben gegeneinander verstimmte Sägezahn-Oszillatoren beschrieben (V: Wikipedia, Roland JP-8000). Detaillierte Analysen existieren: Adam Szabo, "How to Emulate the Super Saw" (KTH, 2010) und Alex Shore (2013), beide auf dieser Seite zitiert. Lesen Sie sie für Detune-Kurven und Mischung, anstatt Zahlen zu raten.
  • Drift und Analoggefühl: Langsame zufällige Modulation von Tonhöhe und Cutoff, pro Stimme, klein und unkorreliert.
  • Ideen, die in kommerziellen Supersaw-Synths zu sehen sind, nur zum Studium; schreiben Sie Ihren eigenen Code und Ihr eigenes Design, kopieren Sie niemals den Code, das Aussehen, den Namen oder die Presets eines Produkts (R, überprüfen Sie nach Gehör und Messung):
    • Ein langsamer LFO pro Oszillator, mit Frequenzen, die durch irrationale Verhältnisse wie den goldenen Schnitt beabstandet sind, damit sich die kombinierte Bewegung nicht hörbar wiederholt.
    • Ein "Drift"-Makro, das Detune und Drift-Tiefe zusammen skaliert, mit Feineinstellungen auf einer zweiten Seite.
    • Ein keygetrackter Hochpass als eigenes Steuerelement (der JP-8000-artige Supersaw-Sound verwendet einen).
    • Ein optionaler 2x oder 4x oversampleter Filter; melden Sie die Oversampling-Latenz an den Host.
    • Überprüfen Sie dB-Skalen auf Messgeräten, pro-Stimme Stereobreite und seitenkettenfähige Effekte: Lücken, die einige Produkte hinterlassen und die Benutzer bemerken.
  • MIDI: Verwenden Sie die Sample-Position jedes MIDI-Ereignisses innerhalb des Blocks, damit Noten samplegenau beginnen. Behandeln Sie Pitch Bend (Standardbereich von zwei Halbtönen, konfigurierbar), Sustain-Pedal, All-Notes-Off und Note-Off mit Release. Bieten Sie Mono, Legato und Portamento an, wenn das Instrument für Leads oder Bässe ausgelegt ist.
  • Wellentabellen: Bandbegrenzung pro Oktave oder Tonhöhenbereich; Überblendung zwischen Frames, um Zipper-Geräusche zu vermeiden; Interpolation (linear ist billig, höhere Ordnung kostet CPU, messen Sie das Aliasing).

8. FX-Design

  • Kompressor und Limiter: Erkennung im Log-Domain mit geglättetem Attack und Release, Anwenden von Gain-Glättung, Hinzufügen von automatischer oder manueller Makeup, Melden von Latenz, wenn Sie vorausschauen. Ein Limiter am Ende einer Kette benötigt eine True-Peak- oder Oversample-Decke, wenn er Intersample-Sicherheit verspricht.
  • Multiband: Teilen Sie mit Linkwitz-Riley-Frequenzweichen, sodass die Bänder wieder flach summieren; verarbeiten Sie jedes Band; rekonstruieren Sie. Halten Sie die Weichen phasenkonsistent und melden Sie jede hinzugefügte Latenz.
  • Delay: Fraktionale-Verzögerungsinterpolation, Dämpfungsfilter im Rückkopplungspfad, Tempo-Sync, Ping-Pong, Ducking und eine Rückkopplungsbegrenzung, damit es nicht ausbrechen kann.
  • Hall: Rückkopplungsverzögerungsnetzwerke oder die Dattorro-Platten-Topologie (J. Dattorro, "Effect Design Part 1", JAES 1997); dämpfen Sie die Höhen im Ausklang; modulieren Sie Verzögerungsleitungen leicht, um metallisches Klingeln zu vermeiden; exponieren Sie Pre-Delay, Decay, Damping, Größe und Mix.
  • Übliche Startpraxis für Leads, nach Gehör testen (R): Halten Sie die Hall-Rückkehr mit einem Hochpass um 200 bis 300 Hz aus den Tiefen heraus, rollen Sie die Höhen des Ausklangs ab und verwenden Sie einen moderaten Mix.
  • Chorus, Ensemble, Phaser

... [für die Übersetzung gekürzt]

Verwandte Skills