Kann wer die VST3-SDK-Samples mit dem gcc(mingw) kompilieren?? Bzw. woher __uuidof() nehmen?



  • Mo0oin!
    Erstmal vorweg: Mein Hirn schmilzt!
    Ich habe den ganzen letzten Tag damit verbracht, mit Code Blocks irgendwie die mitgelieferten HelloWörld-Beispiele vom Steinberg VST-SDK zu kompilieren - erfolglos.

    Die müssen irgendeinen Pakt mit dem MS haben! (Wo ist der Teufel-Smilie?!)
    MSVC-Projektdateien sind dabei, das wars aber auch schon. Für die Docs bin entweder ich zu doof, oder die sinds für mich.. ich weiß jedenfalls nicht wirklich, was bei dem SDK von mir erwartet wird, damit nachher ein schönes Audio-Plugin (.dll) dabei heraus kommt.
    Ich habe aber auch noch nie dlls kompiliert. Das könnte auch zur Hirnschmelze beitragen.

    Das SDK beinhaltet irgendwie auch VST3 und VST2.x. Welche Version die Beispiele aber wollen, oder ob das egal ist, hat sich mir noch nicht offenbart.
    ..So wie ich das sehe, muss man da auch nichts vorkompilieren - einfach die passenden .cpp einbinden und fertig..
    MSVC-Projekt importieren hat mir auch nicht geholfen,.. nur so nebenbei.

    Aber immerhin habe ich durch viel Rumprobieren (Dateien nach fehlendem Kram durchsuchen und einbinden) schon einige Compiler- und Linkerfehler beseitigen können.

    Ich frage mich dabei nur, ob die Steinberg-Leute das so von einem erwarten...
    Geholfen hat bisher:
    - ein "-fpermissive"-Compilerflag wegen irgendwelcher string-casts
    - die Ersetzung von __forceinline mit einem gcc-Äquivalent (inline tuts auch)

    Jetzt fehlt aber noch ein Ersatz für __uuidof(). Ich weiß nicht wozu das gut ist, oder was es macht. Ich weiß nur, dass der gcc das auch nicht weiß - und das ist schlecht.
    Kennt sich jemand damit aus und weiß einen Ersatz für diese MSVC-Eigenheit?

    Dafür, dass es VST3 schon relativ lange gibt, findet man echt wenig zum SDK im Netz. Außer, dass es von vielen gemieden wird..

    Soweit zu meinem "Tagebuch". Jetzt meine Frage/Bitte an alle, die non-MS-Compiler nutzen und evtl. 5Min Zeit haben..:

    Könnt ihr euch mal das SDK runterladen (.zip ~70MB) und versuchen das Sample AGain, oder ADeley zu kompilieren!? Man muss theoretisch nichts weiter machen, als seine IDE auf "dll" zu konfigurieren..

    Hier der Link zum SDK: https://www.steinberg.net/de/company/developer.html
    Und hier noch ein Link zu einem älteren Tutorial, das eigentlich genau das beschreibt, was ich vor habe (was neues zu finden war mir nicht möglich..):
    https://learnvst.wordpress.com/old-site/the-build-environment/building-from-an-ide/1-the-sdk-examples/

    Also ich habe irgendwie das Gefühl, dass ich irgendwas übersehen habe, und sich darum alles so umständlich gestaltet. Ich habe zumindest keine wirkliche Struktur erkennen können..
    Mit anderen SDKs und Frameworks hatte ich bislang keine großen Probleme, und einige davon könnte man gemessen an "Steinberg" als Noname bezeichnen.
    Ist wie mit meinen LED-Lampen hier. Die von Osram sind schon kaputt (~1 Jahr), die Noname leuchten wie am ersten Tag..

    Kann sich bitte jemand meiner erbarmen. Selbst wenn nachher auch keine dll dabei raus kommt. Mir gehts jetzt auch darum, herauszufinden, wer hier die Sacher verbockt hat, ich oder die.. 😃

    MfG
    0xMöbius



  • Dieser Thread wurde von Moderator/in Arcoth aus dem Forum C++ (alle ISO-Standards) in das Forum Compiler- und IDE-Forum verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Warum willst du die DLLs unbedingt mit MinGW compilieren, warum nimmst du nicht VStudio wenn die Projektdateien dafür schon vorliegen?
    Es kann dir doch ganz egal sein, wie die DLL erzeugt wurde, du kannst die zuvor mit VS erzeugte DLL doch später ganz einfach in deinem MinGW-Projekt verwenden?!

    Ich habe again mit VS 2015 mal ausprobiert und nach einigen Umbauten im sln-Projekt auch compiliert bekommen:

    1>------ Neues Erstellen gestartet: Projekt: base, Konfiguration: Debug Win32 ------
    1>  baseiids.cpp
    1>  classfactory.cpp
    1>  fatomic.cpp
    1>  fbitset.cpp
    1>  fbuffer.cpp
    1>  fcpu.cpp
    1>  fcriticalperformance.cpp
    1>  fdebug.cpp
    1>  fdynlib.cpp
    1>  finitializer.cpp
    1>  fmemory.cpp
    1>  fobject.cpp
    1>  fpoint.cpp
    1>  frect.cpp
    1>  fregion.cpp
    1>  fstreamer.cpp
    1>  fstring.cpp
    1>  fthread.cpp
    1>  istreamwrapper.cpp
    1>  timer.cpp
    1>d:\projekte\vst3 sdk\base\source\fstring.cpp(1494): warning C4302: "Typumwandlung": Verkürzung von "LPWSTR" in "Steinberg::char16"
    1>d:\projekte\vst3 sdk\base\source\fstring.cpp(1517): warning C4302: "Typumwandlung": Verkürzung von "LPWSTR" in "Steinberg::char16"
    1>d:\projekte\vst3 sdk\base\source\fstring.cpp(1542): warning C4302: "Typumwandlung": Verkürzung von "LPSTR" in "Steinberg::char8"
    1>d:\projekte\vst3 sdk\base\source\fstring.cpp(1554): warning C4302: "Typumwandlung": Verkürzung von "LPSTR" in "Steinberg::char8"
    1>  updatehandler.cpp
    1>  conststringtable.cpp
    1>  funknown.cpp
    1>  base.vcxproj -> D:\Projekte\VST3 SDK\base\win\Win32\Debug\base.lib
    2>------ Neues Erstellen gestartet: Projekt: AGain, Konfiguration: Debug Win32 ------
    2>  again.cpp
    2>  againcontroller.cpp
    2>  againeditor.cpp
    2>  againentry.cpp
    2>  pluginview.cpp
    2>  vstaudioeffect.cpp
    2>  vstbus.cpp
    2>  vstcomponent.cpp
    2>  vstcomponentbase.cpp
    2>  vsteditcontroller.cpp
    2>  vstguieditor.cpp
    2>  vstinitiids.cpp
    2>  vstparameters.cpp
    2>  dllmain.cpp
    2>  pluginfactoryvst3.cpp
    2>  funknown.cpp
    2>  ustring.cpp
    2>  cvstguitimer.cpp
    2>  vstcontrols.cpp
    2>  vstgui.cpp
    2>  vstguidebug.cpp
    2>d:\projekte\vst3 sdk\vstgui.sf\vstgui\vstgui.cpp(3674): warning C4996: 'GetVersionExW': wurde als veraltet deklariert
    2>  c:\program files (x86)\windows kits\8.1\include\um\sysinfoapi.h(442): note: Siehe Deklaration von "GetVersionExW"
    2>again.obj : warning LNK4075: /EDITANDCONTINUE wird aufgrund der Angabe von /SAFESEH ignoriert.
    2>     Bibliothek "Win32\Debug\AGain.lib" und Objekt "Win32\Debug\AGain.exp" werden erstellt.
    2>  again.vcxproj -> D:\Projekte\VST3 SDK\public.sdk\samples\vst\again\win\Win32\Debug\AGain.dll
    ========== Alles neu erstellen: 2 erfolgreich, 0 fehlerhaft, 0 übersprungen ==========
    

    Aber ich gebe dir recht, ich verstehe auch nicht, warum fast alle Lib-Anbieter ihre Libs nicht gleich in vorcompilierter Form anbieten, sondern dem Anwender es zumuten, irgendwelche Spezialumgebungen der IDE u.ä. zunächst mal herzustellen nur um dann einen Compilerlauf damit selbst durchführen zu müssen.

    Warum nicht ganz einfach *eine .h und *eine .lib/*.a, dann vielleicht noch eine 32/64-Bit Version für Win+Linux und noch die Aussage, ob Multithread-fähig oder nicht und fertig.

    Wie gesagt, ich verstehe es auch nicht und würde selbst nie dem Anwender solches Zeugs zumuten, der hat genug damit zu tun, die oftmals umfangreichen Lib-Schnittstellen zu erlernen.

    Übrigens gab es hier schon mal das Problem, leider ohne Lösung:
    https://www.c-plusplus.net/forum/329372

    Die Lösung dafür war relativ einfach:
    statt Linker-Output

    $(CommonProgramFiles)\VST3\Steinberg\$(ProjectName).vst3
    

    korrekt:

    $(OutDir)\$(ProjectName)$(TargetExt)
    

    verwenden und statt Zielerweiterung

    .vst3
    

    korrekt

    .dll
    

    Dieser ganze Eiertanz wäre hinfällig, wenn die Steinberg-Leute eine fertig compilierte Lib anbieten würden und man nicht in deren suboptimalen Projektsettings noch rumfrickeln müsste.



  • Und ich dachte hier würde sich nichts mehr tun - falsch gedacht. Hat sich immerhin noch ein Leidensgenosse eingefunden.
    Man könnte sagen, dass die Steinberg-Leute denjenigen, die GCC nutzen offenbar mehr zutrauen als den MSVC-Nutzern ;). Aber wenn es dann unkompilierbar wird, scheint es andere Gründe zu geben.. Ist die erste und einzige mir bekannte Lib, die sich so verhält. Naja, dann eben erstmal kein VST3 .. vielleicht wirds mit VST4 ja besser 😃

    Warum willst du die DLLs unbedingt mit MinGW compilieren, warum nimmst du nicht VStudio wenn die Projektdateien dafür schon vorliegen?

    ... , sondern dem Anwender es zumuten, irgendwelche Spezialumgebungen der IDE u.ä. zunächst mal herzustellen nur um dann einen Compilerlauf damit selbst durchführen zu müssen.

    In meinem Fall wäre es dann eine spezielle IDE mit spezieller Spezialumgebung für diesen einen Durchlauf..



  • Na so schlecht ist VStudio nun auch wieder nicht zu installieren, ich würde aber VS2013 Express nehmen (Windows Desktop), ist einfach sehr viel schneller als VS 2015 zu installieren und zu starten.



  • Wie man ja sieht, gibt es bei MS nichts umsonst. Wenns so weiter geht, gehört mir bald sogar mein eigener PC nicht mehr, oder zumindest Teile davon, obwohl ich die Teile und den Strom für die Teile bezahlt habe. Bleibt abzuwarten, wie fruchtbar dieses Geschäftsmodell hierzulande sein wird.
    Das ist bei freier Software anders. Und Schritt 1 freie Software zu unterstützen, ist sie zu nutzen.
    So eng sehe ich das zwar auch alles nicht, aber wenn es denn ohne große Umstände möglich ist, bleibe ich bei meiner ollen IDE. Ich habe mich schon so darauf eingegroov-t, und auch mit VST3 kann man schlechte Plugins schreiben.

    Das mit der fehlenden Geschwindigkeit wäre schon das Aus. Als ich angefangen habe zu programmieren, bin ich erstmal alle (freien) IDEs durchgegangen. Ich meine CodeLite war auch ein Schwergewicht. Quasi bei jedem Tastendruck 100% CPU, oder so.. Dev-C++ war/ist, was das angeht, wirklich flott - ist aber trotzdem nicht dauerhaft auf der Platte gelandet; ich weiß garnicht mehr warum.. 😕


Anmelden zum Antworten