Roland ACB Modelling / Modelling allgemein - Pro&Contra

[Martman]

Na ja, beim ACB wird nicht einfach nur das theoretische Verhalten der Schaltung im Idealfall simuliert, sondern das tatsächliche Verhalten realer Schaltungselemente. Da wird also sehr detailliert nachgeahmt, wie sich sozusagen ein echtes Stück Silizium verhält. Jeder Kondensator, jeder Transistor, jedes Poti etc. wird dafür analysiert. Die sind weit vom Idealfall entfernt. Und genau dieses Vom-Idealfall-Entfernte ist, was den Charakter eines Analogsynthesizers ausmacht.

Was natürlich nur schwerlich emulierbar sein dürfte, ist die Serienstreuung. Die Roland TB-303 wurde ja gefühlt zusammengelötet aus den Teilen, die für den Bau des Jupiter-8 nicht gut genug bzw. "auf Linie genug" waren. Deswegen ist das "Seriennummer n klingt anders als Seriennummer n + 1"-Phänomen gerade bei der 303 weit verbreitet.

Allerdings hat auch ACB seine Grenzen. Was nämlich auch mit zum Charakter eines Analogsynthesizers beiträgt, sind die Wege zwischen den Komponenten. Manchmal ist es die Laufzeit, so minimal sie auch sein mag, die Einfluß hat. Manchmal sind es Eigenwiderstände elektrischer Leiter. Oder von irgendwoher streut etwas ein (was eine ACB-artige Emulation des ARP 2500 sehr schwierig erscheinen läßt).


Martman

 

[engineer]

Das bestreite ich ja genau, dass die Schaltungen genau nachsimuliert werden. "Wie sich ein echtes Stück Silizium verhält" erfordert z.B. Simulationstechnik in der Größenordnung von ASIC-Prototyping-Plattformen und die liegen im 5-6-stelligen Euro-Bereich, können aber trotzdem gerade mal eine einzige Ausgangstreiberschaltung eines Chips im Detail simulieren und das auch nicht vollständig 3-dimensional. Vor allem geht es nicht in Echtzeit, dass man damit im Audiotempo Daten bekäme.
Selbst wenn man die stark vereinfachten Modelle von pSpice nimmt, reicht eine solche Prototypingplattform mit 16 FPGAs der Virtex6-Klasse gerade mal, um für einen kompletten 1-Transistor-Verstärker das Ersatzschaltbild 50x die Sekunde auf 0,1% genau zu berechnen. Das reicht nicht mal für Bässe. Schneller geht nur, wenn man ungenauer rechnet und weniger Iterationen betreibt oder das Modell vereinfacht. Ich hatte das ja schon mal aufbereitet und gelinkt: Ein angenommener monophoner Synthesizer mit gut 400 Bauelementen kann damit gerade 2x die Sekunde auf ca 1% Genauigkeit durchgerechnet werden, wenn man die linearen Modelle nimmt. Die Plattform hat eine Performance im Loop von etwa 2-4 PCs und im pipelining-Betrieb von 12-24 PCs. Für einen polyphonen Synthesizer mit 8 Stimmen bräuchte man rechnerisch etwa 200 solcher Plattformen, um die Performance zu haben, 48kHz durchzurechnen, was aber praktisch nicht geht, weil es mit dem Loop nicht passt. Man kriegt einfach die Menge an Rechnungen nicht in einem Sample durch.

 

[synthos]

Hmm, aber in der Praxis funktioniert ACB doch gut!? Bestimmt hat auch schon jemand die Boutique-Geräte aufgeschraubt, so dass man sehen kann, was da an Prozessoren drinsteckt.

Grüsse,
synthos

 

[Martman]

Möglicherweise wird das in Richtung Convolution gehen, also ähnlich wie Faltungshall. Man schickt ein Signal rein und analysiert das Signal, das rauskommt. Das wiederholt man mit unterschiedlichen Signalen. Nur statt einer Kathedrale, einer Hallspirale oder einem Roland Space Echo nimmt man die einzelnen Bausteine einer Roland TB-303. Die analysierten Ergebnisse müssen dann nur noch bei der Klangsynthese wiedergegeben werden.

Wie das jetzt ganz genau funktioniert, werden wir wohl nie erfahren. Roland ist sehr gut in Geheimniskrämerei; nach gut drei Jahrzehnten wissen wir immer noch nicht, wie die Structured Adaptive-Synthese des MKS-20 funktioniert, zumal es keinen voll editierbaren SA-Synth gibt.


Martman

 

[engineer]

