Beiträge von martin

    Zitat


    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.

    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.

    Zitat


    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.

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

    Zitat


    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.

    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.

    Zitat


    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.

    Schau dir einmal die Größe des Verzeichnisses an - im Vergleich zum den Samplesets ist das Mini. Falls es doch einmal zu groß wird, sollte mit einer komprimierten Speicherung das Problem gelöst sein.

    Da Einstellung etwas wertvolleres sind, speichert GO seit einiger Zeit den ODF in diese Dateien. Damit kann man zB in einen Backup nach den Einstellungen suchen und sie neu in GO importieren.

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

    Zitat

    Original geschrieben von chilissimo

    Ja, und warum werden die Pfade dann überhaupt in den Einstellungen angezeigt? :-confused:

    Damit man den Ordner verlegen kann (bzw. den Ordner bei Bedarf auf komplett entsorgen kann).

    Die beiden GO Verzeichnisse gelten als intern - ein User hat da nichts zu suchen. :-teacher:

    Im Moment wird pro Preset und ODF ein Cachefile angelegt - in Zukunft kann das aber auch total anders werden.

    Löschen/Update geht per ja per Menü.

    Zitat


    Automatische Dateinamen - Wie man das programmiert weiß ich nicht, aber fortlaufenden Nummerierung tut es.


    Es geht hier nicht um die Frage, wie man etwas umsetzt - Diese Spezifikation ist noch zu ungenau:
    * Wo kommt dann die Datei hin?
    * Es soll ein Nummer in der Datei stehen - woher kommt der Rest?

    Bei etwas Nachdenken kommen noch weitere Fragen auf, zB:
    * Wie soll das Feedback für den User sein
    * Wie soll das mit den bisherigen Recording Elementen im Menü zusammenpassen?
    * Ist das ganze für andere User auch logisch? (Ganz wichtig)

    Dann sollte man sich noch über die Sonderfälle Gedanken machen, zB:
    * Man ist in einer Aufname und wählt den anderen Button.
    * Es gibt schon eine Datei mit den Namen, der automatisch generiert wurde - bei Nummern ist das meiner Ansicht nach sehr wahrscheinlich.

    Du musst aufpassen: Höhere Zahlen bedeuten auch mehr Overhead, so das GO sich immer mehr mit sich selbst beschäftigt. Ab einer gewissen Zahl hast du garantiert einen schöne CPU Auslastung (auch wenn du nicht spielst).

    Dein Prozessor hat Hyperthreading - ich kann dir nicht beantworten, ob du mit on oder off im Bios besser dran bist.

    GO hat für Endnutzer keine Einschränkungen, egal wofür und wie es ge- bzw. missbraucht wird.

    Für Entwickler bzw. Distributoren gibt es ein paar kleine Bedingungen zu beachten - die genauen Details kann man im Lizenztext nachlesen.
    Im wesentlichen kurz zusammengefasst: Man muss den Sourcecode heraus-/mitgeben => Sie sollten nur eine Problem sein, wenn man propritäre Versionen machen wollte.

    Die jeweiligen Samplesets können aber Einschränkungen haben, die dessen Nutzung/Aufnahme einschränken.

    Ansich sollten GO Versionen seit einiger Zeit per Default den Concurrency Level auf die Anzahl der CPU Cores stellen (wenn keine alte Version unter den User gestartet worden war).

    Namen sind extrem schlecht. Was ist, wenn jemand eine Orgel noch einmal aufnimmt? Was ist mit einer neuen Release (wie es Lars Palo zB bei einigen Samplesets gemacht hat)?

    Das funktioniert nur, wenn man wie bei HW ein striktes Schema macht und kontrolliert.

    Homunculus: Also sind mit gebrochener Oktave Subsemitonen gemeint?

    http://de.wikipedia.org/wiki/Wöckherl-Orgel
    http://commons.wikimedia.org/wiki/File:Wöckherl-Orgel-IMG_8002.JPG

    Add Traktur-Geraeusche:
    Seit r1303 kann man in GO alle Arten von Trakturgeräuchen modellieren. Lars Palo hat auch ein Prototyp für eines seiner Samplesets gemacht.

    Noch etwas.
    Gibt es bei HW nicht noch weiter Nutzungseinschränkungen je nach Edition:
    Öffentliche Nutzung? Irgendwelche Einschränkungen für Aufnahmen?

    Zitat

    Wahrscheinlich wird keiner auf die Idee kommen so eine Klaviatur für HW/GO bauen zu wollen, aber würde das notfalls mit GO machbar sein?

    Mir ist nach Lesen des Artikels noch immer nicht klar, was genau eine gebrochene Oktave ist.

    Die eingebaute Funktion in GO dient dazu, auf einer normalen Klaviatur/ODF mit kurzer Oktave spielen zu können (vgl. meine Anleitung dazu im Sakralorgelforum).
    Ein weiteres Layout könnte man noch in GO einbauen, wenn Bedarf besteht.

    Zitat


    Macht Hauptwerk da noch etwas anderes? Wo kann man die Verfahren denn evtl. mal nachlesen so ganz verstehe ich immer noch nicht was mit den gesampleten Tremulanten bei Hauptwerk nun gemeint ist.

    Gesampelte Tremulanten sind extra Aufnahmen mit Tremulant=On.
    Die HW simulierten Tremulanten wenden mehr Filter an.

    Zitat

    Bei HW ist in der Audio Engine die Rede von z.B.:
    - harmonic shaping filter
    - swell box filter
    - pipe EQ
    - random pipe detuning
    und noch ein paar anderen Zufallswerten

    "random pipe detuning" sollte GO auch haben.

    Zitat

    Wie ist das wohl zu verstehen wenn HW da 96 kHz angibt? Ich kenne auch nur Sets mit 48 kHz. Ich will ungern für GO etwas schlechteres angeben müssen, wenn HW da auch nicht besser ist.

    Du kannst in GO auch 96kHz Sample laden. Die GO Audio-Ausgabe ist aber im Moment auf die 2 Sampleraten eingeschränkt - eventuell füge ich noch 96000 in die Auswahlbox hinzu.

    Zitat


    Gute Frage - sagen wir den, der mindestens notwendig ist, damit das kleinste Betriebssystem und GO läuft mit einem Minimalst-Sample - und ich gebe dann eben an ab soundsoviel Kilo/Mega-Bytes.

    Ein GO Prozess mit extra min Sampleset (ein kurzes WAV) kommt bei mir unter Linux auf 32 MB. Linux-Kernel 2-4 MB RAM und in 30-40 MB sollte man locker einen minimalen Desktop hineinqueschen können. Mit ein bischen Optimierung geht sicher noch weniger.

    Unter 512 MB wird man aber mit den Samplesets kaum glücklich. Spass wird man erst mit ein paar GB RAM haben.

    Zitat

    War mir nicht klar, dass MAC OS und OSX im Prinzip das selbe ist - ist auch weniger meine Welt ;) Ab welcher Version sollte GO denn laufen?

    Ich meinte eh OS X.

    https://sourceforge.net/p/ourorgan/bugs/17/ -> der letzte Build sollte ab OS X 10.6 unterstützen.

    Wenn man selbst kompiliert, sollten auch ältere Versionen gehen.

    PS:
    Vielleicht sollte man noch auf sonstige Nutzungseinschränken im Vergleich hinweisen.