Posts by Ezasi

Quote from blu4r

Weiß jemand, wie das funktioniert und was man da so an Software braucht?

Am Kangbeispiel 12 des Beitrags 2233 möchte ich kurz die Vorgehensweise zur Veränderung eines Obertons mit Hilfe der Software SpectraLayers zeigen: Bild1_Krummhorn8'_036_C_SpectraLayers_2025-09-11.pdf. Das Bild 1 zeigt, wie beispielsweise mit Hilfe der Software SpectraLayers Vers. 9 die dritte Oberschwingung um 15 dB angehoben wird.

In der Hauptansicht von SpectraLayers zeigen sich die Teiltöne als farblich hervorgehobene horizontale Linien. Die unterste Linie steht für den Grundton (hier im Beispiel bei 66 Hz), darüber aufsteigend sind die Obertöne bildlich dargestellt. Zur Pegeländerung wird zunächst der gewünschte Bereich mit der Bildschirmmaus markiert. Über die Menüfolge „Verarbeiten“ -> „Amplitude“ -> „Verstärkung“ öffnet sich ein kleines Fenster, in das entweder durch Eintippen des Zahlenwertes oder alternativ durch Ziehen des Balkenschiebereglers mit der Bildschirmmaus der gewünschte Änderungsfaktor eingegeben wird. Durch Drücken der Leertaste lässt sich das Ergebnis unmittelbar anhören (ggf. vorher die Bereichsauswahl aufheben, sonst hört man hier im Beispiel nur den verstärkten dritten Oberton solo bzw. isoliert und die anderen Teiltöne nicht).

Wenn man mit der Software SpectraLayers schon etwas vertraut ist, schafft man eine Obertonbearbeitung in ein bis zwei Minuten (inkl. Laden und Speichern der jeweiligen Wave-Datei). Um ein komplettes Orgelregister zu bearbeiten, summiert sich die gesamte Bearbeitungszeit auf den Stundenbereich. Will man dann noch verschiedene Pegelveränderungen ausprobieren, ist dies manuell kaum mehr zu stemmen. Deshalb ist der Wunsch nur allzu verständlich, dies mit Hilfe einer Software zu automatisieren. Unter vielen möglichen Lösungswegen nachfolgend skizzenhaft ein (von mir jedoch nicht vollumfänglich in der Praxis erprobter) Lösungsansatz:

- In Ermangelung einer hierfür geeigneten und anwenderfreundlichen Spezialsoftware könnte man die Aufgabe ggf. selbst in die Hand nehmen und in die Musikprogrammierung eintauchen. Zuerst stellt sich da die Frage nach der Programmiersprache. Aus meiner Sicht ist hierfür Python eine gute Wahl, insbesondere wegen der umfangreichen Programmbibliotheken für die Signalverarbeitung. In vielen Linux-Distributionen ist Python enthalten. (Unter MS-Windows 10 verwende ich Python 3.11 in der kostenlosen Programmierumgebung Spyder IDE 5.4 von Anaconda.)

- Um eine Wave-Datei in Python zu lesen (bzw. zu schreiben) bedient man sich am besten der ebenfalls kostenlosen Zusatzmodule NumPy (Numerisches Python) und SciPy (Scientific Python). In letzterem befindet sich ein Untermodul namens „io“, mit dem sich auf sehr einfache Weise ein Sampling vollständig dekodieren und in einem Array speichern lässt. Vereinfacht ausgedrückt ist das Array ein Zahlenfeld, vergleichbar mit einer Excel-Tabelle: in der ersten Spalte stehen die Pegelwerte für den linken Stereokanal und in der zweiten jene für den rechten. Hierbei ist einzig nachteilig, dass man sich um den Erhalt der Loop-Punkte und ggf. des Release-Markers gesondert kümmern muss, um diese nicht zu verlieren.

- Mit Hilfe der Diskreten Fast Fourier Transformation („fft“-Untermodul bzw. -Funktion der SciPy-Bibliothek) führt man die Samples in eine andere Betrachtungsebene hinüber, in das Fourier-Frequenzspektrum. Im Prinzip ist es die (fertig ausprogrammierte) reversible Annäherung des ursprünglichen Sampling-Verlaufs durch viele harmonische Einzelschwingungen verschiedenster Frequenzen und Phasenlagen. Als Ergebnis liegen dann die aufsummierten Amplituden über den Frequenzen vor (das "Spektrum"). Jedoch sollten vor der gezielten Amplitudenveränderung über die Berechnung des Schallleistungsdichtespektrums die Frequenzbereiche der Teiltöne eindeutig identifiziert und abgegrenzt werden. Auch hierfür bietet SciPy eine vorgefertigte Lösung in Form des Untermoduls „signal.periodogram“ an. Im Prinzip ist dies eine erweiterte „fft“-Transformation.

- Somit lässt sich auf diese Weise recht komfortabel die Grundfrequenz eines Pfeifentons bestimmen. (Anmerkung: mit dieser Vorgehensweise bestimme ich den Korrekturwert für das Stimmen eines Pfeifentons. Den Korrekturwert trage ich dann in der ODF einer GO-VPO unter „Pipe0xxPitchTuning=“ ein). Hierbei ist das Ergebnis erheblich genauer, wenn das Sampling mit einer höheren Auflösung aufgezeichnet wurde (z.B. Bittiefe 24 anstatt 16 Bit).

- In der Betrachtung des Fourier-Frequenzspektrums zeigen sich die Oberschwingungen bis hin zur halben Samplingfrequenz. Bei der üblichen Abtastrate in CD-Qualität (44,1 kHz) liefert die „fft“-Transformation alle Oberschwingungen im Hörbereich eines (eher jüngeren) Durchschnittsmenschen. Mit Hilfe des Python-Plotmoduls „plot“ lässt sich das Ergebnis der Fast Fourier Transformation (sowie des Schallleistungsäquivalents) recht einfach am Bildschirm als Grafik ausgeben (s. Bild 2 für das oben verwendete Pfeifentonsampling des beispielhaft gewählten Krummhorntons 8´, c2).

Bild2_Krummhorn8_036_C_Python-Plots_2025-09-11.pdf Bild 2: Mit Python ermitteltes Periodogramm des beispielhaften Krummhorntons 8‘ c2. Den zugrunde liegenden Programmcode habe ich in der Datei „Listing1_Krummhorn_Spektrum_Python“ angehängt. Listing1_Krummhorn_Spektrum_Python_2025-11-10.pdf

- Auswahl des zu verändernden Teiltons: Nun ist mit Hilfe des Periodogramms der Frequenzbereich festzulegen, in dem die gewünschten Amplituden (Obertonbereich) angehoben oder abgesenkt werden sollen. Bei Labialpfeifen schwingt ein Oberton mit der ganzzahlig vielfachen Frequenz des Grundtons. Dagegen muss man bei Zungenpfeifen auch zwischen den Grundtonfrequenzvielfachen die Fourier- (bzw. Leistungsdichte-) Ausschläge beachten und somit rechnerisch ermitteln. Interessanterweise zeigen sich im Spektrogramm weder die Grundtonschwingung noch die Obertonschwingungen als exakt dünne, trennscharfe Linien. Deshalb empfehle ich - ähnlich wie beim manuellen Arbeiten mit der Software SpectraLayers - einen Bereich von ca. +- 20 Hz um die jeweils betrachtete Oberschwingung herum programmiertechnisch für die Amplitudenveränderung vorzusehen. Für das Anheben oder Absenken eines Obertons reicht eine einfache Multiplikation (bzw. Division) der Fourier-Amplituden im betrachteten Frequenzbereich mit einem Änderungsfaktor aus. NumPy ist da derart komfortabel, dass man für das betrachtete Frequenzintervall nicht mal eine explizite Schleife programmieren muss. Ähnlich zu markierten Excel-Zellen wird die Rechnung über den benannten Array-Bereich hinweg in einem Rutsch ausgeführt.

- In gleicher Weise, wie die Samples mit Hilfe der „fft“-Funktion vom Zeitbereich in den Frequenzbereich transformiert wurden, funktioniert auch die nahezu verlustfreie Rücktransformation des modifizierten Fourier-Spektrums mit Hilfe der inversen SciPy-Transformation namens „ifft“.

- Die Loop-Punkte und der ggf. vorhandene Release-Marker sind noch in die modifizierte Wave-Datei einzutragen. Dazu kann man den „Vorspann“ (den vor den Nutzdaten liegenden Header) im modifizierten Wave-File mit dem der Ausgangsdatei überschreiben. (Näheres zum Aufbau eines Wave-Files s. Wave-Files für GO)

- So komfortabel, wie mit SciPy das Lesen und Dekodieren eines Wave-Files ist, ist auch das Kodieren und Anlegen bzw. Abspeichern eines Wave-Files. SciPy kümmert sich um alle Details, wie z.B. die Byte-Reihenfolge im „Little Endian“ und Vorzeichenkodierung im sog. „Zweierkomplement“. Es braucht nur der Dateiname vorgegeben werden.