Faltung ist noch aufwändiger, bei gleichem Ergebnis und wird eigentlich nur angewendet, wenn es anders nicht geht. Das Rechnen im Frequenzbereich hat auch so seine Tücken, gerade bei Audio. Das sieht man ja an der Unmöglichkeit, Stimmen wirklich exakt in der Höhe zu verschieben, ohne sich Artefakte einzuhandeln.

Nein, Ich bin sicher, die verwenden entsprechende Näherungsgleichungen und zwar solche, die analytisch lösbar sind. Man steckt also einen Strom rein und bekommt die Spannung. Damit fallen die Iterationen zur Lösung numerischer Gleichungen weg und man spendiert soviel oversampling, dass die Fehler klein werden. Damit lassen sich aber solche Details wie Nichtmonotonie und Hysterese nicht richtig modellieren. Analoge Sättigung und Ferromagnetismus sind dann schon mal aus dem Spiel und müssen zurechtgebastelt werden.

Der Punkt ist wohl auch der, dass - je echter man die Systeme modelliert - desto mehr Unschönheiten kommen rein in den Klang, die eigentlich schlecht sind, weil unkontrolliert. Ein linearer Transistor, der an einer Stelle im Audiopfad sitzt, wo er einfach nur verstärken soll, hat eben erst gar nicht die Schmutzeffekte, die man per aufwändiger Umbeschaltung korrigieren müsste. Also läasst man seine Dreckeffekte und kurzerhand die Korrekturschaltung weg und hat eine perfekte Stufe. (Mache ich bei mir auch so )

 

[Moogman]

Hmm, aber in der Praxis funktioniert ACB doch gut!? Bestimmt hat auch schon jemand die Boutique-Geräte aufgeschraubt, so dass man sehen kann, was da an Prozessoren drinsteckt.

Grüsse,
synthos

Mir ist das eigentlich ziemlich egal, welche Technologie in einem Synthesizer steckt, wichtig ist doch nur, das es so klingt, wie ich das erwarte. Und wenn der analoge Sound aus einem Prozessor perfekt emuliert wird, ist das absolut okay.
Bin mit dem Roland 1m als Ersatz für das System 100 recht glücklich.
Ist zwar nicht zu 100% perfekt, aber sehr sehr nahe dran und der gewonnene Platz ist mir auch sehr wichtig.
Am Ende kümmert es den Musikhörer doch kein bisschen, was womit produziert wurde, das muss einfach nur gefallen.

 

[.Jens]

Ein angenommener monophoner Synthesizer mit gut 400 Bauelementen kann damit gerade 2x die Sekunde auf ca 1% Genauigkeit durchgerechnet werden, wenn man die linearen Modelle nimmt.

Wenn man die linearen Modelle nimmt, wäre man aber schlecht beraten, wenn man die alle stumpf einzeln rechnet. Da wird man schlauerweise versuchen, soviele Gleichungen wie möglich (blockweise, global macht das meist keinen Sinn) schonmal analytisch zusammenzufassen. Das geht letztlich auch bei nichtlinearen Gleichungen - man kocht die Gleichungen analytisch soweit runter wie es geht, macht vielleicht noch eine Entwicklung um den Arbeitspunkt und schmeißt Terme höherer Ordnung weg, sobald die Koeffizienten klein genug werden, um auch für die nichtlinearen Effekte, die man noch modellieren möchte, nicht mehr relevant zu sein. Quadratische oder kubische Terme nimmt man vielleicht noch mit, ab 4. Ordnung dann nicht mehr (zum Beispiel).

Hmm, aber in der Praxis funktioniert ACB doch gut!? Bestimmt hat auch schon jemand die Boutique-Geräte aufgeschraubt, so dass man sehen kann, was da an Prozessoren drinsteckt.

In der Praxis wird man in Echtzeitsimulationen (egal ob Wetter, Verkehr, Audio oder sonstwas) kaum die rohen "first principles"-Gleichungen lösen. Das heißt übrigens im Umkehrschluss nicht, dass man statt dessen Näherungen oder grobe Vereinfachungen nutzen muss. Es gibt auch - neben der schon erwähnten analytischen Modellreduktion - Techniken wie "surrogate modeling" (manchmal als Metamodelling bezeichnet), Submodeling, multidimensional mapping etc.
Das bedeutet, ich muss z.B. für 30 baugleiche Transistoren, die an verschiedenen Stellen der Schaltung sitzen, nicht 30-mal den vollen Satz Gleichungen lösen, sondern mache das einmal für ein sinnvolles Parameterfeld und bilde das Ergebnis entweder in Form einer Lookup-Table oder einer interpolierten Mehrdimensionalen Funktion ab oder bilde das Ergebnis in dieser Umgebung durch einen niederdimensionalen Satz Differentialgleichungen ab, ...
Das sind die "einfachen" Methoden (im Sinne von einfacher zu verstehen). Es gibt noch eine ganze Reihe weiterer Mittel, die sich unter dem Begriff "Model order reduction" (MOR) zusammenfassen lassen: https://en.wikipedia.org/wiki/Model_order_reduction

 

