Cuelist wird zeitlich unsauber wiedergeben

    Leider habe ich das Problem das ich keine frame perfect Ausgabe erzielen kann. Ich muss den Dimmer alle paar frames ändern was nach meinem testen einfach nicht möglich ist. Die cue wird gleich schnell abgespielt egal ob 00:00:00.01 oder 00:00:00.10. Bin ich da der einzige der das Problem hat?

    Hallo,

    generell kann man schon sagen, dass DMXControl 3 recht genau triggert. Aber irgendwo sind tatsächlich die technischen Grenzen. Alles unter 100ms-150ms (jenachdem, welche Aktion es ist) wird schon sehr schwierig. Das liegt aber auch daran, dass wir auf einem Windows-System arbeiten, also definitiv einem nicht echtzeitfähigen Betriebssystem. Wenn das eben gerade wichtigere Aufgaben hat, kommt DMXControl erst verspätet dran und kann dann eben auch erst verspätet starten. Nur der Vollständigkeit halber: Auf einem Echtzeitbetriebssystem sind die Delays, also die zeitlichen Verzögerungen sogar noch größer, aber sie sind exakter, planbarer und haben weniger Jitter (zeitliche Ungenauigkeit)). Dieses Problem haben prinzipiell alle Programme auf Windows (und normalen Linuxen). Auch andere Faktoren in der gesamten Ansteuerungskette wie z.B. das Interface und die Kommunikation dahin spielen eine Rolle. Das technische Delay von einigen ms an dieser Stelle und den Jitter von bestimmt auch einigen ms wirst du aber nur sehr sehr schwer und mit spezieller, sich aktiv synchronisierender Hardware deutlich drücken können. Wenn du jetzt also einen Strobe auf exakt gewisse Frames haben möchtest, dann wird das ziemlich sicher nicht funktionieren. Das wirst du aber vermutlich auch mit anderen Lichtsteuerungsprogrammen nicht hinbekommen.

    Viele Grüße

    JP

    Quote from JPK

    Hallo,

    generell kann man schon sagen, dass DMXControl 3 recht genau triggert. Aber irgendwo sind tatsächlich die technischen Grenzen. Alles unter 100ms-150ms (jenachdem, welche Aktion es ist) wird schon sehr schwierig. Das liegt aber auch daran, dass wir auf einem Windows-System arbeiten, also definitiv einem nicht echtzeitfähigen Betriebssystem. Wenn das eben gerade wichtigere Aufgaben hat, kommt DMXControl erst verspätet dran und kann dann eben auch erst verspätet starten. Nur der Vollständigkeit halber: Auf einem Echtzeitbetriebssystem sind die Delays, also die zeitlichen Verzögerungen sogar noch größer, aber sie sind exakter, planbarer und haben weniger Jitter (zeitliche Ungenauigkeit)). Dieses Problem haben prinzipiell alle Programme auf Windows (und normalen Linuxen). Auch andere Faktoren in der gesamten Ansteuerungskette wie z.B. das Interface und die Kommunikation dahin spielen eine Rolle. Das technische Delay von einigen ms an dieser Stelle und den Jitter von bestimmt auch einigen ms wirst du aber nur sehr sehr schwer und mit spezieller, sich aktiv synchronisierender Hardware deutlich drücken können. Wenn du jetzt also einen Strobe auf exakt gewisse Frames haben möchtest, dann wird das ziemlich sicher nicht funktionieren. Das wirst du aber vermutlich auch mit anderen Lichtsteuerungsprogrammen nicht hinbekommen.

    Viele Grüße

    JP

    Hey,

    vielen dank für deine ausführliche Antwort!

    Da meine Anforderung von ein "paar" ms (5 FPS = 200ms) definitiv kein Echtzeitbetriebssytem benötigt denke ich eher das es ein anderes Problem sein muss.

    Vorallem weil gerade DAWS oder Videoschnittprogramme perfekt funktionieren und auch kein hör oder sichtbaren jitter haben.

    Ich glaube eher das DMXC3 wohl die zeit ganz falsch Interpretiert (jegliche delays, fadings sind auf 0ms gesetzt)

    Wenn ich bis 100 zähle komme ich nicht bei 1000 raus :D

    Gleiches problem hier. 10 Sekunden statt 1 Sekunde

    Ich vermute das wird beim Timecode wohl genau das gleiche Problem sein

    Guten Abend!


    Kannst du mal die obere Zeile des Cuelist Editors zeigen? Ich habe das Gefühl, dass du den Fade Faktor verstellt hast. Denn an sich arbeitet DMXControl 3 schon sehr akkurat - ich habe bereits mehrere Timecode-basierte Lichtshows gefahren. Über die Ergebnisse habe ich bereits im Rahmen eines Live@Works berichtet.


    Viele Grüße, Stefan.


    PS.: ich habe deine Frage mal aus dem ursprünglichen Thread herausgelöst, weil wir zwar thematisch im Bereich der Cuelists unterwegs sind, aber dann doch thematisch anders unterwegs sind.

    Hey :)

    Gerade gesehen das dieser auf 10% stand. Ich hätte allerdings erwartet das dieser Wert nichts aussagt wenn man überall 0ms als Fade stehen hat :D

    Hier nochmal ein screenshot wie das gerade mit den timecodes aussieht.


    Egal ob ich nun 10% oder 1000% einstelle es wird beim Timecode gleich schnell abgespielt (was ja prinzipiell sinn macht)

    Leider gibt es trotzdem keinen unterschied zwischen 00:00:00.10 und 00:00:00.01

    Gibt es eine Möglichkeit das die trigger auch auf dem Timecode direkt hören und nicht der Timecode als eine art "delay" dient?


    Nach meinen tests verhält sich das ganze nämlich relativ und nicht absolut was schon sehr schade ist.

    Gerne schaue ich mir deine Berichte an um noch mehr zu lernen, da ich selber noch ziemlich neu in der Software und allgemein das Thema DMX bin. Hast du diesbezüglich ein Konkretes Video oder ein anderen Link für mich?

    Ich bin aber hauptsächlich mehr an der Entwicklung und Automatisierung interessiert weshalb ich aktuell ein "timecode+" Plugin schreibe (was ziemlich anstregend ist ohne ein funzel an Dokumentation :P ) welches dann im besten falle 40 FPS unterstützt um noch genauer zu sein

    Hallo,

    Quote from Justin

    Gibt es eine Möglichkeit das die trigger auch auf dem Timecode direkt hören und nicht der Timecode als eine art "delay" dient?


    Nach meinen tests verhält sich das ganze nämlich relativ und nicht absolut was schon sehr schade ist.

    öhm ich weiß ja nicht, was und wie du das getestet hast, aber Cues hören tatsächlich absolut auf Timecodes und nicht relativ, so wie du das hier in deinem Bild aufgebaut hast. So wie in deinem Bild kann das also nicht funktionieren ;) Gib allen Cues einen absoluten Timecode als Startpunkt an und dann musst du einen Timecode in DMXC 3 produzieren. Dies geht am besten mit einem Audiofile, was du in einer (z.B. anderen) Cue startest. Der Timecode dieser laufenden Audiodatei triggert dann die Cues. Mit deiner relativen Angabe der Cue-Zeiten (wenn du also tatsächlich alle zum selben Zeitpunkt triggerst) müsstest du die minimal technische Triggerzeit zwischen zwei Cues innerhalb einer Cuelist sehen (müsste mir das aber nochmal genauer im Code anschauen).


    Quote from Justin

    Ich bin aber hauptsächlich mehr an der Entwicklung und Automatisierung interessiert weshalb ich aktuell ein "timecode+" Plugin schreibe (was ziemlich anstregend ist ohne ein funzel an Dokumentation :P ) welches dann im besten falle 40 FPS unterstützt um noch genauer zu sein

    Bevor du das machst, damit einiges an eigener Entwicklungszeit verbrätst und etwas doppelt machst, was es teilweise schon gibt: Was willst du denn überhaupt am Ende erreichen, also was ist deine Anwendung? Klar kann man versuchen, Dinge selbst noch einmal "besser" zu implementieren als die Entwickler, die auch die Innereien der Software kennen ;). Das hängt aber eben auch von einigen Randbedingungen ab, die man vielleicht nicht auf den ersten Blick sieht. Aber vielleicht gibt es ja auch andere, einfachere Wege, das zu erreichen, was du möchtest :). Und wenn es da wirklich Probleme gibt, kann man sich die nochmal anschauen und fixen.


    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 ().

    Quote from JPK

    öhm ich weiß ja nicht, was und wie du das getestet hast, aber Cues hören tatsächlich absolut auf Timecodes und nicht relativ, so wie du das hier in deinem Bild aufgebaut hast. So wie in deinem Bild kann das also nicht funktionieren ;) Gib allen Cues einen absoluten Timecode als Startpunkt an und dann musst du einen Timecode in DMXC 3 produzieren. Dies geht am besten mit einem Audiofile, was du in einer (z.B. anderen) Cue startest. Der Timecode dieser laufenden Audiodatei triggert dann die Cues. Mit deiner relativen Angabe der Cue-Zeiten (wenn du also tatsächlich alle zum selben Zeitpunkt triggerst) müsstest du die minimal technische Triggerzeit zwischen zwei Cues innerhalb einer Cuelist sehen (müsste mir das aber nochmal genauer im Code anschauen).

    Mein test sah genau so aus

    Wenn das ganze absolut wäre, würden die unteren Aktionen trotzdem ausgeführt werden. Der Timecode "geber" ist in dem falle eine Audio die als aller erstes abspielt wird.

    Vielleicht liegt es auch an einer falschen Einstellung welche ich übersehe aber wie man im Screenshot sehen kann warten die unteren Aktionen darauf das der obere Timecode fertig wird.


    Quote from JPK

    Bevor du das machst, damit einiges an eigener Entwicklungszeit verbrätst und etwas doppelt machst, was es teilweise schon gibt: Was willst du denn überhaupt am Ende erreichen, also was ist deine Anwendung? Klar kann man versuchen, Dinge selbst noch einmal "besser" zu implementieren als die Entwickler, die auch die Innereien der Software kennen ;) . Das hängt aber eben auch von einigen Randbedingungen ab, die man vielleicht nicht auf den ersten Blick sieht. Aber vielleicht gibt es ja auch andere, einfachere Wege, das zu erreichen, was du möchtest :) . Und wenn es da wirklich Probleme gibt, kann man sich die nochmal anschauen und fixen.

    Ich möchte nichts "besser" entwickeln sondern etwas was mein genau meinen Anforderungen entspricht. Aber deswegen frage ich genau hier nach um zu schauen ob es ein echtes Problem ist oder nur User error :)

    Natürlich kann ich nichts "besser" implementieren als die Entwickler. Ich habe legitlich eine andere vorstellen davon wie das funktionieren soll (wie gesagt kann ja auch einfach eine einstellungssache sein)

    Genau genommen möchte ich auf ein soundboard für meinen twitch kanal haben welche dann neben dem sound eine kleine lichtshow abspielt. Z.b bei einem Flashbang sound effekt alle lichter 100% und auf weiß

    Heißt quasi eine art Soundboard welche den abgespielten Sound nochmal mittels Licht unterstreicht.


    P.s Das ganze soll in keinster weise eine Kritik sein ich find super was ihr hier geschaffen! Mir gefällt besonders gut das man einen Server hat welcher die ganze arbeit macht und man einfach mit einem seperaten Client verbindet. Das ganze noch Linux kompatible und den Kernel Open Source und die welt ist perfekt ^^

    Einen schönen guten Morgen!

    Quote from Justin

    Genau genommen möchte ich auf ein soundboard für meinen twitch kanal haben welche dann neben dem sound eine kleine lichtshow abspielt. Z.b bei einem Flashbang sound effekt alle lichter 100% und auf weiß.

    Heißt quasi eine art Soundboard welche den abgespielten Sound nochmal mittels Licht unterstreicht.

    Also dafür musst du in dem Sinne nichts programmieren. Das funktioniert definitiv so bereits mit dem aktuellen Stand. :)



    Quote from Justin

    Wenn das ganze absolut wäre, würden die unteren Aktionen trotzdem ausgeführt werden. Der Timecode "geber" ist in dem falle eine Audio die als aller erstes abspielt wird.

    Das ist eher ein bisschen der Punkt, wie DMXControl 3 eine Cuelist wiedergibt. Hierzu haben wir auf unserem YouTube-Kanal auch ein extra Video, dass die Zusammenhänge nochmal genau erklärt. Dem folgend, ist das Verhalten in dem Sinne genau richtig. Die Cuelist wird von oben nach unten abgearbeitet. Und da die Cue 5 mit dem Timecode für 10 Sekunden vor der Cue 7 mit der erneuten Zeit für 17 Frames kommt, wird die Cue 7 nicht mehr wiedergegeben, da der Timecode schon längst abgelaufen ist.


    Möchtest du also ab dem Frame 17 nochmal zeitlich relativ positionierte Cues einsetzen bzw. wie im aktuellen Fall nochmal Cues wiedergeben, die exakt 17 Frames nach dem ersten absolut gesetzten Timecode folgen, dann arbeitest du in der Tat mit den Triggern "wait" bzw. "follow". Wie das aussehen kann, siehst du direkt im ersten Screenshot des Artikels für die Cuelist im unserem Wiki.


    Die weitere Frage ist: was geben die Cues wieder? Vielleicht lässt sich dies auch mit einem Effekt und dann mit nur einer Cue realisieren. Da wäre dann ggf. mal interessant, dein Projekt zu sehen, damit das am "lebenden Objekt" nachvollzogen werden kann. Ist bestimmt einfacher, als das in viele Worte zu packen. Bzw. umgekehrt: du formulierst dein gewünschtes Ergebnis und wir schauen gemeinsam, wie das sich im Ideallfall umsetzen lässt.


    Viele Grüße, Stefan

    Quote from Justin

    P.s Das ganze soll in keinster weise eine Kritik sein ich find super was ihr hier geschaffen!

    Alles gut. Vielleicht kann man meinen Kommentar auch etwas bissig interpretieren, was er eigentlich nicht gemeint war :saint:


    Quote from Justin

    Wenn das ganze absolut wäre, würden die unteren Aktionen trotzdem ausgeführt werden.

    Nein, tatsächlich nicht. Das liegt daran, dass eine Cuelist eine Reihenfolge hat und hier nur der Trigger für die nächste Cue ausgewertet wird (wie das LightningBrothers mittlerweile auch geschrieben hat).


    Quote from Justin

    Das ganze noch Linux kompatible und den Kernel Open Source und die welt ist perfekt ^^

    Linux kann in Teilen irgendwann kommen. Da vor allem der Kernel, weil die GUI Windows-spezifische Elemente verwendet. Open Source ist seit Jahren ein Thema und wir haben uns aus diversen Gründen immer wieder dagegen entschieden. Das DMXControl 3 nicht Open Source ist heißt aber noch lange nicht, dass man nicht auch bei uns mitarbeiten kann und DMXControl 3 aktiv voranbringen kann ;) Immerhin steht ja ein Verein dahinter, der die Softwareentwicklung trägt. Wir möchten das eben nur in geordneten Bahnen und anhand der erdachten Konzepte machen 8)

    Quote from LightningBrothers

    Das ist eher ein bisschen der Punkt, wie DMXControl 3 eine Cuelist wiedergibt. Hierzu haben wir auf unserem YouTube-Kanal auch ein extra Video, dass die Zusammenhänge nochmal genau erklärt. Dem folgend, ist das Verhalten in dem Sinne genau richtig. Die Cuelist wird von oben nach unten abgearbeitet. Und da die Cue 5 mit dem Timecode für 10 Sekunden vor der Cue 7 mit der erneuten Zeit für 17 Frames kommt, wird die Cue 7 nicht mehr wiedergegeben, da der Timecode schon längst abgelaufen ist.

    Gut ich habe in dem fall tatsächlich ein blödes Beispiel gefliefert und ja so macht das ganze sinn.


    Ich versuche das problem jetzt nochmal etwas genauer zu beschreiben


    vs

    Beide Werden exakt gleich ausgeführt. Das delay zwischen den einzelnen (Lampe 100% und Lampe 0%) ist immer der gleiche.

    Man sieht auch das beide an der gleichen stelle stoppen (weil die audiodatei zu ende ist OBWOHL der Timecode der eingegeben wurde vor dem ende des Sounds war)

    Hier einmal in Audacity die Tonspur. Man sieht unten das sie .15 lang ist.

    Die Videos zum Thema Trigger und advanced Trigger habe ich mir bereits angeschaut.



    Das untere müsste doch logischerweise Sehr schnell hintereinander abgespielt werden und deutlich schneller als das obrige sein oder verstehe ich da was falsch?

    Quote from LightningBrothers

    Die weitere Frage ist: was geben die Cues wieder? Vielleicht lässt sich dies auch mit einem Effekt und dann mit nur einer Cue realisieren. Da wäre dann ggf. mal interessant, dein Projekt zu sehen, damit das am "lebenden Objekt" nachvollzogen werden kann. Ist bestimmt einfacher, als das in viele Worte zu packen. Bzw. umgekehrt: du formulierst dein gewünschtes Ergebnis und wir schauen gemeinsam, wie das sich im Ideallfall umsetzen lässt.

    Die Cues setzen lediglich die Helligkeit auf 100% und auf 0% (manuelles strobo quasi).

    Der sound ist ein lautes Türklopfen von "Fbi open up" und möchte gerne das bei jedem Schlag das licht aufblinkt.

    Natürlich könnte man ein Strobo effekt nehmen allerdings löst das nicht das Grundproblem, da die sounds nicht immer einen Rythmus haben wie bei Musik. Z.b ein lautes Türklopfen hat ungefähr den gleichen rythmus wo das ganze noch gehen würde bei unrythmichen sounds leider nicht.

    Gerne teile ich heute Abend mein Projekt (es ist eigentlich sogut wie leer außer diese eine Cuelist zum testen). Vielen dank für die Hilfe bis jetzt!

    Ich habe in das Licht in echt beobachtet. Also die DMX Ausgabe.


    Mein DMX Controller kann nichts unter ~40FPS darstellen also heißt ein abstand von 25ms +-10ms sollten machbar sein


    Folgende Tests habe ich gemacht

    Abstand von 30ms

    - Funktioniert in 90% der fällen ohne Probleme. Hier und da wird mal eine cue verschluckt alle 5 Versuche

    Abstand von 50ms (sichtbarer unterschied zum vorherigem)

    - Funktioniert ohne Probleme

    Abstand von 100ms (sichtbarer unterschied zum vorherigem)

    - Funktioniert ohne Probleme

    Genau so wie ich es haben mit dem "workarround" über ein Wait

    - Funktioniert ohne Probleme

    - Genau so wie ich es haben will ohne auch nur eine einzige Verzögerung

    Genau das gleiche nur mit Timecodes

    - Funktioniert wie mehrfach gesagt nicht richtig.

    Trifft jedenfalls nicht den Timecode


    Nur beim Timecode ist es nicht möglich was für mich ein eindeutiges zeichnen ist das irgendwo ein Fehler sein muss.

    Ich habe schon genug Software unter Windows benutz benutzt welche einigermaßen zeitkritisch sind (FL Studio, Abelton Live, Premiere Pro, After Effects, Unity, Unreal Engine 5).

    Jede dieser Software kann Frame Perfekt im loop etwas abspielen mit nur wenigen ms abstand ohne auch nur ein einzigen Delay.

    Möglich ist es also nach eigenen Erfahrungswerten. Nur der Timecode in DMXC3 kann das nicht..


    Ein Echtzeitbetriebssystem wäre komplett overkill. Es geht sich ja nicht um tausenstel nanosekunden Genauigkeit sondern um einige ms (40ms ist garnichts wobei es in dem beispiel ja um gerade mal 100ms - 200ms geht) und das ist komplett im rahmen des machbaren in Windows.


    Ich hab mir mal die Zeit genommen um etwas zu analysieren :D

    • Tick = Der akuelle Tick der alle 40ms geupdated wird
    • CurrentTime = blockAlignedStream.CurrentTime.TotalMilliseconds
    • WavePosition = Die aktuell abgespielten millisekunden berechnet durch geschriebene bytes
    • Stopwatch = Eine Stopwatch welche beim ersten tickevent getriggert wird (also fast (+-5ms) zeitgleich mit dem abspielen der datei)

    Die Audiodatei war eine 300 BPM Metronom (4 Sekunden)

    Tick CurrentTime msWavePosition msStopwatch ms
    1 300 0 0,7955
    2 300 43,89583333 51,8418
    3 300 88,89583333 96,8444
    4 300 129,4583333 137,417
    5 450 176,4791667 186,4052
    6 450 223,4375 231,3759
    7 450 270,4791667 280,4115
    8 600 317,1041667 327,0722
    9 600 365,0416667 372,9844
    10 600 412,1041667 422,0394
    11 750 460,125 468,0674
    12 750 511,1041667 519,0593
    13 750 550,125 560,0567
    14 900 601,125 609,1253
    15 900 646,1041667 654,1301
    16 900 693,1666667 703,1301
    17 900 741,1458333 749,1668
    18 1050 787,1041667 795,0572
    19 1050 836,1041667 846,0595
    20 1050 892,1875 902,1885
    21 1200 933,2916667 943,3638
    22 1200 982,2916667 990,4593
    23 1200 1037,1875 1047,1289
    24 1350 1085,145833 1093,1586
    25 1350 1134,708333 1144,6394
    26 1350 1175,6875 1185,6123
    27 1500 1224,75 1232,7388
    28 1500 1271,729167 1281,709
    29 1500 1323,104167 1331,1335
    30 1650 1364,041667 1372,0754
    31 1650 1411,604167 1421,6046
    32 1650 1457,5 1467,4906
    33 1800 1510,458333 1518,4261
    34 1800 1551,479167 1559,4537
    35 1800 1596,520833 1606,4907
    36 1800 1645,604167 1653,5956
    37 1950 1686,666667 1694,8007
    38 1950 1737,729167 1747,8194
    39 1950 1790,5625 1798,5032
    40 2100 1830,583333 1840,518
    41 2100 1883,645833 1891,7263
    42 2100 1929,75 1937,8448
    43 2250 1980,729167 1988,6952
    44 2250 20:30:00 2028,8338
    45 2250 2060,895833 2068,8445
    46 2400 2106,5 2114,4801
    47 2400 2147,458333 2155,3962
    48 2400 2192,5 2202,4136
    49 2400 2240,5 2248,4656
    50 2550 2289,3125 2297,2823
    51 2550 2333,4375 2343,4593
    52 2550 2386,291667 2394,2362
    53 2700 2427,833333 2435,7625
    54 2700 2471,875 2481,7906
    55 2700 2524,833333 2532,7514
    56 2850 2571,833333 2579,7739
    57 2850 2615,875 2625,8139
    58 2850 2667,854167 2675,7824
    59 3000 2708,833333 2716,8225
    60 3000 2755,833333 2765,7653
    61 3000 2803,833333 2811,7633
    62 3150 2851,4375 2861,3976
    63 3150 2896,604167 2906,6434
    64 3150 2950,5 2958,6264
    65 3150 2992,604167 3002,648
    66 3300 3050,395833 3058,314
    67 3300 3091,354167 3099,2869
    68 3300 3137,916667 3147,8286
    69 3450 3180,895833 3188,8205
    70 3450 3224,875 3232,8145
    71 3450 3273,104167 3283,0937
    72 3600 3317,333333 3327,3989
    73 3600 3371,270833 3379,1912
    74 3600 3416,75 3426,7078
    75 3750 3460,083333 3468,1819
    76 3750 3504,6875 3512,6289
    77 3750 3551,729167 3561,6292
    78 3750 3596,770833 3606,7086
    79 3900 3647,854167 3655,8567
    80 3900 3696,729167 3706,641
    81 3900 3737,729167 3747,6335
    82 4000 3786,708333 3794,6446
    83 4000 3830,791667 3840,7645
    84 4000 3880,8125 3888,8916
    85 4000 3926,854167 3934,9296
    86 4000 3974,75 3984,6784
    87 4000 4022,791667 4030,7311

    Meine Empfehlung wäre

    statt

    Code
    SceneTriggerManager.getInstance().getSceneTriggers<TimecodeSceneTrigger>().ForEach<TimecodeSceneTrigger>((Action<TimecodeSceneTrigger>) (t => t.Timecode = (long) blockAlignedStream.CurrentTime.TotalMilliseconds));

    lieber

    Code
    double wavePositionMs = WaveOut.GetPosition() * 1000.0 / WaveFormat.BitsPerSample / WaveFormat.Channels * 8 / WaveFormat.SampleRate;
