Cachebezeichnungen

Gerade wenn man mit GrandOrgue öfter herumbastelt und immer wieder neue Versionen installiert, kommt man schon schnell in die Verlegenheit, dass sich an verschiedenen Stellen auf dem PC die Cache-Files anhäufen.
Also ich hätte mir schon oft gewünscht zu wissen, zu welchem Sampleset ein Cache-File gehört. Kann ich es nun löschen? Brauche ich es doch noch? Im Zweifel dann alle löschen? Dann muss ich bei jedem Set auch wieder länger warten bis der Cache erstellt ist.

So wie es aussieht, stellt GrandOrgue auch automatisch das Cache-Verzeichnis wieder um, sobald aus irgendeinem Grund das eingestellte Laufwerk mal nicht Verfügbar ist. Wenn ich mit SSD hantiere kommt das schnell mal vor. Plötzlich werden Cache-Dateien wieder im User-Verzeichnis abgelegt? Oder waren diese doch älter? Man verliert den Durchblick und da hilft dann die integrierte Cache-Löschfunktion auch nicht mehr weiter, wenn die Verknüpfungen nicht mehr bekannt sind.

Bei Verwendung von SSD als Cache kommt leicht noch folgendes Problem dazu, das auch Hauptwerk bisher nicht gelöst hat.:
Verwende ich etwas größere Sets und davon mehrere und vielleicht noch in verschiedenen Konfigurationen, dann wird sehr schnell eine SSD zu klein. Da ich aber nur ein einziges Cache-Verzeichnis definieren kann, bleibt mir nur entweder eine größere SSD einzubauen oder wieder einen Teil der Sets zu löschen. Das ist ungeschickt.

Wünschen würde ich mir, dass man am Besten zu jedem Set separat den Speicherort des Cache angeben kann. So kann man mehrere SSDs nutzen oder auch weniger wichtige große Sets den Cache auf eine HDD speichern lassen.

Also eine Kennzeichnung der Cache-Dateien die irgendwo den Namen der ODF enthält fände ich auch dringend notwendig. Der "Normaluser" hat dort vielleicht weniger damit zu tun, es schadet ihm dann aber auch nicht. Aber ich denke bei GrandOrgue wird es sicher viele "PowerUser" geben, die darum froh sein werden. ich könnte mir auch vorstellen, dass GO einfach zu jeder ODF ein Unterverzwichnis mit dem ODF-Namen innerhalb des Cacheverzeichnisses anlegt. Darin kann es dann meinetwegen soviele Dateien anlegen wie es will und diese nach Gutdünken benennen - aber wenn ich ein Set nicht mehr brauche bin ich mir wenigstens sicher, dass mit Löschen dieses Verzeichnisses alles weg ist.

Das Selbe gilt übrigens auch für die Einstellungs-Dateien - da blickt man mit den Dateinamen genauso wenig durch. Auch hier am Besten in ein Unterverzeichnis mit dem ODF-Namen.

Zitat

Original geschrieben von martin
Der Cache sind temporäre Dateiein, die aus den originallen Sampleset vollständig neu erzeugt werden können. Bei einigen GO Updates werden auch alle Cache Dateiein sowieso ungültig und müssen neu erstellt werden.

Daher gilt: Im Zweifelsfall einfach löschen.

Wenn ich an Hauptwerk denke, dann graust mich so eine Vorstellung. Manche großen Sets brauchen bis zu 1 Std. um den Cache neu zu generieren (aktueller Quad-Core). Bei 10 größeren Sets und noch etlichen kleinen wäre ich da locker einen Tag beschäftigt. Bei meiner GO-Installation mag es im Moment noch einigermassen überschaubar sein und bei kleinen Sets kann man die Wartezeit auch noch akzeptieren wenn man gerade das Set schnell laden möchte und es baut dann erst noch den Cache auf. Ich bin aber gespannt wie schnell das GrandOrgue bei Sets von 16 GB und mehr machen wird.

Zitat

Original geschrieben von martin

Das ist ein "Komfort-Feature" von GO: Defekte Pfade werden automatisch "repariert".

Unter Komfort würde ich verstehen, wenn mich ein Programm fragt was es tun soll wenn etwas unvorhergesehenes eintritt. Ich hasse nichts mehr, als wenn Software über meinen Kopf hinweg entscheidet. Windoofs fängt an 86 Updates auszuführen, wenn ich es herunterfahren will weil ich schnell weg muss, oder denkt für mich mit und lagert Pfeifensamples aus, damit RAM frei wird für eine Routine die automatisch mitdenkt und mir während dem Orgelspielen alle möglichen "nützlichen" Tasks startet, weil es "denkt" ich mache ja eh nichts Besonderes.

Zitat

Original geschrieben von martin

Die Limitierung auf ein Cache Verzeichnis ist sicher ein Problemfeld - die Frage ist nur ob das auf GO oder doch nicht besser OS Level gelöst gehört.

Alle modernen Betriebsysteme bieten Volums über mehr als eine Platte an, zu man jederzeit weiteren Speicher dazuhängen kann. Unter Linux geht das zB mit LVM unter Windows zB: http://technet.microsoft.com/en-us/library/cc732422.aspx.

Wenn man es in GO angehen würde, würde das bedeuten das man nur eine Liste von Pfaden (eventuell mit Limits) angeben könnte.

Die übergreifenden Volumes nützen mir nicht sehr viel. Ich brauche zum einen den sehr schnellen Cache - der besteht bei mir aus 2 bis 4 SSD Laufwerken im RAID-0 Verbund um noch höhere Datenraten zu schaffen. Dies ist dann ein recht schneller aber teurer Cache, den ich für meine Lieblingssets gern bereithalte. Für alle anderen Sets, Demos, Testinstallationen von Sets usw. könnte ich auch den Cache auf einen billige langsamere SSD oder dann auf eine lahme Festplatte speichern lassen. Das Problem könnte mir nur GrandOrgue lösen aber nicht das Betriebssystem. Auch die Leute von Hauptwerk wollen das Problem noch nicht erkennen - ich bin aber nicht der einzige User den das stört.

Zitat

Original geschrieben von martin
PS:
GO kennt einen -i Parameter, mit dem kannst du komplett eigenständige GO Instanzen laufen lassen (inkl. eigenes Cache/Daten Directory).

Das ist natürlich eine neue und interessante Information! Damit könnte ich wohl vorläufig mein Problem lösen - was allerdings noch nicht so elegant ist wie ein Parameter für den Cachespeicherort innerhalb einer Instanz.

Kann man diese ganzen GO-Parameter auch irgendwo nachlesen?