[engineer]

Die Methoden zur Vereinfachung sind mir ja bekannt, man kann die Gleichungen differenziell leicht untersuchen und ausrechnen, wie gross Fehler sind und wo man gut Tabellen einsetzen kann, wie dicht dort die Punkte sein müssen, etc. Das ist aber bei der Betrachung der Aufwände, die ich anführe, schon berücksichtigt. Parametrische Tabellen speziell sind sehr schnell am Anschlag wenn es um mehr als 4-5 Parameter geht.

 

[synthos]

Jetzt kommt auch noch der Physiker Vielleicht sollten wir mal zu dritt ein Modeling-Projekt auf die Beine stellen, wenn wir schon die Expertise aus dem Ingenieurwesen, der Physik und der angewandten Mathematik hier vereint haben

Grüsse,
synthos

 

[engineer]

Physiker? Volle Deckung! Das riecht nach komplizierten zu breit gefassten Ansätzen, umständlichen Vorgehensweisen und unbezahlbaren Lösungen.

Nein, im Ernst, runter auf die Physikebene kriegt man Schaltungen nicht berechnet. Nicht mit der benötigten Genauigkeit und nicht mit den benötigten Abtastraten. Die Kunst liegt wahrscheinlich im geschickten Vereinfachen. Wahrscheinlich muss man ACB genau so sehen.

Aus einem anderen Kontext des Gewinnens von Kunden und der Art der Werbung für bestehende Produkte unter Hinweis auf scheinbar neu Technologien, könnte man ACB im Übrigen auch mit " advanced customer baiting " übersetzen.

 

[.Jens]

Nein, im Ernst, runter auf die Physikebene kriegt man Schaltungen nicht berechnet.

Na, aber klar doch. Nur nicht jeden Teil in Echtzeit. Die Kunst ist jetzt, mit einer Mischung aus Wissen, Mathematik, Analytik und geschickt gewählten numerischen Verfahren nur genau DIE Teile der Physik zu berechnen, die für die Reproduktion eines bestimmten Verhaltens der Komponente auch wirklich entscheidend sind. Glaubst du wirklich, dass für die Wettervorhersage die vollen Navier-Stokesgleichungen inklusive der Zustandsgleichung für Wasser(dampf/eis) auf dem gesamten Globus bis rauf zur Stratosphäre in zuckerwürfelgroßen Netzzellen gerechnet wird? Das müsste man eigentlich tun - trotzdem klappt es auch anders ganz passabel.

Manche Transistoren in einer (mglw. sogar derselben!) simulierten Schaltung kann man als schlichte Schalter modellieren, manche als (stückweise) lineare Verstärker, für manche muss man eine Kennlinie a la I(U) ansetzen, für wieder andere muss man vielleicht noch eine DGL für die Ladungsträgerdynamik mitlösen - aber die dann sicher auch nur in "0D", nicht in einem 3D-Modell des ganzen Transistors. Das gleiche gilt dann für Leiterbahnen, C's, R's etc.
Das hat mit "Veräppelung der Kunden" nichts zu tun - denn physikalisch motiviert gerechnet und modelliert wird ja.
Die Kunst ist eben, die sinnvoll einsetzbaren Ressourcen an Rechenleistung und die gewünschte Genauigkeit bzw. die darstellbaren Effekte so gegeneinander abzuwägen, dass das Ergebnis passt. Analogie aus dem PC-Spielebereich: Das, was da an "Raytracing" und "Physik" gerechnet wird (Grafik, Kollision von Objekten, Bewegung von Haaren, Wasseroberflächen etc.) ist physikalisch stark vereinfacht - aber eben an den richtigen Stellen. Dadurch wird es echtzeitfähig. Für wissenschaftliche Berechnungen sind die Algorithmen aus der Computergrafik (meist) nicht zu gebrauchen. Aber sie liefern dennoch sehr realistische Bilder mit um Größenordnungen reduziertem numerischen Aufwand.



Wollte man dieses Ergebnis mit den "richtigen" physikalischen Gleichungen (für Kenner: selbst wenn man sich auf inkompressible RANS-Gleichungen beschränkt) und Standard-Methoden wissenschaftlicher Numerik erreichen, sollte man mal beim CERN anfragen, ob man ein paar Monate Rechenzeit auf dem Cluster bekommt... Quasi unlösbar auf diese Weise. Mit dem Ansatz aus dem Video (SPH; smoothed particle hydrodynamics) kann das jeder mit einem flotten Gaming-PC zuhause machen...

 

