Latenzen

G

Gelöschtes Mitglied 10924

Guest
Ich hab Bock auf 'nen Shitstorm… 😂

Inhaltlich ist das Video mäßig gut geeignet, einzelne Sachverhalte technisch korrekt zu lernen resp. nachzuvollziehen.
Die "Einlassungen" bspw. zu den Themen Samplingprozess und Auflösung/Bitrate sind völlig unbrauchbar,
um jemandem verständlich zu erklären, was dabei genau passiert bzw. was die Begriffe bedeuten.
Die Tests der Latenzen sind so wahrscheinlich schon dutzende Male durchgeführt worden.
Also nichts besonderes neues.
Die Ergebnisse waren im Großen und Ganzen ja auch bekannt.
Die Vorgehensweise bei einem solchen Test wurde nur sehr rudimentär erläutert.
Insgesamt dominiert in diesem Video ne Menge typischer "Gitarristensprech", den viele verwenden, den aber nicht alle auch immer in Gänze verstehen.
Vor allem Newbies und Leute, die technisch nicht ganz so versiert sind.

Meine These:
Hätte es dieses Video nicht gegeben, würde hier niemand viele Worte darüber verlieren, was er/sie (vermeintlich) alles so zu hören imstande ist.
Der Thread um dieses Thema erinnert mich ein wenig an die Papst-Wahlen;
Heute sind wir alle mal ein bisschen Thomas… (Blug)

Und wären die Latenzen im Kontext des AxeFx wirklich unangenehm hoch, würde das Gerät, ob mit oder ohne Vorschaltgeräten wie Effekte oder Sender, nicht genutzt.

Also die Jungs sind ja zweifelsohne beide sehr nette Typen.
Thomas kenne ich auch persönlich.
Aber ich denke, beide sind nicht die geborenen Techniker.
Thomas allein würde das auch ggf. etwas anders gestalten.

So, Alaaf und Helau!
Aber ohne mich… 😂🤡
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.927
Was mir neulich mal aufgefallen ist: Wenn Ihr die Latenz von FAS Geräten erhöhen wollt, nutzt Feedback-Send und Feedback-Return Blöcke! :biggrin:

Liegt der Return Block rechts vom Send Block, also so, dass man sie auch direkt mit Shunts verbinden könnte, dann ist das OK, aber sobald der Return Block LINKS vom Send Block liegt, dann erzeugt das ca. 2-3 ms Latenz. Wenn man alle Send/Return Blöcke verwendet, dann schafft man 5-6 ms. Ich muss die Zeiten bei Gelegenheit mal exakt bestimmen, ist aber nicht so schwierig. Man splittet einfach das Stereo-Signal (also links und rechts separat), schickt eine Seite durch geschickt platzierte Send/Return Blöcke, vereint beide Seiten wieder und nimmt das ganze auf. Dann sieht man den Versatz zwischen rechts und links.
Das ist doch ein Bug, oder?! Drüben melden?
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.927
Ich hab Bock auf 'nen Shitstorm… 😂

Inhaltlich ist das Video mäßig gut geeignet, einzelne Sachverhalte technisch korrekt zu lernen resp. nachzuvollziehen.
Die "Einlassungen" bspw. zu den Themen Samplingprozess und Auflösung/Bitrate sind völlig unbrauchbar,
um jemandem verständlich zu erklären, was dabei genau passiert bzw. was die Begriffe bedeuten.
Die Tests der Latenzen sind so wahrscheinlich schon dutzende Male durchgeführt worden.
Also nichts besonderes neues.
Die Ergebnisse waren im Großen und Ganzen ja auch bekannt.
Die Vorgehensweise bei einem solchen Test wurde nur sehr rudimentär erläutert.
Insgesamt dominiert in diesem Video ne Menge typischer "Gitarristensprech", den viele verwenden, den aber nicht alle auch immer in Gänze verstehen.
Vor allem Newbies und Leute, die technisch nicht ganz so versiert sind.

Meine These:
Hätte es dieses Video nicht gegeben, würde hier niemand viele Worte darüber verlieren, was er/sie (vermeintlich) alles so zu hören imstande ist.
Der Thread um dieses Thema erinnert mich ein wenig an die Papst-Wahlen;
Heute sind wir alle mal ein bisschen Thomas… (Blug)

Und wären die Latenzen im Kontext des AxeFx wirklich unangenehm hoch, würde das Gerät, ob mit oder ohne Vorschaltgeräten wie Effekte oder Sender, nicht genutzt.