- Nun müssen sowohl die Fourier-Transformation als auch die Rücktransformation noch in eine Schleife gepackt werden, damit die gewünschte Modifikation für alle Wave-Files eines Orgelregisters gleichermaßen vollautomatisch abläuft. Hierzu kann Python selbst das Dateiverzeichnis eines benannten Datei-Pfades erstellen, wo alle zu modifizierenden Wave-Dateien abgelegt sind. Die modifizierten Dateien lässt man am besten in ein neues Verzeichnis schreiben. Nach dem Ende des Schleifendurchlaufs sollten für jeden Pfeifenton des betrachteten Orgelregisters die veränderten Samplings spielfertig vorliegen.

Informationen zu NumPy und SciPy sowie praxisnahe Anleitungen sind u.a. in folgender Literatur zu finden:

Knoll C., Heedt R.: Python für Ingenieure für Dummies; 2022 Verlag Wiley-VCH Weinheim; ISBN 978-3-527-71765-5. [Anmerkung: Dummies steht hier für einen gesetzlich geschützten Werbegag, der absolut nichts mit „Blödmännern“ (= Zitat aus dem DUDEN) zu tun hat!]

Steinkamp V.: Der Python-Kurs für Ingenieure und Naturwissenschaftler; 2023 Rheinwerk Verlag Bonn; 2. Auflage; ISBN 978-3-8362-9286-3.

NumPy Developers: https://numpy.org/doc/stable/ NumPy documentation, Version: 2.3 (Onlinedokumentation aufgerufen am 11.09.2025).

The SciPy Community: https://docs.scipy.org/doc//scipy/tutorial/index.html#user-guide Vers. 1.16.1 (Onlinedokumentation aufgerufen am 11.09.2025).

In gleicher Weise wie das gezielte Anheben bzw. Absenken von Teilschwingungspegeln in Python mit Hilfe der Fast Fourier Transformation möglich sein sollte, dürfte auch das selbstprogrammierte Entfernen des Hintergrundrauschens für Rohsamplings funktionieren. Anstatt die Pegel von Teiltönen zu verändern wären hier die Pegel in den Frequenzbereichen zu reduzieren, die zwischen den Teiltönen liegen.

Nun noch eine persönliche Anmerkung zum rechtlichen Aspekt, der ganz oben im ersten Eintrag dieses Treads angesprochen wurde: Kaum zu glauben, was der Datenklau von ca. zwei Sekunden Audiomaterial (im konkreten Fall exakt zwei Takte Musik) auslösen kann, nämlich einen über viele Jahre andauernden Rechtsstreit bis hin zur Verurteilung vor dem Europäischen Gerichtshof: https://openjur.de/u/2230139.html. Deshalb meine Empfehlung: mit einem Resampling lieber KEIN Risiko eingehen!

Quote from elias.orgel

es lassen sich auch geziehlt einzelne Teiltöne "bearbeiten" - mit Cubase geht das zB recht schnell und einfach

Direkt mit Cubase können keine Obertöne bearbeitet werden. Hierfür eignet sich die Software SpectraLayers, welche ursprünglich von Firma Sony entwickelt wurde, danach für ein paar Jahre im Hause Magix angesiedelt war und seit 2019 von Firma Steinberg weitergepflegt wird. Steinberg als Hersteller von Cubase hat in den Versionen Cubase Pro und Cubase Artist eine Schnittstelle zu SpectraLayers integriert und liefert in beiden Programmversionen SpectraLayers im Softwarebündel mit. Ebenso ist im Softwarebündel Sound Forge Pro Suite (bisher im Vertrieb von Firma Magix, zukünftig bei Boris FX) SpectraLayers als Add-on enthalten. Zudem gibt es Programmversionen von Samplitude, die SpectraLayers enthalten. Da kooperieren die Softwarehersteller miteinander. Selbstverständlich gibt es SpectraLayers auch als Einzelsoftwareprogramm zu kaufen.

Quote from blu4r

Ich arbeite seit längerem an verschiedenen Composites und habe gehört, dass es möglich ist, Samples digital so zu bearbeiten, dass man die Klangfarbe der Register (sinnvoll) verändern kann.

Sicherlich mag es spannend sein, mit den klangbildenden Formanten eines Pfeifentons zu experimentieren. Vielleicht findet sich durch eine subjektiv optimierte Neuintonation eine Vorgabe an Orgelbauer, bestimmte Obertoncharakteristika für reale Orgelpfeifen anzustreben. Schließlich hat man ja als OrganistIn bestimmte Vorstellungen, wenn man in der glücklichen Lage sein sollte, eine neue Pfeifenorgel zu bekommen. Da reichen die Wunschvorstellungen von der Disposition bis hin zur Holzsorte für die Manualtasten. Warum sollte man nicht auch Vorgaben hinsichtlich der Ausprägung klangformender Teiltöne eines Orgelregisters formulieren dürfen?

Darüber hinaus gibt es aus meiner Sicht durchaus weitere Gründe, sich mit den Obertönen intensiv auseinanderzusetzen: z.B. zur Ausbildung des Gehörs (als angehende(r) MusikerIn oder gar als Hochbegabte(r) mit dem Berufswunsch, bei einem Orgelbauer IntoneurIn zu werden…)

Quote from Synthematophon 8'

Ich denke mal, es gibt keine wirklichen (allgemein anerkannten) Definitionen.

Dem stimme ich zu.

Gehen wir zeitlich noch etwas weiter zurück, bis in die Zeit der aufkommenden Analogtechnik: Die ersten nicht natürlichen Orgeln hat man seinerzeit als „Elektronische Orgeln“ bezeichnet (umgangssprachlich auch "Elektronenorgeln"). Diesen Begriff verstehe ich heute als Oberbegriff auch für die nachfolgenden Generationen an technischen Weiterentwicklungen für jene Orgelspezies, die nicht zu den natürlichen Musikinstrumenten zählen. Folgende technische Entwicklungsstufen hat es m.E. gegeben:

Generation 1: Analogorgel

Generation 2: Digitalorgel mit künstlicher Klangmodellierung

Generation 3: VPO (Virtuelle Pfeifenorgel) auf Basis realer Orgelklänge; Digitalorgel mit Samplings

Jetzt in der dritten Generation würde ich eine VPO, die ihrem realen Vorbild sehr nahekommt, als „Digitalen (Orgel-) Zwilling“ bezeichnen.

… jedoch ist dies nur meine persönliche Sichtweise …

Für die Touchscreen-Bedienung des Setzers in GO gibt es eine Reihe recht simpler Lösungen, wenn man den Setzer in GO nicht über eine separate, MIDI-gesteuerte Anzeige ansteuert, sondern die Basisfunktionen eines modernen Betriebssystems nutzt. Dazu braucht man auch nicht ein Hauptwerk-zertifiziertes Display. Es geht auch mit einem Tablet oder einem kostengünstigen Touchscreen.

In aktuellen Betriebssystemen lassen sich alle mit der Bildschirmmaus anklickbaren Elemente bei Vorhandensein eines berührungssensitiven Monitors alternativ auch mit dem Finger auf dem Touchscreen aktivieren bzw. deaktivieren. Der Touchscreen sollte ja eine vollwertige alternative Eingabemöglichkeit zur Maus darstellen.

In meiner kleinen PC-Sammlung habe ich selbst vier unterschiedliche, gut funktionierende Konfigurationen mit Touchscreen-Eingabe für GO (inkl. Setzerbedienung) in Verwendung:

1.: Notebook mit integriertem Touchscreen-Display

Vor ein paar Jahren habe ich mir ein edles Notebook geleistet (Asus Expertbook B6602FC). Darauf läuft GO 3.15.2-1 unter MS Windows 11. Den für den Touchscreen erforderlichen Treiber hatte seinerzeit Windows 11 eigenständig mitinstalliert. Ich musste mich um nichts kümmern. Jetzt habe ich hier nun die Auswahl, den Setzer und die Registerzüge entweder mit der Maus oder mit dem Finger zu bedienen.

2.: Desktop mit Tablet-Remote-Steuerung

