Der Nutzen davon ist zumindest fraglich. ?.......
das mag sein, ich habe nur festgestellt dass ich weniger oder gar keine Tonprobleme mehr habe seit ich den GO Prozess mit höchster Prio starte. Man kann auch ein kleines Tool aus dem Netzt installieren mit dem sich alle Hintergrundprozesse zur optimierten Soundwiedergabe deaktivieren lassen.
die Formel zur Berechnung der theoretischen Lebensdauer einer SSD ist sehr wohl bekannt. Besonders wenn Daten immer wieder in den gleichen Bereich geschrieben werden geht die Lebensdauer schnell nach unten. Bin gespannt wie lange die SSD hält. Wenn sie defekt ist gibts die nächst größere und mit einem Backup der gesamten SSD ist das gesamte System schnell wieder lauffähig. Davon abgesehen halte ich drehende Festplatten für deutlich empfindlicher. Eine unbedachte Erschütterung im Betrieb und das wars. Ist mir schon zweimal passiert.
Leider weiß man nie was in einer SSD abläuft. In der Vergangenheit waren ja öfter mal Controller die schlampig gearbeitet haben dafür verantwortlich dass teure SSD's binnen weniger Tage defekt waren.
Betreffend der Probleme beim Ton kannst du vielleicht mal Linux testen. Unter Windows haben ja viele dieses Phänomen.
Ich habe auch ein GO auf einer Linux (Mint) Plattform. Allerdings bislang nur in einer persistenten Life Version auf einer externen SSD.
Die LINUX Installation auf die SSD hat bislang nicht so funktioniert wie ich das gerne hätte nämlich ohne Eintrag in das UEFI Bootmenü von Windows.
Die Option den Booteintrag für Linux auf die externe SSD zu schreiben funktioniert aus welchen Gründen auch immer nicht, und so bin ich erst mal bei der Lifeversion geblieben mit der Konsequenz dass sich dort keine Swapdatei anlegen lässt.
Sobald die 16 GB RAM voll sind stürzt LINUX komplett ab. Mit Samplesets die mit weniger als 16 GB RAM auskommen funktionniert GO auf Linux dagegen ohne jede Probleme. Vor allem die Soundwiedergabe über den ALSA Treiber ist ohne Tonstörung mit weniger als 10ms Latenz hinzubekommen ohne dass irgendwelche Hintergundprozesse stören.
Ich kenne Linux nur ansatzweise und nutze HW und nicht GO. Aber wenn ich die Diskussion hier so verfolge - als technischer Laie - dann wäre es doch, wenn ich haralder weiter oben richtig verstanden habe, an der Zeit, den gewaltigen Speicherbedarf unserer Samples zu reduzieren bzw. sinnvoll zu komprimieren?
Lieber Rainer,
auf ein ehrliches Wort: Ich habe keine Hoffnung, hier im Forum über das unglaublich leistungsfähige, professionelle Audio-Menü von Hauptwerk 7 sinnvoll diskutieren zu können.
Musst du auch nicht. Ich würde es nur verstehen wollen. Vielleicht ist ja der Wortlaut
frequenzmäßige Verteilung der Register auf verschiedene Schallfelder missverständlich oder unglücklich ausgedrückt.
Ich werde es mir mal selbst zu Gemüte führen.
Dann brauchst du es hier nicht diskutieren.
ein anderes Speichermanagement für die Samples ist sicherlich ein Ansatz über den man nachdenken kann.
Eine tiefgreifende Änderung einer Software ist jedoch so einfach nicht zu bewerkstelligen. Das braucht Ressourcen und erzeugt Kosten. GO ist aber eine OpenSource und wird nicht kommerziell vertrieben. Das erfordert dann schon einige Entwickler die das Projekt mehr oder weniger aus Idealismus weiter fortführen.
Die Option den Booteintrag für Linux auf die externe SSD zu schreiben funktioniert aus welchen Gründen auch immer nicht, und so bin ich erst mal bei der Lifeversion geblieben mit der Konsequenz dass sich dort keine Swapdatei anlegen lässt.
Wenn du auf irgendeinem Datenträger eine Swap Partition erstellst, dann sollte dein Livesystem diese automatisch nutzen. Du kannst aber auch in einem Livesystem auf einem Datenträger eine Swap Datei erstellen die du dann einbindest. Schau dazu mal hier https://wiki.ubuntuusers.de/Swap/#Swap-Datei-erstellen
Eigentlich sollte sich der Bootloader auch ohne Probleme auf die SSD installieren lassen. Ich kenne jetzt den Installer von Ubuntu nicht, aber auch da sollte es ein Reiter geben wo der Bootloader installiert werden soll. Im Zweifel schau dir auch mal MX Linux an. Basiert auf Debian und ist noch viel schlanker als Ubuntu. Wenn du dieses auf eine externe SSD installierst, dann ist dort auch alles dabei so dass du davon booten kannst. Zusätzlich kannst du aus einem laufenden System auch mit ein paar Klicks ein Livesystem inkl. Installer erstellen. Ich habe das hier auch so gemacht. Das System einmal sauber eingerichtet inkl. Orgeln und Konfiguration von allem. Dann ein Livesystem daraus erstellt welches auch direkt von einem Stick läuft und sich bei Bedarf auch wieder installieren lässt.
Bei GrandOrgue gab es damals ja auch ein Live System auf OpenSuse basis. Leider gibt es das heute nicht mehr. Das war auch persistent und ließ sich installieren.
ich hatte die Swapdatei genau so wie in dem Link angegeben erstellt. Hat aber nicht funktioniert. Da ich mich mit Linux nur sehr rudimentär auskenne habe ich dann erst mal nicht weiter rumexperimentiert vor allem mit der Installation auf die externe SSD.
Auch ein Life auf eine exteren SSD mit 1TB zu bekommen geht mit den üblichen Tools wie Rufus nicht, da dort nur USB Sticks erkannt werden aber keine SSDs.
Die Installation habe ich mehrfach durchgeführt und im Mint Installer aus dem Lifesystem immer mit der Option den Bootloader auf die SSD zu schreiben, aber jedesmal war mein UEFI Bootloader wieder überschrieben. Beim ersten mal habe ich lange im Netzt suchen müssen bis ich den Windows Bootloader wieder repariert hatte. Die meisten beschriebenen Vorgehensweisen zur Reparatur haben nämlich nicht funktioniert wegen fehlender Rechte den UEFI Bootloader zu überschreiben.
Am einfachsten wird es sein Linux ist auf einem separaten PC zu installieren.
Okay, verstehe. Probiere einfach mal https://mxlinux.org/ aus wenn du Zeit hast und deaktiviere im UEFI/Bios Secure Boot. Dies kann auch das starten von einem externen Gerät verhindern. Der Bootvorgang von einem USB Stick funktioniert technisch ja anders als von einem normalen Datenträger. Aber das übersteigt meine Kompetenz.
> Ich habe z.B. auf einer 1TB SSD PCIe Gen. 3x4, mit 3396 MB/s sequenzielles Lesen und 2625 MB/s sequenzielles schreiben, also nicht mal die schnellste, eine unter
> Windows fest definierte Auslagerungsdatei von 48 GB eingerichtet. Zusammen mit den 16 GB RAM ergeben sich damit 64 GB verfügbarer Speicher.
Ich hab gerade eine pcie-4.0, 7000MB/s mit Linux, GO und 8 Kernen + Hyperthreading installiert. Lädt alles sehr flott ;-).
Wenn man kann, würde ich selber zusammenbauen und eventuell schauen, dass ich auf dem Mainboard 4 Ram-Slots zur Verfügung habe.
Und das kann man auch, wenn man einen Schraubenzieher bedienen kann und sich bei Bedarf entsprechend Yout***-Videos raussucht.
Orgel spielen ist da wesentlich schwerer. Aktuell gibt es auch CPU's mit mehreren Kernen, die im 100-200€ liegen 
.. die Auslastung
der einzelnen Kerne ist zumindest bei GO so minimal, dass wahrscheinlich auch die 100€-Variante reicht.
die Auslastung
der einzelnen Kerne ist zumindest bei GO so minimal, dass wahrscheinlich auch die 100€-Variante reicht.
So lange du nicht mit Dry Sets arbeitest reicht für GO eigentlich selbst eine zehn Jahre alte mobile Tablet CPU von Intel aka Atom/Celeron. So lange sie zumindest mehr als einen Kern hat. Sogar auf einem Raspberry Pi kann man die großen Sets ohne Einschränkung oder hohe CPU Last spielen. Wenn es einen Raspberry PI mit 32 GB Ram geben würde, dann würde das kleine 4 Watt System für wohl die allermeisten Fälle schon überdimensioniert sein.
HW/Swellinq haben da aber tatsächlich sehr viel höhere Anforderungen als GO. Gerade Sweelinq ist mir da sehr negativ aufgefallen. Auf einem Core2Duo ist eine kleine Orgel Tutti nicht mehr spielbar während GO nicht mal eine Last verursacht. Da scheinen also noch mehr Dinge im Hintergrund berechnet zu werden. Aber eine Software die im Standby immer eine hohe CPU Last verursacht ist wohl nicht optimal... Auf die Windanlage oder Stille muss ja wohl kein komplexes Klangmodell berechnet werden
