Requirements Plugin Programmierung

  • Ersteller synthpark
  • Erstellt am
@synth
mach doch erstmal den kern mit c++ oder eine andere schnelle sprache der wahl
auf basis des VST framework
da hast du genug zu tun bis das mal läuft
die gui spartanisch und funktionell mit standard gui elementen

wenn du danach dann noch nicht frustriert den löffel in den sand gesteckt hast, kannst du dich an die gui machen und an die portierung oder crosscompilierung auf andere systeme bzw schnittstellen

was du willst (32/64bit, Plattformunabhängig, top 3 schnittstellen versorgen) ist meines erachtens für einen anfänger zuviel des guten.. lern krabbeln, dann laufen :)

du wirst schon genug probleme im kern bewältigen müssen.. stichwort threading, synchronisation.

ich hab mal eine DAW programmiert, die man für live zwecke über wlan komplett fernsteuern konnte (multiclient fähig usw..) so wie das mackie dingens oder das von sm-pro-audio
da juckt einem die oberfläche erstmal garnicht weil da so viel probleme wärend dem coden auftreten, an die du vorher nicht im entferntesten geahnt hattest :D

z.b. war es krank, die VST plugins einzubinden als VST-Host - ferngesteuert!
dazu die synchronisation mit den lan schnittstellen in beide richtungen und multiclient fähig
das ganze dann auch noch multithreading fähig.. und ganz oben drauf kommt dann noch die anforderung, daß es nicht nur funktionieren soll, sondern auch performant (asio crackles) und stabil (live betrieb)

gut für ein einzelnes kleines VST (oder AU oder was auch immer) pluginchen ist die spielwiese etwas kleiner.. aber gerade die synchronisation der gui mit dem algorithmus, der die buffer berechnet ist schnell mal übersehen :)

btw assembler ist eigentlich kein thema mehr.. das meiste optimiert der compiler eh effizienter
d.h. man kann eher was verlangsamen.. aber das solltest du ja wissen, wenn du DSP kenntnisse hast..
 
gut für ein einzelnes kleines VST (oder AU oder was auch immer) pluginchen ist die spielwiese etwas kleiner.. aber gerade die synchronisation der gui mit dem algorithmus, der die buffer berechnet ist schnell mal übersehen :)

ja leider schaffens viele namhafte Anbieter nicht mal, die Ausschläge der Gain Reduction Nadel bei einem Compressor mit dem Gehörten zu synchronisieren, das stimmt. ;)

Zum Beispiel Duende.

Na mal sehen, was da auf einen zukommt.
 
ja das kann aber so "hinoptimiert" sein - weil es sonst evtl nicht in der gui den flaschenhals gäbe - sondern in der berechnung, weil sie dann zu oft weniger zeitabschnitte zum rechnen bekommen könnte und somit buffer aussetzer bzw die ganze daw verlangsamt und asio aussetzer bekommt (passt sich ja an, wartet auf berechnung)

in deinem beispiel hat dann wohl der bufferthread mit dem algorithmus die prio 1 und der zweite thread für die gui kann nur dann reingrätschen, wenn der erste thread fertig ist und ne lücke lässt
dann hast du eine garantierte berechnungsdauer aber die gui hat dann "jitter" weil mal früher und mal später der lock bereich verlassen wird

man kann auch hilfsfunktionen, die nicht dauernd berechnet werden müssen bzw langsam immer wieder aufgefrischt werden sollen, in einen thread auslagern..

ok ich will das threading thema aber auch nicht zu doll aufkochen lassen.. das wichtigste ist wie immer das was hinten rauskommt -> dein algo wie er rechnet ^^
 
Ich hab jetzt die Sache wieder aufgegriffen.

Hat jemand Ahnung davon, auf welchen GUI Ansatz man heutzutage setzen würde, welcher am schmerzfreisten wäre?

JUCE

Ist schön, Nachteil ist ein fehlendes strukturiertes Handbuch, es gibt nur eine flache technische Doku aller Funktionen/Methoden, und das sind sehr sehr viele!, nicht wie diese untereinander logisch aufgebaut sind, ohne Hierarchie. Einfach finde ich den Einstieg hier deshalb keineswegs.

Steinberg zum Beispiel beschreibt seine SDK schön im Top Down Approach, menschenfreundlich.