[engineer]

Das ist alles richtig, das Problem beim Modellieren ist das Tempo: Eine Animation braucht nur 20-30fps und nur 3 Kanäle begrenzter Dynamik (ca 100-200 Stufen). Es wird als recht gut beurteilt, weil man es nicht so erwartet und man optisch nur schlecht die Geschwindigkeit und Farbtiefe auflösen kann.

Beim Audio ist das ein völlig anderes Kaliber: Abtastrate 100x höher, Dynamik mindestens Faktor 10x und dank täglichem Einhören einen gewissen Anspruch. Da wird es sehr schnell sehr eng mit der Rechenleistung. Die Modellpräzision und zeitliche Repräsentation muss um 3-4 Größenordnungen besser sein.

Solche Animationen sind - wenn sie halbwegs realistisch sein sollen - auch nicht in Echtzeit zu machen. An dem bischen Wasser rechnet der Render eine Weile herum und das für wenige Sekunden.

Du kannst mir aber gerne mal einen Vorschlag machen, was Du tontechnisch virtuell abgebildet sehen würdest. Hätte einige realitätsnahe Resonatoren im Angebot. Momentan probiere ich mich an der Glasharfe. Triggermodell, Reibungsmodell und Glasmodell sind schon fertig. Es fehlt noch das Wasser

 

[.Jens]

Die Vergleiche passen nicht, lieber engineer. "nur 20-30fps" und 3 Kanäle mit 8 Bit... Dir ist klar, dass Videodaten bei gleicher Laufzeit immer deutlich größer sind als Audiodaten, denke ich. Denk nochmal nach, warum das so ist. Die Abtastrate mag bei Audio 100x höher sein, dafür hat es da nur 2-6 Kanäle üblicherweise, während beim Bild die "Kanäle" jedes einzelne Pixel sind - deren Zahl hast du nämlich unterschlagen. Dann bist du nämlich bei Video bei 30 fps x (fullHD = 1920x1080 pixel) x 24Bit = 1.46 GBit/s, bei Audio gerade mal selbst bei 5.1 = 6 Kanäle x 48kHz x 24Bit (z.B.) bei 6.9 MBit/s.

Also 3-4 Größenordnungen stimmt, aber die braucht man MEHR für VIDEO als für Audio...

Auf den Unterschied zwischen Audio und Video wollte ich allerdings auch gar nicht hinaus, sondern auf die Bewegung des Wassers in dem Video. Das "bisschen Wasser" ist - sobald die Physik fertig gerechnet ist - für den Renderer in der Tat kein Problem. Das aber in "physikalisch korrekt" zu rechnen, insbsondere mit den freien Oberflächen und Spritzern (Topologiewechsel, numerisch gar nicht schön!) dauert auf großen Rechenclustern Tage bis Wochen für so eine Sequenz. Mit den richtigen Vereinfachungen geht das auf einem Haushalts-PC in Minuten bis Stunden.
Die Kernaussage ist: mit den richtigen Vereinfachungen, die man eben dem Ergebnis nicht ansieht/hört (darum geht es ja auch bei der Modeling-Synthese) kann man sehr wohl Dinge, die auf den ersten Blick nicht in Echtzeit rechenbar sind, durchaus auf eine Echtzeitfähigkeit trimmen. Dazu braucht es aber nicht nur Kochrezepte aus den Lehrbüchern für Physik und Ingenieurwissenschaften und die "Numerical Recipes" aus den 70ern, sondern moderne Algorithmen, etwas Hirnschmalz und viel Erfahrung in der Numerik.

Ein gutes Beispiel, dass recht umfangreiches Component Modeling durchaus in Echtzeit machbar ist, ist die HX3. Da werden etliche Baugruppen und Bauteile tatsächlich gerechnet.


PS: Auch diese Fluid-Simulation läuft in Echtzeit auf einer (inzwischen technisch völlig veralteten) Grafikkarte - das Video ist 5 Jahre alt:

 

[engineer]