Also die Jungs sind ja zweifelsohne beide sehr nette Typen.
Thomas kenne ich auch persönlich.
Aber ich denke, beide sind nicht die geborenen Techniker.
Thomas allein würde das auch ggf. etwas anders gestalten.

So, Alaaf und Helau!
Aber ohne mich… 😂🤡
Ich kann dir in Teilen zustimmen.

Als Thomas sagte, dass heute die Ecken so fein sind, dass man das nicht mehr hört, habe ich laut aufschreien müssen "NEIIIIIN!!!" Zum Glück wurde es noch korrigiert, aber das tat schon weh! Das Aliasing (man sollte es so aussprechen, wie man es schreibt!) haben sie aber – nach allem, was ich darüber weiß – richtig erklärt. Letztlich aber unnötigerweise, weil das zum Thema doch nichts beiträgt.

Die Messmethode finde ich aber völlig ok!

Mir geht es auch so, dass ich bei Latenzen mega empfindlich bin. Hab gestern zu Hause mit meinem Axe Ultra aufgenommen und da bemerke ich definitiv nichts. Das Signal geht direkt durch die Soundkarte an die Studiomonitore und ich sitze keinen Meter davon weg. Das ist so direkt, da hab ich keine Chance. Hab zum Glück nie einen schlechten Modeller gespielt, aber für mich funktionieren für zu Hause leider keine Amp-Simulationen am Rechner, weil ich da die Latenz nicht klein genug bekomme, um noch spielen zu können. Egal, hat das Ultra auch noch eine Aufgabe und Anwendung für mich :thumpsup: Und ich find das Ding nach wie vor vom Sound her echt gut!
 

Joachim

Active member
Mitglied seit
Mrz 14, 2013
Beiträge
600
Das ist doch ein Bug, oder?! Drüben melden?
Ich denke nicht, dass es ein Bug im klassischen Sinne ist. Denke, es liegt irgendwie daran, dass das Grid von links nach rechts abgearbeitet wird und wenn die Software "plötzlich" durch ein Send/Return wieder zum Anfang springen muss, dann dauert's halt länger... könnte mir aber vorstellen, dass das irgendwie zu lösen sein wird.

Ich gucke erstmal, ob es drüben Beiträge gibt, die dazu passen und werde mal den Support anschreiben. Im Forum will ich es nicht posten, zumindest erstmal nicht, da ich keine Lust auf die ganzen Kommentare habe, dass es ein Bedienfehler wäre, warum ich sowas überhaupt mache, ob das Kabel mal getauscht wurde, u.ä. :biggrin:
 
G

Gelöschtes Mitglied 10924

Guest
Ich kann dir in Teilen zustimmen.

Als Thomas sagte, dass heute die Ecken so fein sind, dass man das nicht mehr hört, habe ich laut aufschreien müssen "NEIIIIIN!!!" Zum Glück wurde es noch korrigiert, aber das tat schon weh! Das Aliasing (man sollte es so aussprechen, wie man es schreibt!) haben sie aber – nach allem, was ich darüber weiß – richtig erklärt. Letztlich aber unnötigerweise, weil das zum Thema doch nichts beiträgt.

Die Messmethode finde ich aber völlig ok!

Mir geht es auch so, dass ich bei Latenzen mega empfindlich bin. Hab gestern zu Hause mit meinem Axe Ultra aufgenommen und da bemerke ich definitiv nichts. Das Signal geht direkt durch die Soundkarte an die Studiomonitore und ich sitze keinen Meter davon weg. Das ist so direkt, da hab ich keine Chance. Hab zum Glück nie einen schlechten Modeller gespielt, aber für mich funktionieren für zu Hause leider keine Amp-Simulationen am Rechner, weil ich da die Latenz nicht klein genug bekomme, um noch spielen zu können. Egal, hat das Ultra auch noch eine Aufgabe und Anwendung für mich :thumpsup: Und ich find das Ding nach wie vor vom Sound her echt gut!
Habe auch noch eins.
Wollte das immer mal verkaufen, aber irgendwie nie aufraffen können.
Müsste es mal wieder anwerfen um zu sehen, ob die Pufferbatterie eigentlich noch ihren Dienst tut.
 
G

Gelöschtes Mitglied 10924

Guest
Ich denke nicht, dass es ein Bug im klassischen Sinne ist. Denke, es liegt irgendwie daran, dass das Grid von links nach rechts abgearbeitet wird und wenn die Software "plötzlich" durch ein Send/Return wieder zum Anfang springen muss, dann dauert's halt länger... könnte mir aber vorstellen, dass das irgendwie zu lösen sein wird.

