Bug! Amp-Block Parameter "Preamp Hardness"

[mrgodin]

Falls es jemand hier noch nicht im US-Forum gelesen, oder festgestellt hat;

Die Speicherung des Preamp Hardness Parameters funktioniert nicht dauerhaft!

Setzt man diesen Parameter auf einen Wert, der vom Default-Wert (Standardwert eines neuen Amps mit Werkseinstellungen) abweicht
und speichert dieses Preset, ist erstmal alles OK.
Wechselt man zu einem anderen Preset und ruft das genannte Preset erneut auf, wurde der Parameter wieder auf seinen Default-Wert zurückgesetzt.
Ausserdem scheint die Funktion nicht in dem Umfang wirksam zu sein, wie dies bisher der Fall war.
Bei Veränderung des Wertes lässt sich keine hörbare Veränderung im Sound feststellen.
Das war zuvor anders.

Auf der Mauer, auf der Lauer liegt 'ne kleine Wanze ... heisst es in einem Kinderlied.

FAS-Programmierer haben, so habe ich gelegentlich das Gefühl, kein konsequentes Checking-Prozedere, welches solche Sachen wie Parameterspeicherung
oder andere, teilweise in der Vergangenheit immer mal auftauchende, Fehlverhalten der Software nach Fertigstellung einer Release Version überprüft.
Das gehört für mich zum festen Bestandteil von Beta-Testing und erweitert sich ggf. auch immer mal um neue Tests.

Finde ich schon manchmal 'ne schwache Leistung, solche Bugs.
Egal;
Auch 7.03 muss seine Existenzberechtigung haben ;-)

Frohe Ostern!
Mike

 

[Marcus Siepen]

Ich ziehe nur Poweramp Hardness hoch, trotzdem gut zu wissen

Gesendet von meinem HTC 10 mit Tapatalk

 

[Andy]

Falls es jemand hier noch nicht im US-Forum gelesen, oder festgestellt hat;

Die Speicherung des Preamp Hardness
FAS-Programmierer haben, so habe ich gelegentlich das Gefühl, kein konsequentes Checking-Prozedere, welches solche Sachen wie Parameterspeicherung
oder andere, teilweise in der Vergangenheit immer mal auftauchende, Fehlverhalten der Software nach Fertigstellung einer Release Version überprüft.
Das gehört für mich zum festen Bestandteil von Beta-Testing und erweitert sich ggf. auch immer mal um neue Tests.

Finde ich schon manchmal 'ne schwache Leistung, solche Bugs.
Egal;
Auch 7.03 muss seine Existenzberechtigung haben ;-)

Frohe Ostern!
Mike

Darauf hab ich im US Forum auch mal hingewiesen und ein paar Links zu Code Checkern gepostet, weil ich das auch absolut ärmlich finde. Gut, die Checker sind auch nicht der Weistheit letzter Schluß aber mittlerweile auch schon ganz gut. Zumindest gibt es zusätzliche Sicherheit und gerade solche Sachen werden schon angzeigt, also wenn sich toter Code im Programm befindet. Daraufhin hab ich mir ein paar "Watschen" (Ohrfeigen) abgeholt.. Interessanterweise nur von Usern Seitens Cliff gab es keinen Kommentar dazu.

 

[aalrh]

Darauf hab ich im US Forum auch mal hingewiesen und ein paar Links zu Code Checkern gepostet, weil ich das auch absolut ärmlich finde. Gut, die Checker sind auch nicht der Weistheit letzter Schluß aber mittlerweile auch schon ganz gut. Zumindest gibt es zusätzliche Sicherheit und gerade solche Sachen werden schon angzeigt, also wenn sich toter Code im Programm befindet. Daraufhin hab ich mir ein paar "Watschen" (Ohrfeigen) abgeholt.. Interessanterweise nur von Usern Seitens Cliff gab es keinen Kommentar dazu.

Pöser Pursche ruust:

 

[Solyth]

auf den Poden! ruust:ruust:

 

[nwngnm]

Ich werf mich nicht auf den Poden, denn ich bin von der Judäischen Volksfront und nicht von der Volksfront von Judäa !pa:

 

[papasoeren]

... jemand Bock auf Lerchenzungen oder Otternasen?

 

[funkstation777]

Ich bin noch ganz voll von den Finkenhirnen und dem römischen Wein. Ave.

 

[mrgodin]

