Requirements Plugin Programmierung

  • Ersteller synthpark
  • Erstellt am
Nochmal vielen Dank für die Empfehlung HISE, @Realist !

Ich baue grade schon mein erstes VST und bin davon begeistert, wie man mit HISE arbeitet. Eigentlich funktioniert es sehr ähnlich wie Kontakt.

Edit: Ich muss mich korrigieren. Das kompilieren eines VSTs habe ich nach mehreren Stunden noch nicht geschafft. Ich habe zwar die Doku gelesen und alle Komponenten installiert, aber ich bekomme immer wieder neue Fehlermeldungen, nach denen ich googlen muss. Aktuell stocke ich und finde keine Antwort. Nun stellt sich doch eine gewisse Frustration ein, wie ich oben schon befürchtet habe. Mal schauen, wie sich das entwickelt.
 
Zuletzt bearbeitet:
Nun stellt sich doch eine gewisse Frustration ein, wie ich oben schon befürchtet habe. Mal schauen, wie sich das entwickelt.
Ich drücke Dir die Daumen, dass Du eine Lösung findest.
Im Programmieren bin ich echt ne Niete. Hatte mich mal immer wieder mit beschäftigt, aber das ist mir zu hoch.
Ich musste damals notgedrungen SPS lernen. Das war schon eine Krampf bei mir. :)
 
Ich drücke Dir die Daumen, dass Du eine Lösung findest.
Im Programmieren bin ich echt ne Niete. Hatte mich mal immer wieder mit beschäftigt, aber das ist mir zu hoch.
Ich musste damals notgedrungen SPS lernen. Das war schon eine Krampf bei mir. :)
Danke dir! Ich habe mich jetzt mal in dem HISE Forum angemeldet und werde versuchen, mich die nächsten Tage ein bisschen durchwurschteln. Je nach dem, wie hoch die Frustrationstoleranz sein wird, entscheide ich dann, ob es mir noch so wichtig ist. Da ich die Dinger nicht unbedingt im VST-Format haben muss, hält sich der Ehrgeiz etwas in Grenzen.
 
Ich schreibe zwar keine VST Plugins, aber kompiliere solche aber häufiger unter Windows mit VisualStudio (Community Edition)
Persönliche Erfahrung ist, daß JUCE Projekte recht unkompliziert zu bauen sind und oft die Nutzung von CMake den Build erheblich vereinfacht. Sowieso mag ich es, wenn ich auf meinem Notebook dann ein make j16 nutzen kann ;-)
Ich nutze auch gerne Plugins mit CUDA oder OpenCL Support (entlastet die CPU erheblich)
 
Ich schreibe zwar keine VST Plugins, aber kompiliere solche aber häufiger unter Windows mit VisualStudio (Community Edition)
Persönliche Erfahrung ist, daß JUCE Projekte recht unkompliziert zu bauen sind und oft die Nutzung von CMake den Build erheblich vereinfacht. Sowieso mag ich es, wenn ich auf meinem Notebook dann ein make j16 nutzen kann ;-)
Ich nutze auch gerne Plugins mit CUDA oder OpenCL Support (entlastet die CPU erheblich)
Danke für den Input, aber leider ist mir das alles zu kompliziert. Ich habe HISE für ein Tool gehalten, mit dem der Programmier-Laie VST bauen kann. Aber im Grunde nützt das ausgeklügeltste HISE-Projekt wenig, wenn man dann doch Fachwissen braucht, um das Ding überhaupt zum VST kompilieren zu können. Ich glaube, die Sache hat sich für mich erledigt. Die lange Liste an Warnungen und Fehlern, durch die der Build fehlschlägt, kann ich persönlich gar nicht abarbeiten, weil mir das Fachwissen fehlt. Ich habe die Meldungen hier mal als Textfile angehängt.
 

Anhänge

  • build-failed.txt
    6,2 KB · Aufrufe: 90
Inzwischen hat sich mein Frust gelegt und ich will es mit HISE nochmal angehen. Nun bin ich mit der Sache ein wenig weitergekommen, was das Verständnis vom Kompilieren angeht. Für alle, die da vielleicht wie ich, ein wenig Berührungsängste haben oder denken, das ist zu kompliziert, hier mal ein paar Erkenntnisse, die die Hürde nehmen könnten...