Ich gucke erstmal, ob es drüben Beiträge gibt, die dazu passen und werde mal den Support anschreiben. Im Forum will ich es nicht posten, zumindest erstmal nicht, da ich keine Lust auf die ganzen Kommentare habe, dass es ein Bedienfehler wäre, warum ich sowas überhaupt mache, ob das Kabel mal getauscht wurde, u.ä. :biggrin:
Das ist eher seltsam und sollte nicht sein.
Die Abarbeitung des Modelingprozesses ist ja nicht ein Spiegelbild der räumlichen Anordnung der Blöcke
im Sinne der absoluten Position im Grid.
Die Reihenfolge, welches Ausgangssignal an einen nächsten Block übergeben wird ist bspw. entscheidend.
Also die Reihenfolge der Verkettung.
Send/Return verlängern ja nur die Verarbeitungskette.
Ob diese Blöcke im Grid nach vorne oder hinten verrutschen darf dabei keine Rolle spielen.
Vorausgesetzt, Deine Wahrnehmung beruht tatsächlich auf der Positionierung.
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.927
Wollte das immer mal verkaufen, aber irgendwie nie aufraffen können.
Ich glaube ehrlich, dass du das nicht mehr los bekommst. Und wenn, dann für so wenig, dass sich das eigentlich auch nicht lohnt.
Wenn ich meins nicht noch nutzen würde, würde ich es wahrscheinlich jemandem hier verschenken, z. B. der Band-AG meiner alten Schule.
 

Comanche

Member
Mitglied seit
Mrz 2, 2023
Beiträge
53
Send/Return verlängern ja nur die Verarbeitungskette.
Wobei "Nur" auch relativ ist. Alleine eine lange Signalkette mit vielen leeren Shunts kostet Prozessorleistung und trägt somit auch zur Latenz bei. Wenn man latenz-empfindlich ist, dann sollte man die Signalkette so kurz wie möglich halten – ist zumindest meine amateurhafte Meinung. Ich hab' schon viele Grid-Layouts gesehen, bei denen verschwenderisch mit Shunts umgegangen wurde, dann aber aus "Platzmangel" Send und Returns eingebaut waren.

Ich bin auch kein Programmierer, kann mir aber gut vorstellen dass es einen Unterschied macht, wenn das Grid durch einen links platzierten Return neu gescannt werden muss.
 
G

Gelöschtes Mitglied 10924

Guest
Ich glaube ehrlich, dass du das nicht mehr los bekommst. Und wenn, dann für so wenig, dass sich das eigentlich auch nicht lohnt.
Wenn ich meins nicht noch nutzen würde, würde ich es wahrscheinlich jemandem hier verschenken, z. B. der Band-AG meiner alten Schule.
Ach, ich denke, das ließe sich schon noch verkaufen.
Natürlich nicht mehr für einen hohen Preis.
Aber mit der letzten Firmware damals klang das Teil nun wirklich nicht schlecht und musste den Vergleich mit Line6 Bohnen keinesfalls fürchten.
Aber ich denke, ich werde es behalten.
Mal wieder anspielen… Wer weiß, vielleicht entdeckt man plötzlich ganz neue Qualitäten.
Wenn ich einen Uralt-Amp anwerfe, ist das ja auch nicht mehr StateOfTheArt.
Klingen tut es aber dann ggf. trotzdem geil.
Ich bin nicht so der Freund von absoluten Wertmaßtäben in der Musik bzw. bei den Gerätschaften.
Wenn etwas gut klingt, ist es am Ende egal, ob es neu ist, oder 30 Jahre alt ist.
 
G

Gelöschtes Mitglied 10924

Guest
Ich denke nicht, dass es ein Bug im klassischen Sinne ist. Denke, es liegt irgendwie daran, dass das Grid von links nach rechts abgearbeitet wird und wenn die Software "plötzlich" durch ein Send/Return wieder zum Anfang springen muss, dann dauert's halt länger... könnte mir aber vorstellen, dass das irgendwie zu lösen sein wird.
Wobei "Nur" auch relativ ist. Alleine eine lange Signalkette mit vielen leeren Shunts kostet Prozessorleistung und trägt somit auch zur Latenz bei. Wenn man latenz-empfindlich ist, dann sollte man die Signalkette so kurz wie möglich halten – ist zumindest meine amateurhafte Meinung. Ich hab' schon viele Grid-Layouts gesehen, bei denen verschwenderisch mit Shunts umgegangen wurde, dann aber aus "Platzmangel" Send und Returns eingebaut waren.