Darauf hab ich im US Forum auch mal hingewiesen und ein paar Links zu Code Checkern gepostet, weil ich das auch absolut ärmlich finde. Gut, die Checker sind auch nicht der Weistheit letzter Schluß aber mittlerweile auch schon ganz gut. Zumindest gibt es zusätzliche Sicherheit und gerade solche Sachen werden schon angzeigt, also wenn sich toter Code im Programm befindet. Daraufhin hab ich mir ein paar "Watschen" (Ohrfeigen) abgeholt.. Interessanterweise nur von Usern Seitens Cliff gab es keinen Kommentar dazu.

Ich dachte jetzt eher an Testroutinen, die sich aus der Programmier- und Debugarbeit ergeben.
Codechecker habe ich auch nie verwendet.

Aber man entwickelt zum Einen im Zusammenhang mit bestimmten, zumeist länger währenden Projekten, aber auch generell
Verfahren, die es einem ermöglichen, bestimmte Fehlfunktionen und sich gelegentlich wiederholende Bugs schnell zu ermitteln.
Hierdurch habe ich im Vorfeld meist einen großen Teil des Beta-Testings selbst vorgenommen.

Das spricht nicht gegen ein Beta-Testing durch Dritte, da dies nicht ersetzbar ist.
Aussenstehende, zumeist User, machen mit Software oft Dinge, auf die man als Entwickler nicht immer kommt.
Und sie geben einem idR. ein Feedback zum Software-Design, welches mir trotz aller Bemühungen um möglichst große
Benutzerfreundlichkeit und intuitive Nuzung ggf. nochmal eine andere Sicht vermittelt.

Hinsichtlich dieses Themas;

Es kam immer wieder mal vor, dass die Einstellungs- und Speichervorgänge bei neuen Firmwareversionen Fehler oder
fehlerhafte Funtionalitäten aufgewiesen haben.
Spätestens beim 2ten Auftreten solcher Sachen beginne ich damit, ein Prozedere zu entwickeln, das mich mit überschaubarem Aufwand checken lässt,
ob derlei Dinge sich in die Logik des neuen Codes eingeschlichen haben.
Das meinte ich.
Gehört für mich seit Ewigkeiten zur Arbeitsroutine.
Erst recht, weil niemand davor geschützt ist, doch an irgendeiner Stelle einen solchen oder ähnliche Bugs ungewollt einzubauen.
Dafür kann man keinen Programmierer verurteilen.

Da die ganze Computerei eine zwiespältige Geschichte im Hinblick auf die große Zahl vermeintlich Wissender und kluger Köpfe ist,
wundert mich die Reaktion im US-Forum nicht sehr.
Ich denke, dort wird es einige Leute geben, die selbst auch Erfahrung mit Softwareentwicklung haben.
Aber jeder hat da idR. seine ganz eigene Philosophie und Herangehensweise.
Und mindestens mal die meisten Autodidakten, die das nicht beruflich machen, sind nicht zwingend so strukturiert, dass sie den Prozess
der Entwicklung und des Designs selbst didaktisch ausreichend durchschauen und erfassen.
Das hat u.a. viel mit strukturiertem Arbeiten, Workflow-Analyse etc. zu tun.
Ein weites Feld.

Und die Fähigkeit, wertfrei und analytisch über dieses spezielle Thema zu diskutieren, ist oft auch nicht besonders ausgeprägt.
Daher holt man sich bei solchen Diskussionen schnell mal ein paar "kluge" Kommentare ab ;-)
Muss man halt sehen;
Manchmal hat der Eine oder Andere ja auch Recht mit Einwänden; man selbst ist ja auch nicht unfehlbar;
Ansonsten ignorieren; schont die Nerven.

Wichtiger wäre ja ohnehin, dass die Mannen von FAS ggf. daraus Nutzen ziehen und ihr Debugging optimieren.

 

[Andy]

Die Code Checker sind, wie gesagt, nur ein erste Schritt. Sobald eine "verzwickte" Parameterübergabe erfolgt, sind die meisten dann auch am Ende. Wobei es auch welche gibt, denen man die Eingangvektoren übergeben kann und damit den Parameterraum abtesten kann. Ist dann aber schon aufwändig.

Aber ich geb dir Recht, bei einem Gerät wie dem AxeFx, bei dem ja fast alles über MIdi ansprechbar ist, könnte man das auch über eine Testsoftware abtesten oder aber auch mit nem Testautomaten über die Bedienfelder der Front. Aber das kostet natürlich.