Ein VST/AU zu erzeugen, ist tatsächlich leider nicht ganz so einfach, dass man in einem Programm wie HISE schön bequem seine Samples mappt, schönes GUI bastelt und "exportieren" klickt und das wäre es schon gewesen.

Der Klick auf "Exportieren als VSTi Plugin" ist eigentlich der erste Schritt im Prozess des Kompilierens. Was HISE damit exportiert, ist erstmal nur eine Projekt-Datei, die dann im sog. Projucer (eine weitere Applikation im HISE-Verzeichnis) geöffnet werden muss. Von dort aus wählt man dann "Save and export to IDE". Damit sollte dann XCode (oder auf Windows vermutlich Visual Studio) mit eurem Projekt aufgehen. Und erst dort sind wir an der Stelle im Prozess angekommen, an der letztendlich das VST/AU/Standalone erzeugt wird. Bin gerade nicht am Rechner, um es genau zu zitieren, aber man wählt, glaube ich, im Menü File Build release und erhält dann das Ergebnis.

Diese hier hervorgehobenen Komponenenten und IPP (Intel Performance Primitives) müssen also auf eurem System installiert sein, um wirklich kompilieren zu können.

Das erfährt man allerdings nicht, wenn man einfach nur Download Latest Version auf der HISE-Homepage wählt. Im HISE-Forum wird stattdessen geraten "build HISE from source"... Sagte mir auch erstmal nichts. Aber damit ist gemeint, man solle über Download HISE Source Code gehen. Da kommt man auf eine GitHub-Seite mit der Versions-Historie. Und unter den Paketen, die man da herunterladen kann, ist ganz gut beschrieben, dass man die oben besagten Komponenten braucht und wie sie zu installieren sind.

Ich glaube, womit man sich als Einsteiger schwer tut, ist, wenn man mit Fehlermeldungen und Warnungen konfrontiert wird. Da steht man erstmal wie der Ochs vor'm Berg, weil man sie nicht versteht. Laut David Healey (gute YouTube-Tutorials dazu) kann man Warnungen (gelb) weitgehend ignorieren, sollte aber Fehlermeldungen (rot) auf den Grund gehen. Und die googelt man dann eben und landet irgendwo im HISE-Forum. Die meisten Fehlermeldungen bei einem einfachen Projekt haben höchstwahrscheinlich manche Foristen schon gehabt.

Das ist jetzt mal mein aktueller Kenntnisstand.
 
Ein paar Videos von David Healey hatte ich mir letzte Woche mal zu Gemüte geführt, um das Prinzip zu verstehen.
Da gibt es schon diverse Fallstricke. Das die Version auf der Website nicht die aktuellste ist und man auf alle Fälle die Files von Github nehmen und selber kompilieren soll ist mir auch in Erinnerung geblieben.
Auch das man bei der Samplebearbeitung die Benennung der Files nach einem Schema bennenen soll um später nicht in Trouble zu kommen.
Das ist schon sehr komplex und recht zeitintensiv.

Ich hoffe Du berichtest weiter, finde das Thema trotzallem noch sehr interessant, auch wenn ich nur die Hälfte verstehe. :)
 
Auch das man bei der Samplebearbeitung die Benennung der Files nach einem Schema bennenen soll um später nicht in Trouble zu kommen.
Das ist etwas, dass du nicht zwangsläufig machen musst. Du kannst die Samples auch, wie in Kontakt, einfach manuell mappen. Meine Samples habe ich bislang immer so erstellt, dass sie Zeitstempel in chromatischer Reihenfolge haben. Wenn man sie dann im Finder nach Datum sortiert und dann ins Mapping-Fenster zieht, hat man sie recht schnell alle auf den richtigen Tasten. Dennoch kann es sehr sinnvoll sein, nach dem empfohlenen Schema vorzugehen – das ist in dem Music Box Tutorial ganz gut beschrieben.

Ich werde da in nächster Zeit weiter rumtüfteln und auf jeden Fall berichten, wenn mein erstes Rompler-VST fertig ist. :D