Ich bin auch kein Programmierer, kann mir aber gut vorstellen dass es einen Unterschied macht, wenn das Grid durch einen links platzierten Return neu gescannt werden muss.
Also ich denke, hier tut Information Not…

Das Grid, auf dem Display und im Editor, ist zunächst lediglich eine grafische Benutzeroberfläche.
Es dient dazu, die Struktur, gemäß der die einzelnen Effekt-Blöcke das Eingangssignal verarbeiten, bereitzustellen.
Die Firmware, das Betriebssystem des Axe, steuert den Ablauf des Modelings auf dieser strukturellen Grundlage.

Die einzelnen Blöcke werden durch separate (Unter)Programme realisiert, in denen die jeweiligen Simulationen eines Effekts ablaufen.
Dies geschieht durch Berechnungen auf Grundlage physikalisch/mathematischer Funktionen.

Um die Reihenfolge zu ermitteln, gemäß der die zuvor von analogen in digitale Signale umgewandelten Datenströme (Zahlenwerte) verarbeitet werden sollen, wird die grafische Grid-Darstellung bspw. in eine Struktur umgeformt, die dies ermöglicht.

Das kann man zBsp. mit Matrizen umsetzen.
Dieses Konstrukt kennen wahrscheinlich die Meisten noch aus dem Mathe-Unterricht.
Keine Sorge; Vektor- und Skalarprodukte werden hier kein Thema sein ;-)

Eine 2-Dimensionale Matrix sähe dann bspw. so aus:

0 3 1 9
1 5 7 3
8 1 6 4

Diese 2D-Matrix besteht aus Zeilen und Spalten.
Jede Position in der Matrix hat einen Index, über den diese Position ansprechbar ist, um einen Zahlenwert einzutragen oder auszulesen.
Die Position (2, 3), Zeile 2, Spalte 3, besitzt hier den Wert (Inhalt) 7.

Nehmen wir nun an, das AxeFx hätte ein Grid aus 4 Zeilen und 10 Spalten.
Dann wird beim Laden eines leeren Presets eine Variable im Arbeitsspeicher erzeugt, also eine Speicherstelle im Arbeitsspeicher, die das Format Matrix besitzt, mit Nullen gefüllt wird und wie folgt dimensioniert wird:

grid = matrix(4, 10)
(grid ist der zukünftige Variablenname, unter dem man sie anspricht und manipuliert)

0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

Danach kann ich diese Variable nutzen, um in eine der Positionen dieser Matrix einen Wert einzugeben oder ihn auszulesen.

grid(1, 3) = 5

0 0 5 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0


Wenn ich nun festlege, dass alle Effekt-Blöcke, Shunts und Leerstellen eine ID bekommen, über die ich diese im Verarbeitungsprozess/Modeling später ansprechen bzw. aufrufen/starten kann, kann ich das AxeEditor-Grid auslesen und ein Abbild davon in diese Matrix einpflegen.

Bsp. für eine ID-Vergabe:
-----------------------------
0 = Leerstelle (nicht belegt)
1 = Amp-Block
2 = Chorus
9 = Shunt

Wenn der User nun eine Änderung im Grid vornimmt, registriert das System dies, passt die grafische Darstellung der Editoroberfläche an und aktualisiert die Matrix.

Ich füge einen Chorus, ein paar Shunts und einen Amp-Block in's Grid ein.
Alles wird in Zeile 1 platziert.

9 2 9 9 9 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

So bekomme ich eine Struktur, nach der ich den Modeling-Prozess ablaufen lassen kann.
Das Eingangssignal geht in den Chorus und von dort in den Amp.
Das reicht für unser Beispiel zum Verständnis aus.

Nun kann das System die Matrix auswerten und ein Unterprogramm aufrufen/starten, den Chorus. Dabei werden die Eingangsdaten, die unsere Gitarre liefert und die in Form eines kontinuierlichen Zahlenstroms vorliegen (A/D Wandler hat das analoge Signal ja umgewandelt) mit an das Chorus-Programm und dessen Berechnungen übergeben.

Gleichzeitig wurde das Unterprogramm eines Amp-Blocks gestartet.
Dieses bekommt nun kontinuierlich die Rückgabe-Daten aus der Chorus-Verarbeitung und modelliert/simuliert damit den Amp.

Was hier nicht zu finden ist, sind Shunts!
Diese existieren nicht als Effekt-Blöcke, die das Signal be/verarbeiten!
Sie haben lediglich innerhalb des Grids und der Matrix einen formalen, strukturellen Wert.
In der Datenverarbeitung werden die Signaldaten ausschließlich nacheinander durch die beteiligten Effekt-Blöcke verarbeitet.


