Die Inkompatibilität bei FAS vom AxeFx 2 zum XL und noch viel schlimmer, von eine Firmwareversion zur nächsten, ist meiner Ansicht nach dem Entwicklungsprozess bei FAS geschuldet und hat nicht zwangsläufig technische Ursachen.
FAS arbeitet meiner Ansicht nach nicht Top-Down sondern eher Bottom-Up und legt auch keinen so großen Wert auf Kompatibilität. Das ist etwas, was mich seitdem ich das AxeFx2 habe ärgert und auch immer wieder bei mir hochpoppt. D.h. Cliff schraubt in der Software an den Amps und stellt fest, dass er jetzt einen Regler mehr benötigt. Schwupps, gibt es im User-Interface einen Regler mehr. Dies erfordert einen zusätzlichen Parameter im Konfigurationsfile (syx) und somit sind die Dateien nicht mehr kompatibel ..... und man hat den Salat. Für FWx geht das Presetfile von FWy nicht, weil die Parameter nicht zusammenpassen. Morgen hat er eine andere Idee, schwupps ist der Regler wieder weg, hat einen anderen Namen oder einen anderen Wertebereich.
Wollte man es kompatibel machen, ginge das zwar (vielleicht!!) , erfordert aber - im Nachhinein - oft massiven Aufwand.
Das alles etwas plakativ und ich weiß, dass Presets bei ner neuen FW nicht grundsätzlich neu erstellt werden müssen
Es gäbe hier auch andere Ansätze, die in der Anfangsphase der Entwicklung solche Sachen betrachten und eine Architektur definieren, die auf Kompatibilität ausgerichtet ist. D.h. aber man muss sich zu Beginn der Entwicklung ganz genau überlegen, welche Parameter brauch ich jetzt (welche halte ich vielleicht vor, wie kann ich erweitern), was brauch ich für die Zukunft, wie sehen meine Interfaces aus (also Schnittstellen, ich meine hier die Softwareschnittstellen aber auch das User-Interface). Das wäre dann eher ein Top-Down Ansatz. Erst wenn ich alles spezifiziert habe (auch das Preset-Format, usw.... ) fang ich an, nach Spezifikation (!!!!) die ersten Zeilen Code zu programmieren. Muss mich dann aber auch an meine Vorgaben halten. Den Weg geht FAS meiner Meinung nach nicht unbedingt
Erfahrungsgemäß wird der zweite Ansatz von kleinen Firmen, mit einem oder zwei Programmierern, eher selten umgesetzt. Wenn ich noch nicht so genau weiß, wo die Reise hin geht kann dieser Ansatz auch schwer sein. Gründe dafür sind oft Zeit- und Geldmangel aber auch mangelndes Wissen oder Erfahrung. Oder, und das unterstelle ich dem Cliff mal, weil man sich keine Schranken auferlegen möchte und eher einen forschungsorientieren Ansatz verfolgt.
Zumindest ist das meine Sichtweise. Ich bin da oft hin und hergerissen. Manchmal möchte ich da dem Cliff das AxeFx quer in seinen Allerwertesten schieben. Dann könnt ich ihn andererseits umarmen, wenn der Sound nach dem Update einfach nur noch genial ist.
Ein bisschen mehr Disziplin bei der Festlegung der SW-Architektur und Programmierung stände meiner Meinung nach FAS trotzdem gut. Das Argument, dann wärst halt bei FW Stand x geblieben, lass ich an der Stelle aber nicht gelten. FW3 hatte mich dazu bewogen, das AxeFx in die Ecke zu stellen und zu warten, dass es besser wird.
- immerhin gibt es in Kürze eine Demo-Booth wo interessierte Musiker, das Gerät über ne PA, ne FRFR-Box und ein traditionelles Gitarrenrig testen oder mit Ihrem Amp vergleichtesten können. Warum? Weil das AxeFx einen solchen Aufwand verdient! 