Kleiner Nachtrag zum letzten Post: David Healey hat mir heute geschrieben, dass man die IPP wohl an einem Mac nicht zu installieren braucht. Man möge nur noch mal die Einstellungen im Projucer kontrollieren, dass das dort als Option deaktiviert ist.
 
Übrigens: HISE ist wohl nicht dazu gedacht, Instrumente zu bauen, die alle verwendeten Waveforms 'unter der Haube' haben (ausgenommen Impulsantworten). Das Sample-Material soll stets als HLAC-Archiv oder unkomprimiert zur Installation mitgeliefert werden und landet in einem separaten Ordner. Macht eigentlich nix, aber fand ich ganz interessant, gleich zu erfahren (will eine Art Synth-Rompler basteln).
 
HISE ist wohl nicht dazu gedacht, Instrumente zu bauen, die alle verwendeten Waveforms 'unter der Haube' haben.
Nachtrag dazu: Die Sache mit den Samples ist aus meiner Sicht nicht ausgereift, sofern man ernsthaft ein Produkt mit Verkaufsabsicht entwickeln will. Denn: Wer sich ein solches VST installiert, wird beim ersten Aufruf dazu aufgefordert, entweder den Pfad zum Speicherort der Sampels anzugeben, oder die Samples zu "installieren". Das könnte die weniger Computer-affinen Leute schonmal abschrecken. Und dann kommt noch hinzu, dass wenn man beides wegen Unfähigkeit abbricht, einem ein Dialog mit mehreren Eingabefeldern angezeigt wird – der vom Plugin-Fenster beschnitten wird, wenn es nicht groß genug ist. Christoph schreibt im Forum, dass sie das wohl auch nicht so schnell beheben werden – und schlagen vor, dass in einem Handbuch ganz vorne und rot rein zu schreiben und: das PlugIn eben so groß zu gestalten, dass der zweite Dialog Platz hat. Naja... Für mich und mein kleines Hobby akzeptabel, aber schon ein nicht unerheblicher Nachteil in Sachen UX.

Ich persönlich mache mir die PlugIn-Installation etwas übersichtlicher, indem ich den Sample-Ordner in die .vst-Datei reinschiebe (geht nur am Mac). Aber damit entfällt die oben genannte Prozedur halt trotzdem nicht.
Hier ein Thread aus dem Forum dazu.

Aber insgesamt trotzdem ganz spannend. Ich werde schon das ein oder andere PlugIn bauen, dass ich schonmal für Kontakt gemacht habe.
 
Zuletzt bearbeitet:
Leider noch nichts. Ich habe denen am 08.02 geschrieben. Wie es aussieht gibts kaum Nachfrage für die Engine ?
Ist das vielleicht tatsächlich ein totes Projekt? Die sind sonst eigentlich recht fix und kompetent im Support (und sehr freundlich). Und von daher finde ich es sehr ungewöhnlich, dass nicht geantwortet wurde.

Schade. Hätte interessant werden können 🤓
 
Nachtrag dazu: Die Sache mit den Samples ist aus meiner Sicht nicht ausgereift, sofern man ernsthaft ein Produkt mit Verkaufsabsicht entwickeln will. Denn: Wer sich ein solches VST installiert, wird beim ersten Aufruf dazu aufgefordert, entweder den Pfad zum Speicherort der Sampels anzugeben, oder die Samples zu "installieren". Das könnte die weniger Computer-affinen Leute schonmal abschrecken.

Also ich kenne es eigentlich schon quasi als Standard dass man bei der Installation von größeren Sample-Instrumenten/Libs extra gefragt wird wo die samples installiert werden sollen (denke das sollten auch alle Computer-User hinkriegen ^^).
Ich mag's auch gar nicht so gern wenn die samples mit einem VSTi zusammengepackt sind (z.B. bei Maize Instrumenten), weil ich eigentlich gerne ne extra Festplatte/Pfad nutze für meine ganzen samples.
 
Ist das vielleicht tatsächlich ein totes Projekt? Die sind sonst eigentlich recht fix und kompetent im Support (und sehr freundlich). Und von daher finde ich es sehr ungewöhnlich, dass nicht geantwortet wurde.

