Hallo zusammen,

ich arbeite seit einiger Zeit an einem experimentellen GrandOrgue-Fork und möchte ihn hier kurz vorstellen – vor allem weil ich Tester suche, die mir ehrliches Feedback geben können.

Klar vorab: Das ist kein Konkurrenzprojekt zu GrandOrgue. Mein Ziel ist es, neue Features auszuprobieren und zu validieren, bevor ich sie als Pull Requests beim Upstream einreiche. Wer den Fork installiert, bekommt also im Grunde GrandOrgue – nur mit ein paar Extras zum Testen.

**Was ist anders?**

Das Herzstück ist ein neues Crossfade-System beim Übergang zwischen Attack- und Release-Samples. Statt der fest eingebauten Kosinuskurve kann man jetzt zwischen fünf verschiedenen Kurvenformen wählen:

- **Linear** – schlicht und direkt
- **Sin / Equal-Power** – klassisch, für die meisten Stimmen gut
- **Sin²** – weicher Einstieg, schnellerer Ausklang
- **Sqrt / Equal-Power** – das Gegenteil: schneller rein, weich raus
- **X²** – für besonders lange, weiche Übergänge

Die Umschaltung passiert live per Tastenkürzel (F7–F12) während die Orgel spielt. Wichtig: Der Fokus muss dabei auf dem GrandOrgue-Hauptfenster liegen, sonst reagieren die Tasten nicht. Einfach einmal ins Hauptfenster klicken, dann funktioniert es. So kann man direkt beim Spielen zwischen den Kurven hin- und herwechseln.

Daneben gibt es noch ein paar weitere Verbesserungen: eine Warnanzeige wenn das RAM-Limit zu knapp gesetzt ist, ein flüssigeres Ladefortschritts-Reporting, und überarbeitetes Polyphonie-Dropping das sanfter reagiert.

**Download**

Einen Windows-Build gibt es hier zum Ausprobieren:
https://github.com/sebion7125/grandorgue....17.2-XFadeDemo

**Was ich suche**

Ich würde gerne wissen: Hört man den Unterschied zwischen den Kurven überhaupt? Bei welchen Stimmen fällt er am meisten auf – Streicher, Flöten, Zungen? Klingt eine Kurve besser als die andere, oder ist es Geschmackssache?

Freue mich über jede Rückmeldung!

Hallo montre, danke für die freundliche Aufnahme!

Mein Ausgangspunkt war teilweise theoretisch: GrandOrgue nutzt bereits für die Loop-Fades keine lineare Kurve — das zeigt dass die Entwickler wissen dass Linear nicht immer optimal ist. Beim Attack-Release-Crossfade ist es aber noch fest verdrahtet.

Konkreter Anlass war die Chamade der Hauptorgel der Laurenskerk Rotterdam — bei Zungenstimmen mit ihrem charakteristischen Attack hatte ich das Gefühl dass der Übergang zum Release-Sample nicht ganz sauber ist. Ich konnte das in eigenen Experimenten für mich plausibel machen, aber mir ist auch bewusst dass Psychoakustik kein einfaches Feld ist — was ich höre könnte auch durch andere Faktoren bedingt sein.

Deshalb bin ich den Weg gegangen: Feature implementieren, Tester suchen, und dann schauen ob andere dasselbe wahrnehmen.

Um die Unterschiede zwischen den Kurven hörbar zu machen ohne GrandOrgue installieren zu müssen, habe ich außerdem ein kleines Python-Tool entwickelt mit dem man verschiedene Kurvenformen mit einstellbaren Attack-Zeiten direkt vergleichen kann:
https://github.com/sebion7125/Crossfade-Simulator

Vielleicht hilft das beim Nachvollziehen der Idee!

VG

Danke für die ausführliche Rückmeldung und die ChatGPT-Analyse — sehr interessant!

Ein paar Ergänzungen dazu:

Die Haltezeit-Parabel im Simulator ist übrigens direkt aus GrandOrgue übernommen. In meiner eigenen Forschung hat sich der quadratische Term allerdings nicht als besonders nützlich erwiesen, weshalb ich ihn durch einen einfachen linearen Ansatz ersetzt habe. In diesem Zusammenhang habe ich mir auch Python-Tools gebaut, die automatisch über die Samples eines Sample-Sets gehen und deren Attack- und Release-Verhalten analysieren. Ziel ist es, für jede Pfeife individuell ein Modell des Einschwingvorgangs zu erzeugen — damit könnten später über zusätzliche ODF-Parameter bei kurzen Tönen realistischere Nachhallverläufe entstehen. Das ist aber ein längerfristiges Projekt das erst in den nächsten Ferien wieder weiterentwickelt werden kann.

