Posts by BasKb

    Allerdings... 3.14.1-1 öffnet auch nicht die Orgel „Hildesheim, Beckerath Organ, Demo1.0“. Ich gehe davon aus, dass es sich um ein ODF-Problem handelt.
    Wieder einmal erscheint „ReleaseCrossfadeLength“ unter den Fehlermeldungen

    Ab Version 3.14 erfordert GO für die Definition der ReleaseCrossfadeLength eine umfangreichere Spezifikation. Anstelle von Pipe999ReleaseCrossfadeLength sollte es nun Pipe999Release999ReleaseCrossfadeLengt heißen. Es gibt noch nicht viele ODFs mit einer definierten ReleaseCrossLength Ich habe es in meinem Version des Odfs für Warrington (im Filebase) schon geändert

    Delay Angaben habe ich bislang in den GO Sample Sets der ODFs von Giubiasco und Friesach von Piotr Grabowski gefunden.
    Wenn man die ODF z.B. mit Notepad öffnet und nach Delay sucht, lassen sich die Einträge zu den jeweiligen Pfeifen leicht finden.

    Das ist klar. Die Verzögerungen können daher ziemlich einfach über das Odf hinzugefügt werden

    Quote

    So wie ich Piotr verstanden habe sind die Delays eingefügt um das zeitgleiche Ansprechen der Pfeifen etwas unterschiedlicher und damit realer wirken zu lassen.

    Das macht Sinn.

    Die Simulation der Gesamtlatenz vom Tastendruck erscheint mir für Organisten interessant, die sich über HW oder GO auf Orgelaufführungen auf der echten Orgel vorbereiten möchten, insbesondere wenn es sich um eine Orgel handelt, die langsam reagiert. Wenn Sie es dafür nicht benötigen, ist meiner Meinung nach eine möglichst geringe Latenz immer noch vorzuziehen.

    Was mich interessiert, ist, ob das Hinzufügen der Zeitverzögerung aufgrund der unterschiedlichen Platzierung der Pfeifen zu einem realistischeren Klangbild mit mehr Tiefe führt. Zu diesem Zweck ist es aber nicht erforderlich, die nächstgelegenen Orgelpfeifen zu verzögern.

    Quote

    Wenn die Sampler der einzelnen Töne immer mit 1-2 ms Sekunden Vorlauf aus der Gesamtaufnahme extrahiert werden, wäre die orgelspezifische Latenz verloren und könnte im Nachhinein nur über die ODF von GO wieder hinzugefügt werden (wie bei Giubiasco, Friesach etc.).

    Die neueren Samples für HW von PG scheinen dagegen die realen Vorlaufzeiten der Orgeln wie im Fall 1 oder 2 beschrieben zu enthalten. Siehe Beispiel Screenshot eines Samples von der Erfurter Predigerkirche mit einem Vorlauf von 60ms.

    Falls die unterschiedlichen Latenzen der realen Orgelpfeifen für die virtuelle Wiedergabe nicht gewünscht werden, gibt es auch eine entsprechende Einstellung in den neueren HW Sets von PG zum Deaktivieren dieser orgelspezifischen Latenzen.

    Es kann also auf 2 Arten geschehen, wenn man als Nutzer jedoch in beiden Fällen die Möglichkeit hat, die eingestellte Vorlaufzeit ein- und auszuschalten, ist es eigentlich egal, ob diese in den Samples oder im Odf verarbeitet wird.

    Quote

    Interessant wäre zu wissen wie das andere Sample SET Hersteller handhaben. In einem Set von SP habe ich nach einigen Stichproben bislang nur Vorlaufzeiten von 1-2 ms gefunden, was natürlich auch bedeuten kann dass die jeweilige Orgel eine durchweg geringe Latenz aufweist.

    Ich kann nur für mich selbst sprechen. Bei meinem Sample-Set der Onderhorst-Kabinettorgel habe ich die Samples gleich zu Beginn des Einschwingvorgangs geschnitten und keine Verzögerung vorgenommen. Bei einer solchen Orgel gibt es aber kaum welche.

    Code
     

    Da man die ODF von GO gut lesen kann lässt sich auch leicht feststellen dass es so ziemlich in jedem Set Anpassungen zur Intonation hinsichtlich Lautstärke, Stimmung und auch Delay für jeden Ton gibt. Die vorgegebenen Einstellungen der ODF werden zusätzlich auch in den Einstell-Dialogen von GO angezeigt.

    Können Sie einen Teil des Odf zeigen, in dem diese Verzögerungseinstellung programmiert ist? Ich bin gespannt, wie man das hinbekommt und ob es wirklich viel Arbeit ist.

    Ermitteln kann man sie nur wenn man das Niederdrücken der Taste erfasst und dann die Zeit zwischen Tastendruck und Toneinsatz berechnet. Das ist schwierig, besonders bei mechanischen Manualen.

    Eine weitere Möglichkeit hat man bei hochauflösenden Mikrofonen, dass man den leisesten Ansatz des aufgenommenen Tones bis zur vollen Entfaltung zeitlich erfasst und als Delay-Time definiert.

    Das ist eine umfangreiche Arbeit. 3 Manuale und Pedal mit 60 Registern Ton für Ton bearbeiten. Dazu braucht man Nächte und viel Kaffee

    Am einfachsten erscheint es mir, die Abstände zwischen den verschiedenen Werken und Orgelpfeifen näherungsweise zu bestimmen. Behalten wir für die nächstgelegenen Pfeifen die Verzögerung bei 0 ms. Anhand des Abstands der weiter entfernten Rohre zur ersten Reihe lässt sich dann mit der Schallgeschwindigkeit von ca. 343 Metern pro Sekunde (also ca. 3 msec pro Meter) eine Zeitverzögerung berechnen, die der Realität nahe kommt.

    in den Sample Sets von PG gibt es wie von ihm angegeben eine Einstellung zum Ein- und Ausschalten von Delays für die Pfeifenansprache.

    Das ist interessant. Dann können Sie den Unterschied auch hörbar machen. Zeitverzögerung ist neben Richtung und Lautstärke ein Faktor für die Wahrnehmung der Lokalisierung der Schallquelle. Als ich mir vor ein paar Jahren einige Audioaufnahmen von Orgeln physisch und über Hauptwerk angehört habe (gleiche Orgel, gleiches Musikstück, gleicher Organist), fiel mir auf, dass mir bei den Hauptwerk-Aufnahmen die Tiefe im Klang fehlte. Dabei könnte möglicherweise das Fehlen einer realistischen Zeitverzögerung in der Simulation eine Rolle spielen.

    Ich denke eher, dass andersherum ein Schuh draus wird.

    Ja, glaube ich auch.

    Quote

    Bei der Aufnahme eines Samplesets werden alle Pfeifen eines Registers, oder evtl. auch der ganzen Orgel, in einer einzigen Sampledatei aufgenommen. Diese Datei wird zunächst insgesamt von Störungen gereinigt, wie Geräusche vom Windmotor usw. und erst danach in einzelne Pfeifenton-Dateien zerlegt. Beim Zerlegen, vor allem wenn es über eine automatische Software passiert, gehen natürlich leicht die individuellen Delays am Anfang jedes gesampelten Tons verloren. Jedes Sample startet dann gleich schnell, was eben nicht mehr dem natürlichen Verhalten der Orgel entspricht.

    Die Informationen zu den individuellen Delays sind eben in der Roh-Audiodatei nicht vorhanden und diese lassen sich eigentlich nur aus der Entfernungsangabe destillieren. Ein Sample-Set-Produzent könnte solche berechneten Verzögerungen zu den Samples hinzufügen. Das Hinzufügen über ein ODF scheint mir aber eine effizientere Methode.

    das könnte auch ein Grund sein, wäre aber sehr aufwendig die Millisekunden (und wie kommt man auf die unterschiedlichen Werte) im Nachhinein für jeden Ton in der ODF zu hinterlegen.

    Zudem erklärt sich damit auch leider noch nicht warum solche Anpassungen beim gleichen SET für HW dann ohne Belang sind.

    Wenn das auch im Hauptwerk möglich war, dann verstehe ich es auch nicht. Ich denke, das wird (zu Unrecht) nicht beachtet.

    nochmal zurück zum eigentlichen Thema der Delay Einstellungen einzelner Register (Ranks) und Pfeifen in GO im Gegensatz zu HW.

    Die Funktion wird ja gerade in den GO ODFs von P. Grabowski wie schon erläutert häufig verwendet. Unzählige Pfeifen auch innerhalb eines Registers haben unterschiedliche Einträge von einer bis zu mehreren Millisekunden.

    Das bedeutet dass sich PG die Mühe gemacht hat für GO alle Register und Pfeifen auf gleiche Ansprache einzustellen. Welch ein Aufwand!? Oder gibt es einen anderen Grund für diese Einträge, bzw. kennt jemand andere Hintergründe für diese Einstellungen?

    Die Pfeifen einer Orgel befinden sich in unterschiedlichen Abständen (Millisekunden) vom Hörplatz. Das könnte ein guter Grund sein,oder?

    Das geht natürlich. Ist aber wenig anwenderfreundlich

    Ja, leider muss man das selbst machen, da nicht damit zu rechnen ist, dass es mit dieser Option fertige Samplesets geben wird. Aber wenn Sie es so machen, wie es in der von mir bereitgestellten Anleitung beschrieben ist, wird es nicht so schlimm sein. Mit hilfe eines automatisierten Prozesses können Sie Ordner voller Samples auf einmal in einem „Batch“ bearbeiten und dabei die Loop-Punkte und Cue-Punkte beibehalten.
    Es ist eigentlich selbsterklärend und eben einfacher als das Anpassen eines Odf. Wenn ich sehe, wie viel Aufwand einige Forumsmitglieder in die Hardware stecken, verblasst es im Vergleich.

    Mal eine Frage zum Schweller in GO. Ist das tatsächlich eine realistische Simulation oder nur eine Veränderung der Lautstärke? Ich habe es noch nie näher getestet. Bei einer echten Orgel bewirkt der Schweller ja nicht nur die Reduzierung der Lautstärke, sondern auch eine klangliche Veränderung wie gedämpfte Höhen.

    Die Enclosures in GO verfügen tatsächlich nur über eine Lautstärkeregelung. Lars Palo hat vor einigen Jahren eine Version mit einem einfachen Frequenzfilter programmiert, der (wie in HW) in Echtzeit pro Pipe angewendet wurde. Dies wurde seinerzeit nicht implementiert , da es im damaligen Entwicklungsteam keine Begeisterung dafür gab. Einwände waren der zusätzliche Rechenleistungsbedarf / die Reduzierung der maximalen Polyphonie (wie auch bei HW).

    Insbesondere bei Romantischen Orgeln ist es in natura eine unglaubliche Wirkung, wenn bei geschlossenem Schweller schon ALLES da ist: Die Schwellwerke haben oft besonders viele Register und vornehmlich Zungenstimmen. Ein tiefes Grollen, das sich mit dem Öffnen steigert und eine geradezu "göttliche", numinose Wirkung entfaltet.

    Ich war von diesem Effekt bei realen Orgeln schon öfters völlig "weg".


    (Nichts davon ist in GO verwirklicht)

    Dies bedeutet jedoch nicht, dass die Schwelkasten mit der aktuellen GO-Version nicht realistischer simuliert werden könnten.

    Eine Alternative zur Echtzeitfilterung ist die Vorabfilterung. Zusätzlich zu dem Samples, der bei geöffneter Swell-Box aufgenommen wurde, können Sie Samples mit dem Sound erstellen wie wenn die Swell-Box vollständig geschlossen ist. Diese werden dann auf einem extra Windchest im Odf platziert. Wenn die Swell-Box mit den „offenen“ Samples geschlossen wird, wird gleichzeitig (und mit demselben MIDI-Signal) die Swell-Box mit den „geschlossenen“ Samples geöffnet.

    Das habe ich auf das Demo-Sampleset der Fleitner-Orgel in Billerbeck angewendet.

    Eine Demo des Ergebnisses finden Sie unter: https://www.contrebombarde.com/concerthall/music/40404

    In der Filebase finden Sie das Odf und eine Anleitung, um die „geschlossenen“ Samples (im Batch) selbst zu erstellen: Odf GO-Schwellkastensimulations Demo für dem Billerbeck Semi-Dry Demo Sampleset von Sonus Paradisi der Fleiter Orgel in der St.Ludgerus Dom

    Soweit ich das jetzt beurteilen kann, liegt ein Fehler im GO-Programm vor, der nur Sie betrifft. Sie könnten mit dem Audioausgang beginnen, ihn entfernen und neu zuweisen. Wenn das nicht funktioniert, müssen Sie vermutlich eine Neuinstallation durchführen.
    Wenn es immer noch nicht funktioniert, löschen Sie die Datei „GrandOrgueConfig“: Alle benutzerdefinierten und/oder falschen Einstellungen gehen dann verloren.


    Wer hat eine bessere Lösung? Bitte helfen Sie!

    In einigen ODFs, die direkt von HW-ODFs übersetzt werden, ist der Mindestwert des Volumens der Enclosures auf 0 gesetzt. In GO muss dieser jedoch mindestens 1 sein. Wenn nicht, tritt der oben genannte Effekt ein.

    Beim Pedalspiel oder bei einem Hauptwerks-Prinzipal wäre das Durchhören der c/cis-Ladenteilung schon sehr gut. Aber bei irgendeinem Brustwerk, 2´Hochtöner oder Solomanual – habe ich da merkbare Einbußen, wenn ich das nur über einen Monokanal ausgebe?

    Das Tolle an Stereo ist, dass man mit nur zwei Lautsprechern ein Klangbild erzeugen kann, bei dem die Klangquellen virtuell in zwei Dimensionen im Raum platziert sind, links, rechts und dazwischen, fern und nah. Sie verlieren diese virtuelle Platzierung, wenn Sie in Mono spielen.
    Abgesehen davon sind die Sample-Sets in Stereo aufgenommen und nicht alle Stereoaufnahmen eignen sich für die Wiedergabe in Mono. Wenn Sie den Ton des linken und rechten Kanals in einem Kanal mischen, kann es sein, dass Ihnen ein Teil des Tons entgeht. Dies hängt von der Platzierung der Mikrofone ab. Wie schlimm das ist, variiert je nach Sample-Set und Register.

    Gruß Bas

    In der ganzen Übertragungskette ist der D/A-Wandler wohl das Bauteil, das heutzutage am billigsten zu produzieren ist und dabei praktisch einen Qualitätsstand erreicht hat, bei dem der normal Sterbliche einfach keine Unterschiede mehr wahrnehmen kann.

    Wenn Sie nicht über die Ohren eines Audiojournalisten verfügen, können Sie mit einem einfachen Test trotzdem hören, ob ein D/A die Klangqualität beeinflusst. Dabei wird eine Audiodatei mit einem D/A-Wandler analogisiert und anschließend mit einem A/D-Wandler erneut digitalisiert und dieser Vorgang dann mehrmals wiederholt. Ich habe das selbst einmal mit einem einzelnen Sinuswellensignal gemacht, aber dann habe ich im Internet einen Artikel von Ethan Winer gefunden, der einen ausführlicheren Test und resultierende Dateien enthielt und den Leser herausforderte, zu identifizieren, welche Datei in jeder Gruppe das Original und welche Kopien sind .

    Für diejenigen, die die Unterschiede selbst hören und sich der Herausforderung anschließen möchten: Es stellt sich heraus, dass der Artikel weiterhin zugänglich ist: https://ethanwiner.com/loop-back.htm

    zu 2) Die Sets mit 3-4 Perspektiven sind schon von der Mikrofonierung her so ausgelegt, das etwas im Klang fehlt, wenn man eine Perspektive weg lässt.

    Das ist mir auch aufgefallen.aber Ich glaube nicht das das Absicht ist. In einigen Sample-Sets wurde an der Aufnahmeposition in der Nähe der Orgel ein Aufbau mit recht weit auseinander liegenden Mikrofonen verwendet. Die Folge davon ist, dass es in den tiefen Tönen zu einer Phasenauslöschung zwischen dem linken und dem rechten Kanal kommt. Und dann löst das Einmischen einer weiter entfernten Aufnahme dieses Problem in gewisser Weise.

    Die Linux KDE ist in Qt programmiert. Mit Qt Quick kann eine Touch-Oberfläche plattformübergreifend gebaut werden. Der Weg ist sozusagen frei. Aber bevor man damit anfängt, muss man erst mal eine brauchbare Oberfläche entwerfen. Das ist auch viel Arbeit.

    Hauptwerk VIII (die Oberfläche ist mit Qt programmiert aber hat noch nichts mit einer echten Touch-Anwendung zu tun) fängt im Kleinen an - mit dem Touchmenü (was schon mal ein cooler Anfang ist).

    Hier sind noch ein paar Alternativen zu Touchscreen-MIDI-Controllern

    :

    und dann gibt es noch Midi Stops: https://midiorgelprojekt.wordpress.com/2019/04/03/midistops-2-2/