Farbprung beim Minutenwechsel, Überblenden und Geschwindigkeit > 0

[RoHA1965]

Farbsprünge bei Tranition Typ Übergang und Speed > 0.
Beim Minutenechsel wird in saveMatrix "act" in "old" gespeichert und "act" neu coloriert.
Dann wird zwischen "old" und "akt" Überblendet und letztendlich ist akt=work wobei work immer die aktuelle Anzeige enthält.
Wenn speed = 0 dann ist das IO, da nach einer minute die Matrix noch immer act=work ist.
Aber wenn speed > 0 ist dann ändert sich die Farbe "work" zwischen den Minuten. Act bleibt wie beim "Minutensprung".
Wenn jetzt die nächste Minute kommt, dann wird wieder das "nicht mehr angezeigte act" in old copiert. Old entpricht aber einem "Urold".
Daruch gibt es einen Farbsprung beim Minutenwechsel weil zwischen "Urold" (also einem old, das aber zwischenzeitlich nicht mehr stimmt) und dem neuen act Überblendet wird.
Das Minutenarray macht bei Geschwindigkeit > 0 auch nicht mit. Die Farbe bleibt beim Mínutenwechsel "hängen".

[dbambus]

Hallo @RoHA1965,

wow, an diesem Bug hab ich etwas zu knabbern. Erst einmal vielen Dank für die detaillierte Beschreibung, dass hat wirklich gut geholfen, zu verstehen das da vor sich geht. In diesem Kontext vielleicht noch wichtig, dass eine der Optionen Bunte Buchstaben oder 'Bunte Wörter' aktiviert sein muss.

Ich habe hier einige Dinge ausprobiert und das zugrundeliegende Problem näher untersucht. Selbst wenn man vor jedem Wechsel direkt in den work in act wechselt, kommt es zu einem störenden Farbwechsel. Da über die led.hpp Routine die gespeicherte Farbe 'G.color[Foreground]' auf dem Stripe gespeichert wird und dann in der 'Transition.hpp' wieder vom Stripe gelesen und in den act geschrieben wird. Dabei kommt es zu einem Farbsprung, da sich 'G.color[Foreground]' nicht ändert. Aktuell aber zu vernachlässigen, da die Transition das komplett überblendet.

Hier mein Lösungsansatz:

1. Die einstellbaren Übergänge sollten auch wirklich nur dann ausgeführt werden, wenn sich etwas an der Matrix ändert und nicht auch wenn Minuten dazukommen. (Für den Fall des Überblendens muss ich mir ein ToDo aufschrieben)

Hierzu hatte eine If-Abrage gefehlt, die ich bald in einem Commit ergänzen werde.

if (changesInWordMatrix != WordclockChanges::Minute) { matrixChanged = true; }

2. Bei jedem MatrixChange = true sollte vor dem Ausführen der 'saveMatrix()' Funktion ein Codeblock folgen, der die aktuelle 'work' nach 'act' schreibt um da den aktellen Stand zu haben. Das es eben kein Urold mehr gibt.

if (isColorization() && (G.transitionSpeed > 0)) {
              copyMatrix(act, work);
          }

Für das Minutenarray habe ich auch etwas gefunden:

hier sollte man statt Foreground -> foregroundMinute schreiben. Somit sollte sich hier die Farbe auch mit ändern.

        for (uint8_t i = 0; i < 4; i++) {
            led.setPixel(minArray[i],
                         HsbColor{m > i ? foregroundMinute : background});

Generell wollte ich jetzt nur Bugfixing betreiben, damit wir irgendwann mal einen fehlerfreien Stand haben. Etwas Neues werde ich bis dahin auf ToDo verschieben.

Denn dieser ganze Code der Übergänge sollte neu geschrieben werden, ich finde es nicht gut, wenn die Farben hier neu analysiert werden müssen und dann wieder manipuliert werden.
Ich möchte gerne für die Versionen nach 4.0.0 ermöglichen, dass von der binären FrontMatrix auf eine Farbmatrix mit Farbinformationen pro Pixel umgestellt wird, sehr ähnlich zu 'work, act, old' nur global. Damit sollten sich solche Fehler hoffentlich nicht mehr einschleichen und so etwas wie farbige Wörter auch ohne Übergänge funktionieren. Ferner steht auf dem ToDo feste Farbverläufe von der ersten Zeile zur letzten Zeile. Das geht allerdings erst nach der Umstellung.

[dbambus]

Testen kann man die Änderungen in meinem Repo https://github.com/dbambus/Wortuhr

[RoHA1965]

Auch wow. Ich hatte nicht mit einem solchen Feedback gerechnet.
Ja, das mit den farbigen Wörten habe ich leider vergessen zu erwähnen.
Ich habe den Code in meinem "work" branch am laufen ohne diese Farbsprünge.
Dazu hatte ich noch einen Fix wegen 10 min vor/nach halb. ABER ich weiß nicht 100% wie sich diese 10min. vor/nach halb auf andere Uhren auswirkt überblicke ich nicht im ganzen. Keiner spell Korrektur im Web "Nach xxx schieben".
Die Minuten auch zu transitionieren :-) hatte ich auch schon gelöst.
Momentan hab ich in meiner Version aber noch das "KEINE" Transition entfernt, und einen Workaround mit der transitionspeed == 0 gemacht, weil ich sonst immer in WLAN hänger laufe, für die ich noch keine plausible Erklärung habe.
Da ich den Code (vor allem das analyzeColors ist mir noch ein Rätsel, das ich zugegebener Maßen nicht intensiv untersucht habe) nicht Vollständig überblicke, wollte ich nicht mit meinen evtl. rudimentären Änderungen tief in andere Uhrversionen eingreifen. Ggfs. mal ein Auge (KURZ) darauf werfen, ob das ggfs doch was zu gebrauchen ist. Bezieht sich ja zu 99% auf die Transition.hpp.
Aber bitte keine Klimmzüge deswegen anstellen.
Der wichtigste Punkt in meiner Änderung ist tatsächlich die Änderung copyMatrix(old, work) in save Matrix().
Denn "work" (nicht mit meine Branch verwechseln) hat ja die aktuellen Anzeigedaten (obwohl es work heißt :-) )
Danke für die super Tolle Entwicklung. Prima Projekt.
https://github.com/RoHA1965/Multilayout-ESP-Wordclock/tree/work