Beiträge von sygo

    Dadurch kommt meist eine ganz erhebliche Latenz von durchaus 60-160 ms zusammen.

    es gibt auch Hersteller die können es besser und vor allem geben die die max. Latenz in den technischen Daten explizit an (Nubert, Abacus zum Beispiel)

    Der Hersteller Nubert gibt für die Soundbar nuBoxx AS-225 max eine Latenz von nur mit 8 ms an. Ich habe z.B. zwei Aktivboxen von Nubert mit einer Latenz von nur 3,9ms, die sich beim Spielen nicht auswirken.

    Leider gibt es nur sehr wenige Hersteller die die Latenz in den technischen Daten angeben.

    Das mit dem ZIP Archiv probiere ich auf alle Fälle. Bedeutet das, dass GO gar nix in die Registry schreibt?

    das habe ich noch nicht ausprobiert. Wenn ich ein neues Release von GO das erste mal ausprobiere, versuche ich dieses immer aus dem entpackten zip Archiv in einer eigenen Instanz zu starten um für diese Version eine separate Config Datei zu erzeugen.

    Die Config Datei ist im Root Verzeichnis ...AppData/Roaming abgelegt und wird von allen GO Versionen verwendet.

    Das hat zwar den Nachteil dass die MIDI Konfiguration neu definiert werden muss, hat aber den Vorteil dass man sich die Config Datei des letzten funktionierenden Releases beim Testen nicht zerschießt.

    ich versuche ja immer erst die zip Version, da man die nicht installieren muss. Das zip Archiv der 3.14.01 scheint allerdings fehlerhaft und lässt sich nicht als Archiv öffnen.

    Beim Installationsversuch der exe Datei gibt es meist ein paar Hürden vom Virenscanner und auch von Windows selbst da die exe zunächst als potenzielle Schadsoftware eingestuft und die Installation verweigert wird. Die Software hat wie mein Virenscanner meldet keine gültige Signatur.

    Nach Freigabe des Zugriffs auf die Netzwerkressourcen des Rechners lässt sich die 3.14. starten und läuft auch ohne Absturz unter Win10.

    GO-3.14 Warnmeldung.png

    Unter Linux Mint sollten sich auch unterschiedliche GO Instanzen verwalten lassen, habe ich aber noch nicht probiert, die Syntax der Startdatei wird sicherlich etwas anders sein.

    wenn ich das richtig verstehe geht es um unterschiedliche MIDI Konfigurationen für das gleiche Sampleset.

    Das sollte sich mit unterschiedlichen GO Instanzen lösen lassen. Für jede Hardwarekonfiguration wird dabei eine eigene GrandOrgueConfig Datei im ...../AppData/Roaming Ordner mit den jeweils unterschiedlichen MIDI Konfigurationen angelegt.

    Die Instanzen lassen sich über separate .bat Dateien vom Desktop aus starten.

    siehe Kapitel 3 Benutzerhandbuch:

    grandorgue:kapitel3 [MPS Wiki]

    Many thanks to ahall41 for the wonderful ODF for Naber Organ of the Reformed Church from Rumpt (Netherlands)

    Danke für den Hinweis. Die Orgel oder besser das SET klingt sehr gut, besonders bei mehrkanaliger Wiedergabe.

    Es muss nicht immer eine Orgel mit 40 und mehr Registern sein. Weniger ist manchmal mehr.

    Die Stimmen klingen sehr ausgewogen mit klaren und differenzierten Klangfarben was auch noch von der Akustik des Kirchenraumes optimal unterstützt wird.

    habe ich damit begonnen, den Namen der Orgel und das Datum, an dem die Cache-Datei erstellt wurde, in einer Textdatei aufzuschreiben.

    man kann jede Orgel auch in einer eigenen GO Instanz starten, dann wird automatisch für jede Orgel sowohl ein eigener Cachordner und zusätzlich auch noch eine eigene Config Datei angelegt. Damit lassen sich auch orgelspezifische Einstellungen z.B. für die Audioausgabe speichern.

    Zur Frage der ODF Erweiterung um eine zusätzliche Perspektive #1 habe ich jetzt folgendes Ergebnis.

    1. Pro Rank ist jeweils nur eine Windchestgroup definierbar
    2. Die Nummerierung der Ranks muss durchgehend lückenlos erfolgen. Wenn nicht werden beim Laden der ODF irreführende Fehler wegen des fehlenden Eintrags "FirstMidiNoteNumber" eines nicht vorhandenen Ranks ausgegeben.

    Da muss man erst mal darauf kommen, dass es an einer fehlenden Rank Nummer z.B. 30 liegt die zwischen den z.B. vorhandenen Ranks 29 und 31 vergessen wurde zu definieren.

    Nachdem ich die Änderungen 1,2,3 wie in #1 beschrieben durchgeführt habe und auch eine komplette durchgehende Nummerierung aller Ranks erfolgt ist, habe ich jetzt für die Noeske Orgel von Kassel-Niederzwehren eine ODF mit den Perspektiven Front und Rear sowohl für die Manuale als auch für das Pedalwerk und kann diese getrennt auf die Ausgangskanäle des Audiointerfaces geben.

    Was bringt das Experiment, da ja die Samples beider Perspektiven die gleichen sind?

    Nach ein wenig Probieren habe ich für die Rückkanäle ein Delay von 60ms eingestellt und die Stimmung um 1 cent verändert und über die DSP der Aktivboxen die Basswiedergabe auf ein Minimum reduziert.

    Der Effekt gegenüber der Stereowiedergabe über nur zwei Lautsprecher ist gigantisch.

    Sobald die Rücklautsprecher aktiv sind öffnet sich der Raum, der Orgelklang wird raumfüllend luftig und mit dem verzögerten Einsetzen und Nachhall der Töne über die hinteren Lautsprecher kommt es der Klangentwicklung in einem realen Kirchenraum viel näher als nur mit Stereo.

    Wie bei einer echten Mehrkanalaufnahme erklingen die Perspektiven zeitversetzt mit einem der Raumlänge entsprechenden Delay.

    Die zusätzlichen Perspektiven in der ODF führen allerdings dazu dass die Samples für jede Perspektive, also doppelt, in den Cache geladen werden, was deutlich mehr RAM Speicher beansprucht.

    Die hinteren Kanäle nur etwas leiser und mit einem Delay versehen auszustrahlen entspricht ja nicht ganz einer originalen Wiedergabe.

    Hallo Rainer,

    das ist sicherlich richtig. Die Pegel und die Klangbeeinflussung der hinteren Lautsprecher ist aufgrund des DSP der Aktivboxen kein Problem. In GO wäre lediglich das Delay einzustellen was ja sehr einfach geht.

    Die rückwärtigen Lautsprecher über eine Differenzschaltung zu betreiben ist eine interessante Idee und würde ich gerne ausprobieren. Das würde auch für alle anderen nur Stereo Sets sicherlich was bringen.

    Die weiteren Details zur Differenzschaltung können wir ja per PN klären.

    Gruß Sylvia

    Jetzt hast du die echt echte Orgel in Störeo und willst Rückkanäle einführen?

    Bist du da nicht im falschen Forum, liebe Sylvia?

    Lieber Michael,

    das Sampleset der Orgel gibt es nur für GO und ist auch nur in "Kunstkopfstereofonie" also als binaurale Aufnahme verfügbar.

    Das ist natürlich bei Wiedergabe über Lautsprecher nicht ganz unproblematisch, da das für Kopfhörer getrennte linke und rechte Tonsignal über Lautsprecher jeweils mit beiden Ohren gehört wird, also ein Übersprechen der linken und rechten Signale stattfindet bei dem die 3D Information der binauralen Aufnahme verloren geht.

    Ich kann mich eben mit Kopfhörern nicht anfreunden, da damit das hören unnatürlich wird (keine Klangänderung bei Kopfdrehung) und die Dinger einfach auf den Ohren drücken egal welche Ausführung der Kopfhörer.

    Soweit so gut. Zur Zeit lasse ich daher die binauralen Stereo Samples der Pfeifen sowohl über die Lautsprecher vorne als auch für die Lautsprecher hinten wiedergeben.

    Ich würde aber gerne die Ausgabe über die hinteren Lautsprecher etwas modifizieren. Mit GO könnte man z.B. ein kleines Delay für hinten hinzufügen. Eine Möglichkeit wäre natürlich auch die Rückkanäle über eine Effekt DSP laufen zu lassen, habe ich aber derzeit nicht verfügbar. Also versuche ich das mit den GO Bordmitteln. Und dazu muss ich die ODF etwas erweitern damit ich die Rückkanäle als Objekte in den Orgeleinstellungen modifizieren (intonieren) kann.

    Das ist das gleiche was man auch in vielen einfachen GO Sample Sets vorfindet. Man kann aus wenigen gesampelten Orgelpfeifen oft sogar mit nur einer Oktave, beliebig viele Stimmen zaubern indem man das gleiche Sample mehreren Ranks zuordnet und über diverse Attribute so anpasst dass eine Orgel mit unterschiedlich klingenden Registern daraus wird, klingt zwar irgendwann langweilig aber besser als gar nichts.

    Bei der Kassel-Niederzwehren PO wurde das sogar schon bei der realen Orgel so gemacht, indem 3 Pedalregister vom Manual1 einfach abgekoppelt wurden und als Pedal Registerzüge verfügbar sind.

    Im Sample habe ich den Pedalumfang der 3 Manual Register ohnehin schon dupliziert und dem Windchest Pedal separat zugeordnet, um die Lautstärken zwischen Pedal und Manual für die Lautsprecher Wiedergabe separat einstellen zu können.

    Die Frage ist auch nicht ob die Erweiterung eines binauralen Samples auf zwei zusätzliche Rückkanäle sinnvoll ist oder nicht, es geht für die Erweiterung nur um eine Frage zur Syntax der GO ODF.

    In welchem Forum sonst als dem mps-orgelseite-Forum findet man u.a. auch die geballte Expertise zu Fragen rund um die Spezifikation der GO ODF.

    Um also die Frage zum richtigen Forum zu beantworten, ja ich bin dafür sehr wohl im richtigen und besten Forum.

    Falls also jemand eine Antwort zur ODF Deklaration Anzahl WindchestGroups pro Rank hat (siehe Beitrag #1), würde ich mich auf eine Antwort freuen.

    Gruß Sylvia

    Ich bin gerade dabei eine GO ODF um zusätzliche Perspektiven (Rückkanal) zu erweitern, eigentlich nicht sehr kompliziert, trotzdem stellt sich eine Frage zur Syntax (siehe weiter unten) auf die vielleicht jemand eine Antwort hat.

    Natürlich ließe sich das auch einfach mit einer zusätzlichen Audiogruppe lösen, die dann den Rückkanälen über das Audiodevice zugeordnet wird.

    Um allerdings individuelle Anpassung wie z.B. eine zusätzliche Verzögerung für die Rückkanäle vornehmen zu können, müssen die Ranks oder Windchestgruppen der zusätzlichen Kanäle in den Orgeleinstellungen als Objekte gelistet sein, was nur über die ODF definiert werden kann.

    Bei dem SET handelt es sich um die Kassel-Niederzwehren PO. Trotz der binauralen Aufnahme spiele ich das SET ausschließlich über Lautsprecher, vor allem auch um den Sound besser zu spüren. Eine Erweiterung auf 4 Kanäle könnte den räumlichen Eindruck vielleicht noch verbessern, ein Versuch ist es jedenfalls wert, da das SET sehr klare und differenzierte Orgelstimmen enthält.

    Folgende Test-Anpassungen funktionieren wenn auch mit etwas Aufwand:

    1. Jeweils zusätzliche Windchestgroups für die Rückkanäle definieren. Um die Reihenfolge mit den Manualen der Frontkanäle einzuhalten ist eine neue Durchnummerierung empfehlenswert.
    2. Alle Ranks für die Rückkanäle duplizieren, um die Windchestgroups der Rückkanäle in den Duplikaten eintragen zu können.
    3. In den Stop Abschnitten müssen ebenfalls die zusätzlichen Ranks der Rückkanäle eingetragen werden.

    Wenn es die Möglichkeit gäbe in den Rank Abschnitten mehr als einen Windchestgroup Eintrag einzufügen wären die Schritte 2 und 3 nicht notwendig und es würde sich sehr vereinfachen.

    [Rank019]
    Name=Subbass
    HarmonicNumber=4
    FirstMidiNoteNumber=36
    NumberOfLogicalPipes=30
    AmplitudeLevel=100
    NumberOfWindchestGroups=2
    WindchestGroup1=003
    WindchestGroup2=005
    AcceptsRetuning=N
    Percussive=N
    Gain=1
    etc......

    Leider scheint der Eintrag NumberOfWindchestGroups=2 im Rank Abschnitt nicht möglich zu sein, zumindest wird das als Fehler beim Laden des Sets gemeldet.

    Gibt es eine andere elegante Lösung um sich die Schritte 2 und 3 s.o. zu sparen oder ist die Syntax des Eintrages einfach nur falsch? Falls jemand eine bessere Lösung weiß würde ich mich über eine Antwort freuen.

    Das Ergebnis sieht dann in den Orgeleinstellungen so aus (erst mal nur das Testbeispiel mit Pedal Front und Pedal Rear und dem Subbass)

    grafik.png

    leider scheint das immer mehr zur Mode zu werden. Man braucht sich nur die Gottesdienste am Sonntag in den ÖRR Sendern anzuschauen. Ältere Menschen für die der Weg zur Kirche zu aufwändig ist würden gerne das ein oder andere Kirchenlied mit Orgelbegleitung mitsingen.

    Und was kommt: kein einziges Kirchenlied aus dem evang. Gesangbuch, dafür aber Gitarre, Schlagzeug, Keyboard manchmal Klavier und jede Menge Sologesänge völlig unbekannter Melodien bei denen geschunkelt und demnächst auch getanzt wird.

    Die Orgel hört man nur noch gaaaaanz selten. Der Orgelklang scheint manchen Leuten lästig zu sein, dafür demnächst wahrscheinlich auch noch Rapper mit ihrem unsäglichen Sprechgesang oder wie angekündigt Schlager.

    In wenigen Jahren wird es keine Gottesdienste mehr geben, Organisten werden dann nicht mehr gebraucht und die Orgeln zerfallen langsam, da es dafür kein Geld mehr gibt.

    Deshalb tut man gut daran so viele Orgeln wie möglich zu Sampeln, um wenigsten den Klang von einst zu konservieren.

    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.

    das wäre aber nur für eine bestimmte Perspektive der Mikros oder Hörposition am Spieltisch interessant.

    Festgelegt wird m.E. der Beginn eines Tones rein elektronisch bei der Bearbeitung

    das wäre eine der Grundsatzfragen für die VPO. Wie authentisch soll die PO als virtuelle Orgel klingen? Da ja auch die gesamte Geräuschkulisse jeder einzelnen Taste, der Registerzüge und Windmaschine in den Samples aufgezeichnet wird, liegt es nah auch die natürliche Latenz der PO mit zu erfassen.

    Technisch lässt sich das sicher lösen, und ich denke jeder SET Hersteller hat da seine eigene Technik und Erfahrungen. Der Aufwand wächst natürlich für technisch perfekte Samples und spiegelt sich nicht zuletzt auch im Preis wieder.

    Informationen zum Samplen einer Orgel sind eher spärlich im Netz zu finden. Der Link unten gibt einen kleinen Einblick in so ein Projekt.

    Absamplen einer Orgel zur Verwendung als virtuelles Instrument - SAE Alumni Association Europe
    Probleme und Aspekte beim Absamplen einer akustischen Kirchenorgel zur späteren Verwendung als virtuelles Instrument anhand des Software-Samplers EXS24
    alumni.sae.edu

    Leider sind in dem Artikel die Screenshots der verwendeten Software sehr unscharf (vielleicht gewollt), sodass sich nicht erkennen lässt mit welchen Werkzeugen dort gearbeitet wurde.

    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

    z.B. ODF Giubiasco:

    Bei 1145 Pfeifen finden sich Delay Werte zwischen 1-20ms

    grafik.png


    grafik.png

    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.

    Damit ist nicht der Einschwingvorgang einer Pfeife gemeint, der ja naturgemäß abhängig von Art, Dimension, Material, Mensur etc. immer unterschiedlich ist.

    Wenn man sich die Samples in einem Audioeditor anschaut findet man in der Wellenform eines Pfeifentones oft eine Vorlaufzeit x bevor der eigentliche Einschwingvorgang (Attackphase) als solcher beginnt.

    Die Vorlaufzeit x schwangt nach einigen Stichproben neuerer HW Samples von PG zwischen 2 ms bis zum Teil 60 ms für den Direktschall (Frontmikrofone), wobei extreme Vorlaufzeiten wahrscheinlich nur bei schlecht abgestimmten und intonierten Pfeifen vorkommen.

    Die Frage ist, wie wird er Aufnahmestartpunkt eines Samples festgelegt, also der Punkt an dem die Vorlaufzeit x beginnt.

    Ist das

    1. der Zeitpunkt mit Beginn eines Tastendruckes, oder

    2. der Zeitpunkt an dem die Taste vollständig gedrückt ist, oder

    3. mit einem Triggersignal was vor jeder Aufnahme eines Tones mit aufgezeichnet wird.

    Im ersten Fall würde man die von der jeweiligen Orgelkonstruktion (Traktur) abhängige Latenz zwischen Tastendruck und Öffnen des Pfeifenventils bekommen.

    Im zweiten Fall nur die Latenz vom Einströmen der Luft bis der Einschwingvorgang einsetzt.

    Im dritten Fall eine unabhängig davon festgelegte Startposition.

    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.

    grafik.png


    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.

    Wie das technisch umgesetzt ist weiß ich nicht, möglicherweise über Marker in der Audio-Datei ähnlich wie die Marker für die Loops.

    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.

    Danke für die Rückmeldung. Meine HW8 Installation läuft schon auf WIN10 pro. Ich konnte das Problem nach Deinstallation und Neuinstallation des Samples lösen. Wodurch das Hängenbleiben von HW bei dem SET ausgelöst wurde bleibt aber dennoch ein Geheimnis.

    Das willkürliche Verdrehen der in den Samples und ODFs eingestellten Verzögerungen gehört allerdings - wie Rainer sagt - im allgemeinen nicht dazu.

    das ist auch nicht das Anliegen. Es geht einfach darum welches Delay bis zum Beginn des Einschwingvorgangs in den Samples aufgezeichnet wird. Mit den Samples von PG ist mir das das erste mal aufgefallen, bzw. er hat sich offensichtlich darüber Gedanken gemacht, aber wie halten es die anderen Sample Hersteller.

    Und welches Delay wäre richtig und sinnvoll. Dass die Abstrahlung des Pfeifenklangs aus den Samples sich grundsätzlich anders verhält als bei den einzelnen Pfeifen im realen Kirchenraum ist außer Frage.

    Die Zeitverzögerung oder besser Latenz vom Tastendruck bis zum Beginn des Einschwingvorgangs bzw. Erklingen des Tones ist ja nur für die Spieltischposition relevant.

    Interessant ist das relative Delay der Orgeltöne untereinander, welches erstens von der Hörposition im Kirchenraum abhängig ist und sich zweitens bei großem Abstand zur Orgel kaum noch auswirkt.

    Daher meine Frage, welche Delays sollten die Samples enthalten oder müssten in der HW XML ODF hinzugefügt werden, sofern es überhaupt unterstützt wird um einen realistischeren Klang zu simulieren?

    Die drei Samples Front, Diffuse und Rear des Pedalregisters Subbass 16‘ 036-c der Erfurter Predigerkirche z.B. enthalten in der Aufnahme für Front 70ms, Diffuse 65 ms und Rear 173 ms Vorlauf bis der Einschwingvorgang beginnt.

    Wie kommt es aber zu den Werten? Ich kann mir nicht vorstellen dass diese nach Entfernung berechnet und nachträglich eingefügt worden sind, wobei es auch kaum Differenzen zwischen linkem und rechtem Kanal gibt.

    Da das Geräusch des Tastendrucks beim Samplen mit aufgezeichnet wird, vermute ich mal dass einfach die Zeit vom Tastaturgeräusch bis zum Beginn des Einschwingvorgangs als Delay in der Tonaufzeichnung beim Nacharbeiten erhalten bleibt nachdem das Tastaturgeräusch extrahiert wurde.

    Das wäre aus meiner Sicht jedoch für die virtuelle Reproduktion des Klanges nicht ganz korrekt, da ich ja nicht unbedingt das Delay oder in diesem Fall die Latenz zwischen Tastendruck und Ton der realen PO wiedergeben möchte, es sei denn ich lege auch Wert auf die Wiedergabe der klappernden Tastatur und deren Latenz bis zum Ton.

    Wenn wie im Fall des Samples der Predigerkirche das Delay generell deaktiviert werden kann, werden offensichtlich die in der Aufzeichnung vorhandenen Vorlaufzeiten bis zum Beginn des Einschwingvorgangs abgeschnitten.

    Ich habe jedenfalls den Eindruck dass beim Abschalten der Delays alle Töne exakt gleich schnell erklingen. (lässt sich am deutlichsten bei den Pedalregistern feststellen)

    Leider findet man dazu wenig bis gar keine Informationen von den SET Herstellern und in der XML oder der Doku danach zu suchen habe ich nach einiger Zeit aufgegeben.

    Die Delay Einstellungen in GO sind dagegen transparent nachvollziehbar und bei Bedarf auch leicht individuell anpassbar.

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

    HW Delay Settings.png

    Allerdings konnte ich bislang weder in der xml noch in der Hauptwerk Design Module Doku irgend einen Hinweis zu Delay Einstellungen finden. Ich hätte gerne gewusst welche Delays in dem Demo Set eingestellt sind. Das von mir verwendeten SET ist das Demo Sample der Erfurter Predigerkirche von PG.

    Die Verzögerung der Pfeifenansprache bei Tastendruck ist im Vergleich mit ausgeschaltetem Delay deutlich spürbar.