Abweichungen/Ungenauigkeiten des Speedmasters

  • Hallo liebes DMXControl Team,


    ein großes Dankeschön für Eure phänomenaltale Software und die Hilfe der gesamten Forums-Community. Die Möglichkeiten - insbesondere des Input Assignments - sind großartig, wenn sie auch etwas Einarbeitung erfordern.

    Für alle meine bisherigen Wünsche hat die Software eine Lösung geboten, wenn auch manchmal mit kleinen Umwegen.


    Eine Kleinigkeit würde ich trotzdem gerne an Euch heranreichen.

    Ich bin primär Hobby DJ und beschäftige mich erst seit kurzem intensiv mit der Lichtsteuerung. Da ich den Alleinunterhalter spiele und die Musik schon recht viel Zeit in Anspruch nimmt, bin ich darauf angewiesen, dass Cuelists auch mal lange laufen. Dabei ist mir aufgefallen, dass der Speedmaster geringe Abweichungen aufweist.

    Um auch bei halben/viertel/... Beats Szenen in Cuelists triggern zu können, habe ich den Beat im Input Assignment mit 16 multipliziert (anbei ein Beispielprojekt). Dabei ergeben sich aber deutliche Abweichungen zum vorgebenen Beat. Ich habe das ganze auf zwei verschiedenen Rechnern je über eine halbe Stunde getestet und habe Abweichungen von 6,6% und 10% ermittelt. Sprich, bei Vorgabe von 2048 BPM im Speed Master gibt dieser pro Minute nur etwa 1800 bis 1900 Beats aus. Wenn ich mal ganz weit spekuliere, könnte ich mir vorstellen, dass DMXControl von Beat zu Beat rechnet und dann natürlich Abweichungen im Millisekundenbereich relevant werden (bei 2048 BPM, liegen die Beats ja nur 29 ms auseinander). Falls das der Fall sein sollte und Ihr mal ganz viel Zeit haben solltet, wäre es toll, wenn ihr auf Basis des vorgegebenen BPM die Zeitpunkte jedes Beats von einer einheitlichen Basis errechnet, sodass sich Fehler nicht aufsummieren (anbei eine Grafik, die das illustrieren soll).

    Auch wenn Abweichungen im Beat von Licht und Ton von 10% (zumindest mir) kaum auffallen, ist es bei Einsätzen (z.B. Stroboskop) beim ersten Beat eines neuen Takts schon arg störend. Ich werde vermutlich auch so einen Workaround finden, aber vielleicht hat ja in Zukunft nochmal jemand das Problem.


    Nichts destotrotz möchte ich mich nochmal ganz, ganz herzlich für Eurer Engagement und die wirklich hervorragende Software bedanken!!!

    Ich habe damit sehr viel Freude und in den letzten Wochen einiges andere vernachlässigt, weil ich am Aufbau eigener Softdecks und Szenen einfach zu viel Spaß hatte ;D

    Viele Grüße!

  • Hallo,

    Wenn ich mal ganz weit spekuliere, könnte ich mir vorstellen, dass DMXControl von Beat zu Beat rechnet und dann natürlich Abweichungen im Millisekundenbereich relevant werden (bei 2048 BPM, liegen die Beats ja nur 29 ms auseinander). Falls das der Fall sein sollte und Ihr mal ganz viel Zeit haben solltet, wäre es toll, wenn ihr auf Basis des vorgegebenen BPM die Zeitpunkte jedes Beats von einer einheitlichen Basis errechnet, sodass sich Fehler nicht aufsummieren (anbei eine Grafik, die das illustrieren soll).

    mal hier etwas zum Grundsätzlichen Aufbau nicht nur in DMXControl 3 sondern in vielen Programmen, die mit Zeiten arbeiten, bevor ich zum eigentlichen Problem komme. Wenn man in einem Programm nach einer gewissen Zeit eine Aktion ausführen möchte, dann gibt es mehrere Möglichkeiten. Eine sehr einfachste Methode ist es, so lange in einer Schleife die Zeit zu prüfen, bis man die Aktion ausführen darf. Man berechnet also vorab, wie die Systemzeit nach dem Verstreichen der Wartezeit genau sein sollte und prüft dann ständig die Systemzeit, ob diese nun gleich oder größer dieser errechneten Zeit ist. Das ist wie wenn ich dauerhaft auf die Uhr schaue und so lange warte, bis eine gewisse Uhrzeit erreicht ist um z.B. die Eier aus dem Kochtopf zu holen. Dieses Beispiel zeigt aber schon ein grundsätzliches Problem dieser Methode: Ich muss all meine Aufmerksamkeit (Rechenleistung) dieser einen Aufgabe widmen (auf die Uhr schauen, bis ich die Eier aus dem Topf holen darf) und kann nichts anderes mehr machen. Nicht anders ist es bei einem Programm auch. Da es nun in der Schleife rennt und ständig prüft, ob die Zeit schon erreicht ist, kann es nichts anderes mehr machen und produziert über dies hinaus noch sehr viel Rechenlast (volle Auslastung eines CPU-Kerns).


    Eine abgeschwächte Form ist es, immer in mehr oder weniger regelmäßigen Abständen auf die Uhr zu schauen. So widmet man nicht die volle Aufmerksamkeit der Uhr und kann noch andere Dinge nebenher machen (z.B. diesen Text hier schreiben). Diese Methode ist tatsächlich häufiger mal in Programmen ausreichend und wird so auch eingesetzt. Hierbei nimmt man aber üblicherweise eine gewisse feste Wartezeit (z.B. 100ms) bevor man wieder prüft, ob die Zeit erreicht ist. Dabei kann es aber vor kommen, dass man beim letzten Prüfen den Zeitpunkt ganz knapp nicht erreicht hat. Dann wartet man fast die volle Wartezeit, bevor man wieder auf die Uhr schaut, feststellt dass die Uhrzeit schon drüber ist und die Aktion ausführt. Diese Methode hat also eine gewisse Ungenauigkeit.


    Eine weitere Methode für ein Programm sind Timer. Da gibt es natürlich ganz unterschiedliche Varianten, aber man kann mehr oder weniger allen sagen, dass sie sich melden sollen, wenn eine gewisse Zeitspanne verstrichen ist. Das ist wie wenn man eine Eieruhr auf eine gewisse Zeitspanne einstellt, nach der sie klingeln soll. Dann kann man vollkommen andere Dinge machen und muss sich überhaupt nicht mehr um das "auf die Uhr schauen" kümmern. Wenn es klingelt, ist das der Trigger für die Aufgabe (also das Ei aus dem Topf holen). Das erklärt ganz grob die Arbeitsweise von Timern, die auch DMXControl 3 verwendet.


    Nachdem wir nun mal die grundlegende Arbeitsweise mit Zeiten in Programmen angeschaut haben, kommen wir zum eigentlichen Problem: Egal welche Variante man verwendet, sie haben auf Windows-PCs ein großes Problem: Windows ist nicht Echtzeit-fähig. Was bedeutet Echtzeitfähigkeit? Im Grunde garantiert ein echtzeitfähiges Betriebssystem (stark vereinfacht), dass jedes Programm nach einer gewissen maximalen Zeitdauer an der Reihe ist, um für eine gewisse maximale Zeitdauer Berechnungen durchzuführen. So wird die Ausführung des Programms planbar. Ohne diese Echtzeitfähigkeit hat man aber ein Problem. Selbst wenn der Timer gerade klingelt heißt das noch lange nicht, dass das Betriebssystem nun DMXControl 3 die Aufgabe ausführen lässt. Schauen wir uns das wieder anhand der Eieruhr an. Nur, weil diese klingelt, heißt das noch lange nicht, dass ich nun alles stehen und liegen lasse, zu den Eiern renne und diese aus dem Topf hole. Wenn ich gerade noch einen Text wie diesen hier tippe und einen Satz vollenden möchte, weil ich mir sonst danach wieder Gedanken machen muss, was ich eigentlich schreiben wollte, dann müssen eben die Eier trotz Timerklingeln kurz warten. Ein Echtzeitbetriebssystem würde mir jetzt harte Vorgaben machen, wie lange ich maximal für das Schreiben des Satzes brauchen darf. Außerdem würde es mir den Text hart weg nehmen und meine Aufmerksamkeit auf die Eier im Eiertopf lenken ganz so wie der/die Lebenspartner/in nun wirklich möchte, dass man sich um die Frühstückseier kümmert und nicht noch den Text... ;)


    Lange Rede, kurzer Sinn, DMXControl 3 ist darauf angewiesen, dass es möglichst exakt und rechtzeitig das Klingeln des Timers mitbekommt und dann auch rechnen darf. Da das unter Windows nicht garantiert ist, wird es rein technisch sehr schwierig, das gerade bei hohen BPM-Zahlen zu verbessern. Es gibt Ideen für Korrekturen, die das versuchen auszugleichen. Aber wenn der Unterbau (sprich Windows) schon nicht exakt arbeitet, ist das in DMXControl 3 auch nur eingeschränkt möglich. So lange man die BPM nicht zu hoch schraubt (so bis geschätzt 300-400BPM) sollte das keine Probleme machen. Bei BPM über 1000 ist das aber dann einfach technisch nicht mehr möglich ;)


    Nichts destotrotz möchte ich mich nochmal ganz, ganz herzlich für Eurer Engagement und die wirklich hervorragende Software bedanken!!!

    Ich habe damit sehr viel Freude und in den letzten Wochen einiges andere vernachlässigt, weil ich am Aufbau eigener Softdecks und Szenen einfach zu viel Spaß hatte ;D

    Das freut uns :)


    Viele Grüße

    JP

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

    Edited once, last by JPK: Typo fix ().