Woher weiß das System aber, welchen Weg das Signal nehmen muss?
Dies erreicht man dadurch, dass man die Matrix zu einer 3D-Matrix umformt bzw. sie gleich so anlegt.
Hört sich kompliziert an, ist es aber nicht.

grid = matrix(4, 10, 5)

Die ersten beiden Indizes bleiben weiterhin für die Positionen von Zeile und Spalte im Grid/in der Matrix.

Nun kann ich in dieser Matrize eine Speicherstelle ansprechen, die aus 3 Indizes statt aus 2 besteht.
Also wird unsere Matrix einfach etwas anders aufgerufen, um Daten hineinzuschreiben oder auszulesen:

9 2 9 9 9 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

Der Amp-Block, ID = 1, wird nun ausgelesen, wenn ich abfrage, was an Position
grid(1, 6, 1) = (Zeile, Spalte, Zusatzdimension) eingetragen ist: "1"
D.h., die ersten beiden Indizes der Matrix dienen immer dazu, Zeile und Spalte des Grids abzubilden.
Der 3. Index dient dazu, bei Index = 1 den Block-Typ gemäß ID zu speichern.
Ab Index 2 könnte man nun Positionen aus dem Grid speichern, mit denen diese aktuelle Zelle VERBUNDEN ist.

9 2 9 9 9 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

Der Chorus, Position 1, 2 im Grid (Matrix) sei mit dem Shunt an Position 1, 3 auch verbunden (also die Blöcke sind nicht nur dort eingebaut ohne Verbindung).
Dann könnte ich das in der Matrix für die Speicherposition des Chorus folgendermaßen speichern:

grid(1, 2, 1) ist ja mit der ID des Chorus belegt; dort steht eine "2".

grid(1, 2, 2) = 1,03 wäre eine Angabe (Koordinaten) zu einer Verbindung

1. kleiner Trick; Die 1,03 belegt nur einen Speicherplatz in der Matrix.
Aber in Form einer Dezimalzahl kann ich 2 Koordinatenwerte im Grid gleichzeitig angeben,
Um die Zeile und Spalte zu ermitteln, bediene ich mich einfach einer Funktion, mit der ich wahlweise den Ganzzahl-Anteil oder den Dezimal-Anteil zurückbekomme.
Dann habe ich die Koordinaten 1 und 03 bzw. 3!
Zeile 1, Spalte 3.

2. kleiner Trick.
Da ich die ganzen Zwischenschritte, mit Shunts belegt, eigentlich garnicht benötige, trage ich in die Matrix stattdessen gleich

grid(1, 2, 2) = 1,06 ein!

Dann erkennt das System, dass hier der Chorus mit dem Block im Grid an Position Zeile 1, Spalte 6 verbunden ist.

Und genau diese Info benötigt das Modeling-System für die Bearbeitung.
Wieviele Shunts es braucht, um anzuzeigen, welche Blöcke miteinander verbunden sind, interessiert hier nicht.

In der Verarbeitung/Modeling werden die Signal-Daten DIREKT an die einzelnen Effekt-Blöcke übergeben und die berechneten Rückgabewerte übernommen, um sie an den nächsten Block oder die nächsten Blöcke weiterzugeben.

Die Shunts im Grid und in der Matrix dienen nur dazu, dass das System erkennen kann, welchen Weg das Signal nimmt.
D.h., immer dann, wenn ich eine weitere Verbindung zwischen zwei Zellen im Grid herstelle, wird in der Matrix (Variable grid) ein entsprechender Wert eingetragen, der bezeichnet, mit welcher Zelle die aktuelle Zelle verbunden worden ist.

Bsp.:

Matrix (Variable grid)
------------------------
9 2 9 9 9 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

grid(1, 2, 1) = 2 (ID = 2 = Chorus)
grid(1, 2, 2) = 0 (Zeile 1, Spalte 2, Chorus, ist nicht verbunden)

Der User zieht eine Verbindung zur rechts angrenzenden Zelle, in der er anfangs einen Shunt platziert hatte.

Das System registriert dies und ändert 2 Werte.

grid(1, 2, 2) = 1,03 (Zeile 1, Spalte 2, Chorus, verbunden mit Zeile 1, Spalte 3, Shunt)

grid(1, 3, 2) = 1,02 (Zeile 1, Spalte 3, Shunt, verbunden mit Zeile 1, Spalte 2, Chorus)



