Moin moin zusammen;
Habe mir die Mühe gemacht, vllt. etwas Klarheit in die eine oder andere Thematik zu bringen.
Da auch ich z.T. auf meine Kenntnisse aus der Informatik zurückgreifen muss, erhebe ich nicht in
allen Belangen den Anspruch auf absolute Gültigkeit meiner Darstellungen!
Nur so zur Info mal.
Let's go ...
1) Updates
Ich habe mein Verfahren mittlerweile wieder ein bisschen modifiziert.
Was? Warum?
Die Firmware spiele ich nur noch 1 mal ein.
Da die Programmierung des EPROMS (interner Chip, welcher die Firmware beinhaltet) immer,
wie allgemein üblich, verifiziert wird, zu sehen auf dem Axe-Display an dem Hinweis "Verifizierung",
kann man davon ausgehen, dass ein Update ohne Fehlermeldungen gewährleistet, dass die Daten
aus der Update-Datei des Rechners korrekt in das EPROM kopiert wurden.
Ein 2. einspielen würde somit nichts am Ergebnis ändern.
Zudem lässt die empfindliche Reaktion des Prozesses(Geräts auf USB-Timing Veränderungen darauf
schließen, dass, wenn es ohne Probleme geklappt hat, zumindest die Daten alle da sind, wo sie hingehören.
Das zuvor, nach der FW-Aktualisierung, bisher gesicherte System-Backup spiele ich nicht mehr zurück,
da man keine Informationen bekommt/findet, welche System-Einstellungen insgesamt gesichert und vor allem
bei einem Restore wieder zurückgeschrieben werden.
Es wird, dies lässt sich aus dem Rat von FAS, ggf. einen System Reset bei Problemen durchzuführen,
unzweifelhaft ersehen, mit Sicherheit noch abseits der im Handbuch erwähnten I/O & Utility Parameter
ebensolche geben, die dem User (aus gutem Grunde) nicht zugänglich sind, die aber einen irgendwie
gearteten Einfluss auf die korrekte Funktion des Axe haben.
Um die nach einem Update mit dem "alten" System Backup nicht auch zu überschreiben, lasse ich es.
Leider bekommt man zu diesen Dingen ja keinerlei umfassende Informationen.
Der ganze Update-Prozess hätte im übrigen auch nach so vielen Jahren ohnehin mal auf ordentliche Füße
inkl. einer ordentlichen Doku gestellt werden können.
Aber da ist FAS auch leider nicht das einzige Unternehmen, welches solche Punkte mehr oder weniger vernachlässigt.
Hier also meine aktuelle Verfahrensweise.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Firmware Updates installieren
- Roland FC-200 ggf. angeschlossen, aber ausgeschaltet
- Axe-Fx <> iMac via USB
- Fractal-Bot > Backups von System & Bank A (eigene Presets) & ggf. User Cabs
- Fractal-Bot > Update > Axe-Fx / keine parallele Rechneraktivität !
1) Firmware 1x installieren inkl. Neustart
2) Nach der Installation:
- Utility/Reset System Params - Neustart - I/O & Utility Einstellungen anpassen
- Utility/Backup System - Reset System Params - Neustart - Restore System - Neustart / im Moment nicht anwenden!
3) Amps:
- X > Y kopieren
- Amp-Wechsel auf X & speichern & Amp-Wechsel zum ursprüngl. Amp auf X & Block Reset X & speichern X
- X <> Y Vergleich und alte Werte von Y nach X übernehmen, ausser gemäß Release Notes ergänzte oder geänderte Parameter
- speichern X
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
2) Warum ändern sich nach einem Update manche Dinge im Amp Sound und andere nicht?
Warum ändern sich manche Amps und andere nicht? .......
Das Schaubild soll möglichst einfach und nachvollziehbar erläutern, wie die Firmwarestruktur des Axe bezogen
auf einen Amp-Block in etwas aufgebaut sein wird.
Ich gehe davon aus, dass bei FAS objektorientiert programmiert wird.
Umfassendere Infos dazu, wenn von Interesse, bitte bei WiKi o.ä. nachschlagen, da eine allzu detaillierte Erklärung
den Rahmen hier sprengen würde!
Nur soviel zum Verständnis;
Objektorientierung in der Softwareentwicklung sorgt für eine möglichst ideale Anpassung einer Software an unsere
Realitätswahrnehmung und die Art, wie unsere Realität strukturiert ist und funktioniert.
Unser Welt besteht aus Objekten, die Eigenschaften und Handlungsmöglichkeiten/Tätigkeiten besitzen.
In der OOP (Objektorientierte Programmierung) Attribute und Methoden genannt.
Es gäbe zwar noch die Sinnesorgane oder Sensoren; die lassen wir hierbei allerdings ausser Acht.
Das wären beim Menschen zBsp. die Augen, beim Axe das JogDial oder eine Taste.
Wenn ein, wie auch immer geartetes Ereignis eintritt, reagieren diese o.g. Objekte und handeln.
Wobei auch "nicht zu handeln" eine Form von Reaktion sein kann.
Der Mensch wäre also zBsp. ein Objekt.
Als Wesen in einer Hierarchie von Arten und Gattungen kann er aber auch mal als Basis-Objekt dienen.
In unserem Fall also der Ausgangspunkt einer bestimmten hierarchischen, vererbungsgestützten Struktur.
Der Oberbegriff von etwas in einem bestimmten System, wenn man so will.
Man nennt dies eine Klasse.
Da wir von uns Menschen Nachfahren erzeugen können, erben diese nach bestimmten Regeln unsere Attribute und Methoden.
Gleiches passiert übrigens u.a. auch in einem Automobil-Werk. Nur anders.
Unsere Nachfahren erben also unsere Attribute und Methoden:
Attribute wären Augenfarbe, Haarfarbe, Arme, Beine, Mund ...
Methoden wären Laute erzeugen, bewegen, essen ...
Wir vernachlässigen mal hierbei Vererbungsfehler, Krankheiten, Mutationen etc..
Die OOP (Objektorientierte Programmierung) ist ein Modell; man kann sie sehr tiefgreifend perfektionieren;
aber auch ein Modell hat natürlich seine Grenzen.
Systemwechsel:
Die Axe-Firmware ist ein Stück Computersoftware.
Auf unserem Axe läuft ein Betriebssystem, ähnlich Mac OS oder Windows.
Dieses stellt unterschiedlichste aufrufbare Funktionen bereit und steuert gleichzeitig im Hintergrund eine Menge automatisierter,
ständig aktiver Prozesse, welche wie bei einem Computer u.a. Dinge wie Displayausgaben, Daten Ein- und Ausgaben
(dazu gehört auch die Soundausgabe) etc. umfassen.
Uns interessiert hier allerdings nur der Bereich Soundprozessing, bzw. ein Teil davon.
Wie man im Schaubild sieht, fängt unser DSP softwareseitig mit einem Block an.
Sozusagen das Urelement aller funktionalen Bestandteile unserer Presets.
Die hier sichtbare Abstufung innerhalb der Hierarchie (aus Sicht der Software Struktur!) dient u.a. der Tatsache,
dass man Anpassungen und Veränderungen an einem Attribut o. einer Methode lediglich 1 mal an der obersten Position der
Hierarchie vornehmen muss.
Sie vererben sich sodann; vergleichbar übrigens mit den Globalen Amps, die das Axe speichern kann.
Globalen Amp ändern > in allen Presets wirksam. die ggf. mit dem Amp verlinkt sind.
Bei der Programmierung der Firmware werden in der Folge lauter Klassen u. Objekte (Nachfahren einer Klasse) gebildet (programmiert),
bei denen Letztere ggf. ihrerseits auch wieder als Ausgangsklasse für weitere Nachkommen (Objekte) dienen,
und deren Attribute (Eigenschaften) und Methoden (Handlungsmöglichkeiten/Tätigkeiten) vererbt werden.
Am Ende dieses Entwicklungsprozesses steht der einzelne Verstärker ;-)
All seine Attribute und Methoden existieren im laufenden Betrieb eines Presets in einem Bereich des Arbeitsspeichers unseres Axes
als Programmcode, auf den wir nicht direkt Einfluss können.
All seine Attribute und Methoden bedeutet, alles, was erforderlich ist, um die Hardware des Axe dazu zu bringen, einen bestimmten
und gewünschten Ampsound (natürlich hier ohne weitere Blöcke wie Cab etc. betrachtet!) zu erzeugen (also das Eingangssignal
entsprechend DSP-mäßig zu manipulieren).
Die aktuellen (User-)gewünschten Einstellungen für einen Teil dieser Attribute und Methoden sind in unseren Presets separat gespeichert.
Dargestellt werden sie durch die veränderbaren Parameter im Axe bzw. Editor.
Von den firmwareseitig (gespeichert im EPROM) zur Verfügung stehenden Verstärkern (Programmmodule in der Firmware)
werden bereits beim Start des Axe, was ja mit einem aktivieren sowohl der Firmwareprozesse, als auch mit dem Aufruf eines bestimmten
Presets verbunden ist, 1 oder 2 Stück erzeugt (instanziieren nennt man das; eine oder mehrere Instanzen davon anlegen)
und im Arbeitsspeicher gespeichert.
Ob eines oder beide Programmmodule erzeugt, aufgerufen und gestartet werden, ist abhängig davon,
ob in unserem aktuellen Preset Amps vorhanden sind.
Wenn ich ein Preset wechsle, wird ein Prozess gestartet, der prüft, welche Blöcke vorhanden sind, wie sie verschaltet sind und so weiter.
Die im Preset gespeicherten Werte für vom User veränderbare Parameter einzelner Blöcke werden zBsp. für die ggf.
im Arbeitsspeicher bereitstehenden Amps eingestellt.
Wer bereits mal programmiert hat weiss, dass da bestimmten Variablen (Parametern) die im Preset vorgesehenen Werte zugewiesen werden.
Ich denke, soweit reicht dieser theoretische Teil dann aber auch erstmal.
Kommen wir zu dem wesentlichen Umstand, Veränderungen im Sound nach einem Update nachzuvollziehen.
Wenn man das beschriebene Prinzip ungefähr verstanden hat, kann man in dem Schaubild erkennen,
dass Veränderungen in der Softwarestruktur der Amps unterschiedlichste Auswirkungen haben müssen.
Eine Änderung an den Attributen oder Methoden der Röhrenamp Basisklasse zBsp. wirkt sich auf alle nachfolgenden Amp-Generationen,
also Unterklassen, aus.
Hier wirkt das bereits angesprochene Vererbungsprinzip.
Da nun gleichzeitig die einzelnen Amp-Unterklassen (Bsp. Marshall Amp und Fender Amp) ggf. ganz eigene und spezifische Attribute u. Methoden
haben können, kann es zudem sein, dass bestimmte Amps aufgrund ihrer Zugehörigkeit zu einer anderen Klasse (Bsp. Marshall Amp statt Fender Amp)
auch anders auf Änderungen in einer übergeordneten Amp-Klasse reagieren, da diese klassenspezifischen Attribute oder Methoden möglicherweise
entsprechende Wechselwirkungen mit dieser Änderung zur Folge haben können.
Fender Amps reagieren ggf. anders auf Änderungen in der Amp Basisklasse, als Marshall Amps.
Hat sich der Gesamtsound der Amps verändert, sind höchstwahrscheinlich Änderungen an übergeordneten Klassen vorgenommen worden.
Hat sich der Sound bestimmter Amps geändert, anderer hingegen nicht, gab es wahrscheinlich Änderungen weiter unten in der Klassenhierarchie.
Manches lässt sich u.a. an der Zugehörigkeit einzelner virtueller Amps zu realen Amp-Typen oder Gattungen ganz gut ermitteln.
Hier ende ich jetzt mal.
Rückfragen, Anregungen, Korrekturen oder Feedbacks können ja immer noch behandelt und ggf. tiefergehend beleuchtet werden.
Eine allzu tiefschürfende Softwareanalyse ist eh nicht möglich mangels Information und führt insofern nur in's Reich der Spekulation.
Aber vielleicht hilft das bereits geschriebene dem Einen oder Anderen.
In diesem Sinne.
Bis die Tage!
Mike
wichtig ist, daß am Ende was geiles dabei raus kommt.
