Der Code ist sehr interessant.

Mir fällt dein flush an diversen Stellen auf. Du rufst an verschiedenen Stellen ein flush auf, jedoch außerhalb der Funktion wo ein Midi Befehl gesendet wird. Beispiel noteOn erstellt ein Befehl und da wäre es logisch, wenn es sofort gesendet werden soll auch unmittelbar vor verlassen der Funktion ein flush zu machen, anstatt irgendwo anders.

Bei deiner Lösung zum entprellen musst du etwas aufpassen. millis läuft nach einer gewissen Zeit über und beginnt dann wieder bei 0. Soweit ich weiß sind es wohl etwa 50 Tage. Im Normalfall also bei einem Spieltisch nicht relevant. Aber wenn z.B der USB Anschluss weiter Strom liefert, dann hättest du diese Zeit irgendwann erreicht und wunderst dich, warum es nicht mehr funktioniert. Entweder nutze eine andere Möglichkeit, oder setze im Loop eine Kontrolle ein, ob es zu einem Überlauf gekommen ist. Wenn millis bei einer Abfrage plötzlich kleiner ist als vorher, dann hat wohl ein Überlauf stattgefunden und du solltest alles zurücksetzen. Wie gesagt, wird vermutlich nicht relevant sein, aber wenn es doch einmal passiert, dann stehst du erst einmal auf dem Schlauch :)

Zum entprellen kannst du auch fertige Bibliotheken wie Bounce2.h nutzen. Die von dir genannten Keypad Helfer haben das meist auch schon mit drinnen. Ich habe damit jedoch eher negative Erfahrungen gemacht, da diese Bibliotheken oft wenig flexibel sind und einige können auch nur eine einzige Matrix abfragen. Hast du mehrere oder geteilte, dann stößt man dort an die Grenzen.

Auf der anderen Seite wird der Code extrem schlank, hier ein Beispiel für die sichere Abfrage auf einem Pi Pico mit Python:

# Importe
# =======
import time
import board
import busio
import usb_midi
import keypad
 
import adafruit_midi
from adafruit_midi.note_off import NoteOff
from adafruit_midi.note_on import NoteOn
from adafruit_bus_device.i2c_device import I2CDevice
 
from digitalio import DigitalInOut, Direction, Pull
 
# Variablen
#==========
midiChannelOut = 1
midiChannelIn = 1
 
midi = adafruit_midi.MIDI(midi_out=usb_midi.ports[midiChannelIn], out_channel=midiChannelOut)
 
# Pins für die Tastenmatrix
km = keypad.KeyMatrix(
    row_pins=(board.GP0, board.GP1),
    column_pins=(board.GP2, board.GP3, board.GP4),
)
 
# Midi Keycode für die dazugehörige Taste
KEYCODE = (51, 52, 53, 54, 55, 56)
 
# sendNoteOn sendet ein NoteON mit den übergebenen
# Parameter
def sendNoteOn(keycode, velocity=127):
    midi.send(NoteOn(keycode, velocity))
 
# sendNoteOn sendet ein NoteON mit den übergebenen
# Parameter
def sendNoteOff(keycode, velocity=0):
    midi.send(NoteOff(keycode, velocity))
    
# Hauptschleife
while True:
    event = km.events.get()
    if event:
        sendNoteOn(KEYCODE[event.key_number]) if event.pressed else sendNoteOff(KEYCODE[event.key_number])
 

Kompakter geht es wohl nicht mehr :)

Zitat von Christian_Hofmann im Beitrag #122

---

Der Code ist sehr interessant.

---

Zitat von Christian_Hofmann im Beitrag #122

---

Mir fällt dein flush an diversen Stellen auf. Du rufst an verschiedenen Stellen ein flush auf, jedoch außerhalb der Funktion wo ein Midi Befehl gesendet wird. Beispiel noteOn erstellt ein Befehl und da wäre es logisch, wenn es sofort gesendet werden soll auch unmittelbar vor verlassen der Funktion ein flush zu machen, anstatt irgendwo anders.

---

Zitat von Christian_Hofmann im Beitrag #122

---

Bei deiner Lösung zum entprellen musst du etwas aufpassen. millis läuft nach einer gewissen Zeit über und beginnt dann wieder bei 0. Soweit ich weiß sind es wohl etwa 50 Tage. Im Normalfall also bei einem Spieltisch nicht relevant. Aber wenn z.B der USB Anschluss weiter Strom liefert, dann hättest du diese Zeit irgendwann erreicht und wunderst dich, warum es nicht mehr funktioniert. Entweder nutze eine andere Möglichkeit, oder setze im Loop eine Kontrolle ein, ob es zu einem Überlauf gekommen ist. Wenn millis bei einer Abfrage plötzlich kleiner ist als vorher, dann hat wohl ein Überlauf stattgefunden und du solltest alles zurücksetzen. Wie gesagt, wird vermutlich nicht relevant sein, aber wenn es doch einmal passiert, dann stehst du erst einmal auf dem Schlauch :)