Den Hinweis auf die Phasenausrichtung finde ich besonders spannend, weil ich rein zufällig vor zwei Tagen ebenfalls den Artikel von Nick Appleton gelesen hatte und seine Empfehlung zur Kreuzkorrelation notiert hatte. GrandOrgue hat zwar bereits ein primitives Release-Alignment, aber es arbeitet nur mit 32 Amplituden-Bins — das ist sehr grob. Ich arbeite gerade an einer Erweiterung die Kreuzkorrelation verwendet um eine bessere Phasenausrichtung zu erreichen, und die bisherigen Ergebnisse bestätigen was Appleton beschreibt: ein gutes Release-Alignment ist tatsächlich wichtiger als die Wahl der Crossfade-Kurve.

Das führt aber zu einem interessanten Nebeneffekt: bei phasenausgerichteten Releases ist Equal-Power paradoxerweise nicht unbedingt die beste Wahl. Korrelierte Signale erzeugen beim Überblenden einen unerwünschten Lautstärkepeak — in diesem Fall kann eine einfachere Kurve natürlicher klingen. Die Kurvenauswahl bleibt also auch bei besserem Alignment relevant, nur mit anderem Vorzeichen.

Entwickelt habe ich das übrigens mit Unterstützung von ChatGPT und Claude — die Tools haben den Prozess erheblich beschleunigt.

VG

Sie haben vor allem dabei geholfen das große Projekt schnell zu durchblicken. Ist ja doch einiges historisch gewachsen und viele unerwartete Seiteneffekte bei Änderungen. Als ich angefangen hab war openai gerade so weit dass es halbwegs benutzbar war. Aber Claude ist echt ein anderes Level und ich hab so meine Tricks die KIs einzunorden 🤪

hier mal ein schönes beispiel aus dem neuesten feature an dem ich gerade arbeite. Ich versuche ja das release alignment zu verbessern. Wer sich für die theorie interessiert kann hier näheres lesen: https://www.appletonaudio.com/blog/2014/...-organs-part-1/

man sieht sehr schön, wie in dieser Situation Grand-Orgue die falsche Phasenlage für das release sample erwischt. und es kommt trotz sin^2 kurve zu einem einbrechen in der amplitude. Mit dem neuen NDP-Korellations feature wird die Ähnlichkeit der Kurven über das Crossfade Fenster sicher gestellt und man sieht einen natürlichen übergang ohne einbruch.

Ist leider ein sehr komplexes feature, dass noch einige stunden entwicklungszeit brauchen wird. aber ich denke es wird eine lohnenswerte verbesserung.

Hallo zusammen,

ich habe jetzt endlich die neue experimentelle GrandOrgue-Demo mit korrelationsbasiertem Release Alignment hochgeladen:

https://github.com/sebion7125/grandorgue...eleaseAlignDemo

Das ist eine Weiterentwicklung meiner früheren XFade-/Release-Scaling-Demo und basiert jetzt auf GrandOrgue 3.17.3.

Die wichtigste Neuerung ist das korrelationsbasierte Release Alignment. Wenn eine Taste losgelassen wird, muss GrandOrgue vom aktuell klingenden Attack-/Sustain-Sample auf ein separates Release-Sample umschalten. Wenn das Release-Sample dabei an einer ungünstigen Wellenformposition startet, kann der Übergang knacken, phasenmäßig unsauber wirken oder hörbare Auslöschungen erzeugen.

Der neue Code analysiert beim Laden der Orgel das Attack-/Sustain-Sample und das zugehörige Release-Sample. Daraus wird pro Pfeife eine kleine Lookup-Tabelle erzeugt, die die aktuelle Haltezeit bzw. Loop-Position auf einen Release-Offset mit hoher Korrelation abbildet. Zur Laufzeit verwendet GrandOrgue diese Tabelle, um das Release-Sample vor dem Crossfade an einer besser passenden Phasenposition zu starten.

Das Ziel ist, den Übergang ins Release-Sample glatter und weniger zufallsabhängig zu machen.

Ich habe außerdem einige Screenshots aus meinem analyze_lut-Tool angehängt. Sie zeigen, was der Algorithmus intern macht:

* Die Heatmap zeigt die Korrelationslandschaft.
* Die x-Achse ist der Periodenindex im Attack-/Sustain-Sample.
* Die y-Achse ist der mögliche Offset im Release-Sample.
* Grüne Bereiche zeigen hohe Korrelation, rote Bereiche niedrige oder negative Korrelation.
* Die eingezeichneten Punkte sind die Release-Offsets, die für die Runtime-LUT ausgewählt wurden.