Das war jetzt ne Menge Stoff und ich hoffe, ihr beide seid nicht zu früh ausgestiegen…
Diese Variante ist eine Möglichkeit, die Verbindungsstruktur für das System nachvollziehbar und auswertbar zu machen.
Die grafische Darstellung des Grids ist nur das sog. User-Frontend; die Bedieneroberfläsche.

Ob das so in der Firmware umgesetzt ist, oder ggf. etwas anders, weiß ich natürlich nicht.
Das weiß nur FAS.

Aber man kann sehen, dass das Betriebssystem/die Firmware sich nicht durch das visuelle Grid von oben links nach unten rechts arbeitet.
Das Grid selbst ist ebenfalls keine verarbeitende Einheit.
Die Effekt-Blöcke bestehen aus einzelnen Programmen bzw. Unterprogrammen, die nacheinander die Daten verarbeiten.
Wenn in diesem System die Programmierer den Shunts eine zeitlich relevante Funktion zugeordnet haben sollten, halte ich dies für einen gravierenden Fehler in der Konzeption.

Diese Matrix kann man im übrigen bei der Speicherung des Presets mitspeichern.
So lässt sich einfach die Struktur eines Presets wieder aufbauen, wenn man es aufruft.

Einiges habe ich sehr rudimentär dargestellt und formuliert.
Es ging um ein Verständnis des Grundprinzips.
Nicht um eine vollständige Darstellung des Firmware-Systems.

Nun denn;
Viele Grüße an die rauchenden Köpfe ;-))
Mike
 

Joachim

Active member
Mitglied seit
Mrz 14, 2013
Beiträge
600
Beiß Dich nicht daran fest, so lange wir nicht Cliff's Vorgehensweise kennen, so lange werden wir nicht wissen, was die Send/Return Verzögerungen verursacht.

Natürlich weiß ich auch nicht was da passiert. Das sollte nur ein Versuch sein die Verzögerung zu erklären.
Meine Vermutung, dass das Grid von links nach rechts abgearbeitet wird, kam daher, weil dies eine typische Vorgehensweise für einen Signalfluss ist und die Verzögerung erklären könnte. Denn bei Send/Return steht man irgendwann vor einem "Glaskugelproblem" (ich nenne es mal so :biggrin:), Du brauchst eine Information, die erst in der Zukunft erzeugt wird 🤷‍♂️
Und dass die Verzögerung sich bei der Verwendung von 2x Send/Return exakt verdoppelt (im Vergleich zu 1x Send/Return) ist doch auch verdächtig.

Natürlich könnte man das ganz sicher anders und geschickter lösen, aber dann wäre die Verzögerung ja nicht vorhanden! ;)
 
Zuletzt bearbeitet:
G

Gelöschtes Mitglied 10924

Guest
Beiß Dich nicht daran fest, so lange wir nicht Cliff's Vorgehensweise kennen, so lange werden wir nicht wissen, was die Send/Return Verzögerungen verursacht.

Natürlich weiß ich auch nicht was da passiert. Das sollte nur ein Versuch sein die Verzögerung zu erklären.
Meine Vermutung, dass das Grid von links nach rechts abgearbeitet wird, kam daher, weil dies eine typische Vorgehensweise für einen Signalfluss ist und die Verzögerung erklären könnte. Denn bei Send/Return steht man irgendwann vor einem "Glaskugelproblem" (ich nenne es mal so :biggrin:), Du brauchst eine Information, die erst in der Zukunft erzeugt wird 🤷‍♂️
Und dass die Verzögerung sich bei der Verwendung von 2x Send/Return exakt verdoppelt (im Vergleich zu 1x Send/Return) ist doch auch verdächtig.

Natürlich könnte man das ganz sicher anders und geschickter lösen, aber dann wäre die Verzögerung ja nicht vorhanden! ;)
Dass Deine Wahrnehmung ein Fakt ist, glaube ich Dir ja.
Ich habe Dir aus der Sicht des Informatikers/Entwicklers ein Beispiel geben wollen, dass die visuelle Darstellung in dem Grid, sei es im Editor oder auf dem Display, nicht 1zu1 umsetzbar in die interne Verarbeitung des Signals ist.

Send/Return-Blöcke sind etwas anderes.
Das sind funktionale Blöcke, die einen Einfluss auf die Laufzeit haben können.
Anders, als die Shunts.
 
G

Gelöschtes Mitglied 10924

Guest
Beiß Dich nicht daran fest, so lange wir nicht Cliff's Vorgehensweise kennen, so lange werden wir nicht wissen, was die Send/Return Verzögerungen verursacht.