Bei dem Vergleich Video <-> Audio musst Du das in Anschlag bringen, was das Hirn wahrnehmen kann und das ist das Gehör erheblich präziser. für ein Bild in HDMI muss man in der Tat GBits berechnen, die werden aber so nicht aufgenommen. Die Bandbreite des Sehnervs hat nicht einmal 10Mbit. Wahrgenommen werden auch kein 16Mio Farben, wie das gerne behauptet wird, sondern je nach Aussteuerung einige 100 Farbabstufungen. Die Monitore machen auch kaum mehr. Von dem in Echtzeit in 1080p auf den Monitor gebrachten Bild wird nicht einmal 1% aufgenommen. Es ist daher vergleichsweise einfach, ein 3D-Objektmodell zu rechnen und mit einfachen Shadern mit halbwegs realistischen Schatten und Farben auszumalen, denn das ist, was in Grafikkarten passiert. Bei dem Thema lassen sich Viele täuschen. Ich weiß warum ich den Vergleich mit Video infragegestellt habe.

Konkret bei der o.g. Simulation ist der Informationsgehalt des Bildes relativ gering. Da wird einfach nur ein Eindruck erzeugt, nämlich der von Wasser. Das Meiste im Bild ist zudem statisch. Schon eine Kamerabewegung wäre nicht mehr abbildbar. Und selbst das Wasser ist keine tatsächliche Simulation mit Brechung des Lichtes und Absorbtion. Da stimmt so ziemlich nichts und wenn man mal kritsch hinschaut, ist das fließendes Plastik. Entsprechende Darstellungen mit dem Anspruch auf Realität werden in zahlreichen Filmen realisiert und da geht nichts in Echtzeit. Auch Simulation von optischen Effekten, damit sie halbwegs stimmen, laufen in Zeitlupe ab. Ein Programm, das z.B: einer meiner Kunden der Optikindustrie benutzt, um Linsen zu entwickeln, rechnet ein einziges Bild durch eine einzige Linse in 3-4 Minuten, damit es ein 1280x1024 Bild füllt und eine Aussage über Aberation und Farbtreue machen kann. Bei Wasser wäre sowas quasi für jeden einzelnen Tropfen zu machen. Alles was du abseits davon vereinfachst, geht weg von der Realität und man landet schnell bei etwas völlig anderem.

Zum Thema HX3 ist an anderer Stelle schon viel geschrieben worden. Dort wird auch nicht die Mechanik nachgebildet, sondern das elektrische Equivalent derselben, nämlich den Anspruch eine periodische Schwingung zu erzeugen. Ein tatsächliches Modell einer Mechanik sieht ein wenig anders aus: Da gibt es Schwingungen im Metall, Schall im Metall, Gehäuse- und Lagerschwingungen, Resonanzen, Resonanzreibung, nichtlineare Reibung, Lagerspiel (besonders nett!) und Ökompression. Auch dafür habe Ich Modelle entwickelt und gesehen, dass selbst kleine Abweichungen zu total anderen Ergebnissen führen. Natürlich kann man alles irgendwie nachbilden, indem man Grund- und Oberwellen bildet und sie shaped und einige wesentliche Einflüsse modelliert. Der Punkt ist aber der, dass man das Ergebnis kennen und das Modell in einem Optimierungsprozess iterativ hinbiegen muss, damit das Ergebnis echt wirkt. Bei einem physisch korrekten Modell ist das nicht der Fall. Der Getriebeklang ist ungeachtet der Einstellung immer der, der sich auch real abbildet. Für einen ähnlich klingenden, den ein Hörender nicht vom Original unterscheiden kann, bräuchte man wiederum kein Modell, sondern einfach ein bischen Tongenration und EQs. Der Unterschied zwischen den beiden Lösungen sind Faktor 180.000 im Rechenaufwand und 4 Monate Arbeit.

 

[Duplobaustein]

Der Punkt ist aber der, dass man das Ergebnis kennen und das Modell in einem Optimierungsprozess iterativ hinbiegen muss, damit das Ergebnis echt wirkt.

Darauf läufts hinaus. Hat ja jens auch schon so geschrieben.

Der Vergleich Video / Audio mit der Bandbreite hinkt ein wenig. Die Bandbreite des Audiosignals sagt ja nichts darüber aus, was im Hintergrund berechnet wird. Die ist ja die selbe bei einem schnöden Sample wie bei einem aufwändigen Model wie Diva oder der HX3. Im Endeffekt sind das alles physikalische Modelle und da könnte ein sehr umfangreiches Audio Modelling wohl auch ähnlich aufwändig sein wie ein Becken Wasser. Ist schon vorstellbar.

 

[.Jens]

Nur mal so am Rande, engineer, damit wir nicht aneinander vorbei reden: Ich mache seit über 10 Jahren hauptberuflich fast nichts anderes als Simulationen. Ich habe da also auch eine gewisse Erfahrung.