Juce wird nur von einer Person gewartet.

Der GUI Editor funzt nicht für das Top GUI Modul, wird angeblich nicht mehr empfohlen, nur noch Direktprogrammierung, na toll!

OpenGL

Ist profesionell, schnell, aber nur Low Level, soweit ich verstanden habe, und es werden keine GUI Elemente realisiert, ist das richtig?

Qt

Cross Plattform Lösung für Widget Kram und Graphik.
Lizenz kostet 5000 Dollar oder so.


VSTGUI 4

Keine Ahnung.


Oder direkt in GDI, GDI+.

GDI+ soll sehr langsam sein.
GDI kennt kein Antialiaising.

Ohne Anti-Aliasing braucht man gar nicht anfangen.

Oder Cockos WDL?

http://www.cockos.com/wdl/


Es ist nicht ohne weiteres klar, wie man am besten
einsteigt und was man lernt. Synthmaker Zeiten sind entgültig passe!

Auf welche Ansätze setzen große Firmen wie NI, Waves und andere? Wahrscheinlich eigene Library?
 
Auf welche Ansätze setzen große Firmen wie NI, Waves und andere? Wahrscheinlich eigene Library?
Ja die haben das einmal richtig selbst angefasst, problem ist nur wenn die Leute die das gemacht haben aussteigen...

Mit Juce wird aber trotzedem noch sehr viel gemacht heute.

Musst du wirklich Plattform übergreifend sein?

Fang doch erst mal an, wenn es denn wirklich was werden sollte, kann man sich immer noch Externe Hilfe für eine andere Platform holen.
 
Ja die haben das einmal richtig selbst angefasst, problem ist nur wenn die Leute die das gemacht haben aussteigen...

Mit Juce wird aber trotzedem noch sehr viel gemacht heute.

Musst du wirklich Plattform übergreifend sein?

Fang doch erst mal an, wenn es denn wirklich was werden sollte, kann man sich immer noch Externe Hilfe für eine andere Platform holen.

ok, so eine gewisse Hierarchie wird hier vermittelt.

https://www.juce.com/api/hierarchy.html

Naja, anfangen mit was? Die größte Hürde wäre erstmal das GUI Framework, zumindest für mein erstes Plugin, da ist der DSP Anteil dann 1% und der Rest wäre GUI, Reaktionsverhalten bei Automatisation usw.
 
Moin

Mit Qt kannst du die Performance ganz schön in den Keller schieben, wenn du dich entsprechend doof anstellst. Hatte mal einen Beratungsauftrag für einen Laminathersteller. Der hatte mit Qt exessiv auf Event Slots gesetzt und dadurch einen riesen Klumpen Overhead an den Hacken...

lg
bird
 
Qt benutzt im VST-bereich wohl eh niemand. würde ich daher eh mal ausklammern.
 
Programmiert hier heute noch jemand hobbymäßig VSTs?
Mir kam auch der Gedanke, dass ich meine Sample-basierten Instrumente, die ich mal für Kontakt entwickelt habe, auf VST-Basis umsetzen möchte. Aber wenn ich das so lese, insb. was buffi so schreibt, vergeht mir die Lust. Ich kann ein bisschen JavaScript und das alte Kontakt Script. Als gelernter Grafiker macht es mir auch Spaß, GUIs zu gestalten. Aber ich sehe schon, dass die Programmierung ein Komplexitätslevel erreicht, dass mich frustrieren würde.

Falls jemand Lust auf ein gemeinschaftliches Hobbyprojekt hätte, würde ich gerne Kontakt aufnehmen. Vielleicht kann ich für euer eigenes Projekt eine GUI stiften und im Gegenzug dafür mir jemand ein VST programmieren.

Hier ein paar Beispiele, was ich vor einigen Jahren für Kontakt gemacht habe:

https://gearspace.com/board/showpost.php?p=14486966&postcount=465
865475d1579901764-share-samples-here-fw-sbd-1_screenshot.png


https://gearspace.com/board/showpost.php?p=14498010&postcount=469
866319d1580333774-share-samples-here-screenshot.png


https://gearspace.com/board/showpost.php?p=14508838&postcount=471
867315d1580758735-share-samples-here-screenshot.png


https://gearspace.com/board/showpost.php?p=14514010&postcount=472
867789d1580935028-share-samples-here-screenshot.png


