Ich arbeite seit ewigen Zeiten - wenn - dann mit dem Wavelab 5 und habe mir für einen anderen Rechner die LE Versionen von Cubase und Wavelab installiert, um dort direkt aufnehmen zu können. Was diese Versionen an bugs haben, ist gelinde gesagt ein Witz. Die Bedienbarkeit ist einfach nicht gegeben. Es kann eigentlich nicht sein, daß Ich größere Probleme habe, mich in die aktuelle Software einzuarbeiten, als es mal gekostet hat, mich überhaupt ins Wavelab einzuarbeiten. Fürher war das einfacher und intuitiver. Und Ich kann mir nicht vorstellen, dass das an LE liegt. Das ganze sieht aus, als hätten da vor ein paar Jahren einige Softwareentwickler gekündigt und wurden durch neue ersetzt, die alles neu hingeschmiert haben und mal gleich ihre eigenen Strategien implementiert haben. Wäre interessant, dazu mal von der Firma was zu hören. SO werde Ich im Traum keine aktuelle Vollversion davon kaufen.
Zum 32/64 Bit Problem: Es gibt praktisch keinen Grund, warum man nicht zwei Versionen anbieten können sollte. Ich bin zwar nicht mehr 100% in der Windows-Schiene drin, entwickle aber nach wie vor Software auf C++, habe seit 1991 Erfahrung und kann sagen: Es gab - wenn - mal ein Problem von der 16 Bit-Schiene des W95 wegzukommen und auf 32 Bit zu übersetzen. Zwischen 32Bit und 64Bit gibt es aber keinen substanziellen Unterschied im OS. Anpassungen für 64Bit macht in erster Linie der Compiler und wenn man über ein built-framework arbeitet, ist das sowieso nochmal weniger Aufwand. Unter wxWidgets z.B. ist es für mich EIN Schalter. Für das hosten von 32 Bit plugins wiederum böte sich ein Generaladapter an, da der so compilierte Code per Emulation auf einer 64 Bit Maschine kein Problem sein kann. Umgekehrt wäre immer ein Problem, ein 64 Bit Submodul in einer 32er Architektur zu packen und dann zeitlich konsistent zu emulieren - wobei das funktionell auch immer geht. Ist halt nicht effektiv.
Es wäre also kein Thema, ein Programm zu zu stricken, dass es alte Module direkt miteinbeziehen kann, selbst wenn das gfs nicht ohne weitere Latenz geschehen kann. Da scheint es schon andere Gründe zu geben
Umgekehrt muss man sich fragen, worin für den Pluginhersteller das Problem besteht, einen Code durch einen 64 -Bit Compiler zu jagen und seinen Kunden ein update anzubieten. Der Code wird dann sicher nicht optimal, aber kompatibel. Klar ist, dass viele plugin Produzenten den Wechsel der OS-Basis auf 64 und/oder VST3 dazu nutzen, altes wegzuschmeissen und ihren Kunden wieder mal was Neues zu verkaufen. Manche arbeiten aber vielleicht mit Visual C++ und haben nicht den kostenpflichtigen 64Bit-Compiler
Wie auch immer:
Das Thema muss man sich vor Augen führen, wenn es um die Halbwertszeit von Software geht! Ich führe ja seit 10 Jahren eine Diskussion mit denen, die die Nutzung meiner eigenen Hardware in VHDL kritisieren und auch in Frage stellen, ob nicht die "Altbackenen" die überhaupt in HW investieren, nicht ständig neu kaufen müssen, weil die Hardware ja "alt" wird und kaputt geht, während die Software ewig hält und sogar leistungsfähigiger wird, wenn die CPUs besser werden.
Nun, man sieht an solchen Beispielen, dass manche Software eher obsolete wird, als mache Hardware!!!! Meine DSP-HW von 2003 bin Ich jederzeit in der Lage, in neue FPGAs zu compilieren, so wie es mir auch möglich ist, meine SW-neu zu übersetzen. Ach ja, meine alten EMU-Geräte und mein Access Virus sind auch noch nicht verfault, sondern produzieren nach wie vor entspannt vor sich hin. Viel SW, die Ich mal benutzt hatte, liegt hingegen brach, weil sie auf einen XP-Rechner fixiert ist, oder Win7 voraussetzt, weil es keine Win10 Treiber gibt und demnächst verfällt, oder es handelt sich um Software, die ich gar nicht erst kaufe, weil sie nur auf Win10 läuft, um das Ich einen Bogen mache!
Wenn man sich dann mal ansieht, was manche so an plugins haben und was sie an Geld investieren, ist HW oft gar nicht so teuer