Du willst mich glaube ich an einigen Punkten bewusst missverstehen. Wenn ein Kunde für eine Kamera eine Linse ausgelegt haben möchte, ist das eine technische Simulation mit einer klaren Fragestellung, für die hat man Zeit, da investiert man Geld - und erwartet nicht nur schöne Bilder, sondern ein technisch höchst belastbares Ergebnis. Wenn die Linsensimulation dagegen nur den Zweck hat, eine CGI-Szene in einem Kinofilm durch hinzugerechnete Lens Flares oder typische Abbildungsfehler / Schärfentiefe etwas realistischer zu machen (mit einer künstlerischen Intention), dann braucht man dafür keine 7 Nachkommastellen, sondern es reicht, wenn es realistisch aussieht. Letzteres geht in Echtzeit, ersteres nicht.
Genauso bei deinem Getriebe. Bevor der erste Prototyp gebaut wurde und bevor die erste Simulation gelaufen ist, muss man alle in Frage kommenden Effekte mitrechnen und auch wieder (s.o.) in höchstmöglicher Präzision. Und zwar deshalb, weil man eben a priori noch nicht weiß, welche Effekte einen Einfluss haben werden und welche nicht. Sobald die erste Simulation durch ist, kann man dann durch Analyse der Ergebnisse feststellen, welche Teile oder Effekte keinen (signifikanten) Einfluss haben. Erst recht, wenn man dann auch ein reales Objekt hat, das man vermessen kann und mit der Simulation vergleichen kann. Die Fragestellung in einem Entwicklungsprojekt ist eine gänzlich andere als die, das Verhalten eines schon existierenden Objekts in einem bekannten Parameterraum durch Echtzeitsimulationen möglichst realistisch zu reproduzieren. Erst recht, wenn dann nicht die Messtechnik entscheidet, was realistisch ist, sondern das Gehör von Menschen.

Bei den Videos mit dem Wasser geht es mir auch wie gesagt nicht um seine Sehnerv-Bandbreite, sondern dass man schnell einen Faktor 1000-10.000 in der Simulationsgeschwindigkeit erreichen kann (für dasselbe Ergebnis - hier: Bewegung von Wasser), wenn man die richtigen Algorithmen wählt.

Vor allem, und da sind wir wirklich ganz weit auseinander: bei weitem nicht jede Vereinfachung ist automatisch physikalisch falsch. Man weiß nicht unbedingt, ob sie richtig ist, sondern muss das prüfen. Aber den Gültigkeitsbereich von Näherungen kann man in der Regel angeben, und selbst die Verwendung bestimmter Näherungen in Bereichen, die mathematisch gar nicht mehr "erlaubt" sind, ist oft für bestimmte Fragestellungen dennoch völlig ausreichend. *)

So, und vor dem Hintergrund bleibe ich dabei: eine elektrische Schaltung von ein paar hundert Bauteilen lässt sich durchaus in Echtzeit so berechnen, dass die für das Hörergebnis dieser Schaltung relevanten Effekte alle enthalten sind. Und zwar nicht mit Hilfe "geratener" Gleichungen, sondern mit Hilfe physikalisch sauber aufgestellten Modellen, die allerdings dann mit den richtigen Methoden "eingedampft" werden, bis es in Echtzeit geht. Nicht JEDE Schaltung lässt sich (auf heute verfügbarer Hardware) so berechnen, und je nach dem, was da simuliert wird, ist da vielleicht auch in der Qualität noch mehr oder weniger Luft nach oben (bei Hammond-Clones erwarte ich gegenüber der HX3 auch in 20 Jahren z.B. keine wirkliche Verbesserung mehr - bei Leslie-Simulationen dagegen schon. Und bei Analogsynths hoffe ich, dass das, was heute noch einen Quadcore i7 voll auslastet, dann in ein paar Jahren wenigstens auf einem ARM oder einem DSP oder ... läuft, so dass ein VA-Synth mit dieser Technologie dann eben keine 2000€ mehr kosten muss, sondern vielleicht 300€.

Aber es geht. Nur, weil du vielleicht selbst manche selbstgesteckten Ziele nicht erreicht hast, heißt das nicht, dass die Entwickler bei Roland das nicht doch hinbekommen haben.


*) Bei den Wassersimulationen für Grafikeffekte z.B. ist es völlig gleichgültig, ob die Energiebilanz 100% stimmt oder ob die Massenerhaltung gewährleistet ist. Bei einer Simulation eines Staudamms dagegen ist das von entscheidender Wichtigkeit.

 

[Duplobaustein]

So, und vor dem Hintergrund bleibe ich dabei: eine elektrische Schaltung von ein paar hundert Bauteilen lässt sich durchaus in Echtzeit so berechnen, dass die für das Hörergebnis dieser Schaltung relevanten Effekte alle enthalten sind.