https://gearspace.com/board/showpost.php?p=14575269&postcount=473
873567d1583529620-share-samples-here-screenshot.gif
 
Mir kam auch der Gedanke, dass ich meine Sample-basierten Instrumente, die ich mal für Kontakt entwickelt habe, auf VST-Basis umsetzen möchte. Aber wenn ich das so lese, insb. was buffi so schreibt, vergeht mir die Lust. Ich kann ein bisschen JavaScript und das alte Kontakt Script. Als gelernter Grafiker macht es mir auch Spaß, GUIs zu gestalten. Aber ich sehe schon, dass die Programmierung ein Komplexitätslevel erreicht, dass mich frustrieren würde.
Es gibt den Maize-Sampler. Ist einfach aufgebaut und ohne grosse Programmierung kann man da eigene Samples als VST Instrument "exportieren". Weiß nur nicht inwieweit Dir die Funktionen ausreichen.

Etwas neuer, flexibler aber wohl komplizierter wäre Hise. Wenn Du aber etwas Ahnung hast, könnte das etwas für dich sein.
 
Programmiert hier heute noch jemand hobbymäßig VSTs?
Ich hab mal mit WDL-OL nen One-Knob-Verzerrer in C++ programmiert:

Im Prinzip schneidet der nur die Amplituden ab, so dass es zu einer digitalen Verzerrung kommt, aber das könnte auch eine gute Grundlage für einen Kompressor sein.

Da ich wusste das ich keine Zeit mehr damit verbringen kann hab ich dann nochmal aufgeschrieben was mir währenddessen so in den Sinn kam:


Ich denke das kann man sich mal so als Schmöker-Lektüre reinziehen wenn man nicht extremst viel Zeit investieren möchte :p.

Im Kern besteht jeder Audio-Insert-Effekt aus diesem Loop:
basic3.png
 
Im Kern besteht jeder Audio-Insert-Effekt aus diesem Loop:
basic3.png
Sehr cool! Vielen Dank für das ausführliche Beispiel. Mal eine grundsätzliche Frage: Den Code schreiben kann ich vermutlich in einem schlichten Texteditor. Aber um das Ergebnis mit GUI zu sehen, muss ich mit einem SDK (in meinem Fall Apple) compilieren? Oder geht das auch mit was anderem? Dieses SDK hatte ich mal installiert, aber irgendwann hat es Probleme gemacht und mir sagte einer, dass sei auf meinem alten Mac gar nicht mehr von Apple unterstützt (was irgendwelche Sicherheitsroutinen angeht).
 
Es gibt den Maize-Sampler. Ist einfach aufgebaut und ohne grosse Programmierung kann man da eigene Samples als VST Instrument "exportieren". Weiß nur nicht inwieweit Dir die Funktionen ausreichen.

Etwas neuer, flexibler aber wohl komplizierter wäre Hise. Wenn Du aber etwas Ahnung hast, könnte das etwas für dich sein.
Aha… dieses HISE sieht vielversprechend aus. Das ist sogar für meinen alten Mac geeignet. Sehr geil. Danke!
 
Sehr cool! Vielen Dank für das ausführliche Beispiel. Mal eine grundsätzliche Frage: Den Code schreiben kann ich vermutlich in einem schlichten Texteditor.
Ja den Code kannst Du in einem Texteditor schreiben, ich bin aber mehr ein Freund von Entwicklungsumgebungen. Je komplexer der Code wird um so mehr weiß man das zu schätzen. Ich mag die Debug-Optionen und den einfachen Kompiliervorgang per Start-Button ;-).

Ich bekomme berufsbedingt immer die neueste, große Version von Visual Studio vom AG. Aber es gibt eine kostenlose "Community Edition". Wenn Du nach Visual Studio 2022 Community Edition googelst findest du die letzte Version für private Nutzung.

Kollegen von mir schwören trotz der kommerziellen Lizenzen aber auf das kostenlose "Visual Studio Code", ich mag lieber den großen Bruder den es wie gesagt umsonst für Privatnutzer gibt :). Und wenn du was verkaufen willst kannst du ja immer noch eine richtige Lizenz kaufen.

