mikrocontroller.net

Forum: FPGA, VHDL & Co. Reverb Chip bauen


Autor: Markus privat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Johannes M. (johannesm)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Superschlumpf (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
> 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...

Autor: Markus privat (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: Sicherator (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch hier gibt es kostenlose Angebote im Web, z.B.
http://www.openairlib.net/auralizationdb

Suchbegriff "free reverb impulse responses"

Autor: Superschlumpf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 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'.

Autor: Udo K. (udok)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Superschlumpf:  Und was nimmt man heute?

Autor: Superschlumpf (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
> 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?"

Autor: Mark S. (voltwide)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes M. (johannesm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist zwar auch nicht FPGA basiert aber vielleicht auch interessant für 
den ein oder anderen:
http://www.analog.com/en/design-center/processors-...
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.

Autor: Superschlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du brauchst auf jeden Fall eine Referenz

Er koennte sich an "Fusion Field" orientieren.
Da gibt es auch en Evaluierungsversion.

Autor: Markus privat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Mark S. (voltwide)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: udok (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Markus privat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ein kleines Echo-Experiment mit Octave.
Hier das Originalfile:
https://www.mikrocontroller.net/attachment/344110/...
Hier das FPGA-Echo von Jürgen:
https://www.mikrocontroller.net/attachment/344220/...
[wsig,fs]=wavread("TwoTone8StepADSR2.wav");

d_ms=700;

osig=zeros(1,length(wsig));

dline=zeros(1,round(fs/1000*d_ms));

ip=1;
for n=1:length(wsig),
  osig(n)=wsig(n)+dline(ip)*0.5;
  dline(ip)=wsig(n);
  ip=ip+1;
  if ip>length(dline),
    ip=1;
  end  
end

sound(osig,fs);

Es braucht tatsächlich einige Sekunden um alle Indeces zu durchlaufen.

Autor: Udo K. (udok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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');

: Bearbeitet durch User
Autor: Udo K. (udok)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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');

: Bearbeitet durch User
Autor: Udo K. (udok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo K. (udok)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

: Bearbeitet durch User
Autor: Udo K. (udok)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:

Autor: init 2 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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...

Autor: Superschlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Udo K. (udok)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Udo K. (udok)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Nils P. (torus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.htm...

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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein Beispiel mit schnell ansteigenden Reflektionen aus 32 RAMs. Kann man 
dann passend verlagern und shapen.

Autor: Markus privat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin S. (sirnails)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Privat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.