Dadurch wird das Problem recht anschaulich: Der beste Release-Offset ist nicht immer konstant. Bei manchen Samples folgt er einem stabilen Ast, bei anderen driftet er mit der Zeit, und in schwierigeren Fällen gibt es mehrere mögliche Korrelationsäste. Der Algorithmus versucht, dem musikalisch sinnvollen Ast zu folgen, ohne im Audio-Thread teure Korrelationssuchen durchführen zu müssen.

Einige Screenshots zeigen zusätzlich einen direkten Wellenformvergleich:

* Blau = aktuelle Attack-/Sustain-Wellenform
* Rot = bisherige/Legacy-Release-Position
* Grün = korrelationsbasiert ausgerichtete Release-Position

In diesen Beispielen liegt die grüne Kurve sichtbar näher an der aktuellen Wellenformphase als die bisherige Release-Position. Genau das soll der Algorithmus erreichen.

Ein paar Hinweise:

* Das ist weiterhin experimentell und kein offizielles GrandOrgue-Release.
* Das Release Alignment ist dafür gedacht, zusammen mit den XFade-Kurvenverbesserungen zu arbeiten.
* F12 ist derzeit ein diagnostischer Sofortumschaltmodus ohne Crossfade. Dieser Modus darf und wird eher knacken als die eigentlichen Crossfade-Modi, ist aber nützlich, um zu hören, ob das Alignment selbst die Häufigkeit oder Stärke der Knackser reduziert.
* Ich habe die Funktion mit einigen größeren Samplesets getestet, aber es kann weiterhin Sonderfälle geben, besonders bei verrauschten Releases, ungewöhnlichen Loops, sehr kurzen Perioden oder schwierigen Mixturen.

Mich würde besonders Rückmeldung zu folgenden Punkten interessieren:

1. Samplesets oder Register, bei denen der Release-Übergang deutlich besser wird,
2. Fälle, in denen es weiterhin knackt oder sogar schlechter klingt,
3. reproduzierbare Notenhänger oder MIDI-Event-Probleme,
4. ob sich die verschiedenen Crossfade-Kurven zusammen mit dem Release Alignment weiterhin plausibel verhalten.

Hallo zusammen,

ich habe einen neuen experimentellen Build veröffentlicht:

https://github.com/sebion7125/grandorgue...adeReleaseAlign

Die klanglichen Features wie Crossfade-Kurven, Release Alignment usw. sind weiterhin enthalten. Die wichtigste Änderung in diesem Build betrifft diesmal aber die Audio-Stabilität.

Die AudioWrapper-/Treiber-Aufrufe laufen jetzt über einen eigenen Worker-Thread. Öffnen, Schließen, Starten und Reconnect der Audio-Schnittstelle werden dadurch sauberer serialisiert und nicht mehr aus verschiedenen Kontexten heraus angestoßen.

Praktischer Effekt: GrandOrgue kann jetzt besser damit umgehen, wenn ein Audiointerface verschwindet, z.B. bei einem USB-Wackler oder wenn ein USB-Audiointerface abgezogen und wieder angesteckt wird. In meinem Testfall erkennt GO den Geräteverlust und verbindet sich automatisch wieder, ohne dass GrandOrgue neu gestartet werden muss.

Zusätzlich gibt es eine Suspend/Resume-Behandlung: Wenn GrandOrgue ein entsprechendes Systemereignis bekommt, wird die Audio-Schnittstelle vor dem Suspend geschlossen und nach dem Aufwachen wieder geöffnet. Das soll Treiberprobleme umgehen, bei denen Audiointerfaces nach Sleep/Resume in einem kaputten Zustand hängen bleiben.

Getestet habe ich das bisher vor allem unter Windows mit meinem USB-Audiointerface. Der automatische Reconnect ist aber nicht bewusst auf Windows beschränkt; wie gut das mit anderen Backends und Treibern funktioniert, müsste man ausprobieren.

Mich würden daher besonders Rückmeldungen interessieren zu:

USB-Audiointerface abziehen / wieder anstecken
Standby / Aufwachen
ASIO / WASAPI / ALSA / CoreAudio
ob GO danach automatisch wieder Ton ausgibt
ob es Hänger, Abstürze oder Notenhänger gibt

Wie immer: Das ist ein experimenteller Fork und keine offizielle GrandOrgue-Version.