Aber um das Ergebnis mit GUI zu sehen, muss ich mit einem SDK (in meinem Fall Apple) compilieren? Oder geht das auch mit was anderem? Dieses SDK hatte ich mal installiert, aber irgendwann hat es Probleme gemacht und mir sagte einer, dass sei auf meinem alten Mac gar nicht mehr von Apple unterstützt (was irgendwelche Sicherheitsroutinen angeht).
Also unter Windows hatte ich auch das Steinberg SDK installiert und da war ein VST-Host dabei, den ich in Visual Studio direkt auf den Start-Button legen konnte. Der hat dann mitgestartet und ich konnte ihm eine WAVE-Datei mitgeben. Ich meine ich hab da auf dem letzten Artikel nen Video verlinkt wo ich das mit Handy gefillmt hatte.
 
HISE ist das Tool !


BTW. Wusste nicht das man mit dem Mazie VSTs machen kann.
Ist aber alles very basic:
  • Poly / Mono / Legato voice mode with glide time.
  • LFO, ADSR envelope and built-in reverb effect.
  • Round-robin / Random overlapped sample trigger.
 
HISE ist das Tool !


BTW. Wusste nicht das man mit dem Mazie VSTs machen kann.
Ist aber alles very basic:
  • Poly / Mono / Legato voice mode with glide time.
  • LFO, ADSR envelope and built-in reverb effect.
  • Round-robin / Random overlapped sample trigger.
Ja, ich habe heute morgen auch von einer nochmal anderen App gelesen, wo man ohne Coding auskommt. Aber die hatte auch den Nachteil, dass die CPU-LAst schnell sehr hoch wird und keine überlappenden Velocity-Zonen erstellen konnte. Sowas scheidet für mich dann doch recht schnell aus, weil ich da kein halbes Ding machen will.
 
Für samplebasierte VSTIs gäbe es möglicherweise noch die Gorilla-Engine von UJAM. Laut Eigenbeschreibung:
  • ein Toolkit for building professional audio plug-ins
  • Focus on creativity, not software development
  • Affordable and accessible
Ich kenne aber nur die Webseite und habe, weil nicht registriert, auch die SDK noch nicht herunterladen können. Da zudem die Page für die Registrierung seit mindestens eineinhalb Jahren überarbeitet und auf persönlichen Kontakt per Email verwiesen wird, könnte es sich möglicherweise um ein nicht weiter gepflegtes oder sogar totes Projekt handeln. Im WWW sind erstaunlicherweise auch überhaupt keine weiteren Informationen zur Gorilla-Engine zu finden, obwohl laut Webseite über 200k+ Plugins damit verkauft worden sein sollen.

Da ich als Selbstständiger in der IT momentan und auf absehbare Zeit keine Kapazität frei habe, um mich ernsthaft (nebenberuflich) auch noch mit der Entwicklung von VSTs und der Gorilla-Engine zu befassen, habe ich, trotz Neugier und Interesse, bislang von der Verbindlichkeit einer persönlichen Registrierung per Email Abstand genommen. Wenn jemand da weniger Skrupel hat und Kontakt aufnimmt, wäre ich am aktuellen Status und den Konditionen allerdings auch sehr interessiert. Der Appetit kommt bekanntlich beim Essen ;)
 
Für samplebasierte VSTIs gäbe es möglicherweise noch die Gorilla-Engine von UJAM. Laut Eigenbeschreibung:
Danke für den Tip. Die Gorilla Engine muss mir mal als Anzeige irgendwo untergekommen sein.
Ich hatte die Seite damals ganz schnell wieder verlassen weil deren Profit (fees) vom Sale eines Plugins abhängt.
Da ist man dann ständig an UJAM gebunden.

Dennoch habe ich jetzt mal nach dem Deal gefragt und hoffe auf eine Antwort mit konkreten Prozentsatz, damit man sich einen Überblick der laufenden Kosten verschaffen kann.
Wieviel man selber scripten muss geht von der Seite auch nicht aus. Mal schauen was die antworten
 
Ich hatte die Seite damals ganz schnell wieder verlassen weil deren Profit (fees) vom Sale eines Plugins abhängt.