Ist ja an und für sich immer wieder das gleiche, was es zu testen gibt. Mit akustischer Verifikation könnte man sogar überprüfen, ob die Regler überhaupt eine Funktion haben. Aber das muss jede Firma für sich entscheiden, wie tief sie da einsteigen will. Bei einer Haltung, dass man das AxeFx vom Lebenzyklus mit nem Handy vergleicht, der Chef "empfielt" das AxeFx 24/7 durchlaufen zu lassen (bzw. schreibt, er macht das so und da wär überhaupt kein Problem und das jeder so machen könnte) zeugt nicht davon sich mit gewissen Dingen bewusst, verantwortlich und nachhaltig auseinanderzusetzen.

Fehlerfreie Software wird es allerdings nie geben, das ist schon richtig. Wenn man sich allerdings mal überlegt, was die Software so kann, sollte das eigentlich kein sooo großes Problem sein, d.h. die Komplexität der Software ist ja nicht riesig.

 

[Andy]

Manchmal ist es fast ein Segen keinen "Kontakt" zu Entwicklern und dem Firmenchef zu erhalten. Aus dem Grund les ich auch nichts mehr im US-Forum, weil ich mich da regelmässig über gewisse Aussagen seitens FAS einfach nur aufregen könnte.

 

[mrgodin]

Die Code Checker sind, wie gesagt, nur ein erste Schritt. Sobald eine "verzwickte" Parameterübergabe erfolgt, sind die meisten dann auch am Ende. Wobei es auch welche gibt, denen man die Eingangvektoren übergeben kann und damit den Parameterraum abtesten kann. Ist dann aber schon aufwändig.

Aber ich geb dir Recht, bei einem Gerät wie dem AxeFx, bei dem ja fast alles über MIdi ansprechbar ist, könnte man das auch über eine Testsoftware abtesten oder aber auch mit nem Testautomaten über die Bedienfelder der Front. Aber das kostet natürlich.

Ist ja an und für sich immer wieder das gleiche, was es zu testen gibt. Mit akustischer Verifikation könnte man sogar überprüfen, ob die Regler überhaupt eine Funktion haben. Aber das muss jede Firma für sich entscheiden, wie tief sie da einsteigen will. Bei einer Haltung, dass man das AxeFx vom Lebenzyklus mit nem Handy vergleicht, der Chef "empfielt" das AxeFx 24/7 durchlaufen zu lassen (bzw. schreibt, er macht das so und da wär überhaupt kein Problem und das jeder so machen könnte) zeugt nicht davon sich mit gewissen Dingen bewusst, verantwortlich und nachhaltig auseinanderzusetzen.

Fehlerfreie Software wird es allerdings nie geben, das ist schon richtig. Wenn man sich allerdings mal überlegt, was die Software so kann, sollte das eigentlich kein sooo großes Problem sein, d.h. die Komplexität der Software ist ja nicht riesig.

Es geht nicht darum, die Funktionalität AM GERÄT zu testen!
Wenn der Parameter, um bei diesem Beispielproblem zu bleiben, nicht dauerhaft gespeichert wird,
lässt sich soetwas bereits in der Entwicklungsumgebung testen.
Die Funktionen innerhalb der Software sind ja nicht vom Gerät und seiner Komponenten alleine abhängig;
mit Ausnahme natürlich der technischen Signalverarbeitung.

Und selbst am Gerät geht es ohne Automat recht schnell.
Ein Amp-Block in's Grid, alle Parameter verstellt, im Editor ein csv-File gesichert, einmal das Preset gewechselt,
zurück, erneut ein csv-File gesichert und in WinDiff oder bei mir FileMerge (Mac) verglichen.
Sollte sich ein Unterschied zeigen, wurde dort nicht dauerhaft gesichert.
Soetwas und andere Checks kann man neben dem Codechecking problemlos ROUTINEMÄßIG
nach jeder Fertigstellung eines zu veröffentlichenden Builds durchführen.
Solche kleinen Überprüfungen ergeben sich oft aus der Erfahrung mit wiederkehrenden Bugs.

In bestimmtem Umfang können Codechecker ggf. natürlich auch zusätzliche Hilfe leisten.

Was mich immer wieder fasziniert, wieviel Du über die Haltung von FAS zu ihrem Produkt weisst ;-)
Ich hab öfter den Eindruck, dass Du den gesamten Laden für eine große Abzocke hälst,
bei der es schwerpunktmäßig darum geht, mehr oder weniger naiven Usern ein mittelmäßiges Produkt
aufzuzwingen.
Täuscht mich mein Eindruck?