An meinen Desktop-PC, auf dem noch Windows 10 läuft, habe ich über das WLAN-Heimfunknetz mein Tablet (Samsung Galaxy Tab S5e, Betriebssystem Android 10) gekoppelt. Hierzu muss auf dem Desktop die Remote-Steuerungsfunktion aktiviert sein. Über den Google-Playstore hatte ich mir seinerzeit die kostenlose App "Remote Desktop 8" von Microsoft heruntergeladen und installiert (Anleitung siehe unter https://www.anyviewer.com/de/how-to/andr…rn-3399-tc.html) Allerdings funktioniert das Ganze nur mit der Windows 10 Pro (sowie Enterprise) und nicht mit der Windows 10 Home-Version. Bei der Installation der App auf dem Tablet ist darauf zu achten, dass der Benutzername sowie das Passwort für den Desktop-PC (und nicht für das Tablet) einzugeben sind. Beim Benutzernamen muss der Name des Desktop-PCs vorangestellt sein und als Trennzeichen der Backslash "\" verwendet werden. Der Vorteil dieser Lösung ist, dass sich damit in GO Registerzüge, Koppeln, Kombinationen und Setzer, Pistons, u.s.w. kabellos steuern lassen.

3. und 4.: Mini-PC mit angeschlossenem (externen) Touchscreen

Meinen NUC mit i7-CPU des chin. Herstellers Eglobal (s. https://de.aliexpress.com/item/32850708878.html) betreibe ich im Dual-Boot-Modus sowohl unter Ubuntu Studio 24.04 als auch unter Windows 10 Pro. Beide Betriebssysteme bringen den jeweils erforderlichen Touchscreen-Treiber von Haus aus bei der Betriebssysteminstallation selbsttätig mit. Als Touchscreen verwende ich ein ASUS Zenbook Touch (Modell MB16AMT). Die Qualität dieses Touchscreens ist m.E. sehr gut (s. auch https://www.testberichte.de/p/asus-tests/z…estbericht.html) . Allerdings haben diese beiden letztgenannten Konfigurationen den Nachteil, dass hier zwei Verbindungskabel zwischen dem PC und dem Monitor erforderlich sind (HDMI-Kabel für die Anzeige sowie USB-Kabel für die Touch-Funktion bzw. Druckpunktrückmeldung). Allerdings gibt es andere Touchscreens, wo nur ein Verbindungskabel erforderlich ist (s. Touchscreen-Monitore)

Meine Anregung ist, zur Nutzung der Touch-Funktionen für den Setzer und die Registerzüge in GO ggf. doch einen der oben beschriebenen (und auch tadellos funktionierenden) einfacheren Wege zu beschreiten.

Falls GO für die Anzeige des Setzers und der Register ein zu unklares oder zu kleines Bild bereitstellt und auch die Anzeige in GO für "Setzer und Kombinationen" nicht ausreichend sein sollte, bietet sich die Erstellung einer zusätzlichen Anzeigemaske für den Setzer und die Register an (unabhängig von der Bedienung Maus vs. Touch). Zur vorbereitenden Bearbeitung und zum Aufbereiten der Bildausschnitte, welche ich schlussendlich in einer selbst erstellten GO-Setzermaske für die Touch-Bedienung verwende, habe ich sehr gute Erfahrungen mit der Software "CorelDraw Graphics Suite 2020" gemacht (ist leider nur für Studenten kostenlos erhältlich). In der Folge verknüpfe ich im ODF die selbst erstellten bzw. bearbeiteten Bildelemente mit der VPO. Damit sind erstklassige Ergebnisse erreichbar. Ein kleiner Wermutstropfen ist, dass man meines Wissens nach in GO aktuell nur statische Bildausschnitte ansteuern und überblenden kann. Für die Weiter- und Zurück-Taster bei der Ansteuerung des Setzers sowie auch für die Ab- und Rücksteller (u.a. auch für "GC") würde ich mir ein kurzes Aufleuchten nach dem Antippen des jeweiligen Tasters als visuelle Rückmeldung wünschen. Für dieses Detailproblem, das nur Taster und nicht Umschalter betrifft, könnte u.U. eine einfache Lösung sein, Bildelemente des animierten Bildformats ".gif" (oder eines Nachfolgeformats, wie z.B. ".mng") vorzusehen. Mit animierten Bildern habe ich bislang keine Erfahrung, lediglich mit der Einbindung von Bildelementen der Formate ".png" und ".jpg". Lt. GO-Dokumentation sollten sich auch ".gif"-Bilder in GO einbinden lassen. Ob dann beim Antippen auch die kurze Aufleuchtanimation startet, habe ich bislang noch nicht ausprobiert.

Aus meiner Sicht sollte es mit Hilfe von CorelDraw auch machbar sein, anstatt oder ergänzend zur üblichen Ziffernregistratur bzw. Nummernanzeige am Setzer eine programmierbare Klartextanzeige für einen Touchscreen vorzusehen (werkspezifische Registratur mit variabler alphanumerischer Benennung). Auch da besteht möglicherweise noch Weiterentwicklungspotenzial für die in GO bereitgestellten Standardfunktionalitäten.

Das Erstellen einer zusätzlichen Anzeigemaske sollte wirklich nur der letzte Ausweg sein. An und für sich sollte sich GO auch mit einem ganz gewöhnlichen Touchscreen problemlos bedienen lassen.

Mittlerweile hat Intel die Ursache gefunden, warum viele leistungsstarke Desktop-CPUs der 13. und 14. Generation vorzeitig ausfallen. Ein fehlerhafter interner Rechenalgorithmus kann die CPU-Betriebsspannung auf unzulässige Werte erhöhen, was zu Instabilitäten, Abstürzen, Überhitzung und somit auch zur thermischen Selbstzerstörung führen kann. Über ein BIOS-Update (zu beziehen über den Hersteller des jeweiligen Motherboards) sollte sich das Problem beheben lassen. Allerdings lässt sich nun mal eine bereits thermisch geschädigte CPU damit nicht mehr reparieren...

s.:

https://klemm-music.de/wp-content/uploads/2022/11/Garritan-Sounds-in-Finale-v27.pdf

Nun spinne ich den gedanklichen Faden noch ein wenig weiter: Firma MakeMusic hat kürzlich in einem YT-Video anschaulich dargestellt, wie die Vorgangsweise zum kostenlosen Download der aktuellen "Finale"-Version (V27) ist und wie man zum Vorzugspreis das Notensatzprogramm "Dorico" von Firma Steinberg erwerben kann. Innerhalb von 24 Stunden haben mehr als 10.000 User dieses Video aufgerufen. Dies waren sicherlich keine Zufallssurfer, sondern m. E. wie ich persönlich angemailte "Finale"-Nutzer. Angenommen es nehmen nun zwei Drittel dieser Personen das Umstiegsangebot zu Dorico Pro 5.1 zum Vorzugspreis von 149 US$ an, dann spült dies mit einem Schlag einen Millionenbetrag in Steinberg's Kasse (vielleicht irgendwie der "gut passende Zeitpunkt“ zum aktuellen vierzigjährigen Firmenjubiläum von Steinberg). Da kann man sich nur wundern, wie ein Unternehmen durch den Niedergang des Konkurrenten bestens verdient. Jetzt könnte man vermuten, dass die tatsächliche Anzahl an "Finale"-Nutzern weltweit tatsächlich viel höher ist, als vorhin aufgrund der kurzfristig vorgenommenen Video-Klicks geschätzt (aktueller Stand: 18.859 Klicks auf YouTube). Hinzu kommt noch, dass in der Folge auch die "Dorico"-Neukunden für künftige "Dorico"-Updates regelmäßig zur Kasse gebeten werden dürften. Das ergibt in der Summe beachtliche Mehreinnahmen für Firma Steinberg, ohne sich hierfür sonderlich anstrengen zu müssen.

Ja, da staunt der kleine Laie, der aus Kostengründen täglich mit dem Fahrrad zur Arbeit fährt...

Ganze zehn Tage hat die Schockstarre von Firma Klemm, dem Vertriebspartner in Deutschland von Firma MakeMusic für das Notationsprogramm "Finale", gedauert. Erst mit dieser Verzögerung hat sich das Unternehmen Klemm an seine deutschsprachigen Kunden gewandt, mit teilweise widersprüchlichen Aussagen zu denen des Herstellers von "Finale", MakeMusic. Klemm schreibt in einer E-Mail an seine Kunden, dass der "Finale"-Lizenzserver doch nicht in einem Jahr abgeschaltet sondern auf unbestimmte Zeit weiterbetrieben wird. Zudem werden die deutschsprachigen Kunden darüber informiert, dass das kostenlose Update von einer früheren "Finale"-Version auf die aktuelle "V27" nicht für Nutzer der deutschsprachigen Version gilt. Um die Verunsicherung zu komplettieren schreibt Firma Klemm von Verhandlungen mit Firma Steinberg, um auch deutschsprachigen "Finale"-Nutzern den Umstieg auf Steinberg's "Dorico" zum Vorzugspreis von 149 US$ zu ermöglichen. (Anm.: Im Onlineshop von Firma Klemm wird die Vollversion von "Finale" aktuell für 349,95 EUR zum Kauf angeboten; bei Thomann kostet "Dorico Pro 5" aktuell 289 EUR.)

Hierzu meine persönliche Meinung sowie meine Spekulationen:

Der deutsche Vertriebspartner von "Finale" dürfte von der Ankündigung der Firma MakeMusic hinsichtlich der Einstellung der Weiterentwicklung von "Finale" ebenso überrascht gewesen sein, wie alle "Finale"-Nutzer. MakeMusic dürfte es verabsäumt haben, seine weltweiten Vertriebspartner vorab zu informieren. Das hätte m. E. nicht passieren dürfen. Nun dürfte der deutsche "Finale"-Vertriebspartner versuchen zu retten, was noch zu retten ist, bzw. aus der aktuellen Situation noch für sich Kapital herauszuholen und am Geldkuchen mitzunaschen. Möglicherweise hat Firma Klemm durch die bisher geleisteten Übersetzungen für die deutschsprachige Softwareversion von "Finale" gewisse Rechte erworben. (Wir kennen ja die bestehenden vertraglichen Regelungen zwischen den Firmen MakeMusic und Klemm nicht.) Jedoch finde ich es fragwürdig, dass im Internetauftritt des deutschen Vertriebspartners nach wie vor verschiedene Versionen von "Finale" zu Kauf angeboten werden. Freilich wird dort jetzt der deutliche Hinweis angegeben, dass das Produkt nicht mehr gepflegt wird. Aber ist dies dennoch moralisch okay? Zudem stelle ich mir die Frage, ob Firma Klemm von Firma Steinberg für jeden Umsteiger der deutschsprachigen "Finale"-Version auf "Dorico" eine Provision erhalten möchte? Eigentlich könnte mir das Verhalten von Firma Klemm ja egal sein, aber man macht sich halt so seine Gedanken... (das kostenlose "MuseScore" lässt grüßen!!)

Quote from Georgy

Wir haben in einem privaten Orgelfreundeskreis einige MiniPCs der 13. Generation gekauft. Nun waren wir natürlich besorgt wegen der bekannten Probleme, die Intel zugegeben hat. Stand gestern sind folgende Prozessoren betroffen: ... Core i5-13600K/KF, Core i7-13700K/KF, Core i9-13900K/KF ... Core i5-14600K/KF, Core i7-14700K/KF, Core i9-14900K/KF

Die genannten Prozessoren sind CPUs für Desktop-PCs. Meines Wissens nach sind keine Prozessoren für Mini-PCs von den speziellen thermischen Problemen betroffen.

Sehr gute Erfahrungen habe ich mit dem Kauf von Mini-PCs (sowohl lüfterlos als auch mit Lüfter) beim chinesischen Onlineshop EGlobal gemacht (wie Qikemall über Aliexpress zu bestellen): https://de.aliexpress.com/item/1005006215758440.html

Baugleich dürfte Topton sein: https://de.aliexpress.com/item/1005006206017843.html

Vermutlich könnten uns spannende Zeiten bevorstehen, da lt. Computerzeitschrift "Chip" der Hersteller Quallcom mit seinem neuen ARM-Prozessor "Snapdragon X Elite" noch leistungsfähiger und energieeffizienter sein dürfte, als es die Intel-Prozessoren der 13. und 14. Generation für Mini-PCs und Notebooks sind. Der "Snapdragon X Elite" weist eine aus dem lithographischen Fertigungsprozess resultierende innere Strukturbreite von nur 4 nm auf (gegenüber 10 nm bei den aktuellen Intel-Prozessoren; Anm.: "nm" = Nanometer). Dadurch erreicht er einen TDP-Wert von lediglich 23 Watt (im Vergleich gegenüber 55 Watt beim i9-13950HX sowie i9-14900HX; Anm.: "TDP" = Thermal Design Power, thermische Verlustleistung bzw. erforderliche Abwärmeabfuhr).

Allerdings werden wir uns da auf die Marktverfügbarkeit entsprechender Mini-PCs noch etwas gedulden müssen...

Die Ankündigung von Firma MakeMusic, USA, dem Hersteller des renommierten Notensatzprogramms "Finale", hat mich doch einigermaßen überrascht. "Finale" wird nicht mehr weiterentwickelt, sondern vom Markt genommen. Daher möchte ich nun etwas wehmütig zurückblicken.

Nun bin ich doch schon seit einigen Jahren begeisterter Nutzer von "Finale". Mit dieser Software bin ich mehr als zufrieden. Sicherlich hatte es seinerzeit lange gedauert, bis ich sie zu bedienen lernte und bis ich wusste, was sich hinter den einzelnen Icons und Funktionen verbirgt. Natürlich hat auch Finale seine Tücken und auch Schwächen. Doch im Laufe der Jahre hat man gelernt, diese zu umschiffen. Mit den regelmäßigen (leider kostenpflichtigen) Updates ist die Software stetig benutzerfreundlicher und auch "besser" geworden. Doch nun ein kurzer Blick noch weiter zurück in die Zeit, bevor ich "Finale" kennen und lieben lernte:

Lange bevor ich mir "Finale" kaufte, arbeitete ich mit dem Noteneditor des Sequenzers "Cakewalk" des Herstellers Twelve Tone Systems Inc (späterer Name: "Cakewalk Sonar"; heute kostenlos erhältlich beim Clouddienst "BandLab" der Firma Caldecott Music Group). Schon damals hatte ich mir eine eigene Noteneingabehilfe gebastelt. Sie bestand darin, die Blatteingabe einer Note in der Tonhöhe und der Tondauer zu entkoppeln. Mit dem Keyboard spielte ich die Tonhöhe ein, dazu gab ich mit einem selbstgebauten Pedal die jeweilige Tondauer an. Für jede Standard-Tondauer hatte ich eine separate Pedaltaste zu Verfügung (z.B. jeweils eine für ganze Töne, für Halbe, Viertel, Achtel usw., sowie eine für punktierte Noten; "krumme" Tondauern gab ich mit der Tastatur ein). Damit umging ich die Problematik der Quantisierung beim Zusammenfügen mehrerer Stimmen. (Anm.: mittlerweile stehe ich mit diesem Ansatz durchaus nicht mehr alleine da.) Zu dem damaligen Zeitpunkt befand sich das Konkurrenzprodukt "Cubase" von Firma Steinberg m. E. noch in den Kinderschuhen. Schließlich verbesserte ich meine Möglichkeiten der Layout-Gestaltung und Partitur-Bearbeitung durch den Kauf von "Capella" und "Capella-Scan", einem sehr guten Notensatz- bzw. Musiknotenerkennungsprogramm. Jedoch hatte irgendwie "Capella" den Anschluss an eine modere Grafikbenutzeroberfläche verpasst (Anm.: vermutlich verschwand sie deshalb vor ein paar Jahren vom Markt). Da jedoch zwischenzeitlich meine Ansprüche an ein Notensatzprogramm gestiegen waren, begab ich mich schon frühzeitig auf die Suche nach einer Alternative zu "Capella". Soviel zum Rückblick in mein Leben, bevor ich mich mit "Finale" anfreundete.

Schließlich war für meine Entscheidung zum Wechsel zu "Finale" ausschlaggebend, dass angesehene Institutionen mit diesem Notensatzprogramm arbeiteten, wie bspw. das Mozarteum in Salzburg. Den Kauf von "Finale" habe ich bis heute nie bereut, obwohl "Finale" mächtig Konkurrenz durch "Sibelius" bekommen hat. (Anm.: m. E. schwindet aktuell auch die Marktpräsenz von "Sibelius", nachdem die Weiterentwicklungskapazitäten für dieses sicherlich sehr gute Notationsprogramm stark heruntergefahren und letztlich in die Ukraine verlagert wurden; einige der ursprünglichen Entwickler von Sibelius wurden von Firma Steinberg zur Entwicklung von "Dorico" (s. weiter unten) angeworben). Trotz des erforderlichen Nachbearbeitungsaufwandes schätze ich bis heute die Möglichkeit, mit "SmartScore" Notenblätter optisch zu erfassen und zu erkennen sowie diese anschließend in "Finale" weiterzuverarbeiten oder auch nur in eine andere Tonart zu transponieren. Jedoch ist mir in einem Punkt "Finale" bis heute etwas suspekt geblieben: es ist die Verschlüsselung des Dateisystems, was den Austausch mit anderen Programmen erschwert.

Als vor etwas mehr als zehn Jahren Firma Steinberg ankündigte, ein eigenes Notensatzprogramm namens "Dorico" entwickeln zu wollen, hatte ich damals nur ein müdes Lächeln dafür übrig. Der spezielle Markt war doch schon sehr gut besetzt. Doch wie sehr sollte ich mich damals geirrt haben! Denn es heißt jetzt von MakeMusic und Steinberg im Gleichklang sinngemäß: "Finale ist tot; es lebe Dorico!". Allen "Finale"-Benutzern wird für 149 US$ ein Crossgrade zu "Dorico Pro 5" angeboten. Ansonsten können bisherige "Finale"-Nutzer ab jetzt nur noch ein Jahr lang ihre gültigen Lizenzen von einem PC auf einen anderen übertragen bzw. Upgrades des MS-Betriebssystems vornehmen (z.B. von Windows 10 auf 11). Danach kann "Finale" nicht mehr in einer anderen Umgebung aktiviert werden, da dann das "Finale"-Lizenzmanagement abgeschaltet wird. Also muss ich mich nun schweren Herzens von "Finale" verabschieden und mich auf die Suche nach einem anderen guten Notationsprogramm begeben.

In dem Ende von "Finale" liegt sicherlich auch die Chance des generellen Neubeginns. Für mich stellt sich jetzt die Frage, ob der passende Zeitpunkt zum Verlassen der MS-Windows-Welt und der Umstieg auf Linux mit ALSA, JACK & Co. gekommen ist. In den entsprechenden Forum-Beiträgen hier in unserer Community lese ich jetzt sehr interessiert über Erfahrungen mit den Open Source-Notationsprogrammen "MuseScore" und "LilyPond", letzteres in Kombination mit "Frescobaldi". Mal sehen, ob die Linux-Umgebung für mich eine Zukunftsperspektive darstellt. Auf der Suche bin ich noch nach persönlichen Erfahrungsberichten über die kostenlose DAW "Rosegarden"... Doch jetzt heißt es: Ade "Finale"!

Quote from elias.orgel

anstelle von "das geht aber nicht, weil..." hatte ich mehr auf ein "was da alles möglich ist..." gehofft

Vielleicht hier ein kleiner Beitrag zu dem, was realitäsnah möglich sein könnte:

Aus meiner Sicht wäre der Aufwand überschaubar, für einen simplen Test aus einem mit Nachhall behafteten Sampleset eine absolut "quasi-trockene" Version zu kreieren. Dazu wären lediglich sämtliche Release-Files des Samplesets durch sog. Dummy-Files zu ersetzen (Wave-Files ohne Nutzdateninhalt). Dies wäre leicht in einer Hochsprache zu programmieren.

Doch zunächst kurz zusammengefasst die größten Nachteile von Lautsprechersystemen, die besonders im Zusammenwirken mit natürlichen Orgelpfeifen auffallen könnten:

• Ein handelsübliches Lautsprechersystem regt im Vergleich zur natürlichen Pfeifenorgel eine viel kleinere Luftmasse zum Schwingen an. Das könnte sich auf das gesamte Klangbild plastisch auswirken.
• Die Klangabstrahlung beim Lautsprecher ist - insbesondere bei höheren Tönen - z.T. erheblich richtungsorientiert. Dies geht zu Lasten der räumlichen Wahrnehmung.
• Es besteht ein großer Unterschied in der dynamischen Akustik-Auflösung im Vergleich der beiden Klangerzeugungssignalketten bis hin zur Wahrnehmung durch das menschliche Ohr (direkt abgestrahlter Orgelpfeifeton vs. Lautsprecherwiedergabe eines gesampelten Orgelpfeifentons).
• Hinzu kommt die nicht zu vernachlässigende Problematik der begrenzten Dynamik der Mikrofone beim seinerzeitigen Erstellen des Samplings (... was hier allerdings weniger das Thema sein dürfte).
• Bei der Wiedergabe von 32´- und tiefen 16´-Orgelpfeifentönen scheitern ohnehin viele handelsübliche Lautsprecher.
• Breitbandige dynamische Lautsprecher haben einen schlechten elektrischen Wirkungsgrad (deutlich unter 10 %). (Auch dies dürfte hier weniger relevant sein).

Es gibt bereits unterschiedliche Konzepte zur alternativen Klangabstrahlung, die auf dem sog. Helmholtz-Prinzip beruhen (Schallabstrahlung mit Hilfe von zum Schwingen angeregten Resonatoren). Die wohl am weitesten gediehene Entwicklung geht auf den Orgelbauer Ewald Kienle zurück, der bis 2021 im Großraum Stuttgart lebte: s. https://de.wikipedia.org/wiki/Ewald_Kienle

Das "Kienle-Abstrahlsystem" ist ein hybrides System: mehrere Resonatoren (im einfachsten Fall pfeifenähnliche Rohre) werden durch einen lautsprecherähnlichen, elektromagnetischen Aktuator zum Schwingen angeregt, wobei ein Resonator für einen bestimmten Frequenzbereich zuständig ist. Das Prinzip zeigt folgende Skizze, die ich der Patentschrift DE2924473C2 des Erfinders Ewald Kienle entnommen habe (die Schutzrechte dieses Patents dürften zwischenzeitlich ausgelaufen sein):

Demnach sind nur wenige Resonatoren nötig, um ein weites Klangspektrum in hoher Qualität abzudecken (unterschiedliche Frequenzbereiche sowie Klangfarben). Angeblich gibt es auf dem Markt bereits elektronische Sakralorgeln, die das "Kienle-Abstrahlsystem" eingebaut haben. (Damit habe ich jedoch noch keine eigenen Höreindrücke gesammelt.)

Aus meiner Sicht wäre es großartig, Samplings mit GO und einem Resonator-Abstrahlsystem wiederzugeben. Da sollte sich doch ein Hersteller finden lassen, der das ganze in eine transportable Box baut...

Innerhalb der finnischen Kulturlandschaft sorgt derzeit die neue Orgel des Konzerthauses in Helsinki für Gesprächsstoff und teilweise auch für kontroverse Diskussionen. Die neue Orgel wurde von Firma Rieger, Schwarzach / Vorarlberg (Österreich), hergestellt. Mit ihren ca. 10.000 Pfeifen und 124 Registern zählt sie weltweit wohl zu den "großen" Konzerthausorgeln. Sie ist 14 m hoch und ragt voluminös in den Konzertsaal hinein. Für die Öffentlichkeit erklang sie zum ersten Mal am Neujahrstag 2024. Auf 4,4 Mio. EUR waren die Anschaffungskosten budgetiert.

Den nicht ganz unumstrittenen Prospekt prägen silberne, schwungvoll gebogene, luftzuführende Rohre sowie zehn sich quasi aus dem hölzernen Gehäuse schlängelnde, voll funktionsfähige Pfeifen. Diese wurden nicht aus einem konventionellen (metallischen) Werkstoff gefertigt, sondern im 3D-Druck aus Bio-Kompositen. Das Orgeldesign stammt vom österreichischen Künstler Harald Schwarz.

Im Gegensatz zu einer herkömmlichen (Kirchenempore-)Orgel sitzen die Besucher im Konzerthaus Helsinki nahe an den Orgelpfeifen. Dadurch ist das Klangerlebnis relativ intensiv. Eine Besonderheit ist, dass im obersten (vierten) Manual durch zusätzliche Tasten das Orgelspiel in Vierteltonschritten möglich ist. Eine andere Besonderheit ist die großzügig dimensionierte Winderzeugung. Sie erlaubt einen flexibel veränderbaren Winddruck (Überdruck / Unterdruck), was ja besonders für die Neue Musik interessant ist. Mit der neuen Orgel lassen sich moderne Klangeffekte erzielen, die wir sonst nur von einem Synthesizer her kennen.

Die Disposition kann unter folgendem Link eingesehen werden: https://organindex.de/index.php?titl…_(Rieger-Orgel)

Weitere Informationen sind unter folgendem Link erhältlich: https://www.uniarts.fi/en/articles/in…ed-work-of-art/

Klangproben mit dem Organisten Olivier Latry (zu Beginn im Musikstück der finnischen Komponistin und großzügigen Förderin besagten Orgelbauprojekts Kaija Saariaho zusammen mit dem Cellisten Anssi Karttunen): https://www.youtube.com/watch?v=yzQqz_eCgP4

Quote from Organist 117

ich kann die Audiodateien aber nicht in zb. dem Organbuilder programm verwenden da nicht alle Töne vorhanden sind. Da frage ich mich wie diese Orgel überhaupt funktioniren kann

... da geht mir folgendes durch den Kopf:

Für die im GO-Installationspaket enthaltene Demo-Orgel wären für ein qualitativ hochwertiges Sampleset theoretisch über Tausend Einzelpfeifen-Samplings erforderlich. Tatsächlich hat hierfür der Ersteller LP nur 84 real gesampelt (ohne Berücksichtigung der acht Samplings für die Betriebsgeräusche). Mit den wenigen Pfeifentonsamplings wird auch der große verbleibende Rest an Tönen abgedeckt, indem innerhalb der ODF u.a. der Eintrag "PitchTuning" ausgiebig angewendet wird. Das spart viel Speicher und auch im Vorfeld viel Arbeit bei der Sampleset-Erstellung, ist jedoch aus meiner Sicht eine fragwürdige und unsaubere Lösung. (Für eine Demo-Orgel kann ich es vielleicht noch gelten lassen...)

Nehmen wir als anderes Beispiel die "Friesach". In den drei Manualen der VPO von PG reicht der Tonumfang von C bis c4. Dagegen deckt das reale Vorbild in der Stadtpfarrkirche zum heiligen Bartholomäus in Friesach in den Manualen lediglich den Bereich von C bis a3 ab. Somit ist in der VPO der Tonumfang in jedem der 35 Manual-Register im Diskant um drei Halbtöne künstlich erweitert. Wenn man dies nicht weiß, merkt man es m. E. beim Abhören nicht unbedingt. Nebenbei bemerkt: In der VPO "Friesach" finden sich weitere 61 "Kunsttöne", die nicht vom realen Vorbild gesampelt wurden. Vermutlich gab es da beim Sampeln störende Nebengeräusche, weshalb nun andere Töne des jeweiligen Registers herhalten und die Lücken schließen müssen, indem sie hierfür in die passende Frequenzlage "verschoben" wurden. (Von den anderen 190 Pfeifentönen, die bei der VPO "Friesach" zwecks Verbesserung der Stimmung in der Tonhöhe nachträglich verändert wurden, will ich ja nicht sprechen...)

Für mich stellt sich die Frage, was hinsichtlich der Authentizität zum originalen Vorbild noch zulässig ist und was an eher fragwürdigen "Tricks" aus ästhetischen Gründen abzulehnen ist? Wo verläuft die Grenze?

Mit der „richtigen“ Software wäre es aus meiner Sicht für Anwender weniger aufwändig, Hintergrundrauschen aus Audioaufnahmen zu entfernen. Es ist eher Knochenarbeit in Verbindung mit Erfahrung, welcher Einstellparameter welche Veränderung bewirkt. Dagegen spielen die Entwickler einer hierfür geeigneten Software in der für Mathematiker absoluten Königsklasse.

Stand der Technik ist, die digitale Tonaufzeichnung als Pegel-Zeit-Funktion mit Hilfe der Diskreten (Fast-) Fourier-Transformation in das Frequenzspektrum überzuführen. Anstatt des zeitlichen Verlaufs der Signalabtastpunkte wird dadurch eine alternative Sicht auf das Tonsignal möglich, welche die Stärke des Signals bei verschiedenen Frequenzen wiedergibt. Stark vereinfacht kann man sich das etwa so vorstellen, dass durch viele Sinus- und Kosinus-Funktionen eine Reihenentwicklung vorgenommen wird. Das Summensignal dieser vielen trigonometrischen Funktionen soll das Audiosignal möglichst gut annähern. Mit Hilfe der sich ergebenden Fourier-Koeffizienten zeigt sich dann das Frequenzspektrum der Audioaufnahme. Diesem wird nun das Frequenzspektrum des separat ermittelten Hintergrundrauschens entnommen. Dies ist unproblematisch für Frequenzen, die unterhalb der Grundtonfrequenz einer Orgelpfeife liegen. Problematisch wird es, wenn das Hintergrundrauschen frequenzmäßig im Bereich der Grund- oder Obertonfrequenzen liegt (wie bspw. das Winderzeugungsgeräusch im Frequenzbereich von Basspfeifen). Dabei ist ein Orgelpfeifenton im Vergleich zur menschlichen Sprachdynamik in seinem Frequenzspektrum über die Zeit noch als relativ konstant anzusehen. Bei der Reduktion eines Audiosignals um den Anteil des Hintergrundrauschens wird meist (ungewollt) auch ein kleiner Teil des Nutzsignals mit entfernt. Da sind die Rechenalgorithmen (noch) nicht perfekt. Schließlich lässt sich durch das Abhören der in den Pegel-Zeit-Verlauf rücktransformierten Fourier-Funktion sich subjektiv feststellen, ob das Entfernen des Hintergrundrauschens in Ordnung geht, oder ob bzw. wie stark das ursprüngliche Signal beschädigt wurde. Man muss sich nach dem Prinzip „Trial and error“ vorantasten, um ein Optimum zu erzielen; eben eine Knochenarbeit. Hierzu bieten gute Softwareprodukte die Möglichkeit, exklusiv nur den reduzierten Signalanteil abzuhören. Da lässt es sich leichter beurteilen, ob bzw. in welcher Intensität auch Teile des Nutzsignals verloren gehen. Durch die Umrechnerei können sich auch Artefakte (Verzerrungen, Störsignale) in die Audioaufzeichnung einschleichen. Auch diese gilt es durch Abhören zu identifizieren.

In jüngster Zeit macht die KI erhebliche Fortschritte. Aktuell laufen große Entwicklungsprojekte zum Entfernen von störendem Bildrauschen für optische Verbesserungen in Filmen, Videos und Bildern. Die neuen Algorithmen lassen sich auch auf Audiodaten übertragen. Ein Ziel ist, mit Hilfe der KI Sprachsignale vom Hintergrundrauschen zu trennen um Sprachaufzeichnungen verständlicher zu machen bzw. Gesprochenes in (Print-) Text zu konvertieren. Falls jemand hierzu nähere Infos sucht, für Python-affine Freaks lauten u.a. die Schlagworte für die Suche im Internet: „Keras API for Tensor Flow“.

Siehe auch unter:

A Deep Dive into Audio Denoising with TensorFlow(CNN)

Introduction

medium.com

https://github.com/nttcslab/deep-sound-field-denoiserhttps://www.tensorflow.org/tutorials/audio/simple_audio

Aus meiner Sicht klingt ein nicht rauschreduziertes Sample-Set, das von einer älteren Orgel aufgenommen wurde, grauenhaft. Vor allem ist es der Geräuschanteil der Winderzeugung (Elektromotor, Gebläse, Überdruckventil, Leckagen), der besonders stört. Nicht rauschreduziert vervielfältigt sich das Hintergrundrauschen beim Orgelspiel entsprechend der Anzahl an gleichzeitig gedrückten Tasten. Dies führt zu einem unnatürlich wirkenden Klangergebnis. Dagegen kann man ja zur authentischen Wiedergabe das permanente Hintergrundrauschen im ODF auf die Orgel-Einschalttaste der VPO legen. Dann ist es unabhängig vom polyfonen Spiel auch nur einmal vorhanden und der Organist entscheidet, ob er es hören will oder nicht.

Heutzutage werden bei neuen (natürlichen) Orgelbauprojekten bereits vom Orgelbauer entsprechende Maßnahmen ergriffen, erst keine unerwünschten Hintergrundgeräusche aus der Orgel in den Kirchenraum dringen zu lassen. Der Aufwand wird nicht gescheut, zwecks Schallisolierung die Winderzeugung schwingungsdämpfend zu lagern und mit massiven Holzkonstruktionen zu umschließen, die im Inneren mit Sand befüllt sind. Da ist es dann nach dem Sampling auch für anspruchsvolle Ohren nicht mehr notwendig, nachträglich aus den Aufnahmen das Hintergrundrauschen zu entfernen...

Nachtrag zum Reduzieren des Hintergrundrauschens mit Hilfe der Software "SpectraLayers":

Mittlerweile habe ich mir das Upgrade auf die Version 10 geleistet. Das Geld hierfür hätte ich mir jedoch sparen können. Hinsichtlich der Funktion zur Reduzierung des Hintergrundrauschens ist das Upgrade enttäuschend, wenn nicht sogar schlechter, als die Vorgängerprogrammversion.

Meinen Erkenntnissen zufolge gibt es keinerlei Qualitätsunterschiede bei der Entfernung des Hintergrundrauschens zwischen den beiden Programmversionen. Allerdings ist die praktische Handhabung bei der täglichen Arbeit mit der neueren Version umständlicher geworden. Zur Erzielung des gleichen Ergebnisses sind nun noch mehr Mausklicks erforderlich. Daher mein Fazit:

"Für das Reduzieren des Hintergrundrauschens in Musikinstrumenten­samplings lohnt sich das Upgrade von SpectraLayers 9 auf die Version 10 nicht!"

Dem Hersteller der Software habe ich hierzu ein ausführliches Feedback gegeben. Von interessierten Orgelseitenmitgliedern kann es im Anhang nachgelesen werden. Nach etwa einem Monat bekam ich von der Herstellerfirma eine Antwort, die ich der Community ebenfalls nicht vorenthalten möchte.

Bleibt zu hoffen, dass der Softwarehersteller die Kritikpunkte konstruktiv aufgreift und in der nächsten Programmversion 11 als echte Verbesserung im Sinne der Anwender umsetzt.

Besten Dank für die Rückmeldungen!

Izotope RX werde ich mir gerne ansehen.

Hinsichtlich der Pegelanpassungen:

Da habe ich wohl eine etwas zu strenge Formulierung gewählt. Wenn die Rahmenbedingungen passen, lassen sich sicherlich gute Sampling-Ergebnisse erzielen, ohne dass der Pegel jedes Einzelsamplings individuell angepasst wird. Allerdings sehe ich schon Gründe, die für das Nichtaußerachtlassen der Pegel sprechen. Ich kann nur jedem Sampling-Ersteller empfehlen, sich die Pegelstände und -verläufe genauer anzusehen. Da kommt so manche Überraschung zum Vorschein. Doch es mag Vieles an Auffälligkeiten im Grenzbereich dessen liegen, was im Gehör eines Durchschnittsmenschen nicht wahrgenommen wird. Dennoch kann die Summe mehrerer gleichzeitig wirkender Faktoren das individuelle Nachjustieren erforderlich machen. Schließlich sind es auch der persönliche Geschmack und die Zielsetzung, wofür das Sampling-Set erstellt wird. So stellt sich bspw. die Frage, ob der digitale Orgelzwilling möglichst nahe an das physische Orgeloriginal mit all seinen Eigenheiten und Schwachstellen herankommen soll (z.B. für das Vorbereiten und Einstudieren entsprechender Literatur zu Hause)? Oder liegt die Priorität beim bestmöglichen Klangerlebnis einer schlichten Übungsorgel? Soll die Virtuelle Orgel als Ersatz für eine reale Orgel dienen, wenn bspw. sich eine kleine Landkirchengemeine aus budgetären Gründen keine reale Pfeifenorgel leisten kann?... Wie dem auch sei, nachfolgend zum Signalpegel ein paar Aspekte, die sich nicht nur auf das Rauschreduzieren beziehen:

- Beim Reduzieren des Hintergrundrauschens fällt auf, dass - abhängig von der verwendeten Software - bei tieferen Tönen zusammen mit dem Hintergrundrauschen ungewollt ein kleiner Teil des Pfeifentonsignals mitentfernt wird. Da stellt sich nach dem Rauschreduzieren eine etwas stärkere Pegeldämpfung ein. Dagegen funktioniert in der Regel bei höheren Pfeifentönen das Entfernen des Hintergrundrauschens sauberer bzw. trennschärfer mit geringerer Auswirkung auf die Pegel. Deshalb kann das Nachjustieren bei tieferen Pfeifentonsamples Sinn machen.

- Werden aus Qualitätsgründen unterschiedliche Softwareprodukte eingesetzt (z.B. für das Rauschreduzieren an tieferen bzw. hohen Pfeifentönen), so wird es im Ergebnis unterschiedliche Pegeldämpfungen geben. Selbst bei Verwendung ein und derselben Software, jedoch grundtonfrequenzabhängig zur Erzielung optimaler Ergebnisse mit veränderten Parametereinstellungen, können Unterschiede in den Dämpfungen auftreten (auch wenn das Hintergrundrauschen immer den gleichen und unveränderten Lautheitspegel hat).

- An manchen Samplings von Pfeifen im mittleren bis höheren Tonbereich beobachte ich nach dem Reduzieren des Rauschens in der Release-Phase eine Zunahme des Spitzenpegels. Dann erinnert mich der Tonverlauf an das Pfeifen einer alten Dampflok. Da ich in unbearbeiteten Rohsamplings diesen Effekt nicht höre, vermute ich die Ursache der Pegelzunahme im Algorithmus der verwendeten Rauschunterdrückungssoftware. (Allerdings könnte es auch sein, dass die Lautstärkenzunahme des Pfeifentons im unbearbeiteten Rohsampling vom Hintergrundrauschen überdeckt ist und daher nicht im Rechenalgorithmus die Ursache liegt.) In diesen Fällen halte ich es für angebracht, im Samplingrelease den Spitzenpegel künstlich zu begrenzen.

- Das Samplen aller Pfeifen einer größeren Orgel nimmt einige Zeit in Anspruch. Da kann es erforderlich sein, die Aufnahmen mehrfach zu unterbrechen. Auch wenn bspw. durch Bodenmarkierungen der Stativstandort für die Mikrofone markiert ist, nach einem Abbau und erneuten Aufbau der Aufnahmetechnik werden sich die Mikrofone nicht hundertprozentig in exakt gleicher Position befinden. Das kann sich - wenngleich geringfügig - auf die Pegel auswirken.

- Über den gesamten Frequenzbereich haben die für das Samplen benutzten Aufnahmemikrofone kein lineares Verhalten. Zwar lassen sich die Kennlinien der Mikrofone im Expander / Equalizer bereits während der Aufnahme berücksichtigen. Jedoch plädiere ich dafür, die Pegelbeeinflussung durch die Mikrofonkennlinien erst nach dem Samplen zu korrigieren. Sonst weiß man später möglicherweise nicht mehr so genau, was schon korrigiert wurde und was nicht.

- Es gibt immer wieder mal Pfeifen, die „aus der Reihe tanzen“. Da findet sich ein Pfeifchen, das im Vergleich zu seinen Nachbarn zu leise oder zu schrill klingt. Spätestens hier kommt die Gewissensfrage, ob eine individuelle Pegelanpassung unter der Berücksichtigung des gesamten Registerklangbildes zulässig ist, oder ob sich diese Eigenheit bzw. Schwachstelle der Orgel im Sampling unkorrigiert wiederfinden soll.

- Bekanntlich kann kein Lautsprecher oder Kopfhörer mit der auditiven Auflösung des menschlichen Ohrs mithalten. Deshalb sind m.E. Kompromisse erforderlich, um ein Orgelsampling hinsichtlich der Dynamik lautsprechertauglich aufzubereiten. So hat man bspw. in mein Studienobjekt nachträglich eine Hochdrucktuba mit eigener Winderzeugung eingebaut. Im Original ist diese Tuba derart laut, dass ich sie im Sampling nachträglich im Pegel absenken muss. Sonst würden alle andere Register viel zu leise klingen oder es käme ständig zu Übersteuerungen.

- Um den Pegelabgleich zwischen Orgelregister, die sich an unterschiedlichen Orten innerhalb einer Kirche befinden, wird man wohl nicht herumkommen. (Dieser Spezialfall ist sicherlich keine alltägliche Situation und dieser Herausforderung habe ich mich noch nicht gestellt. Jedoch durfte ich unlängst in einer großen Kirche an einer Orgelbaustellenführung teilnehmen, wo im Zuge der Orgelrenovierung die Trompetenregister von der hinteren Empore nach vorne in den Altarraum hinein verlagert werden…)

Da gibt es sicherlich weitere Gründe, die Pegel im Blick zu behalten.

Als Kompromiss schlage ich vor, meine Aussage „Für die Virtuelle Orgel müssen deshalb zum Bilden eines stimmigen Gesamtbildes im Zuge der Intonation die Signalpegel jedes Einzelsamplings individuell angepasst werden.“ so zu verstehen: „Ggf. kann die für einzelne Pfeifensamplings oder ganze Orgelregister nachträglich vorgenommene Pegelkorrektur zur qualitativen Aufwertung eines Sampling-Sets beitragen“. (Man möge es mir bitte nachsehen…)

Im Nachgang hier die Klangbeispiele:

Unbearbeitete, mit Rauschen behaftete Testsamplings (Rohaufnahmen):

Klangbeispiel 1: Testsampling Krummhorn 8‘, C

Klangbeispiel 2: Testsampling Krummhorn 8‘, g3

Klangbeispiele_1-2.zip

Ergebnisse nach Reduzierung des Rauschens durch „Audacity 3.3.2“:

Klangbeispiel 3: Ergebnis am Klangbeispiel 1 (Krummhorn 8‘, C)

Klangbeispiel 4: herausgetrennter bzw. entfernter Signalanteil beim Erstellen des Klangbeispiels 3 (Krummhorn 8‘, C)

Klangbeispiele_3-4.zip

Ergebnisse nach Reduzierung des Rauschens am Klangbeispiel 1 durch „Samplitude Pro X7“:

Klangbeispiel 5: Ergebnis am Klangbeispiel 1 (Krummhorn 8‘, C)

Klangbeispiel 6: entfernter Signalanteil beim Erstellen des Klangbeispiels 5 (Krummhorn 8‘, C)

Klangbeispiele_5-6.zip

Ergebnisse nach Reduzierung des Rauschens am Klangbeispiel 2 durch „Samplitude Pro X7“:

Klangbeispiel 7: Ergebnis am Klangbeispiel 2 (Krummhorn 8‘, g3) ohne adaptiver Pegelkorrektur

Klangbeispiel 8: Ergebnis am Klangbeispiel 2 (Krummhorn 8‘, g3) mit adaptiver Pegelkorrektur

Klangbeispiel 9: entfernter Signalanteil beim Erstellen des Klangbeispiels 8 (Krummhorn 8‘, g3)

Klangbeispiele_7-9.zip

Ergebnisse nach Reduzierung des Rauschens durch „Sound Forge Pro 16“:

Klangbeispiel 10: Ergebnis am Klangbeispiel 1 (Krummhorn 8‘, C)

Klangbeispiel 11: entfernter Signalanteil beim Erstellen des Klangbeispiels 10 (Krummhorn 8‘, C)

Klangbeispiele_10-11.zip

Ergebnisse nach Reduzierung des Rauschens am Klangbeispiel 1 durch „SpectraLayers 9“:

Klangbeispiel 12: Ergebnis am Klangbeispiel 1 (Krummhorn 8‘, C)

Klangbeispiel 13: entfernter Signalanteil beim Erstellen des Klangbeispiels 12 (Krummhorn 8‘, C)

Klangbeispiele_12-13.zip

Ergebnisse nach Reduzierung des Rauschens am Klangbeispiel 2 durch „SpectraLayers 9“:

Klangbeispiel 14: Ergebnis am Klangbeispiel 2 (Krummhorn 8‘, g3)

Klangbeispiel 15: entfernter Signalanteil beim Erstellen des Klangbeispiels 14 (Krummhorn 8‘, g3)

Klangbeispiele_14-15.zip

Das Entfernen bzw. Reduzieren von Nebengeräuschen in Einzelsamplings von Pfeifentönen ist für die spielfertige Aufbereitung ein aufwändiger und anspruchsvoller Zwischenschritt. Für diese spezifische Aufgabenstellung habe ich mir die Möglichkeiten, Handhabung und Bedienfunktionen der Softwareprodukte „Audacity“, „Samplitude“, „Sound Forge“, „SpectraLayers“ und „WaveLab“ in den Softwareständen vom Mai 2023 genauer angesehen. Im Dateianhang stelle ich meine eigenen Erkenntnisse Interessierten gerne zur Verfügung.

Hintergrundgeräusche_im_Sampling_reduzieren_2023-06-22.pdf

Zusammenfassend stelle ich fest, dass bei Grundtonfrequenzen unter 150 Hz m.E. das Softwareprodukt „SpectraLayers“ des Herstellers Steinberg uneingeschränkt empfohlen werden kann. Bei darüber liegenden Frequenzen ist unter Qualitätsaspekten u.U. der „Denoiser“ in „Samplitude“ von Magix die um Nuancen bessere Wahl.

Zur Klarstellung: zu keinem Softwarehersteller oder -händler stehe ich in irgendeinem Naheverhältnis!

PS:

Leider überschreitet die vorbereitete Word-Datei mit 25,3 MB die maximal zulässige Dateigröße. Deshalb habe ich hier die ins pdf-Format konvertierte Datei hochgeladen. Damit sind jedoch die eingebetteten Klangbeispiele nun nicht mehr abspielbar. Ich bitte um Verzeihung...!

Nach dem Update unter Win10-64 von GO 0.3.1.2330 auf v 3.6.2-1 stellen sich bei mir gemischte Gefühle ein, denn es gibt mindestens eine gute und eine schlechte Nachricht.

Zunächst die gute, wenn nicht sogar sehr gute Nachricht:

Endlich funktioniert die Funktion zur Übernahme der aktuellen Speichernummernanzeige des Setzers in die Hauptansicht (Image der Konsole). Zur Verdeutlichung wird hier in diesem kleinen Beispiel die "012" von der Anzeige "Setzer Kombinationen" auf die Konsole übertragen:

pasted-from-clipboard.png

Rechts neben der aktuellen Speichernummer befinden sich in diesem Beispiel die Plus- und Minustasten für den Setzer. Diese Tasten haben sich schon bisher benutzen lassen. Neu hinzugekommen ist in der aktuellen GO-Version, dass sich auch die Setzer-Nummernanzeige in die Konsole übernehmen lässt. Für Interessierte hier der zugehörige ODF-Eintrag:

pasted-from-clipboard.png

In diesem Beispiel ist die genannte Image-Datei "SetterNumberDisplay" ein selbst erstellter kleiner Pixelausschnitt aus dem Foto der Konsole als Hintergrund für die Ziffern (bildüberlagerter Platzhalter). Selbstverständlich kann alternativ ein kleines Hintergrundbildchen mit jedem beliebigen Grafikprogramm (z.B. Paint) erstellt werden. Die neue Funktion "SequencerLabel" zentriert die Schrift automatisch sowohl horizontal als auch vertikal. So ganz nebenbei: ich frage mich, warum diese neue Funktion "SequencerLabel" heißt und nicht treffenderweise z.B."SetterMemoryCountLabel" ? Wie dem auch sei, die Funktion funktioniert! Dagegen befindet sich noch ein Bug in der GO-Onlinehilfe: hier steht unter GrandOrgue Help -> The Grand Orgue File format -> Setter Elements -> "Label: Represents the current number of the setter.... for old format panels". Diese Angabe ist schlichtweg falsch. In GO ist "Label" anderweitig belegt (statisches Image ohne Rückgabewert). Irgendjemand sollte dies über GitHub den Entwicklern zurückmelden. Ich fürchte, dass mein Englisch hierfür zu schlecht ist...

Doch nun zur schlechten Nachricht:

In GO 0.3.1.2330 schätzte ich sehr, dass nach dem Aufruf meine Orgelkonsole (ein Image in der Größe von 3.525 x 1.925 Pxl) zunächst vergrößert dargestellt wurde und dass mit Hilfe der seitlichen horizontalen sowie vertikalen Bildlaufleisten durch das Image gescrollt werden konnte.

ScreenShot mit den beiden seitlichen Bildlaufleisten unter GO 0.3.1.2330:

pasted-from-clipboard.png

In der Folge führte ein Doppelklick mit der Maus in die rechte untere Ecke - auf die sechs Punkte im Schnittpunkt der beiden Bildlaufleisten - zur Darstellung des gesamten Images auf dem Bildschirm.

Jetzt unter GO 3.6.2-1 werden keine Bildlaufleisten mehr angezeigt und die Konsole wird immer vollständig (und daher dementsprechend klein) dargestellt. Da sind manche Einzelheiten nicht mehr zu erkennen. Vielleicht hängt dies damit zusammen, dass beim Build in Linux für Windows diese Funktionalität verloren geht bzw. nicht genutzt wird. Unter Windows habe ich mittlerweile mit diversen Tricks erfolglos versucht, die Bildlaufleisten wieder zu bekommen (z.B. durch Ändern der Bildschirmauflösung). Deshalb hier die Anregung, bei der Weiterentwicklung von GO, eine Skalier- bzw. Lupenfunktion für die Anzeigen (speziell für das Hauptbild) mit einzubauen.

Noch ein paar Auffälligkeiten:

- Bei der Installation von GO 0.3.1.2330 wurde seinerzeit die Anwendung GO in der Windows-Systemsteuerung unter "Programme und Features" ordnungsgemäß registriert. Dagegen muss man nach dem Entpacken der v 3.6.2-1 diese einmalig manuell mit einem ODF-File verbinden (z.B. im Dateiexplorer das .organ-File mit der rechten Maustaste einmal anklicken und wählen: "Öffnen mit ...", und danach auf die entsprechende .exe-Datei im GO-Unterpfad \bin\ klicken. Irgendwie war mir in diesem Punkt die seinerzeitige Lösung mit der selbständigen ordnungsgemäßen Registrierung sympathischer.

- Beim Update von 0.3.1.2330 auf 3.6.2-1 blieben meine umfangreichen Einstellungen der Setzer-Kombinationen erhalten. Jedoch bekomme ich jetzt jedes Mal beim Starten von GO die Warnung, dass das ".cmb-File" nicht passend sei. Die Warnung lässt sich nur durch die Radikallösung abstellen, das File mit den Kombinationen zu löschen und alle Setzer-Kombinationen neu anzulegen. Da könnte man nachbessern.

ScreenShot der Warnung:

pasted-from-clipboard.png

- Weil ich schon beim Meckern bin, da habe ich einen weiteren Verbesserungsvorschlag: In der neuen GO-Version ist (ebenso wie schon in der alten) die "Save"-Funktion verbesserungsfähig. Mit der "Save"-Funktion lassen sich Setzer-Kombinationen dauerhaft abspeichern. Ein selbst kreierter "Save"-Button lässt sich sinnvollerweise nur aktivieren, wenn die "S"-Funktion bereits aktiviert ist. (Die "S"-Funktion speichert Setzer-Kombinationen ja nur temporär für die Dauer der jeweiligen GO-Nutzung.) Ist die "Save"-Funktion erst einmal aktiviert, muss sie später auch definitiv explizit wieder manuell abgestellt werden. Mein Vorschlag ist, dass sich die "Save"-Funktion automatisch deaktiviert, wenn die "S"-Funktion abgeschaltet wird. Zudem wäre es aus meiner Sicht wünschenswert, wenn über eine Boolesche Festlegung in der ODF die "S"- und die "Save"-Funktionen je nach Bedarf wahlweise fest mit einander gekoppelt werden könnten.

Zum Schluss noch folgende Anregung: In der ODF müssen für benutzerdefinierte Setzer-Funktionen "Next" und "Prev" jeweils zwei Images hinterlegt werden: einmal für "Off" und einmal für "On". Letztere hat jedoch heute noch keine Bedeutung. In einer künftigen GO-Version könnte man das "On"-Image dazu verwenden, um durch kurzes Aufleuchten das Anklicken des Buttons mit der Maus (bzw. Drücken auf dem Touchscreen) vom Programm her zu quittieren. In GO gibt es meines Wissens nach eine kurze Aufblinkfunktion noch nicht. Ansonsten könnte zwecks Verschlankung der ODF jeweils auch nur eine Datei für die Image-Darstellung der Weiter- und Zurückschaltung des Setzerzählers ausreichen.

Quote from vpo-organist

"Schwellwerk" in deutscher Schreibweise finde ich sehr gut.

Bevor man eine Kopie zieht, sollte man die Weiterentwicklung abwarten und erst mal mit einer Code-Analyse beginnen.

Ein paar Gedanken als Beitrag zur Diskussion über die mögliche Zukunft von GO:

- Für eine komplette Neuprogrammierung könnte die moderne Programmiersprache PY (Python) infrage kommen. Da tut sich momentan viel, insbesondere auf dem Gebiet „Industrie 4.0“. Für VR (Virtual Reality) und auch für die Spieleprogrammierung gibt es da kostenlos geniale Grafikbibliotheken. Für PY scheint es auch funktionierende MIDI-Treiber zu geben: https://pypi.org/project/py-midi/

Zudem soll sich angeblich auch ASIO integrieren lassen. Heutzutage scheint PY für technikaffine Studenten die erste Wahl zu sein.

- Anstatt einer vollständigen Neuprogrammierung könnte sich ggf. ein Aufsatz auf „Kontakt“ lohnen. In den letzten Jahren hat sich „Kontakt 5“ zum quasi Industriestandard für virtuelle Instrumente gemausert (mitteleweile in V6 verfügbar). Den Player gibt es kostenlos. https://www.chip.de/downloads/Kontakt-6-Player_79967104.html

Auch bei Miditzer scheint es schon Überlegungen in diese Richtung gegeben zu haben:

https://miditzer.org/forum/viewtopi…cc36b7a9e2aaf39

Vermutlich muss man sich bei NI die Vollversion kaufen, um die passende Entwicklungsumgebung zu erhalten.

Wenn ich mich recht erinnere hat da schon vor längerer Zeit innerhalb des Orgelforums jemand berichtet, dass er seine vO nach Kontakt „exportiert“ hat.

Mit Linux könnte Kontakt so seine Probleme haben; ist halt keine openSource-Software.