Natürlich weiß ich auch nicht was da passiert. Das sollte nur ein Versuch sein die Verzögerung zu erklären.
Meine Vermutung, dass das Grid von links nach rechts abgearbeitet wird, kam daher, weil dies eine typische Vorgehensweise für einen Signalfluss ist und die Verzögerung erklären könnte. Denn bei Send/Return steht man irgendwann vor einem "Glaskugelproblem" (ich nenne es mal so :biggrin:), Du brauchst eine Information, die erst in der Zukunft erzeugt wird 🤷‍♂️
Und dass die Verzögerung sich bei der Verwendung von 2x Send/Return exakt verdoppelt (im Vergleich zu 1x Send/Return) ist doch auch verdächtig.

Natürlich könnte man das ganz sicher anders und geschickter lösen, aber dann wäre die Verzögerung ja nicht vorhanden! ;)
Und ja, die Verarbeitungsreihenfolge ist natürlich von links nach rechts.
Aber dazu wird dann ein Batchprozess angelegt, in dem nur relevante Effekt-Blöcke eingebunden sind und in dem diese Abfolge berücksichtigt wird.
 

Comanche

Member
Mitglied seit
Mrz 2, 2023
Beiträge
53
Danke für deine Ausführungen. Aber nimm' es mir bitte nicht übel, dass ich nicht alles lese.
Send/Return-Blöcke sind etwas anderes.
Das sind funktionale Blöcke, die einen Einfluss auf die Laufzeit haben können.
Anders, als die Shunts.
Wie ist es dann zu erklären, dass Shunts Prozessorleistung beanspruchen?

Ich kann ja verstehen, dass die Berechnungen im Signalfluss grundsätzlich nichts mit der grafischen Oberfläche – in diesem Fall das Layout Grid – zu tun haben (müssen), aber dennoch ist es ja fakt, dass wenn das Signal nicht ausschließlich von Links nach Rechts abgearbeitet werden kann, Latenzen auftreten bzw. Prozessorleistung beansprucht wird. Sei es nur durch fehlende Optimierung oder kleinere Programmfehler.
 

Joachim

Active member
Mitglied seit
Mrz 14, 2013
Beiträge
600
Ich habe Dir aus der Sicht des Informatikers/Entwicklers ein Beispiel geben wollen, dass die visuelle Darstellung in dem Grid, sei es im Editor oder auf dem Display, nicht 1zu1 umsetzbar in die interne Verarbeitung des Signals ist.
Das hatte ich auch so verstanden. Bin zwar kein gelernter "IT-ler", nur Physiker, erstelle aber auch Software - für selbst entwickelte Messgeräte. Daher kenne ich das Problem nur allzu gut! :biggrin:
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.608
Also meine Meinung und mein Verständnis. Beruht nur auf Beobachtungen und Annahmen!

1. Shunts brauchen natürlich auch Prozessorleistung, aber sehr minimal und ich glaube nicht, dass die Latenzen verursachen. Wie komme ich darauf? Ich habe einmal fix mit dem FM3 zwei Presets gebaut. Eins mit In1 -> direkt in Out1 und ein mit In1 ganz links und Out1 gaaanz rechts. Das Ganze mit Shunts verbunden, beides gemessen und ich kann keine unterschiedliche Latenz zwischen beiden Presets erkennen. Warum auch? Wenn ihr Presets mit Effekten baut, wollt ihr dann ja auch immer die gleiche Latenz und nicht je nach Preset eine andere. Das ist ein stabiler Wert. Prozessorleistung ist dabei nicht gleich der Latenz!

2. Feedback Send/Return Schleifen verursachen höhere Latenz, wenn man damit das Grid "künstlich" verlängert.
Darüber war ich erst geschockt und dachte, dass das doch nicht sein kann. Ich habe das auch gemessen und tatsächlich. Je länger ich aber darüber nachdenke, ist es auch logisch und richtig, aber natürlich unschön. Warum ist es logisch? Das Grid hat eine feste Breite. Warum ist das so? Warum hat das Cliff nicht gleich flexibel gestaltet? Mit diesem fest definiertem Grid ist eine bestimmte Latenz möglich. Jeder Block im Grid hat eine bestimmte zulässige Laufzeit. Bis dahin muss er seine Signale verarbeitet haben. Nur so kann Fractal eine Latenz von X ms gewährleisten.

Wird nun das Grid aber künstlich mit den Feeback-Blöcken verlängert, muss es ja zwangsläufig zu längeren Latenzen führen. Das Grid besteht nun aus mehreren Blöcken und somit auch aus weiteren Latenzen. Das muss sich dann natürlich aufsummieren. Alles andere wäre ja eine spontane Verringerung der Latenzen pro Block. Wie soll das gehen?