Ist damit jetzt die Anzahl (also der Erlös) der verkauften Plugins gemeint, oder grundsätzlich ob die SDK kommerziell genutzt wird oder nicht? Letzteres Lizenzmodell wäre jedenfalls nicht so ungewöhnlich in der IT bzw. bei Anwendungssoftware. Auf der aktuellen Webseite von UJAM ist zudem auch von einem "Monthly Plan" die Rede. Und das klingt für mich danach, als ob man die Software nur dann bezahlen muss, wenn man sie auch aktiv nutzt. Vergleichbar dem Mietmodell von Adobe oder vielen Pluginherstellern. Grundsätzlich wäre das ja auch gar nicht schlecht, erst recht nicht wenn man nebenberuflich damit arbeitet. Es kommt aber natürlich auch auf die Preise an.

Jedenfalls: Ich bin Kunde und besitze einige Plugins von denen. Und wenn ich nicht wüsste, dass UJAM ein seriöser Laden ist, würde ich die Darstellung auf der Webseite ansonsten für einen Fake halten (schon alleine, weil die einzige Darstellung der GUI den Titel "Mockup-1.png" trägt). Es sind wie gesagt ja auch keinerlei Infos über die Gorilla-Engine im WWW zu finden. Vielleicht sind Nebengewerbler oder Hobbyisten aber auch gar nicht als Zielgruppe erwünscht (was ich durchaus verstehen könnte, denn Dokumentation und Support kostet sehr viel Zeit und Geld :cool:).

Da ist man dann ständig an UJAM gebunden.

Wenn man mit SDKs, Drittanbieter-Modulen oder Frameworks arbeitet, ist man sowieso immer an irgendjemanden gebunden. Für gewöhnlich bezahlt man aber unabhängig von der Anzahl der verkauften Softwarelizenzen eine Pauschale und trägt danach dann das finanzielle Risiko selbst.

Dennoch habe ich jetzt mal nach dem Deal gefragt und hoffe auf eine Antwort mit konkreten Prozentsatz, damit man sich einen Überblick der laufenden Kosten verschaffen kann.

Super. Ich wäre Dir jedenfalls dankbar, wenn Du mir/ uns Bescheid geben könntest, sobald Du eine Antwort erhalten hast 👍

Wieviel man selber scripten muss geht von der Seite auch nicht aus. Mal schauen was die antworten

Laut Werbeaussage von Peter Gorges soll die Gorilla Engine das "akustische Äquivalent" zur "Unreal Engine" sein, also viele Funktionen (und Klassen) schon von sich aus mitbringen, die dann mit nur noch wenig Programmieraufwand eingebunden werden können. Und ob das SDK auch ein GUI-Toolkit enthält, ist dann ja auch noch mal eine Frage für sich. Das alles ist jedenfalls mal kein kleines Projekt - und ehrlich gesagt bin ich ziemlich skeptisch, ob die Werbung und Außendarstellung mit der Realität übereinstimmt. Mich macht diese Geheimniskrämerei (keine Details, keine Bilder, keine Downloads und Kontakt nur per Email etc.) jedenfalls stutzig. Aber schauen wir mal ...
 
Ist damit jetzt die Anzahl (also der Erlös) der verkauften Plugins gemeint, oder grundsätzlich ob die SDK kommerziell genutzt wird oder nicht
Ich denke beides zusammen bzw:
zwei fees, die alles abdecken sollen. Ich habe noch keine Infos erhalten.

Für mich ist die Webseite auch ein wenig durcheinander.
Da steht no brainer licensing model. Und das wär wirklich klasse, wenn man die Engine monatlich mieten kann - aber wenn man weiter unter scrollt findet man: no upfront costs aber auch: Fees based on projected revenues. Also was denn jetzt?


Es sind wie gesagt ja auch keinerlei Infos über die Gorilla-Engine im WWW zu finden. Vielleicht sind Nebengewerbler oder Hobbyisten aber auch gar nicht als Zielgruppe erwünscht (was ich durchaus verstehen könnte, denn Dokumentation und Support kostet sehr viel Zeit und Geld :cool:).
Das ist bestimmt damit verbunden dass die 200k+ verkauften Plugins eben mal von 30+ Hersteller kommen. 31 ist auch über 30 :green:

Super. Ich wäre Dir jedenfalls dankbar, wenn Du mir/ uns Bescheid geben könntest, sobald Du eine Antwort erhalten hast 👍
Das werde ich machen ;)
 

Oft gelesene Themen

Zurück
Oben