Fehler machen ist für Dich ein NoGo;
Allerdings, Komplexität von Software kann sehr relativ sein, mein Lieber!
Ich kann Dir versichern, dass die Wahrscheinlichkeit von Fehlern mit dem Umfang der investierten Zeit
in diese Tätigkeit zunimmt ;-)
Selbst wenn man wie ich bei mir den Anspruch des Null-Fehler-Prinzips zugrunde legt.

Das sind Erfahrungswerte.
Ich nehme an, dass Dir in Deinem Job auch schon Fehler unterlaufen sind, die Du nicht einer
beteiligten Komponente anlasten konntest? ;-)

Ich denke, man sollte sich gelegentlich in Nachsicht üben.

 

[Andy]

Nur ganz kurz:
- Nein, ich bin nicht der Meinung, dass FAS seine Kunden abzockt. Vielleicht bin ich beim AxeFx einfach zu früh eingestiegen, als es noch ein wenig mehr drunter und drüber ging. Als nach einem Update alle Sounds wieder ganz anders waren und alle zwei Tage ein neues Update kam, weil in der Release Fehler waren. Ich persönlich hab bei mir im Job höhrer Ansprüche an das "was raus geht". That's it. Wobei der Bug hier in der Tat nicht der Rede wert ist.

- Die Hintergründe oder Einblicke bei FAS geben oder gaben die Jungs ja selbst im firmeneigenen Forum durch eigene Äusserungen oder Verhaltensweisen, auch gegenüber Kritik.

- Grundsätzlich kann man durch den Forscherdrang des Chefs ja schon gewinnen, wenn man sich drauf einlässt. Mir wurde das einfach irgendwann zu anstrengend. Deshalb spielt das AxeFx bei mir eigentlch keine große Rolle mehr. Ich möcht gern einstöpseln und spielen und nicht mehr herumschrauben.

Werd mich zukünftig auch nicht mehr dazu äussern. Weil es mich nicht mehr betrifft.

 

[Deleted member 1155]

Lieber Andy, gib Dir keinen virtuellen Maulkorb - drüben poste ich nicht mehr weil mur da einige Jünger dermassen auf den Sack gehen, dass es mich da überhaupt nicht mehr juckt mitzulesen. Ich weiss wie Amps klingen - und ich weiss auch wieso. Cliff weiss das auch und einige andere User wissen das auch - von denen rede ich nicht. Bezüglich Mike's Zitat - ich schaue zu, "wie die Wanze tanzen kann" und verbleibe vorerst auf Q6.

Aktuell staune ich wie gut meine Eigenentwicklungen sich im "direct to desk"-Betrieb mit analoger Speakersimulation verhalten. Dazu etwas Reverb aus einem 30 Jahre alten Alesis Gerätchen..... Und endlos Spass! Einstecken, spielen - so einfach! Wie gut dass ich weiss was ich tue.....

 

[Andy]

Keine Sorge Paco. Wenn ich was zu sagen hab, reiss ich auch weiterhin "das Maul" auf

Aber ehrlich gesagt geht es mir viel besser, seitdem ich das Axe nur noch als Effektgerät einsetze und mich nur noch wenig damit beschäftige. Seitdem ist es mir auch egal, ob er nach einem Update "meinen" Amp im Axe mal wieder geschreddert hat oder nicht, denn auf meinen echten Amp hat er ja keinen Zugriff haha. Nur manchmal geht's dann mit mir doch wieder durch, wenn ich von nem Bug lese.

 

[Friedlieb]

Ich hoffe, euch beide trotzdem (oder gerade deshalb) auf dem Axe-Fest zu sehen und zu hören!

 

[funkstation777]

Ich hoffe, daß Andy trotzdem seine echte Amp/Cab-Combi und sein Axe plus Matrix zwecks Vergleich mitnimmt.

 

[Deleted member 1155]

...und ich den Wooly (oder eben gar den Wooly Tweakulator - das AxeFx der Röhrentechnik sozusagen...... Und den Ironhaert mit Ironballs Mod

 

[funkstation777]

...und ich den Wooly (oder eben gar den Wooly Tweakulator - das AxeFx der Röhrentechnik sozusagen...... Und den Ironhaert mit Ironballs Mod

:rock: Jawohl, Herr Doktor!!! Mach mir meinen IRT schön böööse!

 

[Andy]

Hast du einen IRT?

Wenn mich der TÜV nächsten Monat nicht von meinem Passat trennt bring ich meinen Amp und Cab mit