Probleme mit CMD_PREVTRACK

Ich habe lediglich einen rotary encoder bei meinem ESPUINO angebracht. Der steuert die Lautstärke, weckt den ESP auf und bei Gebrauch dient ein einzelner Klick als CMD_NEXTTRACK und ein langer Klick als CMD_PREVTRACK. Das funktioniert soweit auch - nur aus irgendwelchen Gründen springt er nicht zum vorherigen Track zurück, sondern spielt den aktuellen Track von vorne. In der Console wird der richtige Befehl angezeigt, der gleiche, wenn ich’s über die WebUI steuere, wo es aber funktioniert. Bin ein wenig ratlos.

Okay, ich habe jetzt verstanden, dass wenn der Track bereits eine gewisse Zeit läuft, er erstmal den Track neustartet.

Kann man das modifizieren? Und: Gibt es eine Möglichkeit, dass der ESP den langen Knopfdruck schon nach einer gewissen Zeit umsetzt und nicht erst beim release des buttons?

Exakt:

Klar. Dafür musst du die Zeilen 517 bis inkl. 523 auf das einkürzen, was in Zeile 521 steht.
Man will halt letztlich auch die Möglichkeit haben, dass man an den Anfang eines Titels geht. Daher habe ich das irgendwann einfach mal so festgelegt.

Nein, das ist aktuell nicht vorgesehen.

1 „Gefällt mir“

Nachtrag noch: Ich wäre aber offen dafür, wenn das jmd. ändern möchte und dafür einen PR einreicht. Weil ich kann schon verstehen, dass das eigentlich etwas unpraktisch ist, weil man nicht so genau weiß, wann die Zeit für long erreicht ist. Also drückt man länger als notwendig, weil man das Event sicher erreichen will. Ne? :slight_smile:

2 „Gefällt mir“

Grundsätzlich geht das mit Änderungen im Code (die Auswahl ist hart codiert). Mit diesen Änderungen kannst du das Verhalten von CMD_PREVTRACK gleich setzten mit der Steuerung der Lautstärke. D.h. sobald die Zeit abgelaufen ist um einen langen Tastendruck zu erkennen wird die Aktion ausgeführt. Die Aktion wird auch mehrfach getriggert, so lange die Taste gedrückt ist.

diff --git a/src/Button.cpp b/src/Button.cpp
index 7680a99..946b178 100644
--- a/src/Button.cpp
+++ b/src/Button.cpp
@@ -310,13 +310,13 @@ void Button_DoButtonActions(void) {
                                                Cmd_Action(Cmd_Short);
                                        } else {
                                                // if not volume buttons than start action after button release
-                                               if (Cmd_Long != CMD_VOLUMEUP && Cmd_Long != CMD_VOLUMEDOWN) {
+                                               if (Cmd_Long != CMD_VOLUMEUP && Cmd_Long != CMD_VOLUMEDOWN && Cmd_Long != CMD_PREVTRACK) {
                                                        Cmd_Action(Cmd_Long);
                                                }
                                        }

                                        gButtons[i].isPressed = false;
-                               } else if (Cmd_Long == CMD_VOLUMEUP || Cmd_Long == CMD_VOLUMEDOWN) {
+                               } else if (Cmd_Long == CMD_VOLUMEUP || Cmd_Long == CMD_VOLUMEDOWN || Cmd_Long == CMD_PREVTRACK) {
                                        unsigned long currentTimestamp = millis();

                                        // only start action if intervalToLongPress has been reached

Aber ich kann dir gleich sagen, das ist nur ein schneller Hack. Die Handhabung ist sehr schwer, man überspringt mal sehr schnell 2-3 Tracks zur gleichen Zeit und es gibt nur den visuellen Feedback durch die Anzeige.

1 „Gefällt mir“

Hätte Lust mich dem anzunehmen mit dem Button-Verhalten, falls sonst niemand das angehen möchte :slight_smile: .
Damit es dafür einen Konsens gibt:
Meine Idee wäre es, dass wenn das Long-Press-Intervall erreicht ist, der Befehl ausgeführt wird, aber nicht erneut getriggert wird, bis der Release kam.
Eventuell könnte man auch nach dem ersten Longpress-Intervall noch ein weiteres Intervall definieren, nachdem dann bei andauerndem drücken doch noch züklisch der Befehl ausgeführt wird.
Also z.B.
Button gedrückt - Warten Intervall Longpress - CMD - warten Intervall 2 - CMD - warten kurzes Intervall - CMD - warten kurzes Intervall - CMD …

Nach einem Release dann wieder von vorne…

Ist das verständlich was ich denke ^^?
Wäre für alle Vorschläge offen :slight_smile:

Genau so habe ich mir das vorgestellt, ja :slight_smile:

Also der erste Part ist ok für mich.
Aber noch ein Intervall!? Leute… das Ding ist für Kinder! Das kapiert doch niemand mehr.

1 „Gefällt mir“

Könnte man nicht statt Intervall 2 und kurzes Intervall weiter das Longpress Intervall verwenden? Dann müsste man zwischen mehreren Longpress nicht loslassen, aber es käme kein extra Intervall dazu und man hätte zwischendurch auch genug Zeit loszulassen.

1 „Gefällt mir“

Hi Zusammen:
hier schonmal die Änderung mit dem direkten ausführen beim erreichen des longpress-intervalls:

Auf diese Art wird der Befehl direkt beim erreichen des longpress-Intervalls ausgeführt und auch nicht erneut getriggert.

Was hier exrtra berücksichtig werden musste ist der CMD_SLEEPMODE. Da wenn dieser schon vor Release ausgeführt werden würde, es direkt ein wakeup beim release geben würde…

Wahlweise kann man es auch so lösen, dass es zyklisch immer nach dem intervall erneut getriggert wird. Auch das könnte ich mir gut vorstellen, bei allem weiteren muss ich @biologist zustimmen, das das einfach zu weit gehen würde :slight_smile:

1 „Gefällt mir“

Das sieht doch gut aus! Willst Du dafür einen PR erstellen?

Mache ich gerne. Will aber nochmal ein paar Dinge testen und anschauen. Und davor noch verstehen wie es zu der aktell schlechten Performance auf dem dev-branch bei mir kommt :slight_smile: .
Könnte also erst morgen oder so werden…

@Joe91 Vielen Dank für den Deinen PR, Ihr könnt gern nochmal drüberschaun:

1 „Gefällt mir“