SceneTriggerManager.getInstance().getSceneTriggers<TimecodeSceneTrigger>().ForEach<TimecodeSceneTrigger>((Action<TimecodeSceneTrigger>) (t => t.Timecode = (long) wavePositionMs));


    Dann ist der Timestamp perfekt ohne Abweichung vom abspielen.


    Fazit:

    Mit dem aktuellen Code wird eine Genauigkeit von ~8 FPS (~120ms) erzielt wobei es eigentlich ja 40ms mit einem TImecode von 25 FPS wäre


    Wenn ihr mir jetzt immer noch nicht glaubt dann weiß ich auch nicht mehr :P


    Bitte überzeugt euch selbst im Anhang

    Hier mal mit meinem Timecode+ Plugin sowie die ganzen tests.

    Das Plugin war gerade nur ein test sowie Proof of Concept also nichts festes

    Frame perfect wie gewollt ^^

    Das einzige Problem ist jetzt nur das der Controller nicht immer hinterherkommt (was jetzt auch nicht das größte problem ist)

    forum.dmxcontrol-projects.org/…dex.php?attachment/17560/

    Moin...


    Das ist ja cool, dass du dich da so reingefuchst hast und ein entsprechendes Plugin geschrieben hast. Solche Leute brauchen wir :P


    Unabhängig davon: magst du mal ein Ticket hierzu in unserem Bugtracker anlegen, auch mit der kurzen Skizzierung des Problems, deinem Lösungsansatz und vor allem einem Verweis auf diesen Thread? Dann kann das Problem ggf. einfach grundlegend behoben werden, sodass ein Plugin dafür nicht mehr benötigt wird. :)


    Viele Grüße, Stefan.

    Vielen Dank ^^


    Ich erstelle eben ein Ticket ^^

    Quote from Justin

    WaveOut.GetPosition() * 1000.0 / WaveFormat.BitsPerSample / WaveFormat.Channels * 8 / WaveFormat.SampleRate;

    Hallo Justin,


    Erstmal tolle Analyse. Danke dafür.


    Hier eine Frage, hast du bei deinen Tests auch Wave / MP3 Dateien mit unterschiedlichen Formaten genommen (44 khz, 48 khz, Mono, Stereo, usw)?


    Ich frage, weil ich unsicher bin, ob deine Vorgeschlagene Lösung dann auch noch geht. Vielleicht kannst du das noch kurz durch dein Test Setup jagen damit wir sicher sind, dass es wirklich mit allen Dateiformaten funktioniert.


    Gruß


    Arne

  • Newly created posts will remain inaccessible for others until approved by a moderator.

    The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.

    • :argh:
    • :shit:
    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • 8|
    • :cursing:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3
    • :!:
    • :?:
    • :glaskugel: