ich finde diese Dry Diskussion irgendwie Quatsch. Ein Ton an der Orgel ist ja nicht nur die einzelne Pfeife und der Hall vom Raum. Jeder der schon eine Orgel gestimmt hat, der wird wissen dass selbst bei einem Register auch Pfeifen die keinen Wind bekommen nicht stumm bleiben. Andere Pfeifen aus anderen Register gehen in Resonanz und erzeugen auch einen Ton, zwar nicht so laut, aber hörbar. Wenn ich z.B den Bombard Stimme, dann kann der selbe Ton vom Subbass auch klingen. Das sind solche Details die den gesamten Klang ausmachen. Von anderen Bauteilen der Orgel die auch in Resonanz gehen ganz zu schweigen. Das fehlt eben alles bei Dry.
Hauptwerk-Alternative? Sweelinq
-
-
- Offizieller Beitrag
Bei Wet Samples sind eben genau diese ganzen Effekte in der Aufnahme jeder einzelnen Pfeife mit enthalten, Vom Einschwingen bis zum Ausklingen. Und das ganze auch noch in Mikrofonposition = Hörerposition. Das ist es ja, was die Wet-Sample-Technik zu solchen verblüffend realitätsnahen Hörerlebnissen führt. Bei den Dry Samples ist das nur in den Loops so authentisch erfasst, nicht aber in den IRs, da das IR nur den Raum abbilden kann, aber nicht das enthält, was die Pfeife als Nebeneffekte innerhalb der Orgel produziert.
-
- Offizieller Beitrag
Wenn der RAM-Bedarf wie weiter oben beschrieben sehr gering ist, die waves aber auch wie bei HW bis zu 11 sec. lang sind, wird offensichtlich an anderer Stelle gespart.
Einige Hersteller haben nur jede Mollterz gesampelt und gespeichert. Die restlichen Töne wurden gerechnet. Einer klingt wie der andere. Das spart Speicherplatz
Im Kfz-Bereich schafft man auch 100 PS aus einem 1,2 l Motor auf Kosten der Drehzahl und Verschleiß
Mit solchem Auto fährt man trotzdem keinen Luxuswagen.
Wir haben hier schon viel für und wider der Systeme gesprochen.
Manchmal hab ich den Eindruck dass sich mancher das System schönreden will.
Manchmal hätte ich Lust mir solch ein System zu kaufen.
Dann zwei beliebige Töne spielen. Einen davon so zu verstimmen dass er genau so hoch steht wie der andere.
Beide auf einem Digitalspeicher-Oszilloskope sichtbar machen, speichern und die Kurvendifferenz betrachten.
Hab bissl Sorge, dass die Differenz mehrerer Töne zueinabder Null ist.
Würde mich gerne eines Besseren belehren lassen. Aber irgendwo muss ja der geringe RAM-Bedarf von 1/3tel oder 1/4tel gegenüber den Sets in HW oder GO herkommen
-
Auf dem System läuft neben Sweelinq nichts anders, daher ist das nicht nötig und eigentlich auch Unsinn.
Dann hast du "Echtzeit" nicht verstanden. Das macht durchaus Sinn. Google nach Linux und Echtzeit, dann wirst du schlau gemacht
-
Dann hast du "Echtzeit" nicht verstanden. Das macht durchaus Sinn. Google nach Linux und Echtzeit, dann wirst du schlau gemacht
Man muss sich überlegen ob man nun "Echtzeit" möchte, oder ein stabiles System. Bei einem Echtzeitkernel kann einem das System doch schnell mal wegsterben. Natürlich abhängig von der Konstellation Hardware und Software.
-
Das halte ich für ein Gerücht. Man baut doch keine Echtzeitfähigkeit ins Betriebssystem, welches dann nicht mehr stabil läuft (?)
-
Man baut doch keine Echtzeitfähigkeit ins Betriebssystem, welches dann nicht mehr stabil läuft (?)
Naja, so hohe Priorität hatte das die letzten Jahre ja auch nicht und die meisten Kernels die das bieten sind auch eher experimentelle Konstrukte Linux: Zentrale Echtzeit-Patches nach 17 Jahren integriert | heise online Da dauert es schnell mal eine Dekade bis da Patches einfließen
Ich selbst habe die Erfahrung gemacht dass vor allem Jack in Realtime oft zu einem einfrierenden System sorgt. Für mich ist der Mehrwert auch eher gering. Auf 1-2 ms kommt es mir nun nicht an. Dies ist aber in meinem Setup in etwa der Gewinn, sofern man den Messungen der Software trauen kann. Da habe ich ehrlich gesagt meine Zweifel. Zumindest spüre ich keinen Unterschied und so lange ich keine Latenz spüre habe zumindest ich keinen Grund da was zu verbessern. Es gibt ja nicht wenige die gerne optimieren, nur aus dem Grund heraus weil sie können. Da spielt es dann meist auch keine Rolle ob da tatsächlich ein spürbarer Unterschied bei entsteht.
Ich bin kein Experte in der Musikproduktion, aber es schein vor allem in komplexeren Audioumgebungen doch wichtig zu sein beim produzieren von Musik. Aber ob das bei einer simplen Orgel Ton abspielen Geschichte etwas bewirkt, dass soll jeder für sich selber entscheiden. Wenn du mit GO oder HW eine spürbare Latenz hast beim spielen, dann liegt die Ursache wohl meist nicht an Echtzeit oder nicht.
-
Da geht es nicht direkt um die Latenzen, sondern das GO mit erhöhter Prio läuft und andere Aufgaben im System mit niedriger Prio behandelt werden, was dann ggf. ein störungsfreies Spielen ermöglicht.
-
Das Problem ist aber, dass diese Aufgaben dann in der Warteschlange stehen und irgendwann doch abgearbeitet werden müssen. Im schlimmsten Fall sind dabei auch Aufgaben die essentiell für das System sind. Der Vorteil ist bestenfalls minimal und wenn man an diesem Punkt angekommen ist, dann ist ein Hardwareupgrade wohl sinnvoll.
-
Nein.
(Schon x-mal erklärt - und zwar aus Erfahrung.....)
-
Naja, so hohe Priorität hatte das die letzten Jahre ja auch nicht
Da hast du Recht. Ich lese gerade, dass das Thema nicht so einfach integrierbar ist, wie ursprünglich gedacht.
-
das Thema nicht so einfach integrierbar ist, wie ursprünglich gedacht.
Ich bin da kein Experte, aber ich vermute es wird schwer sein die Prioritäten zu setzen. Wenn Anwendungen bevorzugt Laufzeit bekommen, dann darf es ja nicht passieren dass für andere Aufgaben wie IO Zugriffe keine Zeit mehr bleibt. Wäre ja nicht zielführend wenn eine Software alle Laufzeit bekommt und das Dateisystem keine Zeit mehr hat Daten zu lesen oder zu schreiben. Da werden wahrscheinlich nur wenige ind er Lage sein so etwas zu programmieren. Dazu kommt ja noch dass jede Distribution ihr eigenes Ding macht was damit kollidieren kann. Beispiel Jack im RT Mode unter Debian bedeutet bei mir instant Crash des Systems. Unter Ubuntu Studio hingegen läuft es scheinbar stabil. Ich glaube wenn man mit solchen RT Geschichten arbeitet unter Linux, dann sollte man eine darauf ausgelegte Distribution wählen und keine die eher Server als Zielgruppe hat
Nein.
(Schon x-mal erklärt - und zwar aus Erfahrung.....)Mich würden ja mal Zahlen interessieren was du an Unterschiede ermittelt hast.
-
Zitat
Woher hast Du denn diese Information? Von Seiten Herrn Wurst war davon nie die Rede! Seinen Berichten nach hat er auch nur ein IR (oder allenfalls ein paar wenige) aufgenommen und keinesfalls für jede Pfeifenposition - und damit jede Pfeife - ein IR. Dass dies optimalerweise gemacht werden müsste war eine Aussage meinerseits im Faden von Maihingen. Dazu müsste aber jede Pfeife an der Orgel ausgebaut werden. Dafür hat er mit Sicherheit keine Genehmigung erhalten.
Diese Info habe ich, weil wir ein Instrument gemeinsam gesampelt haben. Die Aufnahme der Impulsantworten hat dabei erheblich mehr Zeit in Anspruch genommen als die Aufnahme der Sustain-Samples. Die Aufnahme eines Sustain-Samples dauert etwa 6 bis 10 Sekunden. Dann muss man den Nachhall abwarten, bevor man die nächste Pfeife aufnimmt. Wir haben für die Impulsantworten 3 Minuten lange Sweeps verwendet und erst dann die nächste Position aufgesucht, wenn wir 3 perfekte Aufnahmen im Kasten hatten. Das bedeutet, dass jede Position mindestens 10 Minuten in Anspruch nahm.
Und es geht nicht darum, die Pfeifen auszubauen, sondern den Lautsprecher für den Sweep möglichst nahe an die Pfeife zu bringen. Das ist nicht ganz einfach und erfordert z.B. meterlange Stative. Alle hintereinander stehenden Pfeifen bekommen dann die gleiche Impulsantwort, so dass nicht für jede einzelne Pfeife eine Aufnahme erforderlich ist.. Dies ist eine kleine Ungenauigkeit.
Die Kritik, die ich gelten lasse, ist, dass es praktisch unmöglich ist, echte trockene Samples aufzunehmen.
-
Zitat
Doch - es ist im Prinzip genau das, was John Boersma sagt. Es werden nur die vergleichsweise kurzen Loop-Samples in einer Schleife abgespielt, solange die Taste gedrückt wird. Auf die langen Release-Samples wird komplett verzichtet, aber gerade die sind es, die bei einem Multi-Release-Sampleset viel Speicher brauchen und dafür den Klang lebendiger werden lassen.
Das ist so formuliert ein wenig irreführend. Der Speicherbedarf eine Audio-Datei hängt ausschließlich von der Länge der Aufnahme ab. Aus diesem Grund passt auch auf jede CD mehr oder weniger die gleiche Zeit, egal wie komplex die aufgenommene Musik ist.
Angenommen die Kirche hat einen Nachhall von 4 Sekunden. Dann benötigt man für die Sustain-Samples 10 + 4 Sekunden (plus eine Pause zur Sicherheit), also sagen wir 20 Sekunden, das mittlere das kurze Release-Sample benötigen jeweils 1 + 4 Sekunden (plus eine Pause).
Der Bärenanteil an Speicher wird durch verschiedenen Perspektiven verbraucht. Jede Perspektive benötigt ihre eigenen Sustain-Sample plus die dazugehörigen Release-Samples. Ein Sample-Set, welches trockene Samples verwendet, benötigt die Sustain-Samples nur einmal. Alle Perspektiven werden zur Laufzeit über Impulsfaltung generiert.
-
Mal eine dumme Frage, warum nimmt man eigentlich nicht um die Dateigröße und somit den Speicher zu reduzieren komprimierte Formate wie OGG/MP3. Die entfernen bei guten Einstellungen ja nur Frequenzen die man ohnehin nicht hören kann, sind aber nur ein paar MB groß für Stunden lange Laufzeiten. Beispiel Wav 60 Minuten etwa 600 mb, dass ganze als mp3 wenige Mb.
-
Ich nehme an, dass das Entpacken der Samples zur Laufzeit möglicherweise zu viel Zeit in Anspruch nimmt. Wir wollen Systeme, die möglichst ohne Verzögerung arbeiten. Ich kann mir jedoch vorstellen, dass mit steigender Rechenleistung dies irgendwann kommen wird.
Bei GO gibt es die Möglichkeit, die Samples zu packen -- sogar verblüffend effektiv. Ich gehe jedoch davon aus, dass diese gepackten Samples beim Erstellen des Caches bereits wieder entpackt werden, so dass am Ende kein RAM eingespart wird.
-
ChrisS Ich hatte mich vor einiger Zeit für eine Spieleprojekt wo ich technische Unterstützung gegeben habe damit befasst. Man könnte jetzt annehmen dass z.B eine wav Datei die unkomprimiert weniger CPU Leistung braucht als eine mp3. Man kann es aber nicht wirklich allgemein sagen. Wenn ich eine mp3/ogg zur direkten Verwendung vom Datenträger lade und abspiele, dann ist die cpu Last tatsächlich geringer als wenn ich das gleiche mit einer wav Datei mache. Lade ich beide Dateien jedoch in den Arbeitsspeicher und spiele sie von dort dann ab, dann braucht die wav Datei nur einen Bruchteil der cpu Zeit wie die mp3/ogg.
Ich vermute dass dies daran liegt weil die ganze io Zeit und das bewegen der Daten bei der wav Datei eben aufgrund der Größe aufwändiger ist. Befindet sich diese wie bei HW/GO/Sweelinq bereits im Speicher, dann wird es weniger cpu brauchen.
Wobei ich jetzt nicht sagen oder einschätzen kann ob das manipulieren des Klangs dann bei einer mp3 oder wav aufwändiger ist. Der Wechsel auf komprimierte Dateien würde wohl denen auch nicht schmecken die nur auf Zahlen schauen und wo die Auflösung und Bitrate nicht hoch genug sein kann, da es ja Nutzer gibt die Unterschiede hören, wo Messgeräte keine messen können
Aber als Alternative Möglichkeit für alle mit schwacher Hardware wäre das ein guter Kompromiss.
-
Mal eine dumme Frage, warum nimmt man eigentlich nicht um die Dateigröße und somit den Speicher zu reduzieren komprimierte Formate wie OGG/MP3. Die entfernen bei guten Einstellungen ja nur Frequenzen die man ohnehin nicht hören kann.
Aber natürlich hört man das. Bei Popmusik eher weniger, aber aus eigener Erfahrung weiß ich von eigenen Aufnahmen und einen Export mit 320kbit/s, das da hörbare Frequenzen weggesäbelt werden. Ich kaufe grundsätzlich im Klassikbereich keine Mp3-Formate. Wenn ein Samplehersteller sowas machen würde, dann hätte er einen potentiellen Kunden weniger.
-
Diese Info habe ich, weil wir ein Instrument gemeinsam gesampelt haben. Die Aufnahme der Impulsantworten hat dabei erheblich mehr Zeit in Anspruch genommen als die Aufnahme der Sustain-Samples. Die Aufnahme eines Sustain-Samples dauert etwa 6 bis 10 Sekunden. Dann muss man den Nachhall abwarten, bevor man die nächste Pfeife aufnimmt. Wir haben für die Impulsantworten 3 Minuten lange Sweeps verwendet und erst dann die nächste Position aufgesucht, wenn wir 3 perfekte Aufnahmen im Kasten hatten. Das bedeutet, dass jede Position mindestens 10 Minuten in Anspruch nahm.
Und es geht nicht darum, die Pfeifen auszubauen, sondern den Lautsprecher für den Sweep möglichst nahe an die Pfeife zu bringen. Das ist nicht ganz einfach und erfordert z.B. meterlange Stative. Alle hintereinander stehenden Pfeifen bekommen dann die gleiche Impulsantwort, so dass nicht für jede einzelne Pfeife eine Aufnahme erforderlich ist.. Dies ist eine kleine Ungenauigkeit.
Die Kritik, die ich gelten lasse, ist, dass es praktisch unmöglich ist, echte trockene Samples aufzunehmen.
Das ist in der Tat ein sehr aufwendiges Verfahren. Aber warum sollte man dafür so lange Sustain-Samples verwenden? Für die Wahrnehmung der Schallplatzierung in einem Stereofeld sind nur die frühen Reflexionen wichtig. (https://en.wikipedia.org/wiki/Precedence_effect). Sie könnten daher für die ersten 100 ms mit ortsspezifischen IRs ausreichen. Die Hallfahne enthält nur diffusen Klang. Wenn Sie IRs nur mit den frühen Reflexionen auf die Samples anwenden würden, bleiben sie so trocken wie möglich und Sie könnten dann später mit HW oder GO Faltungshall anwenden, um die Hallfahne hinzuzufügen.
Meiner Meinung nach spannt Prospectum mit dem Auftragen von „Fake-Wet“-Samples den Karren vors Pferd. Den Hauptvorteil des Faltungshalls sehe ich in der dynamischen Simulation des Halls. Dazu benötigen Sie möglichst trockene Samples.
-
- Offizieller Beitrag
Diese Info habe ich, weil wir ein Instrument gemeinsam gesampelt haben. Die Aufnahme der Impulsantworten hat dabei erheblich mehr Zeit in Anspruch genommen als die Aufnahme der Sustain-Samples. Die Aufnahme eines Sustain-Samples dauert etwa 6 bis 10 Sekunden. Dann muss man den Nachhall abwarten, bevor man die nächste Pfeife aufnimmt. Wir haben für die Impulsantworten 3 Minuten lange Sweeps verwendet und erst dann die nächste Position aufgesucht, wenn wir 3 perfekte Aufnahmen im Kasten hatten. Das bedeutet, dass jede Position mindestens 10 Minuten in Anspruch nahm.
Ein Sampleset wird nicht automatisch gut, nur weil man möglichst viel Zeit bei den Aufnahmen investiert. Es kommt eher darauf an, wie intelligent man das macht.
Und es geht nicht darum, die Pfeifen auszubauen, sondern den Lautsprecher für den Sweep möglichst nahe an die Pfeife zu bringen. Das ist nicht ganz einfach und erfordert z.B. meterlange Stative. Alle hintereinander stehenden Pfeifen bekommen dann die gleiche Impulsantwort, so dass nicht für jede einzelne Pfeife eine Aufnahme erforderlich ist.. Dies ist eine kleine Ungenauigkeit.
Doch - es geht genau darum jede Pfeife auszubauen um den Lautsprecher für die Sweeps genau an dieser Position jeder einzelnen Pfeife zu platzieren. Das ist dann andernfalls keine kleine Ungenauigkeit, sondern ergibt einen eklatanten Unterschied gegenüber original gesampelten Releases eines Wet Set.
Ein Sampleset einer Orgel mit z. B. 1000 Pfeifen und 4 Releases pro Pfeife hat 4000 originalgetreue Releases, die nahtlos ohne Laufzeitverfälschung der Signale an das zugehörige Loop-Sample angehängt werden können. Diese 4000 Releases enthalten außerdem alle akustischen Nebeneffekte, die für die jeweilige Pfeifenposition im Pfeifenkasten auftreten. Die Aufnahme gestaltet sich relativ einfach und schnell und ist absolut hochwertig im Ergebnis, da alle natürlich auftretenden akustischen Gegebenheiten automatisch in den Aufnahmen enthalten sind.
Im Gegensatz dazu habt ihr bei der Methode von Prospectum Maihingen für (beispielhaft) 1000 Pfeifen nur vielleicht max. 300 IR Positionen für die Releases zur Verfügung. Von diesen 300 IR-Releases stimmt kein einziges mit der tatsächlichen Position irgend einer Pfeife überein! Es berücksichtigt auch kein einziges dieser 300 IRs die akustischen Verhältnisse innerhalb des Pfeifenkastens, da der Lautsprecher für die Sweeps zwangläufig vor dem Pfeifenkasten stehen muss. Wie Du selbst schon schreibst, ist das Erstellen von 300 IRs außerdem ein irrsinniger Aufwand. Geschweige, man würde wirklich 1000 IRs anfertigen, also für jede Pfeifenposition. Es geht aber schon alleine deshalb nicht, weil der Lautsprecher für die Sweeps viel zu groß ist um zwischen den übrigen Pfeifen platziert zu werden, wenn man diese eine Pfeife gezogen hat. Zudem müsste die Lautsprechermembran noch exakt an der Labiumposition platziert werden.
Diese Methode besteht daher nur aus lauter Ungenauigkeiten!
Der unbestreitbare theoretische Vorteil einer Dry + IR Methode ist demnach für eine Pfeifenorgel nur die quasi unendliche Anzahl der Releases, gegenüber 3 oder 4 eines Wet Set. Spielt man fortwährend schnelles Stakkato, dann kann man ggf. die Schwächen von zu wenigen Releases hörbar machen. Nicht jeder nimmt das aber wirklich störend wahr. Und nicht jeder spielt oft schnelles Stakkato. Außerdem tritt der Effekt vor allem erst bei Samplesets mit sehr großem Nachhall negativ auf.
Ein weiterer Vorteil der Dry + IR Methode ist der deutlich geringere Speicherbedarf und bei nur wenigen verwendeten IRs ein geringerer CPU-Bedarf. Speichergrößen und CPU-Leistung sind heutzutage aber ausreichend und günstig erhältlich.
Beide theoretischen Vorteile von Dry + IR kommen aber bei der Methode des Maihingen Prospectum Set nicht zum tragen, da es Hauptwerk nicht ermöglicht. So ist der Kompromiss eben 7 Releases plus alle Ungenauigkeiten, welche die IR Aufnahmen mit sich bringen.
Ich unterstelle deswegen aber nicht, dass das Set Maihingen Prospectum automatisch schlechter klingen muss als das Set Maihingen von Pipeloops. Es hängt natürlich auch bei den Samplesets in Wet-Technik stark von vielen Einzelfaktoren ab und wie gut der Sethersteller dies hin bekommt.
Aber alleine von der theoretischen Betrachtung her hat die Dry + IR Methode eben eklatante Schwächen, speziell bei Pfeifenorgeln.