Verständlich, wie ich das sehe? Aber wie gesagt, alles nur reine Spekulation.
 
G

Gelöschtes Mitglied 10924

Guest
Danke für deine Ausführungen. Aber nimm' es mir bitte nicht übel, dass ich nicht alles lese.

Wie ist es dann zu erklären, dass Shunts Prozessorleistung beanspruchen?

Ich kann ja verstehen, dass die Berechnungen im Signalfluss grundsätzlich nichts mit der grafischen Oberfläche – in diesem Fall das Layout Grid – zu tun haben (müssen), aber dennoch ist es ja fakt, dass wenn das Signal nicht ausschließlich von Links nach Rechts abgearbeitet werden kann, Latenzen auftreten bzw. Prozessorleistung beansprucht wird. Sei es nur durch fehlende Optimierung oder kleinere Programmfehler.
Tja; Wir wissen natürlich nicht, wie Cliff und/oder ggf. Michael Pickens die Firmware programmiert haben.
Meine Idee ist ja eine Option, soetwas zu regeln.
Wenn es wirklich Shunts sind, die je nach Anzahl CPU-Leistung fressen, ist das suboptimal.
Send/Return-Blöcke sind was anderes, da diese einen Funktionsblock darstellen.
 
G

Gelöschtes Mitglied 10924

Guest
Also meine Meinung und mein Verständnis. Beruht nur auf Beobachtungen und Annahmen!

1. Shunts brauchen natürlich auch Prozessorleistung, aber sehr minimal und ich glaube nicht, dass die Latenzen verursachen. Wie komme ich darauf? Ich habe einmal fix mit dem FM3 zwei Presets gebaut. Eins mit In1 -> direkt in Out1 und ein mit In1 ganz links und Out1 gaaanz rechts. Das Ganze mit Shunts verbunden, beides gemessen und ich kann keine unterschiedliche Latenz zwischen beiden Presets erkennen. Warum auch? Wenn ihr Presets mit Effekten baut, wollt ihr dann ja auch immer die gleiche Latenz und nicht je nach Preset eine andere. Das ist ein stabiler Wert. Prozessorleistung ist dabei nicht gleich der Latenz!

2. Feedback Send/Return Schleifen verursachen höhere Latenz, wenn man damit das Grid "künstlich" verlängert.
Darüber war ich erst geschockt und dachte, dass das doch nicht sein kann. Ich habe das auch gemessen und tatsächlich. Je länger ich aber darüber nachdenke, ist es auch logisch und richtig, aber natürlich unschön. Warum ist es logisch? Das Grid hat eine feste Breite. Warum ist das so? Warum hat das Cliff nicht gleich flexibel gestaltet? Mit diesem fest definiertem Grid ist eine bestimmte Latenz möglich. Jeder Block im Grid hat eine bestimmte zulässige Laufzeit. Bis dahin muss er seine Signale verarbeitet haben. Nur so kann Fractal eine Latenz von X ms gewährleisten.

Wird nun das Grid aber künstlich mit den Feeback-Blöcken verlängert, muss es ja zwangsläufig zu längeren Latenzen führen. Das Grid besteht nun aus mehreren Blöcken und somit auch aus weiteren Latenzen. Das muss sich dann natürlich aufsummieren. Alles andere wäre ja eine spontane Verringerung der Latenzen pro Block. Wie soll das gehen?

Verständlich, wie ich das sehe? Aber wie gesagt, alles nur reine Spekulation.
Interessante Gedanken!
Muss jetzt leider pennen gehen und am Handy ist die Schreiberei etwas mühsam. Nur soviel.
Auch Du betrachtest das Grid als ein Objekt, durch welches Daten fließen.
Ich hatte ja bewusst unterschieden zwischen der reinen Datenverarbeitung und der Verwaltung der Block-Struktur.
Wenn ich diese Struktur beim Laden des Presets und ggf. nach Veränderungen durch den User in einen Batch-Prozess ûberführe, der den Rechenprozess steuert, hat die Länge
des Grids keine Bedeutung mehr.
Es werden Daten/Signale ausschließlich durch die beteiligten Effekte/Formeln/Funktionen geschleust.
So jedenfalls würde ich diesen Prozess programmieren.
Das Routing im Grid sollte lediglich dazu dienen, die Abfolge der Rechenprozesse festzulegen.
Da die DSP-Programmierung ja Echtzeit-Verarbeitung umzusetzen hat, sollte jede Art von Latenz-Risiko vermieden werden.
 
Oben
mainframe-fourhanded
mainframe-fourhanded