Ich verwende einen FV-1 von Musikding und habe damit etwas experimentiert, bin aber nicht zufrieden. Ich hätte gerne das qualitativ hochwertige Echo wie man es aus Lexicon-Geräten kennt und denke nicht, daß es das als Chip gibt. Deshalb würde Ich gerne selber so einen Chip in VHDL oder Verilog bauen und am Besten Pin-Kompatibel. Oder sagen wir: funktionskompatibel, also mit gleichem Interface. Hätte dazu einer der Fachkundigen einen Denkansatz? Ich habe hier bereis geblättert, will aber den thread nicht kapern :-) Beitrag "VHDL Grundlagen Tonerzeugung" Es geht vor allem auch um die Tricks, wie man ein gutes Echo hinbekommt, dass es sich groß anhört. Auch das hier habe Ich schon gefunden: Beitrag "Echo und Hall Schaltung" Ist aber ein bissl was anderes. Bin für jeden Input dankbar!
Markus privat schrieb: > Es geht vor allem auch um die Tricks, wie man ein gutes Echo hinbekommt, > dass es sich groß anhört. Eines vorneweg: dir ist schon klar, dass es da spezielle Studiengänge für sowas gibt und dass da einige Ingenieure bei einigen Firmen seit einigen Jahren daran arbeiten? Dir ist also auch klar, dass ein Einzelner, der das nebenher macht, einen gewissen, naja, sagen wir "Aufholbedarf" hat. Und dir ist ebenso klar, dass genau die Algorithmen die den besten Hall machen auch die geheimsten sind? So nachdem das geklärt ist, würde ich empfehlen, den Algorithmus erst mal als Plug-In für Audacity zu schreiben. Und wenn er sich dort dann gut anhört, dann würde ich ihn ins FPGA gießen. > Ich gerne selber so einen Chip in VHDL oder Verilog bauen Für ein FPGA oder gleich als ASIC? Wie gut beherrschst du VHDL oder Verilog?
:
Bearbeitet durch Moderator
Beitrag #5438324 wurde von einem Moderator gelöscht.
Lothar M. schrieb: >> Ich gerne selber so einen Chip in VHDL oder Verilog bauen > Für ein FPGA oder gleich als ASIC? Da sicherlich auch gleich die hochauflösenden ADC und DAC integriert werden sollen, muss ich schon ein Full-Custom-Chip werden. ;-)
Ich finde diese Seite ganz gut um zumindest mal einen Überblick über die Basics zu bekommen. Mit Beispielen in Audacity bzw. Matlab. http://www.hackaudio.com/digital-signal-processing/echo-effects/
> hochwertige Echo wie man es aus Lexicon-Geräten kennt
Das faengt schon bei den Begrifflichkeiten an.
An einem Echo(-Algorithmus) kann kaum etwas hochwertig sein.
Den hat auch ein DSP-Novize in kurzer Zeit zusammengeschrieben.
Wenn dann waere es der Hall aka Reverb...
Ich verstehe die kritischen Anmerkungen, jedoch geht es mir exakt darum, mit Algorithmen herumzuexperimentieren. Und richtig, es geht um Hall aka Reverb, wie geschrieben wurde. Jedoch ist es bekanntlich so, daß sich der Hall aus eben jenen Echos zusammensetzt. Die Chips, wie auch die plugins in Software, arbeiten allesamt mit einem RAM, in das sie die Daten reinkopieren und dann wieder mehr herausholen. Die Grundlagen dafür sind mir auch geläufig, wobei Ich selbstverständlich keine Lexicon-Algo-Tricks kenne, zugegeben. Da möchte Ich mich selbst herantasten. Einen FPGA soll genommen werden, weil Ich mir davon bessere Echtzeitfähigkeit erhoffe. Solche Sachen wie RAMs lesen und schreiben kann Ich. Das wäre nicht das Problem. Und Ich habe schon Schaltungen, wo der o.g. Chip verbaut ist. Die möchte Ich weiter verwenden. Somit scheidet eine Softwarelösung aus. Die Algorithen mit Audcity auszuprobieren, wäre natürlich eine Idee, dazu müsste Ich mich aber erst schlau machen, wie das geht.
Markus privat schrieb: > Die Chips, wie auch die plugins in Software, arbeiten allesamt mit einem > RAM, in das sie die Daten reinkopieren und dann wieder mehr herausholen. Das wäre übrigens exakt das Verfahren, wie du das FPGA-Design auch debuggen würdest: du hat eine WAV-Datie. Die schickst du in den Simulator, wartest eine Nacht und analysierst am nächsten Morgen das Ergebnis. > Die Grundlagen dafür sind mir auch geläufig, wobei Ich > selbstverständlich keine Lexicon-Algo-Tricks kenne, zugegeben. Da möchte > Ich mich selbst herantasten. Wie erwähnt: Algorithmen werden am PC entwickelt. Und zwar fix&fertig. Anschließend wird nur noch dieser Algorithmus auf das FPGA portiert. Und danach wird verglichen, ob mit dem selben Ausgangsmaterial das selbe Ergebnis herauskommt. > Einen FPGA soll genommen werden, weil Ich mir davon bessere > Echtzeitfähigkeit erhoffe. Das ist aber erst der Schritt, wenn du feststellst, dass der schnellste ARM-Prozessor von der Stange nicht für die Rechenaufgabe ausreicht. Denn der Weg, solche Algorithmen in ein FPGA zu bekommen, hat sich schon einige Male holpriger erwiesen als gedacht.... > Die Algorithen mit Audcity auszuprobieren, wäre natürlich eine Idee, > dazu müsste Ich mich aber erst schlau machen, wie das geht. Ja, das wäre sinnvoll. So wird das gemacht. Auch in der Bildverarbeitung: erst mal mit dem zig-GHz-Boliden offline herumrechnen. Denn dort auf dem PC sind eh' die Tools installiert, die für die Analyse des Ergebnisses nötig sind. Und wenns dann theoretisch klappen könnte wird eine Ressourcenbedarfsanalyse gemacht.
:
Bearbeitet durch Moderator
Markus privat schrieb: > Lexicon-Algo-Tricks Der Teufel steckt im Detail! Heutige Hall-Generatoren arbeiten mit Faltung und Impulsantworten. Der Algo besteht also nicht daraus, das Signal möglichst originalgetreu zu dopplern, sondern darin, mit einer definierten Impulsantwort (eines Dirac-Delta-Impulses) das Eingangssignal so zu falten, dass dabei das herauskommt, was wir als Mensch erwarten. Lexicon hat dabei viel Zeit und Geld darin investiert, die Impulsantwort der Räume aufzuzeichnen. Die Genehmigung, mit einer Schreckschusswaffe in Notre-Dame herumzuballern, war sicherlich nicht günstig.
Tip: Nimm nen einfachen DSP-Hybriden, der Blackfin ist für solche Sachen beliebt und reicht für Audio-Echtzeit vollkommen aus. Der Teufel, der im Detail steckt, ist typischerweise der, nicht stupide mit einem superlangen FIR draufzuhauen, wenn man die Impulsantwort hat. Ansonsten ist bei der Hallerzeugung nicht sonderlich viel Geheimes dabei, kniffliger ist eher Echo-Cancelling.
Auch hier gibt es kostenlose Angebote im Web, z.B. http://www.openairlib.net/auralizationdb Suchbegriff "free reverb impulse responses"
> Heutige Hall-Generatoren arbeiten mit Faltung und Impulsantworten.
Das war vielleicht gestern.
Ein Faltungshall ist naemlich viel zu unflexibel.
Man kann eine Impulsantwort nicht kleiner oder groesser rechnen
um zum gewuenschten Hall zu kommen.
Genauso wenig kann man die Bestandteile einzeln extrahieren,
um sie steuerbarer zu machen.
Ausserdem ist ein Faltungshall nicht unbedingt 'wohlklingend'.
> Und was nimmt man heute? Tja, gute Frage. Naechste Frage. Da soll sich der TO mal selber nen Kopf machen. Er kann ja klein mit ein paar ueber Allpaesse zusammenaddierten Delays anfangen und sich darueber freuen. Wenn er will, darf er aber auch gerne falten. Aber wie schrieb hier der Lothar schon: > "Und dir ist ebenso klar, dass genau die Algorithmen die den besten > Hall machen auch die geheimsten sind?"
Neben den fest programmierten Sounds kann man in den FV-1 auch selbst programmierte Algorithmen einbauen. Dazu gibt es von Spinsemi eine komplette Entwicklungsumgebung. Ich benutze diesen chip auch und finde die fest vorgegebene Halleinstellung schon recht ordentlich für die Praxsis.
Soweit ich weiß (sowohl von Audio-Kennern als auch weil ich selber in der Richtung geforscht habe), ist nicht wirklich was Geheimes an Algos dran. Da sind ein Paar Patente, die man beachten muss, und das wars. Diese Patente für Algos beschreiben die Art und Weise, wie man mit langsamen Prozessoren/DSP guten Sound hinbekommt. Mit viel Rechenleistung braucht man so etwas nicht. Noch was, was Lexicon und Co betrifft. Die Hall-Geräte von denen sind alt und teuer. Und das, weil die Leute keine Source-Code dafür mehr haben. Nur die Bit-Files für irgendwelche uralt-CPUs/DSP sind geblieben, deshalb kann man es heute nicht einfach so nachbauen. Die wissen teilweise auch nicht, mehr, was da drin steckt -- müssen ja auch nicht. Wenn man darüber schweigt, trägt es teilweise auch zu ganzem Hype bei (meiner Meinung nach). Du brauchst auf jeden Fall eine Referenz (in Software), deshalb kommst Du nicht drumherum, Plug-Ins zu programmieren Viel Erfolg Kest
Ist zwar auch nicht FPGA basiert aber vielleicht auch interessant für den ein oder anderen: http://www.analog.com/en/design-center/processors-and-dsp/evaluation-and-development-software/ss_sigst_02.html Das ist ein Entwicklungstool, was auf die DSP Prozessoren von Analog Devices zugeschnitten ist. Habe ich aber selber noch nicht benutzt, ist mir bloß bei meinen Recherchen zu DSP mal über den Weg gelaufen.
> Du brauchst auf jeden Fall eine Referenz
Er koennte sich an "Fusion Field" orientieren.
Da gibt es auch en Evaluierungsversion.
Sicherator schrieb: > Heutige Hall-Generatoren arbeiten mit Faltung und Impulsantworten. Der > Algo besteht also nicht daraus, das Signal möglichst originalgetreu zu > dopplern, sondern darin, mit einer definierten Impulsantwort (eines > Dirac-Delta-Impulses) das Eingangssignal so zu falten, dass dabei das > herauskommt, was wir als Mensch erwarten. Richtig. Deshalb muss ja auch ein FPGA her (wegen der Faltung) und dem echten Ausprobieren (wegen dem schnellen Anhören). Ich kann das, was ich in erträglicher Zeit in Software berechnen kann, nicht beurteilen, ohne es zu hören, weil es einfach ist und wenn es komplex genug ist, nicht ohne aufwändiges Rechnen erzeugen lassen. Die einfachen Impulsfolgen der Faltung kennt man ja. Die sind ausgereizt. Siehe ""free reverb impulse responses"
>Richtig. Deshalb muss ja auch ein FPGA her (wegen der Faltung) und dem >echten Ausprobieren (wegen dem schnellen Anhören). Was meinst Du mit "schnellen Anhören"? Wenn Du die Zeit meinst, die es dauert ein FPGA zu programmieren bis man etwas "hören" kann, geht das eher länger. Zumindest war das so bei meiner experimentellen Tonerzeugung, die Du oben verlinkt hast. Die Entwicklungszeit eines Algorithmus mit Matlab gegenüber der Implementierung in VHDL würde ich mal so mit dem Faktor 30 abschätzen.
Die für mich beeindruckendste Hallsimulation durfte ich anläßlich einer Vorführung durch Wolfgang Schwarz im Rahmen der Ars Electronica 1982 erleben. http://www.quantec.com/index.php?id=room_simulation&L=1
chris schrieb: > Wenn Du die Zeit meinst, die es dauert ein FPGA zu programmieren bis man > etwas "hören" kann, geht das eher länger. Allein der Übersetzungsvorgang vom Code zum fertigen "ausführbaren" und geladenen Bitfile dauert länger. Wenn dann noch ein Fehler im Code war, dann verdoppelt sich diese Zeit u.U. gleich noch mal. Und wenn man dann noch die Zeit für eine evtl. nötige Simulation (der Simulator ist der FPGA-Debugger) rechnet, dann ist der, der seinen Algorithmus vorab auf Audacity verifiziert schon lange "am Markt"... Man kann auch mit Audacity so ein Setup aufbauen, dass man sich schnell was aufnhemen und modifizieren kann. Der Vorteil von Audiodateien als Input ist der, dass man ganz einfach immer den selben Input hat und den Output auf Veränderungen/Verbesserungen prüfen kann.
Ein Core i5 oder i7 verblässt jeden FPGA, ausgenommen vielleicht die ganz grossen in der > 10k Euro Klasse. Schau dir mal die Intel AVX 512 Erweiterungen an. Ein 8 Kern i7 macht damit 128 Multiply-Add Operationen (32 Bit Float) pro Takt. Das sind ca. 500 Giga-Flops in der Sekunde. Speicher > 16 GB ist auch kein Problem. Um einiges einfacher als mit Audacity, ist es das ganze File in Matlab oder Octave auf einmal einzulesen, und dann mit der Raumimpulsantwort zu falten. Das sind eine Handvoll Codezeilen inklusiv der Audio-Ausgabe, einfacher gehts nicht mehr.
Ich möchte alle Parameter in Echtzeit verdrehen und anhören. Wenn Ich die Änderung erst programmieren soll, müsste Ich auf das Ergebnis warten, bis es simuliert ist. Was hätte das für einen Vorteil? Dann arbeite Ich zweimal. Die Code Generation von MATLAB ist jetzt so dolle sicher auch nicht, zudem bräuchte es eine Lizenz. >Schau dir mal die Intel AVX 512 Erweiterungen an. >Ein 8 Kern i7 macht damit 128 Multiply-Add Operationen (32 Bit Float) Warum bauen die dann keinen I7 in ihre Soundprozessoren ein? :D Der Vergleich von CPUs und FPGAs ist mir geläufig, da Ich auch beruflich damit zu tun habe. Deine Rechnung ist reine Theorie. Was die Prozessoren theoretisch könnten, kriegen sie hinten und vorne nicht als Bandbreite raus. Da spielen Cache-Strukturen und Vieles mehr eine Rolle. Im schlechtesten Fall ist eine Multi-Core-CPU echtzeitmässig schlechter, als ein gleichschnell getakteter Single-Core.
Markus privat schrieb: > Warum bauen die dann keinen I7 in ihre Soundprozessoren ein? Für die Serie schlicht zu teuer und zu aufwändig. Bei der Entwicklung spielen Kosten weniger eine Rolle, da geht es um schnelle Turnaround Zeiten. In welcher Phase ist dein Design? Serie oder Entwicklung?
Markus privat schrieb: > Ich möchte alle Parameter in Echtzeit verdrehen und anhören. Wenn Ich > die Änderung erst programmieren soll, müsste Ich auf das Ergebnis > warten, bis es simuliert ist. > Auf Rechner erstellt man den Algorithmus als Programm und hat verschiebene Parameter, die, entsprechend gebaut, auch wärend dem Lauf geändert werden können. Und welchen Echtzeit-Compiler benutzt du für FPGAs, wenn die Rechnervariante zu inflexibel ist. Ich habe keine praktische FPGA-Erfahrung, hatte aber bisher den Eindruck, daß Änderungen an der Source eher nicht JIT Wirkung zeigen.
Was in Echtzeit zu ändern ist, um es real abzuhören, hängt wohl sehr an den Parametern selber. Strukturen zu ändern ist eben schwierig, es sei denn man setzt Multiplexer ein, um rasch verschiedene Kombinationen zu ändern. Beim Hall sehe Ich da vor allem die Abgriffpunkte in den RAMs. Solche Sachen wie Dämpfungen, EQ sind ohnehin parametrisch. Ich werfe aber nochmal was anderes in die Runde: Das Grundproblem der Halls ist - egal, ob man Faltung oder Reflektionen im Zeitbereich verwendet - dass in aller Regel echte, also schon reflektionsbehaftete Signale beaufschlagt werden sollen, deren Zusammensetzung man nicht kennt und auch nicht pauschal annehmen kann. Daher ist letztlich immer Hören und Fühlen angesagt, wenn es um das Verhalllen von Musikmaterial geht und das macht der Produzent beim Mischen. Geräte können so schlau und gut sein, wie sie möchten - sie werden aber dieses Problem nicht lösen. Es gibt natürlich ein paar Grundsätze, wie Haas-Grenze / die Behandlung von Erst-Reflektionen und Diffusfeldspektren/-phasen, die man zur Anwendung bringen kann. Faltung ist dabei ein schwieriges Thema! Das hatten wir schon mehrfach diskutiert, z.B. beim thread, wo es um das pitch shifting ging. Bei der Transformation ist es z.B. wichtig, eine engmaschige FFT mit geringer Frequenz-Überlappung hinzubekommen, diese aber ihrerseits stark zeitlich zu überlappen und dann bei der Resynthese der Einzelergebnisse wieder gut zu smoothen. Bei beiden Transformationen treten zudem Artefakte durch die Fensterung auf. Wir haben das Thema just die Tage wieder in der DSP-usenet-Gruppe gehabt. "Engmaschig" und "hoch überlappend" erfordert ernorme Rechenleistung, die sicher FPGAs rechtfertigen. Zu dem Thema I7 und FPGA-Vergleich habe Ich an anderer Stelle schon mehrfach Stellung genommen. Da sind Welten dazwischen, zu Gunsten des FPGAs. Nun ist es so, dass - anders, als beim pitching - beim Hall nur ein Zusatzsignal erzeugt und zugemischt wird, d.h. ein Großteil des Signals bleibt unverändert. Üblicherweise sind das aber Werte bis zu 50% für synthetische "trockene" Signale. Das Summensignal leidet dann anteilig bis zu eben jenen Prozenten an besagten Artefakten, wenngleich die Methodik des Faltens prinzipiell zu richtigen Ergebnissen führen würde - vorausgesetzt, man hat die Effekte der Mikrofone bei der Aufnahme der Echos, die zu den Koeffizienten führen sollen, entsprechend wegprozessiert. Heißt: Faltungshall in sich gesehen, wäre perfekt, lässt sich aber technisch nur schwer störungsfrei umsetzen. Im Normalfall wiederum machen die Artefakte weniger Anteil aus, wenn nur wenige Prozente an Signalanteil hinzukommen. Hier zeigt aber die Praxis, dass die Qualität und Zeitpunkt der Reflektionen entscheidend ist, weil diese sich unkontrolliert mischen und unvorhersehbare Effekte machen können. Ein echter Faltungshall ist hier deplaziert, weil er komplett falsche Ergebnisse liefern würde. Umgekehrt macht das nur leichte Einmischen eines Faltungsfalls zwar wenig Artefakte - aber in Summe auch keinen wesentlichen Unterschied mehr zu dem, was ein künstlicher Hall hinzu bringen kann. Das ist also nicht pauschal entscheidbar. Es kommt einzig auf die konkreten Reflektionen der Quelle und der "Additive" an. Daher hat sich Faltungshall mit echten Impulsantworten nicht wirklich durchgesetzt. Man kann es zu selten richtig nutzen, weil man keine trockenen Signale hat - vom Trance und Techno / Electronic mal abgesehen, wenn oure Signal erzeugt werden. Es ist also zielführender, eine Anzahl von Hallprogrammen mit Auswahl an Echostrukturen anzubieten und dann später im Zusammenspiel mit dem konkreten Material zu entscheiden, was gut klingt.
Ein Punkt noch: Maßgeblich ist dabei auch das Abspielsystem: Das Stereosystem ist ein nichtreales Wiedergabesystem mit ganz spezifischen Eigenschaften, welches ein virtuelles Bild erzeugt. Einfach Mikros am Ort der Ohren aufstellen und wiederzugeben, reproduziert nicht das Bild, das man real hat. Das Stereosystem braucht somit ganz bestimmte konditionierte Signalgemische, um Breite und Tiefe zu erzeugen (andere übrigens, als Kopfhörer oder binaurales Hören!) und damit klappt es auch schon nicht, ein trockenes Fingerschnippen mit dem Notre Dame Hall zu versetzen, um das zu bekommen, was man vorort hören würde und dies ist wiederum ist nicht das, was man in ein Stereosystem einprägen müsste, um ein realitätsnahes Szenario zu erstellen. Daher basteln die Hersteller an allerlei Extremfällen herum und machen auch vor stark unrealistischen Szenarien nicht Halt: Zum Beispiel Lexicon (s.o.) fällt mir ein, dass dort schon vor über 2 Dekaden probiert wurde, mit zufälligen Reflektionen zu arbeiten, also Echos, die aus unterschiedlichen, wechselnden Richtungen kommen. Auch wird mit unnatürlichen EQ-Kurven gearbeitet, z.B. einer geringeren Dämpfung für hohe Frequenzen und sogar negativem Phasenvorlauf für weglaufende Echos, was es beides in der Praxis nicht geben kann. Diese und andere Spielchen sind in den heutigen Geräten und plugins mehr oder weniger drin, aber auch da hat man die Probleme der Rechenleistung. Für einen "echt" und weit klingenden Hall sind oft eine 4-stellige Zahl von Einzelreflektionen zu verarbeiten. Ein große Menge an Reflektionen wird aber sehr schnell "schlecht". Man kann das recht deutlich hören und sehen, was leistungsstarke Halleffektalgorithmen an CPU-Leistung verbraten, bzw was sie in neueren Gerätegenerationen können, die höher Abtasten, feiner modulieren und noch einiges mehr, weil mehr DSP-Power drin sitzt. Da kann man eigentlich nicht genug Leistung haben. Wie die ungefähr funktionieren, lässt sich ein wenig ausspähen, wenn man Dirac-Impulse auf den plugin / das Gerät loslässt und etwas misst :-) Zum Thema Hall mit FPGA: Wer das Spartan-6-Eval board Atlys von Digilent hat, kann hier gerne mal (m)ein Beispiel ausprobieren: www.96khz.org/files/2011/digilent_atlys_audio_test.zip Die Töne sind simple Sinusschwingungen und erzeugen ein sehr nettes Raumklangszenario - obwohl es nur ein simpler statischer ping-pong-Hall mit linearem EQ ist. Für pure Signale eine echte Bereicherung. Echte Musik klingt damit aber ein wenig seltsam. Vor allem zu dicht und fett. Das Problem dabei ist, dass deren Signale nämlich selber schon Kunstechos drin haben, die genau so erzeugt wurden! Man hört also die Kopien der Kopien der Kopien ... usw. Dabei entstehen rythmische Echomuster, die pumpen, klirren, metallisch zerren und was weiß ich so alles produzieren. Praktisch ist es eben kein mehrdimensionales Echobild eines Klangs mit n Dimensionen, sondern immer "die Stereoanlage in der Kirche" also 2-Kanal-Hall mit jeweils n-fachen 2-kanaligen Kopien. Das ist schon methodisch sehr begrenzt! Halbwegs gut klingt immer ein Kunsthall, der nach dem eigentlichen Verlöschen der inbegriffenen Kurzreflektionen einsetzt und auf Material angewendet wird, welches real aufgenommen wurde. Umgekehrt kann man einen Realhall auf ein künstlich verhalltes Signal draufkleben, wenn man ihn so formt, dass sein Maximum den Beginn des künstlichen Nachhalls überdeckt und dieser nicht zu laut im Signal enthalten ist. Was es auch noch gibt, ist der Versuch, mit Echo cancelling die ersten Störreflektionen im Signal zu killen, bevor es in den Hallprozessor geht. Dann gibt es nicht so viele unschöne "Kopie-Kopie-Kopien" und man kann mehr, des Halls zumischen. Zieht man aus dem Original noch sanft die schlechten Kurzechos heraus, wird das Ergebnis breiter UND näher / deutlicher, was sich sonst bekanntlich ausschließt. Eine Lösung des Problems heißt Mehrkanaltechnik! Man braucht trockene UND verhallte Signale. Bei klassischen Tonaufnahmen werden nicht ohne Grund Stützmikros und Raummikros sowie reine Hallmikros gestellt und getrennt aufgezeichnet. Da geht dann später noch ein bischen was in Richtung Raumklanggestaltung. Notwendig sind dazu natürlich auch Mehrkanalprozessoren. Mit der typischen Mischtechnik auf Stereo-2-Kanal, dann auf plugin oder Stereo-outboard hat man verloren. Mein Ansatz zu dem Thema ist die individuelle Behandlung jeder Spur vor und beim Platzieren im Raum schon bei der Gewinnung der Signale - also der Erzeugung! Mein Synth macht das für jede der mindestens 64 "Spuren" einzeln und dann im Raum 8-kanalig für jeden Lautsprecher und dies zudem dynamisch modifizierbar. Im Prinzip ist das die Arbeitstechnik der Trance-Produzenten, die schon immer jede Spur einzeln individuell mit Echos und Wiederholungen verhallt haben, um sie dann individuell zu modifizieren, bevor sie in einen Submix gehen. Leider unterstützt das bis heute keine der mir bekannten DAW-Software-Pakete vernünftig. Muss man alles händisch tun.
Im Anhang ein kleines Echo-Experiment mit Octave. Hier das Originalfile: https://www.mikrocontroller.net/attachment/344110/TwoTone8StepADSR2.mp3 Hier das FPGA-Echo von Jürgen: https://www.mikrocontroller.net/attachment/344220/mixtest.mp3
1 | [wsig,fs]=wavread("TwoTone8StepADSR2.wav"); |
2 | |
3 | d_ms=700; |
4 | |
5 | osig=zeros(1,length(wsig)); |
6 | |
7 | dline=zeros(1,round(fs/1000*d_ms)); |
8 | |
9 | ip=1; |
10 | for n=1:length(wsig), |
11 | osig(n)=wsig(n)+dline(ip)*0.5; |
12 | dline(ip)=wsig(n); |
13 | ip=ip+1; |
14 | if ip>length(dline), |
15 | ip=1; |
16 | end
|
17 | end
|
18 | |
19 | sound(osig,fs); |
Es braucht tatsächlich einige Sekunden um alle Indeces zu durchlaufen.
Du musst in Matlab mit Vektoren und Matrizen arbeiten, um schnellen Code zu erhalten... For Schleifen werden interpretiert, und sind langsam. Also etwa so: fname = 'cguitar1.wav'; [x, fs, nbit] = wavread(fname); delay = 100e-3; n = round(delay * fs); y = [x; zeros(n, size(x,2))]; m = length(x); y(1+n : m+n, :) = 0.5 * x; wavplay(y, fs, 'async');
Ich bin dem Spieltrieb nachgegangen, und habe einen einfachen Faltungs-Hall in Matlab nachgebaut. Im Anhang die Impulsantwort des Buero-Vallejo-Theater in Alcorcon (ir1.wav), und ein Gittaren Beispiel ohne (cguitar1.wav) und mit Hall (cguitar1-ir1.wav). Wenn man das File ausführt, merkt man auch dass da ohne Rechenpower nichts mehr geht... ich gehe mal davon aus, das Matlab nicht sehr gut optimiert ist... zumindest rechnet es nur mit einm Core. % Eingangs Wave File wav_name = 'cguitar1'; [x, fs, nbit] = wavread(wav_name); % Raumimpulsantwort in Buero-Vallejo-Theater, Alcorcon, Spain ir_name = 'ir1'; [ir, ir_fs, ir_nbit] = wavread(ir_name); b = ir(:, 1); a = 1; [y, zf] = filter(b, a, x); y = [y; zf]; y = y ./ (1.05 * max(y)); wavwrite(y, fs, [wav_name, '-', ir_name]); %wavplay(y, fs, 'async');
Markus privat schrieb: > Der Vergleich von CPUs und FPGAs ist mir geläufig, da Ich auch beruflich > damit zu tun habe. Deine Rechnung ist reine Theorie. Was die Prozessoren > theoretisch könnten, kriegen sie hinten und vorne nicht als Bandbreite > raus. Da spielen Cache-Strukturen und Vieles mehr eine Rolle. Im > schlechtesten Fall ist eine Multi-Core-CPU echtzeitmässig schlechter, > als ein gleichschnell getakteter Single-Core. Die Rechnung ist keine reine Theorie, es gibt Beispiele von Intel, die diese 500 GFlops erreichen. Und eine FIR Filterung (Faltung) lässt sich ziemlich gut optimieren... Schau dir mal die Intel Performance Libraries an.
Ich habe noch ein Beispiel für die Santa Lucia Kirche in Bologna gerechnet (Anhang). Ich finde da kommt ganz am Ende so richtig der Kirchenhall durch :-)
So, und nun ein letztes, mit der Impulsantwort einer "Parking Garage"! Im grossen und ganzen funktioniert das gut, jetzt muss man sich nur mehr überlegen, wie man so eine Impulsantwort künstlich berechnet. Schönes WE, Udo
Udo K. schrieb: > Im grossen und ganzen funktioniert das gut, jetzt muss man sich nur mehr > überlegen, wie man so eine Impulsantwort künstlich berechnet. Die soll eigentlich gemessen und errechnet werden. Wenn man es generisch berechnet, kann man gleich die Echos im Zeitbereich draufklatschen. chris schrieb: > Hier das FPGA-Echo von Jürgen: Das sind aber rythmische Echos, die den Takt komplettieren sollten, nachdem 8 Noten verwendet werden, während Du 9 Noten in der Wiederholung hattest. Echos für Hall sehen anders aus. Udos Beispiel zeigt das von mir oben skizzierte Problem: Das Ausgangsfile klingt schon etwas eng, hat starke Kurzreflektionen drin. Klebt man da noch Faltungshall hinzu, wird es dichter, noch kleiner und hört sich eben an, wie ein Lautsprecher, der in der Kirche steht. Was wir mit Hall aber eigentlich haben wollen, ist Grösse, Weite. Eher in Richtung dem angehängten file:
> ganz am Ende
Jaja. Sehr huebsch. Aber:
100% wet will keiner beim Hall.
So -24 bis -12 dB reichen.
Bei Soloinstrumenten dann auch nicht unbedingt auf die Solospur
sondern auf die "gedoppelte" Solospur mit mehr Spread.
Mal ganz ehrlich: So einen Matschhall kann auch ein mehrfederiger
Spiralhall erzeugen...
> wie man so eine Impulsantwort künstlich berechnet.
Auch das ist schon erfunden: Acoustic Raytracing.
Der grosse Durchbruch wird aber vermutlich nie kommen.
Weil fuer Serienprodukte zu aufwendig und im Studioeinsatz
zu unflexibel.
Es fehlt da die spontane Interaktion: Mann dreht und das
Resultat aendert sich in Echtzeit.
Vor weiteren Faltungsversuchen solltest du wirklich
mal so was wie "Fusion Field" oder den "ZRev" anhoeren.
Deren Reverb laesst sich "passgenau" in einen Mix einfuegen.
Von anderen Herstellern (Cakewalk, Waves, Ozone) gibts es auch
reichlich.
Udo Krebelder (udok) >Du musst in Matlab mit Vektoren und Matrizen arbeiten, >um schnellen Code zu erhalten... Ursprünglich hatte ich die delay-line via der Filterfunktion realisiert bsp. für eine Verzögerung von 4: B=1; A=[1 0 0 -0.5]; filter(B,A,sig); Für eine Verzögerung von 700ms war die Rechenzeit in Octave dann aber so lange, dass ich diesen Weg aufgegeben habe. Eigentlich hatte ich geglaubt, dass Octave so schlau ist und die Nullen nicht mitrechnet und damit die Rechenzeit optimiert. In meinem Script oben ist ein Fehler > osig(n)=wsig(n)+dline(ip)*0.5; > dline(ip)=wsig(n); Diese Zeilen ergeben nur eine einmalige Addition des verzögerten Signals. Man muss aber statt des reinen verzögerten Signals das Hall Signal zur delay-line dazu addieren, also so: osig(n)=wsig(n)+dline(ip)*0.5; dline(ip)=osig(n); Wenn ich es richtig sehe, hast Du den Fehler in die Vektoraddition übernommen. Am schnellsten könnte man wahrscheinlich rechnen, wenn man für C eine Wavread und Wavwrite Funciton hätte. Damit wäre ein Hall schnell programmiert.
Jürgen S. schrieb: > > Udos Beispiel zeigt das von mir oben skizzierte Problem: Das > Ausgangsfile klingt schon etwas eng, hat starke Kurzreflektionen drin. > Klebt man da noch Faltungshall hinzu, wird es dichter, noch kleiner und > hört sich eben an, wie ein Lautsprecher, der in der Kirche steht. Was > wir mit Hall aber eigentlich haben wollen, ist Grösse, Weite. Die Impulsantworten, die ich verwendet habe sind gemessen, nicht gerechnet. Nur, das Problem ist ja, dass da mehrere Raumantworten überlagert werden, zunächst die Impulsantwort des Aufnahmeraumes, und dann die Impulsantwort des Halls. Das wird dann automatisch immer "matschiger" (zeitlich und frequenzmässig), man sieht das sehr schön am Spektrogram in foobar2000. Dazu zwei Beispiele im Anhang. Das erste snare1.mp3 ist zeitlich super definiert, nach dem Hall überlagern sich die einzelnen Schläge regelrecht, praktisch ein neues Instrument. Das zweite violin1.mp3 ist dagegen im Frequenzbereich durch die Schwingungen der Saiten super definiert. Auch da kommt es zu einem Überlagerungseffekt durch den langen Hall. Ist einfach interessant, sich das mal im Spektrogram Plugin von foobar2000 anzuschauen, bzw. sich anzuhören. Ein guter Hall müsste erst mal den Aufnahmeraum wegrechnen. Sonst wird es automatisch matschiger, und das Ergebnis ist eher herumprobieren. Stimmt natürlich, dass das Extrembeispiele sind. Und mir ist schon klar, dass das kein fertiges Hall Plugin ist. Ist nur zum herumspielen...
@chris: Der Fehler ist mir auch schon aufgefallen, den habe ich aber nur im delay line Beispiel kopiert. > > Für eine Verzögerung von 700ms war die Rechenzeit in Octave dann aber so > lange, dass ich diesen Weg aufgegeben habe. Eigentlich hatte ich > geglaubt, dass Octave so schlau ist und die Nullen nicht mitrechnet und > damit die Rechenzeit optimiert. Die Rechenzeit ist da schon heftig, Der Kirchenhall ist sogar 4 Sekunden lang. Echtzeit geht auf dem Laptop nicht mehr mit meinem alten Matlab, das einen Core verwendet. > > Am schnellsten könnte man wahrscheinlich rechnen, wenn man für C eine > Wavread und Wavwrite Funciton hätte. Damit wäre ein Hall schnell > programmiert. Ist im Prinzip eine einfache Sache, der Header hat 44 Bytes, wo praktisch nur die Anzahl der Samples drinnen steht. Wenn die Impulsantwort kleine Werte hat, kann man die vernachlässigen, und das ganze wird sehr viel schneller. Aber vorher müsste man wissen, was man eigentlich machen will... Soweit ich das verstanden habe, liegt die Kunst in der Berechnung angepasster Raumimpulsantworten. Wahrscheinlich nehmen dann die meisten Plugins irgendwelche rechnerischen Abkürzungen und sparen sich das Filtern komplett. Das Raytracing, dass irgendwo oben erwähnt wurde, vernachlässigt ja die Beugung komplett, und dann läuft das auf mehrere Delaylines hinaus. Gruß, Udo
Ihr denkt viel zu kompliziert. Ja, IR ist ein Thema, aber es gibt viele Algorithmen die auch guten Hall mit viel weniger Rechenleistung erzeugen. Z.b. die Allpass Struktur von Keith Barr ist Super: http://www.spinsemi.com/knowledge_base/effects.html#Reverberation Das sind lediglich acht Allpass Filter mit einer großen Feedback Schleife und ein bischen gefilter. Damit kommt man schon ganz schön weit. Noch Pre-Delay dazu (einfache Delay Line). Vielleicht zwei Allpass Diffusoren vor dem Eingang. Dazu dann Early Reflections über eine Delay Line und Du hast alles was Du brauchst um einen guten algorithmischen Hall zusammenzubauen. Die Kunst, das es gut klingt liegt in den Parametern. Da hilft Erfahrung, ein gutes Ohr und viel viel Zeit.
Nils P. schrieb: > Das sind lediglich acht Allpass Filter mit einer großen Feedback > Schleife und ein bischen gefilter. Damit kommt man schon ganz schön > weit. Das ist aber Asbach Uralt und wird schon ewig nicht mehr so gemacht. Die reinen Delayfilter dieser Art produzieren ekelige Kammfiltereffekte, die genau es zu vermeiden gilt und die bei länger anhaltenden Signalen massiv zu Tage treten. So wie er es dort beschreibt, ist das auch suboptimal, weil alle Filter mit Faktor +/-1/2 rückkoppeln. Das sind dann zwar Allpässe, aber es geht mit abgestimmten Filterkoeffizienten besser. Diese Lösung ist eher in Richtung "wenig Rechenleistung". So haben wir in den 90ern mit Hall DSPs gebaut :-) Nach meinen Erfahrungen ist es nicht zweckmäßig, ausgeprägtes looping zu verwenden, um Reflektionen zu bekommen. Indem man stark rückkoppelt, denn dann sind die Muster zu prägnant. Die regelmäßigen Wiederholungen müssen im Bereich von >>300ms bleiben, in jedem Fall länger, als der elementare Rhythmus im Mix, also eher Richtung 1 Sekunde, damit kann man nur beim Kirchenhall davon profitieren. Wenn man Reflektionen sauber hinbekommen will, muss man das auch sehr fein und sauber auflösen, d.h. durchaus auch unterhalb der Samplegrenze, weil diese Zeitfehler kumulieren und immer wieder mit anderen Interferenzmuster bilden. Genau die führen dann zu den künstlichen Resonanzen, weil sich einige Frequenzen massiv aufschaukeln, während andere fehlen. Damit ist der Hall quantitativ früh zu laut, während er qualitativ noch nicht dicht genug ist, um weich zu tragen. Was auch benötigt wird, sind hohe Rechengenauigkeiten: Die vielen kleinen Reflexionen im Raum haben alle einen sehr geringen absoluten Beitrag, müssen aber korrekt addiert werden, um zu sinnvollen Ergebnissen zu kommen. Dabei sind insbesondere auch die Auslöschungen wichtig. Diese funktionieren aber nicht richtig, weil nach Addition von Phase und Antiphase zweimal der Rechenfehler über bleibt und der sich bestenfalls statistisch weghebt. Zu hören ist das bei den Lauten "Z", "S" und "T", welche regelmäßig zu grandiosen Artefakten bei hellem Hall führen. Dort "oben" schlagen die nichtidealen digitalen Filter, die Aliaseffekte und die Granularität der Faltung bie Samplefrequenz voll zu. Das Standard-Gegenmittel ist das oversampling. Mit FPGAs und ihren Taktfrequenzen kann man das sehr leicht bewerkstelligen und mit ModelSIM im Vorhinein die Reflektionen mit Delays ausprobieren und ein file schreiben lassen. Allerdings braucht es wegen der Komplexität des Halls viele lines und damit unabhängige RAM-Bereiche und wegen der hohen Samplerate auch sehr große RAMs. Ein bisschen tricksen kann man, indem man mehrere kurze verwendet, welche so gestaltet und verschaltet sind, dass sich die ersten Reflektionen erst einmal gegenseitig weglöschen und sich dann scheinbar zufällige schnell verdichtende Reflektionen ergeben.
Ein Beispiel mit schnell ansteigenden Reflektionen aus 32 RAMs. Kann man dann passend verlagern und shapen.
Nils P. schrieb: > Z.b. die Allpass Struktur von Keith Barr ist Super: Das ist doch der Hersteller des vin mir genannten Chips: http://www.spinsemi.com/products.html Und der arbeitet mit 16 bit und ist auch sonst leicht veraltet. Die dort beschriebenen Filterstrukturen wären auch mein Ansatz gewesen, Ich möchte diese aber ändern und das ist so mit deren Konfigurationssoftware nicht möglich. AD-Wandler möchte Ich selbverständlich nicht nachbilden. Das ist auch nicht nötig, weil auf meiner PCB ein Wandler drauf wäre und obendrein die Daten digital vorliegen. Udo K. schrieb: > Ein guter Hall müsste erst mal den Aufnahmeraum wegrechnen. Sonst wird > es automatisch matschiger, und das Ergebnis ist eher herumprobieren. Das dürfte ein Problem werden. Schon mal damit befasst?
Jürgen S. schrieb: > Mit der typischen Mischtechnik auf Stereo-2-Kanal, > dann auf plugin oder Stereo-outboard hat man verloren. Ja aber das ist doch auch vollkommen egal. Es ist irgendwo schon im Thread erwähnt worden: Ob das Ding jetzt wirklich klingt, wie in Notre-Dame oder nicht, spielt keine Rolle, denn welcher Hall genutzt wird, hängt einzig und alleine von der Produktion ab, zu der er passen muss. Wenn es darum geht, eine trockene Stimme etwas feuchter zu gestalten, ist doch Wurst, ob es Höhle 1, oder Autobahnraststätte 47 ist. Insgesamt muss der Hall passen. Ausnahme sind hier höchstens Spezialanwendungen, bei denen ein ganz bestimmtes Resonanzverhalten gewünscht wird. Aber auch da wird der Produzent nicht sagen: Hey, ich war doch vor acht Jahren mal im Urlaub - die Akustik vom Taj Mahal würde passen, sondern er wird solange durch die Presets durchdrücken, bis er einen hat, der passt. Hinterher läuft das zu 99% sowieso auf Anlagen, die akustisch total unzureichend sind (Radios in der Arbeit, im Auto, irgendwelche billigen Kopfhörer und ganz selten mal auf ner hochwertigen Stereoanlage). Dolby Atmons hat kaum einer daheim und selbst wenn gibt es kaum Trägerformate geschweige denn Produktionen, die ein Vielkanalton überhaupt erlauben. Entsprechend ist auch gar kein Bedarf dar, dass der Hall so realistisch ist, wie im aufgenommenen Objekt selbst.
Martin S. schrieb: > Dolby Atmons hat kaum einer daheim Hey, doch ich! Auf dem Tablet. Aber ich habe mich schon gewundert wozu, weil die max. 4 mm dicken Lautprecher keinen vernünftigen Sound ausgeben können...
Martin S. schrieb: > Ja aber das ist doch auch vollkommen egal. Nee, das ist nicht egal. Ein n-fach 2-dimensionales Abbild ist etwas anderes, als ein 3D-Abbild (2D + Zeit). Wenn man sich die Reflektionen eines 3D-Raums ansieht und dann in Betracht zieht, wie diese im 2D-Stereosystem abgebildet werden, ist dies mit einem weiteren Prozessieren eines 2D-Datenstroms nicht mehr zu kontrollieren. Qualitativ nicht und quantitativ nicht. Ich bin bei Dir, dass man Hall am Ende nach Gefühl einstellen muss und hatte das weiter vorne ja bereits ausgeführt. Ein 3D-Reflexionsbild auf einem möglichst trockenen Signal bietet die Möglichkeit, viel mehr zu verdichten, als das bei einem 2D-Hall der Fall ist, d.h. mit zunehmenden Reflexionen wird die Räumlichkeit größer, statt kleiner. Das ist den meisten nur so nicht bewusst, weil es es nicht erleben, da sie nur mit bereits verhalltem Material weiterverhallen und/oder 2D arbeiten. Mit einem echten Surroundprozessor und passend aufgenommenen oder erzeugten Signalen geht da schon etwas mehr. Und es bleibt auch mehr von über, wenn man auf 2D zurück geht - auch bei schlechten Lautsprechern - Gerade bei denen!
finde erstmal solltest du feststellen was du brauchst und dann kannst du an die Technik gehen. Ich würde mir irgendein Program ala Goldwave holen da, kann du z.B. die Echozeit und die Wiederholungen eingeben und das dann immer wieder über deine Originalaufnahme probieren. Z.B. erst ein kurzes Echo im 2-3 stelligen mSek Bereich damit es etwas fülliger wird und dann kannst du ein längeres Echo drüber legen. Also erstmal versuchen was gut klinkt und dann mit dem Wissen wie man das gemacht hat sich an die Arbeit zu machen es mit einem DSP/FPGA... nachzustellen.
Was ich möchte, ist mir schon bewusst :-) Das Ausprobieren mit Programmen wie Goldwave habe Ich auch schon hinter mir. Das ist auch zu langwierig, bis ich damit die Echos zusammen habe. Wie deren Hall arbeitet weiß ich ja nicht und den möchte ich auch nicht benutzen. Ich wollte nur etwas wissen zur der Funktion selbst und wie ich es in meine Schaltung reinbekomme. Hier hat das das Thema schon ein mal gegeben: Beitrag "Echo und Hall Schaltung"
Markus Privat schrieb: > Ich wollte nur etwas wissen zur der Funktion selbst und wie ich es in > meine Schaltung reinbekomme. Du wirst kaum einen FPGA finden, der das Gehäuse eines Chips hat. Wenn dann müsste eine Adapterplatine her, die einen FPGA hat und auf DIL übersetzt. Für kleine Anwendungen gab es so etwas mal z.B. von Trenz - aber da passt nicht viel rein. Also täte es wohl irgendein Bastel-PCB mit FPGA und flexiblen Leitungen. Zu der Frage, wie man Hall erzeugt, ist eigentlich genug gesagt worden. Diejenigen, die sich damit näher befassen, haben mit der Zeit ihre Tricks entwickelt, aus den gegebenen Mitteln das Maximale herauszuholen und die werden sie kaum offen posten. Um Echos richtig zu erzeugen und verarbeiten, muss man sich auch ein wenig in das Thema Tontechnik und Wahrnehmung von Schall durch das Ohr hineinlesen, um zu verstehen, wie man Reflektionen zumischen muss, damit sie richtig wirken. Dazu wurde weiter oben aber schon genug geschrieben. Da heißt es eben auch reinarbeiten und lernen. Ich habe auch einige Hallgeneratoren gebaut und die ersten waren nicht so berauschend, inzwischen habe Ich (vor allem wegen der Möglichkeiten in FPGAs) ein bisschen was zusammen, was recht ansehnlich klingt, wenn man es richtig anpasst und einstellt: http://pyratone.de/snd/pyraechoreverb.mp3 > Hier hat das das Thema schon ein mal gegeben: > Beitrag "Echo und Hall Schaltung" Habe etwas dort geschrieben.
Markus Privat schrieb: > Was ich möchte, ist mir schon bewusst :-) Das Ausprobieren mit > Programmen wie Goldwave C-sound ware noch zu nennen,!
Jürgen S. schrieb: > Um Echos richtig zu erzeugen und verarbeiten, muss man sich auch ein > wenig in das Thema Tontechnik und Wahrnehmung von Schall durch das Ohr > hineinlesen, um zu verstehen, wie man Reflektionen zumischen muss, damit > sie richtig wirken. Hättest du zufällig links zu Literatur? Martin S. schrieb: > Hinterher läuft das zu 99% sowieso auf Anlagen, die akustisch total > unzureichend sind (Radios in der Arbeit, im Auto, irgendwelche billigen > Kopfhörer und ganz selten mal auf ner hochwertigen Stereoanlage Die Denkweise halte ich nicht für schlüssig. Schlechte Lautsprecher machen alles schlechter, ja - aber darf dann der Hall schlecht sein? Das kann man nicht heranziehen, finde ich. Es gibt schon auch Nuter mit Musikgeschmack und guten Anlagen. @TE: Ist bei deinem Projekt nun etwas herausgekommen?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.