Das denke ich auch. Letztlich kommt es dann ja nur auf den Vergleich an und wenn ich mit Näherungen bei 98% bin, knn ich mir die letzten zwei Prozent sparen.

Sollen wir den allgemeinen Teil auslagern, oder den Thread zu einem Modelling Thread machen? Ich bin für Zweiteres.

 

[.Jens]

Ich würde das mal alles so lassen.

 

[engineer]

Darauf läufts hinaus. Hat ja jens auch schon so geschrieben.

Der Vergleich Video / Audio mit der Bandbreite hinkt ein wenig. Die Bandbreite des Audiosignals sagt ja nichts darüber aus, was im Hintergrund berechnet wird.

Eben, deshalb hatte ich ich den Einwurf von Jens auch infrage gestellt. Der scheinbare gewaltige Mehraufwand, den man bei Video gegen Audio hat, ist in diesem Ausmass nicht der Fall, selbst wenn es technisch auf den ersten Blick so aussieht.Daher habe ich auch sauber unterschieden, zwischen der Signalbandbreite und dem was der Mensch wahrnimmt. Bei Video kann man da sehr viel mehr reduzieren, was sich z.B: auch darin äußert, dass Videodatenströme nur etwa 2-3mal größer sind, als Audiodatenströme. Bei Audio haben wir z.B. einen unkomprimierten CD-Datenstrom von 3MBit mit einem Durschnittlichen IG von 1MBit. Beim Video reicht schon das 10fache. Zumindest, wenn es darum geht, das auszusteuern, was Fernseher so darstellen können.

Nur mal so am Rande, engineer, damit wir nicht aneinander vorbei reden: Ich mache seit über 10 Jahren hauptberuflich fast nichts anderes als Simulationen. Ich habe da also auch eine gewisse Erfahrung.

Du willst mich glaube ich an einigen Punkten bewusst missverstehen

Ich mache das sogar seit 25 Jahren beruflich und eben konkret für Audio und Video, offline in MATLAB und in Echtzeit in DSPs und FPGA. Von daher habe ich die Lösungen direkt vor Augen. Und nein, ich möchte Dich nicht absichtlich misverstehen.

Bei den Videos mit dem Wasser geht es mir auch wie gesagt nicht um seine Sehnerv-Bandbreite, sondern dass man schnell einen Faktor 1000-10.000 in der Simulationsgeschwindigkeit erreichen kann (für dasselbe Ergebnis - hier: Bewegung von Wasser), wenn man die richtigen Algorithmen wählt.

Die Kapazität der Menschlichen Wahrnehmung ist aber der eigentlich Grund dafür dass man das kann. Das muss man verstanden haben. Und insbesondere bei Video ist es so, dass hier scharfe Randbedingungen wirken, die die Notwendigkeit der Darstellung und den Rechenbedarf bei Simulationen massiv einschränken. Das sehen wir bei den Hörgeräten, den 3D-Brillen, den Projektoren, Echtzeitvideomanipulationen etc. Natürlich spielen hier auch die technischen Randbedingungen eine Rolle. Mit besseren und größeren Fernsehern würde es mehr Sinn machen, Bandbreiten hochzufahren und die Wahrnehmung besser auszulasten, entsprechend stiege dann der Mehrwaufwand für die Berechnung. Dann reichen 10Bit Auflösung von aktuellen Kameras nicht mehr und auch Simuationen müssten darauf Rücksicht nehmen. Mein RT-Simulatior kommt z.B. mit 24 bit aus, weil er Annahmen über die maximal 60-100 Helligkeitsstufen des Fernsehers macht. Das Auge kann wenigstens 10x mehr.

Lösen wir uns jetzt aber mal vom Video und fragen uns, was der Mensch hören kann und was er erfassen kann. Da ist vor allem wichtig es er an Erfahrung hat. Manche kann man mit klanglichen Nachbildungen einfacher täuschen als andere, weil sie das Original in seinen Feinheiten nicht kennen. Das gilt z.B. auch für das Beispiel HX3. Oftmals werden Dinge weggelassen, weil man es nicht merkt, das was fehlt. Wie möchte man einem Klang anhöhren, dass ihm eine Oberwellenmodulation fehlt, weil Rückwirkungen im Gerät unterschlagen wurden?

