Beiträge von Ezasi

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.

Zitat von 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.

Das GrandOrgueTool ist nicht zu finden (auch nicht unter o. a. Link). Kann mir jemand weiterhelfen?

Vielen Dank im Voraus!

Hallo liebe Aktivisten im MPS-Forum,

als Neueinsteiger in die Welt des Samplens habe ich ein paar Fragen:

Kann mir bitte jemand eine Sampler-Software empfehlen, die sich bestens für die Aufnahme von Sample-Sets für GO oder HW eignet?

-  Mit Audacity scheint das Erstellen von Samples ja echte Knochenarbeit zu sein.

-  SampleRobot (Skylife) scheint im Anlegen der Ordner- und Filestrukturen sehr viel automatisch zu erledigen und ein fleißiger Helfer zu sein, kann aber meines Wissens nach in der aktuellen Version keine Release-Files exportieren.

-  SoundForge (Magix), HaLion / WaveLab (Steinberg) sowie Kontakt (Native Instruments) dürften gut geeignete Softwarekandidaten sein. Kennt jemand die markanten Unterschiede?

In welches Produkt soll ich da am besten investieren?

Weiß jemand, womit der große ehrwürdige Meister PG arbeitet?

Zudem interessiert mich, wie die unterschiedlichen Attack- und Release-Files für GO erstellt werden? Sind es in jedem Fall mehrere Einzelsamples für jede individuelle Orgelpfeife oder können die unterschiedlichen Attack- und Release-.wav-Dateien softwaremäßig aus einem einzelnen Sample-Set abgeleitet werden?

Wie viele Velocity-Layer sollten für das Sampling des Schwellwerks vorgesehen werden?

Reichen drei Samplings pro Pfeife aus? (Schwellerposition in Minimal-, Mittel- und Endstellung?)

Im Forum habe ich den Begriff „Plain-Wave“ gelesen. Um welche besondere Eigenschaft einer „.wav-Datei“ handelt es sich hier?

Kann GO Samples nutzen, die mit 192 kHz und 24 Bit gesampelt sind?

Macht eine derart hohe Sample-Rate wegen des enormen Speicherbedarfs überhaupt Sinn?

Besten Dank und viele Grüße

Ezasi