---

Zitat von Christian_Hofmann im Beitrag #122

---

Zum entprellen kannst du auch fertige Bibliotheken wie Bounce2.h nutzen. Die von dir genannten Keypad Helfer haben das meist auch schon mit drinnen. Ich habe damit jedoch eher negative Erfahrungen gemacht, da diese Bibliotheken oft wenig flexibel sind und einige können auch nur eine einzige Matrix abfragen. Hast du mehrere oder geteilte, dann stößt man dort an die Grenzen.

---

Zitat von Brassmann im Beitrag #123

---

Aber sogar die ehrwürdige Sabine arbeitet mit Flush!

---

Pins sind massig frei, könnte es auch über klassische MIDI Schnittstelle senden. Sabine nutzt meines Wissens den Due, aber nicht mit dem USB-Versand. Schweller könnte ich mal auskommentieren, der dürfte aber nicht ins Gewicht gefallen sein, weil ich das Schwellpedal beim Manual testen nicht berührt habe. Somit gibt es keine Änderung und keinen Durchlauf der Schleifen.

@Montre
Jetzt haben wir Bernds Thema gekapert. Vielleicht lagerst du diesen Midi-Strang in ein neues Thema aus?

Bei Python tatsächlich nicht, was ich sogar logischer finde.

Führe sendNoteOn aus wenn event.pressed wahr ist, wenn es nicht wahr ist, dann führe sendNoteOff aus.

Tritt keine Veränderung ein, dann wird die Zeile übersprungen. Theoretisch könnte man das if event auch noch einbauen, aber ich schreibe nur ungern Code, welchen ich nach einigen Monaten selbst nicht mehr verstehe. Mit solchen "Erleichterungen" kann man durchaus Code schreiben, der nicht mehr nachvollziehbar ist. Daher ist es objektiv gesehen besser so etwas nicht zu machen und lieber mehrere IF Blöcke zu schreiben... Aber die Faulheit siegt :)

Ich bin kein Entwickler von Interpreten oder Compiler, spannend wäre aber die Frage ob sich beide Varianten in der Ausführungszeit unterscheiden...

Die Methode verwende ich daher nur mit stabilen PIN Zuständen, also Input pullup oder bei Tastendruck halt LOW oder anders herum, je nachdem ob NO oder NC.

Zitat von Christian_Hofmann im Beitrag #12

---

Ich kenne deinen Code nicht, ich vermute, dass du in den Funktionen noteon und noteoff ein sendMIDI einfach ausführst oder? Versuche mal hinter den sendMIDI direkt ein delayMicroseconds(300); zu setzen und entferne zusätzlich einmal alles flush aus deinem Code (auskommentieren).

---

Das es so funktioniert ist meines Erachtens nach ein Indiz, dass du das gleiche Problem hast wie ich. Du sendest etwas und kurze Zeit später wird wieder etwas geehrt, bevor der Controller wieder bereit ist. Dieses midiusb ist einfach Murks. Es läuft zwar auf dem Due, aber der Entwickler unterstützt diesen wohl nicht selbst. Auf anderen Modellen funktioniert das ohne Probleme.

Mit den Optimierungen ist das immer so eine Sache. Man kann in dem Code wohl eine Menge verbessern, aber ob der Aufwand den Nutzen überwiegt?

Bei solchen eigenen Lösungen kommt es ja weniger auf perfekte Leistung an, sondern unterm Strich darauf, dass es funktioniert. Das fängt ja schon an bei solchen Geschichten wie die Notennummer. Im Code steht bei ihm, genau so wie bei mir Tastencode 49,50,51 und so weiter. Ganz spontan gefragt ohne nachzuschauen, was für eine Note verbirgt sich hinter dem Code 85?

Ich weiß es nicht, daher wäre es sinnvoll im Code Enums zu nutzen, statt Midi Notennummern. Also Beispiel:

num MidiNote {
  C1 = 36,
  Csharp1 = 37,
  // ...
};
 

Nur ist es das Wert für ein Hobby Projekt an dem keiner außer man selbst arbeitet? Ich habe meinen Code damals geschrieben und seit dem er funktioniert, habe ich einige Jahre nichts mehr daran verändert :)

Ich lese hier interessiert mit wie ihr eure Midilösungen programmiert.
Mal eine andere Frage dazu. Wie führt ihr die Midisignale der einzelnen arduinos zusammen?
Gruß
Bernd