Diese Dinge werden sehr genau untersucht, sind auch vielfach publiziert und mithin die Basis für technische Umsetzungen. Und da lässt sich ganz klar sagen, daß Simulationen und auch Bandbreiten von Datentransportstrecken nach wie vor an den Resourcen und auch den Kosten scheitern. Aus physiologischen Gründen müsste man z.B. Audio generell mit 96kHz übertragen und dies auch nicht nur mit 2 Kanälen. Praktisch hat sich aber das Stereosystem durchgesetzt, weil es frühzeitig da war. Weil viele keine Orchesterkonzerte besuchen, fehlt ihnen ein Gefühl für Tiefenstaffelung und sie merken nicht, wie schlecht das Stereosystem das abbildet. Dank Verarmung des Gehörs heutiger Menschen reichen ja Vielen sogar die MP3s, die viel zu sehr einränken. Da ist aber das Internet der Limiter. Man möchte keine großen Datenströme haben. Oder sagen wir, man wollte es in der Vergangenheit nicht.

Video z.B. müsste man mit 100Mit übertragen, dass man alle Bildbereiche des Fernsehers mit ausreichender Helligkeitsstufung versorgen kann und es nicht zu Schattensprügen kommt, wie beim H.265. Das scheitert an den Kosten. Nimmt man das her, was mit modernen TFTs im Labor geht und rechnet ausreichende Bilddiagonalen kommt man rasch auch 500 MBit.

 

[.Jens]

Die Kapazität der Menschlichen Wahrnehmung ist aber der eigentlich Grund dafür dass man das kann.

Nur, wenn du wieder nur konkret an Video denkst. Vergiss mal das Video und denke nur an die Bewegung der Wasseroberfläche. Man kann so ein Fließen von Wasser durch nach oben offene Kanäle (neben vielen anderen, im Detail leicht unterschiedlichen Algorithmen) im Wesentlichen durch zwei wichtige Verfahren lösen: SPH (wie im Video) oder per LS-FVM (Levelset-Finite-Volumen). Das eine ist ein Partikelansatz, das andere ein Kontinuumsansatz. Letzterer ist "exakt", skaliert aber leider sehr schlecht mit der Größe des Berechnungsgebietes, so dass man dann bei begrenzten Ressourcen sehr grob rechnen muss, wodurch die "Exaktheit" der Gleichungen wieder zum Teufel ist, weil man sich Diskretisierungsfehler noch und nöcher einhandelt.
Für einen Ingenieur oder Architekten, der wissen will, ob der Staudamm oder das Fundament eines Hochhauses einem eventuellen Tsunami standhält, bleibt aber keine Wahl, der muss zähneknirschend die Ressourcen bereitstellen, die es dann braucht, um auch feiner zu rechnen. Für diese Fragestellung ist das nicht anders machbar, weil man da Informationen über Tiefenströmungen, Fließgeschwindigkeiten und die resultierenden Staudrücke braucht.
Wenn hingegen der Katastrophenschutz wissen will, wie weit die für übermorgen angekündigte Sturmflut die Stadt überschwemmt (wo also evakuiert werden muss), ist SPH trotz Schwächen an anderer Stelle die richtige Wahl. Erstens wird die LS-FVM-Rechnung so lange brauchen, bis die Strumflut längst vorbei ist, zweitens kann man bei SPH dann eben ein paar Szenarien durchspielen. Für Roland Emmerichs nächsten Streifen ist das erst recht völlig ausreichend.

Dito bei der Simulation von Schaltkreisen. Du erweckst trotz deiner langjährigen Erfahrung hier den Anschein, als gäbe es nur die Stufen "maximale Vereinfachung der Formeln, aber leider physikalisch falsch" und "physikalisch richtig, aber nicht in Echtzeit zu rechnen". Und das sehe ich eben anders. Es gibt ein schönes Zitat von George Box: "ALLE Modelle sind falsch, aber einige sind trotzdem ganz nützlich". Die Kunst besteht darin, zu wissen, was an der Stelle nützlich ist. Mir scheint, du gehst da vielleicht gerade bedingt durch deine Berufserfahrung von einem zu hohen Stand der Modellierung aus, der nötig wäre.

Klar, analog zu dem Beispiel oben muss jemand, der eine Schaltung auslegt, der einen neuen Synthesizer konstruiert und viel mehr wissen muss als "nur", wie es klingt, sicherlich viel aufwändiger rechnen (pSpice und aufwärts). Und DAS geht natürlich nicht in Echtzeit. Du scheinst dich aber irgendwie dagegen zu sträuben, dass man ganz viel davon weglassen kann, wenn man nur reproduzieren will. Und das ist eben NICHT gleich das "supersimple Lehrbuch-Modell" eines idealisierten Filters, sondern siedelt sich irgendwo zwischen dem einfachsten und dem komplexesten Modell an. Um das zu schaffen, braucht es aber auch ein klein wenig Phantasie - rein technisch-regelbasiert kommt man nicht dahin.