Beiträge von Alf

    Danke, dass ihr euch so bemüht -

    ich versuche erst mal vor Ort Verbesserungen anzuleiern: ein Hutschienen-Digitalnetzteil mit 24V u 40A Drehstrom gibt's ja schon für ca. 400 €. Dann wäre der Trafobrumm weg. Das Gebläse leiser zu kriegen dürfte schwieriger sein, wenn es denn wirklich das Gebläse ist, was das Windgeräusch erzeugt. Hab heute mit dem Orgelbauer, der die Wartung macht, darüber gesprochen, aber ich bin leider (oder besser: Gott sei Dank) nicht der Auftraggeber. (Und die Frage ist, ob solche "Luxusprobleme" gerade zeitgemäß sind.)

    Danke,

    aber zurzeit macht das Sampling wegen des lauten Trafos und Gebläses keinen Sinn. (Während sich beim Live-Spiel auf dem Instrument nur einmal die Nebengeräusche dazuaddieren, sind sie beim Sampling bei jedem Ton mitaufgezeichnet - das Geräusch addiert sich also entsprechend der Anzahl der gespielten Töne und Register.)

    Hab gerade die Mac-Version ausprobiert, läuft bei mir ohne Probleme. Danke für den Tipp, Haralder. Da ich kein Entwickler bin, sehe ich das Auftauchen derartiger "Konkurrenz" entspannter. Sicher wird bald eine Android-Version auftauchen, und auf ihr Smartphone passen die Kids auf. Vielleicht wachsen die unterschiedlichen Ansätze noch stärker zusammen und es gelingt, Waves mathematisch noch authentischer abzubilden...

    Die Grenzingorgel an meinem Wohnort wurde 2013 eingeweiht. (Sorry für die spärlichen Infos, aber ich war in das tolle Projekt nicht eingebunden und schon gar nicht zuständig.)

    Ich wurstle mit meinen Aufnahmen noch etwas weiter, um grundlegende Erfahrungen zu sammeln.

    (Wahrscheinlich ist es sowieso ziemlich anachronistisch, eine Orgel quasi als "rasender Reporter" in der Kirche sampeln zu wollen. Eher wahrscheinlich, dass ein Orgelbauer beim Vorintonieren in der Werkstatt "ein Mikrofon daneben stehen hat" und gleich die Pfeife aufnimmt. Aber hier soll auch kein matktreifes Produkt entstehen.)

    An Orgeln mit lautem Motor und leisen Registern sind auch schon renommierte Samplesethersteller verzweifelt ..

    Danke, das "beruhigt" etwas. (Bei den hohen leisen Pfeifen hört man auch bei einer längeren Aufnahme ständig dien Brumm als "2. Stimme")

    ..ich möchte noch mal den Vorschlag machen, bei Aufnahmen nicht nur Einzeltöne sondern auch Klangkombinationen als ein Sample aufzunehmen, z.B. ein Prinzipalplenum ..

    Das habe ich gemacht - in meinem Fall, um schneller zu einem Ergebnis zu kommen, allerdings kein Prinzipalplenum. Mir ist nicht klar, ob das der Grund war, dass der Loopauditionner ausgestiegen ist.

    (Wenn's um die Auswahl einer passenden Orgel fürs Sampling ginge, würde man an meinem Wohnort eher die ziemlich neue Grenzing-Orgel nehmen. Aber darauf spiele ich nicht.)

    Danke. Ich habe erst mal versucht das Geräusch "drinzulassen" - keine gute Idee:

    Der Gleichrichter- und Gebläsebrumm macht sich bei den höheren Tönen besonders stark bemerkbar, es entsteht quasi eine Zweistimmigkeit. Anders als bei Spiel auf der Pfeifenorgel addiert sich der Brumm, wenn man mehrere gesampelte Töne spielt. Man müsste vielleicht das Gebläse bei der Aufahme dämmen, wenn das möglich wäre. (In meinem Fall ist der Brumm laut zu hören, weil die gesampelten Labialpfeifen relativ leise sind, das wäre bei den 3 Zungenregistern der Orgel sicher anders.)

    Vielleicht sollte auch der Aufnahmepegel gleich passen, so dass später man keine Anpassungen braucht.

    Anderes Problem:

    Die Auto-Loop-Funktion des Programms Loopauditionner erkannte bei einigen Wave-Dateien keine Loops. Ich vermute, dass es vielleicht daran liegt, dass 2 Pfeifen gleichzeitig erklingen und die vielleicht nicht exakt gestimmt sind. Man sieht die Schwebung teilweise in der Wave-Datei. Die Samples sind vielleicht auch zu kurz, ca. 2 sec.

    (Es gibt also noch einige Herausforderungen, aber man sich kann die Erfahrung und das Wissen, das andere in Jahren angesammelt haben, gerechterweise nicht in ein paar Stunden aneignen.)

    Hallo, ich denke, meine Probleme passen am besten in diesen Themenbereich:

    Heute lerne ich die Arbeit der Anbieter von Orgel-Samples zu würdigen:

    Ich will gerade selbst von einer Orgel aufgenommene Klänge mit audacity bearbeiten. (Drei Registergruppen hab ich aufgenommen: OM und UM jew. zusammen, leise 8- und 4-Fuß-Register, Ped, 16- und 8-Fuß. Warum zusammen aufgenommen? Um schneller zu einem spielbaren Ergebnis zu gelangen.) Zuhause stellte ich fest, dass die Signale zu leise sind - aber leider werden mit audacitiy auch die Nebengeräusche "normalisiert"

    Die erste Erfahrung: Es ein Heidengeschäft, besonders, wenn man wie ich jedes Sample einzeln "von Hand" bearbeitet.

    Deshalb schreibe ich nach 30 Samples lieber diesen Text.

    En paar Fragen hätte ich:

    An unserer Pfeifenorgel ist der Gleichrichter und der Winderzeuger ziemlich laut. Man hört das Geräusch, wenn man den Klang von den Pfeifen aufnehmen will. Theoretisch müsste sich das mit audacity über Anlernen wie beim Rumpeln der Schallplatten entfernen lassen.

    Hat zufällig jemand Erfahrung mit dem Rausrechnen solcher Grundgeräsuche? Wird da das Pfeifensignal "angeknabbert" und verliert an Fülle?

    Entscheidend ist m. E., dass das Sample mit einem Nulldurchgang beginnt und ebenso endet. Ich hab das

    optisch versucht (Welle vergrößert dargestellt und geschnipfelt), aber bekomme eher Zufallsergebnisse: Es knackt halt manchchmal leise.

    Gibt es da Routinen, die das übernehmen?

    Ich geh davon aus, dass es da Makros gibt, die solche Dinge automatisch lösen, aber man kann nicht erwarten, dass Profis alle ihre Werkzeuge veröffentlichen. Genauso ist es mit der Looperkennung, das dürfte auch automatisiert z. B mit Loopauditionner gehen. Möchte jemand was dazu bemerken?

    Wie bekomme ich die Wave-Dateien überhaupt in eine Orgel rein?

    Mangels besserem Wissen mit der "Kuckucks-Methode": Die Wave-Dateien einiger Register der vorhandenen Samples durch meine gleichen Namens ersetzen. (Quasi ODF-Prgrammierung für (geistig) Arme.)

    Grüße

    Alf

    Hallo Mikelektric,

    ich hab mich oben auf diese Aussage bezogen, aber vielleicht unklar ausgedrückt:

    https://de.wikipedia.org/wiki/Elektronische_Orgel

    "Zum anderen muss der Ton bei der Wiedergabe künstlich verlängert oder verkürzt werden, was aufgrund der Lautstärkekonstellation zwischen erklingendem Ton und sich entwickelndem Hall nicht vollständig darstellbar ist.

    Eine besondere Schwierigkeit besteht darin, dass mittels Sampling der Effekt der gegenseitigen Beeinflussung mehrerer gleichzeitig erklingender Pfeifen auch mit hohem Aufwand kaum simuliert werden kann"

    Aber ich erkenne natürlich an, dass die Simulationen wirklich sehr gut sind und immer besser werden.

    Wobei ich trotzdem noch zuhause am Spieltisch sitze und vor mir meine Bücherwand sehe, selbst wenn ich eine 100%ige Simulation einer Kathedralorgel spielen könnte.

    Wer weiß, vielleicht wird irgendwann eine "Orgelkabine" angeboten, bei der um den Spieler herum Filmaufnahmen aus der Wunsch-Kathedrale laufen. (Einfacher wäre 'ne 3D-Brille, nat. mit Möglichkeit der Einblendung des Notenpults incl. der gerade zu spielenden Noten.)

    Grüße

    Alf

    Danke für die Antwort - ziemlich aufwändig, Loop- und Release-Bausteine so zu "behauen", dass sie aneinanderpassen. Da wünscht man sich als Laie eine Funktion, die den Ausklingvorgang mathematisch darstellt. Den Loop abrupt in Lichtgeschwindigkeit beenden und Hall dranhängen ist spieltechnisch brauchbar, aber nicht wirklichkeitsgetreu: die Pfeife klingt mit dem Restdruck ganz kurz weiter. Der Druckabfall dürfte sich dabei auch auf die Tonhöhe auswirken, nicht nur auf den Schalldruck. Interessant wäre, ob der Vorgang schon erforscht ist und es Modelle/Simulationen dazu gibt. (Das widerspricht nat. der Sample-Idee, aber die realistische Wiedergabe durch Samples stößt bekannterweise auch an Grenzen, z.B. bei der Interferenz der zahlreichen Schwingungen im Raum.)

    Hallo emsig,

    danke für die ausführlichen Antworten. Das lässt mich vermuten, dass der AU-Hall zu jedem einzelnen loop dazugerechnet wird und nicht zum Summensignal. (Mir fielen beim AU-Hall die früheren günstigeren Hallgeräte ein, die das Zischen mitverstärkten. Hall schluckt m. E. wegen der Raumreflexionen die höheren Frequenzanteile.)

    A apropos Release-Signal-Ankopplung: Ich finde gerade die Stelle nicht, wo Sie im Forum den Rechenweg beschreiben, wie man einen ""nahtlosen" Übergang aus jeder bel. Stelle des Loops hinkriegt. Ich habs eigentlich nicht kapiert, aber anscheinend läuft der Loop nach dem Loslassen der Taste etwas länger und der Computer rechnet schnell die Stelle mit der passenden Wellenform aus, an der der Loop beginnen muss, damit kein Bruch entsteht. Könnte man das nicht mit Ausblenden-Einblenden einfacher haben? Die Wellen ergänzen sich dann halt "irgendwie" ((Fourier?). Aber Knackser dürfte es dabei nach meinem "Gefühl" nicht geben.

    Gruß

    Alf

    Lesen bildet doch!

    Jetzt hab ich die Antwort gefunden, was bei den IOS Orgel Apps AU bedeutet: audio unit.

    (Im Internet hatte ich bei AU Hall nichts Gescheites gefunden.)

    Kann es sein, dass der AU-Hall ganz leicht rauscht? (Rechner-bedingt?)

    Und die Ausklingzeit bezieht sich auf den natürlichen Nachklang? Ist das der Release-Teil?

    Wird dann ohne Hall und Ausklingen der Loop abgebrochen?

    Sorry, aber beim Überlegen entstehen eben immer neue bzw. alte Fragen. (Vielleicht sollte jemand eine

    KI-Beantwortungs-App fürs Forum programmmieren: Alexa oder Siri für Orgler...)

    Grüße

    ALf

    Hallo, ich habe jetzt mal der Gambe aus der GO Demo-Version ein tiefes F# "meiner" Pfeifenorgel "untergejubelt": den Ton mit 44 kHz in Mono aufgenommen, leider mit viel Hall und dem Motorengeräusch, deshalb mit Audacity bearbeitet: Mit der Einblenden-Funktion den Einschwingvorgang beschleunigt und den Hall mit der Ausblendenfunktion gekürzt und das Ganze verstärkt, damit ich "meinen" Ton wiedererkenne. Danach noch Loops mit dem Loopauditionner eingefügt (Martin sei Dank), was immer auch das Programm mit meinem Wave-File angestellt hat. Dann den Ton entsprechend dem Originalton umbenannt und in das passende Verzeichnis kopiert: GrandOrgue hat das "Kuckucksei" akzeptiert und auf die vorgesehenen Töne verteilt. Allerdings klingt der Ton durch die Bearbeitung mehr wie tiefes Blech und der Hall ist verschwunden. Es ist wohl nach einiges an Wissen und Erfahrung notwendig, bis ich brauchbare Ergebnisse erzielen kann. (Ich hoffe auch nicht, dass ich da Rechte verletze, wenn ich auf meinem Computer zuhause Dateien des GO-Demos modifiziere.) Ich denke, es gibt Möglichkeiten den Hall und den Motor auszurechnen, aber ich habe Sorge, dass da noch mehr vom Klang verschwindet, weil die Periodizität wahrscheinlich sehr komplex ist.

    Endlich hab ich den Zusammenhang Samples pro Buffer und Verzögerung realisiert!

    (Steht auch "irgendwo" im Forum.) Insofern ist meine Aufnahme weiter oben, was GrandOrgue betrifft, Makulatur...)

    Aber ich hätte noch Anfängerfragen:

    - Kommt das Demo von GO mit nur 2 Samples pro Oktave aus? (Ich finde nur wenig Samples pro Register.)

    - Auf den Wavedateien der einz. Töne findet man (z.B. bei Obersuhl) 5 Loops markiert, aber es ist wohl nur einer aktiv. Stimmt das oder werden da je nach Spielweise unterschiedliche Loops angesteuert? (In 'ner Anleitung zu Wavlab las ich, dass auch mehrere Loops ineinandergreifen können um fließende Übergängen zu erzielen. Das dürfte bei Orgeltönen nicht erforderlich sein.)

    (Mein Traum in der Ferne wäre, zunächst mal Registergruppen von der Pfeifenorgel, auf der ich spiele, zu samplen und z.B. mit GO zu spielen. Was das ODF angeht, müsste ich mich wohl als Schmarotzer betätigen. Ich habe noch nie Loops erstellt, bin also noch weit weg von der Praxis und von brauchbaren Ergebnissen.)

    Ich tendiere eher zu Organnery, bräuchte da aber einen 3b oder 3b+:

    "Current image version 0.7.5 is ONLY compatible with model Raspberry Pi 3B ou 3B+, it will NOT boot on other models such as RaspberryPi4"

    Mal schaun, wann die wieder (preislich erträglich) lieferbar sind.

    Für GrandOrgue zögere ich, mir so einen P 400 anzuschaffen, obwohl er aussieht wie mein C64 früher:

    PI 4 Prozessor, Broadcom BCM2711 Chipsatz

    64 bit Quad Core ARM v8 Cortex-A72 @ 1,5 GHz

    Aber leistungsmäßig entspricht der wohl(?) meinem Zotac:

    Intel Celeron N2930 1,83 GHz 4 Kerne 8 GB Ram

    Da läuft zurzeit Win 7, aber ich muss für MX Linux quasi nur die SSD wechseln.

    Hallo Haralder, danke für die Infos. Der Raspberri ist zurzeit teuer und fast nicht zu kriegen - aber das klingt interessant, werd mich langsam vortasten. (Hab auch noch 'nen Dongle von einer uralten Hauptwerkversion rumliegen, den ich nicht nützen kann, weil ich das Programm auf dem Laptop zerlegt hab. Weiß nicht mal mehr die Version.)

    Hallo,

    ich weiß nicht, ob ich hier mit meiner "Latenz-Demo" (siehe Anlage) falsch lande,

    das Thema ist ja ein alter Hut und im Forum schon so oft mit unterschiedlichesten Aspekten durchgeprochen worden.

    Als Hobby-Orgelspieler hat's für mich bei Orgelsoftware aber ne gewisse Bedeutung - wohl wissend, dass man sowas auch bei mechanischen Orgeln hat, je nach räumlichen Gegebenheiten, von der Latenz des Gemeindegesangs ganz zu schweigen...

    Habe deshalb gerade 'ne dreiteilige Miniaufnahme gemacht:

    Mein Sk1 Hammond-Keyyboard spielt einen 8-Fuß (Pipe Organ Register, kein Sinus-Zugriegel) und dient als Referenz - nicht, weil es besonders gut klingt, sondern weil es eine für mich unhörbare Latenz hat.

    Dazu hab ich über Usb-Midi (nacheinander) immer (nur) ein 2'-Register mit folgenden Apps auf dem Mac M1 mini registriert:

    1. dem Programm Grandorgue...

    2. einer App aus dem Mac Store mit dem Sample einer spanischen Grenzingorgel von einer Firma wohl aus dem Polargebiet... (sorry, Gedankenblitzle)

    3. einer weiteren Church Orgel App aus dem Store (Zielgruppe Bestattungsfirmen?), die m. E. nicht mit Einzelsamples arbeitet (aber ich kann auch irren.)

    Ich will nicht großartig 'ne Bewertung abgeben. Dass Grandorgue hier bei mir schlechter abschneidet, liegt vielleicht auch an meiner Konfiguration...

    (Wenn ich mir vorstelle, wieviel know how hier im Forum verteilt wird, und das open source, werd' ich automatisch bescheiden.)

    Jeder Organist hat seine eigenen Schwerpunkte, was Klang, Vielfalt, Authenzität, Spielbarkeit usw. angeht.

    Grandorgue läuft bei mir noch auf älteren PCs mit Win 7 und MX Linux, aber speziell meine Linux-Kenntniss sind nach dem, was ich so im Forum lese und nicht kapiere, sehr ausbaufähig, gilt erst recht bei Äolus / GrandOrgue auf dem Raspberry.

    Grüße

    Alf