MIDI Ereignisse präzise timen / Timer allgemein

[arc]

Ich arbeite an einem kleinen Midi Projekt und möchte die Daten, die an den Midi Ausgang gesendet werden möglichst zeitlich korrekt senden. Ich lese die zu sendenden Midi Daten alle ein, sie liegen im Speicher, ich weiß in welcher zeitlichen Reihenfolge was gesendet werden muß.

Nun möchte ich eigentlich keine Schleife bauen die 1ms wartet und dann immer schaut ob das nächste Midi Ereignis dran ist. Als Alternative ist mir eingefallen, daß sich die Schleife mit timeout/sleep von Ereignis zu Ereignis hangelt. Also ein Ereignis senden und dann solange schlafen bis das nächste dran ist. Dann wieder senden und so weiter.

Ich befürchte aber, daß ich so einen relativen Fehler bekomme der sich immer weiter aufsummiert - der ganze Ablauf soll synchron zu anderen Geräten erfolgen und ich möchte eine möglichst geringe Abweichung vom "idealen" Timing.

Jetzt kommt aber noch etwas dazu, ich möchte auch eine Art "Mixer" einbauen, der zwei Midi Dateien ineinander überblenden kann. Das heißt je nach Interaktion des Nutzers kommen dynamisch neue Ereignisse hinzu oder verschwinden alte.

Das ganze muß also möglichst präzise und dazu noch flexibel sein. Ich bin ehrlich gesagt etwas ratlos, fast hätte ich für jedes Ereignis einen TTimer angelegt aber das kann doch auch nicht effizient sein oder?

Ich bedanke mich schonmal für alle Tips!

[arc]

Ich habe in einem anderen Thema gelesen, daß die TTimer in Delphi nur bis 10-20ms runterkommen, was hat es damit aufsich? Kann man gar nicht exakt timen? Ich könnte es mir so vorstellen, daß ich eine Fehlerrechnung mache, also ermittel wie viel Zeit der Timer bereits drüber ist und den nächsten entsprechend kürzer stellen, damit sich das kompensiert. Hat wirklich niemand Erfahrung damit?

Wie machen denn z.B. die ganzen 3D Spiele sowas? Bei 60 FPS ist aller 16,7ms ein neues Bild dran, das muß ja auch relativ präzise und stabil getimed werden, sonst fühlt sich das Spiel komisch an...

[generic]

Zitat von arc:

Wie machen denn z.B. die ganzen 3D Spiele sowas? Bei 60 FPS ist aller 16,7ms ein neues Bild dran, das muß ja auch relativ präzise und stabil getimed werden, sonst fühlt sich das Spiel komisch an...

Windows ist KEINE Echzeit-Betriebssystem!
Die Grafikkarte schickt einen IRQ zum OS.

Man abgesehen davon, die Bildwiederholungsfrequenz/Darstellungsfrequenz ist nicht die Frequenz in welcher das Bild berechnet wird.

[divBy0]

Benötigst du wirklich eine Genauigkeit von 1ms?

[arc]

Nein, bis zu 10 ms sind okay. Was mir aber Probleme bereitet, sind Folgefehler, ich muß synchron bleiben. Deswegen die Ausgangsfrage, wie man das am besten löst.

Mit einem Timer und einer Liste von Ereignissen und Wartezeiten? Ist ein Ereignis dran, wird der Timer neu gestellt und wartet ab. Das hat aber mM nach den Nachteil, daß sich die Fehler aufaddieren.

Die Alternative Idee was es, für jedes Ereignis einen eigenen Timer zu erzeugen und zu stellen. Aber das ist wahrscheinlich auch nicht wirklich geschickt bei 300+ Ereignissen.

Daher die Idee irgendwie den Fehler zu ermitteln und zu korrigieren, hab nur keine Idee so recht.

[Medium]

Sobald Windows Messages ins Spiel kommen, kannst du die Genauigkeit knicken. Die sind (bzw. genauer: der Scheduler) gerade auch beim TTimer das Problem. Mögliche Wege wären der Multimedia-Timer (Unit MMSystem), der mit einem Callback statt Messages arbeitet, oder aber ein hübscher kleiner Thread, der tatsächlich in einer Schleife fröhlich seine Runden dreht.

Wenn du sagst, du müsstest synchron bleiben: Wozu? Weil das ist dann noch wieder mit einigen Implikationen verbunden: Alle Medien müssen dann von ein und dem selben "Taktgeber" gesteuert werden, oder man muss sich Methoden zur gegenseitigen Verständigung schaffen. Was dabei dann sinnvoll ist, hängt davon ab, was genau synchronisiert werden soll.

[arc]

Vielen Dank für den Hinweis mit dem Multimedia-Timer, hast du eventuell ein Beispiel zur Verwendung für mich? Callback sagt mir leider nichts.

[rollstuhlfahrer]

Folgefehler wirst du immer haben. Selbst ein einfaches Sleep zeigt mit QueryPerformanceCounter nachgemessen doch erhebliche Schwankungen, vor allem im kurzen Bereich, gerade weil Sleep intern die CPU-Leistung einem anderen Prozess zugute kommen lässt.

Ansonsten dein Beispiel zu den MMTimern habe ich bei den Schweizern gefunden: http://www.swissdelphicenter.ch/de/showcode.php?id=216
Und was fertiges hier in der DP.

Bernhard

[arc]

Vielen Dank nochmal, ich denke damit komme ich ein ganzes Stück weiter! Frage geklärt!

[hathor]

MIDI-Timer:
https://ultrastardx.svn.sourceforge..../src/lib/midi/