Hallo Leute, ich möchte eine 10x8 Tastenmatrix (mit Dioden - sodass auch mehrere Tasten gleichzeitig gedrückt werden können) aufbauen und mit einem Teensy abfragen. Wird eine Taste gedrückt, so soll der Teensy, welcher sich als Midi-Device ausgibt - eine Midinote senden. Kann mir jemand sagen, wie ich eine möglichst geringe Latenz erreiche? Ist es sinnvoll (und generell möglich) externe ICs wie "tca8418", "ede1188", etc. zu verwenden? Oder ist es schneller, den Teensy alles alleine machen zu lassen? Vielen Dank!
> Kann mir jemand sagen, wie ich eine möglichst geringe Latenz erreiche? Häufig scannen und Tasten nehmen, die wenig prellen. > Oder ist es schneller, den Teensy alles alleine machen zu lassen? Wenn du genügend Pins frei hast, nimm den. Tasten scannen macht der im Schlaf nebenbei. Da hast du auf jeden Fall die Möglichkeit, das Scannen deinen Bedürfnissen beliebig anzupassen. Btw, die von dir genannten ICs sind nicht allzu fix - Scannintervall 25ms und mehr.
Das Thema wird seit einer Woche hier schon heiß diskutiert: Beitrag "4x4 Matrix Tastatur am FPGA" Das Teensy müsste genug Pins haben, um eine passive Matrix abzutasten. Kann das die IOs auf Tristate schalten? Wenn nicht, alle Schalter linksseitig auf GND, einen der PWM-Ausgänge verwenden, um Latches/Schieberegister am Ausgang der Schalter damit zu takten und so alle Tasten nacheinander abzuholen. Wären 10 Register-Chips und 80 Takte. Statt der Dioden dann einfach pulldowns an den Chip-Eingängen. Die Taktfrequenz zwischen 100kHz ... 200kHz. Oder Du machst es analog mit einem DAC und einen Analogmultiplexer: Immer 5 Schalter über -> "R2R" an eine Leitung und diese 16 Leitungen multiplexen und mit Teensy-DAC auswerten, falls noch frei. Es müssten theoretisch 1% Widerstände reichen. Ich würde aber für die hohen beiden bits 0,1% nehmen. Bei geschickter Spannungsdimensionierung kriegst Du das Schaltermuster direkt als Bitmuster vom DAC heraus. Das Prellen sollte kein Problem sein, wenn Du einfach nach jeder Änderung eines gelesenen Bits einen timeout von 50ms setzt. Damit erwischt man die Information bei der ersten Änderung und ignoriert das Prellen. Drehencoder sind da etwas schwieriger auszuwerten. Das Teensy ist sicher schnell genug, das zu verarbeiten. Die Latenz dürfte eher in Richtung USB-PC entstehen. Mich würde im Übrigen interessieren, wie die MIDI-USB-response des Teils im Detail aussieht, weil ich das auch für meine Zwecke im Auge habe: Beitrag "Universelles Eingabegerät mit Drehencodern" Kannst Dazu was sagen?
:
Bearbeitet durch User
foobar schrieb: > Btw, die von dir genannten ICs sind nicht allzu fix - Scannintervall > 25ms und mehr. Das reicht ja auch fürs Texteintippen, selbst für rekordverdächtige Schnellschreib-Sekretärinnen, die es garnicht mehr gibt. Bei Musik sieht das natürlich anders aus. Aber auch eine rein mechanische Klaviertaste erzeugt nicht in 0 ms einen Ton. Ist nicht mein Fachgebiet, aber ich würde davon ausgehen, dass es für einen Musiker irritierend wäre, wenn die elektronische Tastatur anders reagiert als die traditionelle, auch wenn es schneller ist, bei langsamer sowieso. Scanzeit, Entprellung und Reaktionsverzögerung kann man nur mit einem Controller und Software nach Wunsch einstellen. Georg
> Aber auch eine rein mechanische Klaviertaste erzeugt nicht in 0 ms > einen Ton. Aber evtl mehrere schnell hintereinander. Wenn ich mit dem Finger einmal quer über die Klaviatur wische, hab ich problemlos 40 Tasten in ner halben Sekunde angeschlagen und wieder losgelassen. Wenn man die einzeln zeitlich auflösen möchte, reichen 25ms Scanintervall nicht mehr.
paulx schrieb: > Kann mir jemand sagen, wie ich eine möglichst geringe Latenz erreiche? > Ist es sinnvoll (und generell möglich) externe ICs wie "tca8418", > "ede1188", etc. zu verwenden? Oder ist es schneller, den Teensy alles > alleine machen zu lassen? Der Mensch schafft ca. 10 Hz. pro Taste, (=100ms) da fällt die Scan- und Entprellzeit kaum ins Gewicht. Wenn nötig leg die scanlines auf einen Interrupt (über Dioden entkoppelt), dann hast du so was wie "Echtzeit" = garantierte Reaktionszeit.
X4U schrieb: > Der Mensch schafft ca. 10 Hz. pro Taste, (=100ms) da fällt die Scan- und > Entprellzeit kaum ins Gewicht. Glaubst du ernsthaft, daß ein Musiker seine Noten im 0.1-Sekunden Raster spielt ?
georg schrieb: > Ist nicht mein Fachgebiet, aber ich würde davon ausgehen, dass es für > einen Musiker irritierend wäre, wenn die elektronische Tastatur anders > reagiert als die traditionelle, Wegen traditionell: Du solltest mal auf einer voll pneumatischen Orgel spielen ;-) paulx schrieb: > ich möchte eine 10x8 Tastenmatrix (mit Dioden - sodass auch mehrere > Tasten gleichzeitig gedrückt werden können) aufbauen und mit einem > Teensy abfragen Für welche Anwendung oder mit welcher Ansprechzeit? Was sind das für Tasten(kontakte)?
Hallo, das passt vielleicht nicht genau auf die Anforderungen, aber hier geht es um das optimieren der latenz einer PC Tastatur mit USB Interface, vielleicht findest du da ein paar Anregungen. GPN18 - kinX: keyboard hacking https://media.ccc.de/v/gpn18-19-kinx-keyboard-hacking https://www.youtube.com/watch?v=H2fipGm2ysY
Michael B. schrieb: > Glaubst du ernsthaft, daß ein Musiker seine Noten im 0.1-Sekunden Raster > spielt ? Scheint so. Auch mir will man immer einreden, man könne 10ms nicht hören. Kann man aber sehr wohl!
Michael B. schrieb: > Glaubst du ernsthaft, daß ein Musiker seine Noten im 0.1-Sekunden Raster > spielt ? Naja, 100ms sind bei 150bpm eine sechzehntel Note. Das ist mit ein wenig Üben bei einem unkomplizierten Lauf schon drin... Organist schrieb: > Kann man aber sehr wohl! Hast du da mal ein Beispiel mit echter Musik? 10ms entsprechen bei 180bpm(!) etwa einer 1/64 Note. Das hörst man bestenfalls bei synthetischem und überaus perkussivem Tonmaterial.
Lothar M. schrieb: > Michael B. schrieb: >> Glaubst du ernsthaft, daß ein Musiker seine Noten im 0.1-Sekunden Raster >> spielt ? > Naja, 100ms sind bei 150bpm eine sechzehntel Note. Das ist mit ein wenig > Üben bei einem unkomplizierten Lauf schon drin... Ich befürchte, du hast nicht verstanden, wie rum ich das meinte...
:
Bearbeitet durch User
Wenn es um die Messung und Einstellung eines MIDI-Tempos geht, muss das schon sehr genau sein, weil der Rhythmus sonst wegläuft. Die virtuellen DJ-Maschinen und -turnttable, die mit MIDI arbeiten, haben sowas manchmal drin. 1% wäre da schon anzustreben und das erfordert bereits mehrere Tippimpulse und sehr genaues Messen. 100ms geht da gar nicht. 1ms würde ich mal nehmen. Trotzdem man muss immer wieder Tippen, um zu synchen, um "in Phase zu bleiben". Für dieses Problem habe ich allerdings eine andere Lösung, die ich mal in der Access-Gruppe vorgeschlagen hatte: Man analysiert das Spiel des Keyboardmanuals und ermittelt daraus das Tempo, das Raster und auch den Offset der Noten infolge leicht falschen Spiels. Damit sind die Noten in Echtzeit zu quantisieren. Diese Mimik habe ich in meiner Workstation drin. Das Musikstück muss natürlich ein paar Sekunden laufen, um das Tempo zu haben und arbeiten zu können und man braucht eine retrigger-Methodik bei Pausen und und und ... sozusagen eine MIDI-PLL. Wenn das wirklich benötigt wird, sollte man eine extra Taste vorsehen.
Jürgen S. schrieb: > Wenn das wirklich benötigt wird, sollte man eine extra Taste vorsehen. Lothar M. schrieb: > Organist schrieb: >> Kann man aber sehr wohl! > Hast du da mal ein Beispiel mit echter Musik? > 10ms entsprechen bei 180bpm(!) etwa einer 1/64 Note. Das hörst man > bestenfalls bei synthetischem und überaus perkussivem Tonmaterial. Braucht man dazu Tonmaterial? -180 BPM sind 3Hz. -3Hz sind 333ms für den Takt -sind 80ms für die Viertel -sind 20ms für die Sechzehntel -sind 2ms für die Position der 16tel bei Lageunsicherheit von 10% und eigentlich möchte man Notenposition und Notendauer deutlich genauer haben, als die Notenlängeneinteilung des Taktes weil sonst ist es kein Takt X4U schrieb: > Der Mensch schafft ca. 10 Hz. pro Taste, (=100ms) da fällt die Scan- und > Entprellzeit kaum ins Gewicht. Das ist doch vollkommen unerheblich. Auch wenn er nur einmal pro Sekunde drückt, kommen bei einem Akkord gleich mehrere Tasten gleichzeitig. Auch kann man eine Taste mit zwei Fingern betätigen. Und man kann, wie hier gefordert, feststellen wollen, wann die Taste gedrückt wurde. Alle 100ms eine Information ist weit weitem zu ungenau.
Organist schrieb: > Alle 100ms eine Information ist weit weitem zu ungenau Ja, aber selbst normales Midi sendet mit 31250baud und damit in unter 1ms eine Note, und es ist nicht nötig, mehrere 'Tasten' schneller parallel spielen zu können. Wenn alsó eine Implementation ein Geschwindigkeitsproblem hat, liegt es an der Implementation, nicht an Midi. Nur Lightshow-Effekte können bei vielen Lichtern und shcnellen Effekten mal ein Problem haben, aber nicht Musik. Man muss auch nicht mit jedem Tastendruck gleich das komplette Setting des Instruments mitsenden. Man könnte auch special events definieren, mit denen ganze Abläufe 'Polyphonic key pressure' durch ein Kommando angestossen werden.
Michael B. schrieb: > Ja, aber selbst normales Midi sendet mit 31250baud und damit in unter > 1ms eine Note, und es ist nicht nötig, mehrere 'Tasten' schneller > parallel spielen zu können. Für einzelne Funktionstasten stimme ich zu. Aber: > Wenn alsó eine Implementation ein Geschwindigkeitsproblem hat, liegt es > an der Implementation, nicht an Midi. Nur Lightshow-Effekte können bei > vielen Lichtern und shcnellen Effekten mal ein Problem haben, aber nicht > Musik. Musik hat sicher mehr Noten und einen höheren Anspruch an gleichzeitiges Erscheinen, als Beleuchtung, oder?
paulx schrieb: > Kann mir jemand sagen, wie ich eine möglichst geringe Latenz erreiche? Die vorgeschlagenen Bauteile kenne ich nicht, würde aber sagen, dass MIDI mit jedem popeligen µC zu machen sein muss. Serielle Übertragung von 30kbps machen uralte Teile. Es käme nur darauf an, die Tasten bis dahin zu checken. Im Arduinoforum gibt es gefühlt 100 Tastaturabfragebeispiele.
Hier wird wieder Vieles gleichzeitig diskutiert, nämlich Abtastrate für gleichzeitiges Drücken, Übertragungsrate für alle Tasten, Sonderfall Musik. Urspünglich ging es eigentlich gar nicht um MIDI, sondern nur um eine Tastenabfrage von 80 Tasten. Was "gleichzeitig" hier heißen soll, ist wie der Anwendungsfall noch offen. Für mich sind Tasten dann gleichzeitig, wenn die Zeitdifferenz maximal dem entspricht, was eine typische Person erreicht, wenn sie das auszulösen versucht. Das sind maximal wenige 10 Millisekunden im Bereich der Echogrenze, bei zwei individuellen Tasten. Es geht aber noch erheblich schneller: foobar schrieb: > Aber evtl mehrere schnell hintereinander. Wenn ich mit dem Finger einmal > quer über die Klaviatur wische, hab ich problemlos 40 Tasten in ner > halben Sekunde angeschlagen und wieder losgelassen. Wenn man die einzeln > zeitlich auflösen möchte, reichen 25ms Scanintervall nicht mehr. Das ist es. Um nun "Gleichzeitig" von "nacheinander" zu trennen, komme ich hier schon auf eine Taste in 10ms und eine Anforderung der Präzision von 1ms. Gröber darf das in diesem Fall nicht sein. Michael B. schrieb: > Ja, aber selbst normales Midi sendet mit 31250baud und damit in unter > 1ms eine Note, und es ist nicht nötig, mehrere 'Tasten' schneller > parallel spielen zu können. Das ist natürlich eine interessante Interpretation, nicht mehr Tasten anzunehmen, als man übertragen kann. Ich sehe das etwas anders: Einmal sollte MIDI kein Kriterium für diesen Fall sein, zum anderen ist dieses MIDI ja veraltet und bereits ersetzt. Letztlich wäre es sogar nicht einmal ein show stopper für schneller gewonnene Information, denn: Tech N. schrieb: > MIDI mit jedem popeligen µC zu machen sein muss. Serielle Übertragung > von 30kbps machen uralte Teile. Es käme nur darauf an, die Tasten bis > dahin zu checken. Das ist richtig, wenn nur eine in Echtzeit übertragen werden soll. Binnen einer Wiederholrate von 100ms für das Drücken von Tasten mit denselben Fingern kann man aber auch mit normalem MIDI bis zu 100 solcher Informationen übertragen und mittels MTC auch als "gleichzeitig" einstufen.
Und da hier schon MIDI als Kriterium eingeflossen ist, noch folgender Punkt: Man muss wie schon angedeutet die Übertragungsrate von der internen Takt-Präzision der Geräte trennen. MIDI arbeitet intern mit mindestens 96 Zeitschritten je MIDI-Note und bei 240bpm wäre das immerhin 384Hz und somit 3ms Auflösung. Damit die Sinn machen, sollten die Noten, bzw. deren Zeitstempel schon auf 1ms genau liegen. Sofern ein Gerät einen MIDI-Trigger bekommt, synched es sich im Tempo oft deutlich genauer, weil es ständig Tempo-Codes bekommt und sich drauf einstellt. Will man Klänge layern, sind 0,1ms anzustreben. Trotzdem gibt es Musiker, die damit nicht zufrieden sind und stellen z.B. ein 80er Blues-Tempo gerne auf 160, um mehr Präzision zu haben. Das gerne angeführte Argument, dass sich Musiker selber um den eigentlichen Takt herumbewegen, hat oft musikalische Ursachen und ist Ausdruck deren Stimmung. Das ist ein musikalischer "jitter" oder "offset". Kommt z.B. ein dominantes Instrument wie die bass drum etwas hinter dem Takt, wirkt es verschleppend und beruhigend - umgekehrt pushend und beschleunigend. Das ist Teil des musikalischen Ausdrucks und funktioniert nur, wenn die zeitliche Position des Akzents stimmt. Da kann man keine 10ms hin und her gebrauchen. Der zufällige Offset, den ich bei guten Musikern sehe, bewegt sich im Bereich von 1..2ms und darunter! Das Thema wird gerne unterschätzt und ist mithin ein Grund, warum viele Musiker MIDI meiden, obwohl man sich dort inzwischen angepasst hat und höhere Auflösungen bis zu 960 ticks je Viertelnote zulässt. Warum es genau das 10/40fache ist, weiß ich nicht, aus musikalischer Sicht wäre das 12/48-fache die bessere Option, weil es für die jeweils benötigten Takte 3,4,6 er mehr zusätzliche Feinheit zulässt. Vielleicht war die Intention, auch 5er Takte genau abbilden zu können, was mit 4x96 nicht geht. Mein MIDI arbeitete von Anfang an mit 1024 Zeitfragmenten je beat, von daher ist es Wurscht. Das Problem, dass das normale MIDI heute aber nach wie vor hat, ist der zu große Abstand und der Jitter im Taktsignal selbst. D.h. die Geräte könnten zwar theoretisch sehr genau das Tempo stabilisieren und auch Änderungen folgen - sie könnten es sogar so genau, dass die Granularität keine Rolle mehr spielt - aber sie kriegen den Takt von Außen nicht genau genug. Sie kriegen ihn übrigens selbst bei einer Handeingabe nicht genau. Dies aber nicht etwa deshalb nicht, weil die Musiker nicht rhythmisch genug drücken können, sondern, weil die Tastenabfragen nicht funktionieren ! Das kann man leicht selber feststellen, wenn man mit dem Fingernagel auf dem Tisch einen Rhythmus klopft und es aufnimmt: Das ist super präzise im Vergleich zu dem, was man über MIDI mittels der modernen touch pads in den Controllern rein bekommt. Erstaunlich, aber wahr. Entweder tasten die nicht schnell genug ab, oder es haut mit dem time code nicht hin. Auch über USB-MIDI klappt es nicht annähernd so genau, wie es die Audioaufnahme vermuten lässt. (Wegen der Fingernägel ist das Signal recht hochfrequent und damit gut beurteilbar). Die Geräte addieren immer noch bisschen zusätzlichen Fehler. Sei es wegen der Übertragung des Taktes, der Synchronisation des Empfängers oder was auch immer. Vielleicht spielen in der Tat unzureichende Überlegungen bei der Tastaturabfrage eine Rolle. Siehe auch hier: Beitrag "Re: MIDI-Latenzen"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.