Schade. Hätte interessant werden können 🤓
Vielleicht melden die sich noch.
Bei den 30+ Entwicklern kann man davon ausgehen dass die Hälfte internals und promo Aktionen sind. Das heißt für den kleinen Entwickler ist nicht viel Platz. Das ist ja alles Business. Mag denen jemand als Firma anschreiben? Ich bin als privatmann im start up nicht weit gekommen - bis jetzt
 
Also ich kenne es eigentlich schon quasi als Standard dass man bei der Installation von größeren Sample-Instrumenten/Libs extra gefragt wird wo die samples installiert werden sollen (denke das sollten auch alle Computer-User hinkriegen ^^).
Ich mag's auch gar nicht so gern wenn die samples mit einem VSTi zusammengepackt sind (z.B. bei Maize Instrumenten), weil ich eigentlich gerne ne extra Festplatte/Pfad nutze für meine ganzen samples.
Okay, heutzutage sind einfach viele VST-Instrumente im Grunde groß angelegte Rompler mit massig Multi Samples, Round Robin und allem… Da macht es Sinn, die Soundbanks extern zu lagern – keine Frage. Ich bin halt davon ausgegangen, ein VST zu machen muss nicht unbedingt das bedeuten. Die Dinger, die ich machen will, kommen oft mit sehr wenig Sample-Material (30 MB wäre schon viel) aus und sind aus Sicht des Anwenders eher sehr simple Synthesizer, denn Sampler, die irgendwelche akustischen Instrumente möglichst detailtreu virtualisieren sollen. Da hätte ich schon gern, dass das jemand einfach in den VST-Ordner kopieren und loslegen kann, ohne wegen ein paar MB an Wellenformen extra Samples lokalisieren oder installieren zu müssen. Ich sag ja nicht, dass das nichts taugt – im Gegenteil, ich bin da jetzt mal eine Weile damit beschäftigt. Aber als Option wäre die Inklusion nicht schlecht.
 
Vielleicht melden die sich noch.
Bei den 30+ Entwicklern kann man davon ausgehen dass die Hälfte internals und promo Aktionen sind. Das heißt für den kleinen Entwickler ist nicht viel Platz.

Ich kann mir echt nicht vorstellen, dass sie deshalb nicht antworten.

Da sich die Kontaktseite seit mindestens eineinhalb Jahren "under Construction" befindet, und aktuell auch nicht auf die Email geantwortet wird, gehe ich mittlerweile eher davon aus, dass wir gerade versuchen ein totes Pferd zu reiten - oder den Pferdestall über ein anderes Tor betreten müssen. Wenn der Hafer zu sehr sticht, könnte man ja auch ein Request beim Support von Ujam einreichen. Da bekommt man bestimmt eine Antwort.

Es wäre davon unabhängig vielleicht aber auch ganz interessant, sich jetzt schon mit CLAP und Midi2.0 zu beschäftigen. Einen Wrapper liefert die Open Source-API jedenfalls mit. Um damit einen simplen Sampler zu basteln, oder nebenbei als Hobby zu entwickeln, ist das ganze ohne Vorkenntnisse aber natürlich etwas zu zeitintensiv :eek:. Und für die Musik muss ja auch noch Zeit übrig sein 😊

Sag mir bitte Bescheid, falls Du neue Infos bekommen solltest. Danke.
 
hello world.PNG
 
Kleines Update auch von mir, bezüglich VST bauen mit HISE…

Inzwischen konnte ich alle Funktionen umsetzen, die ich im Vergleich zu Kontakt noch vermisst hatte. Und da muss ich sagen, gefällt mir das Code schreiben in HISE viel besser, weil es fast pures JavaScript ist. Aber auch die grafische Oberfläche der Module ist dort viel besser geraten. Man braucht scohn etwas Zeit, um sich einzuarbeiten, aber ich bin nun in wenigen Wochen schon sehr weit gekommen – vor allem Dank der Hilfe des HISE Forums (kann ich nur empfehlen, bevor man irgend nen Scheiß ließt, der einem eh nur die Laune verdirbt :D ).

Bildschirmfoto 2023-03-13 um 20.56.45.png
 

Oft gelesene Themen

Zurück
Oben