halli hallo...
ich hab mit HE-LS das gleiche problem....
es is wohl so, dass es immernoch verschiedene Mentalitäten beim Export von ILDA files gibt.
Meine Meinung (ob die nun richtig is oder nicht kann man drüber streiten): Da bei einem ILDA export nur Frames und Punkte im File sind, und somit jegliche Zeitinformation quasi weg radiert ist, is für den Export von Software zu Software nur eine Methode die Richtige:
Framekonstant
heißt... die Bildzahl pro Sekunde muss über das ganze File konstant sein, egal wieviel Bildinhalt (Punkte) pro Frame vorhanden sind.
Meiner Meinung nach sind 30 Bilder pro Sekunde schon ausreichend, 25 reichen auch gerade noch, ruckelt aber schon.
Sicherlich entstehen so teils zu viele oder auch zu wenige Bilder... aber nur so kann man hoffen, das File überhaupt synchron zu bekommen.
Beispiel (Abspielen von Frames mit konstanter Framerate): angenommen eine Passage von Bildern hat nur ne simple Ebene, mit 100 punkten. Wir scannen mit 10000 Punkten, und haben eine Framerate von 25 Bildern / Sekunde. Dann ergibt sich folgendes:
Bildzeit = 10 Millisekunden weil (1000[ms] / 10 [p/ms] * 100 [p] = 10 ms ist)
Bei 25fps müsste aber ein Bild 40ms dauern ==> Also muss die Software dann halt einfach 4 mal den gleichen Frame wiederholen (beim abspielen)
Andersrum... hätten die Frames einer Passage zB grad 800 Punkte... dann ergibt sich ne Framezeit von 80 millisekunden... Also muss dann die Soft so schlau sein, und einfach jeden 2. frame weg lassen.
insgesamt is es doch simpel:
Auszugebende Framenummer = (AktuelleSongzeit[ms] - StartzeitDesFiles [ms]) / (1[s] *1000 / Framerate [frames/s])
(kurz gesagt)
Framenummer = VergangeneZeitSeitAufruf / DarstellungszeitEinesFrames
is doch simpel.... immer bevor man den Frame für die Ausgabe wählt.. einfach diese Rechnung
Die FPS Rate kann sich auch gerne durch Drag And Drop ergeben... Wenn anfang und Ende bekannt, dann weis man ja mit hilfe der Framezahl auch die Framerate..
Beispiel: Beim Export muss es halt dann so aussehen:
Da ein Framekonstanter Export evtl in "Echtzeit" garnicht möglich ist (schließlich muss man unter umständen mehr Frames berechnen und exportieren, als man mit aktuellen DAC einstellungen überhaupt ausgeben kann), macht man das halt
nicht in Echzeit.
Bei HE nehm ich ne Schleife:
Code: Select all
For Istzeit = 0 to Songlänge (in millisekunden) Step (1000/ Framerate)
nu is es simpel: Nach der Istzeit die der Timeline entsprechenden Figuren, Effekte usw. setzen, Berechnen, und die sich ergebenden Punkte in ein Ilda File schreiben, anstatt zum DAC aus zu geben.
Next Istzeit.
so simpel...
Ich weis nicht, warum das bei manchen programmen nicht so unterstützt wird. Schade....
Noch eins kommt dazu: Zugegebenermaßen muss ich dazusagen, dass es mit dieser Methode zu unerwünschen Effekten kommt. Was tun, wenn die "Theoretische Framenummer" = 174,5 ist ??? Den frame gibt es nicht, da hilft nur runden. So kann es immer wieder zu der Situation kommen, dass zB alle 20 Frames ein Frame 2 mal gezeigt wird, weils nicht anders ausgeht. Dadurch sieht man dann etwa jede Sekunde einen Hüpfer (ruckeln).
Dies lässt sich vermeiden, in dem man Extrem viele Frames im File zur verfügung hat.. also zB 60 oder 80 Fps plant. Dann gibts immer den passenden korrekten Frame, ABER das File wird brutal groß
Dieses Phänomen tritt natürlich bei Punktkonstantem Export nicht auf, wenn das File dann mit exakt der selben Punktrate wieder abgespielt wird.
manchmal denke ich... Den einen Proggern kommts aufs Timing an, den anderen eher auf das Flüssige Laufen der Ausgabe. Bei nem ILDA File muss man sich leider entscheiden... ich persönlich finde das Timing wichtiger, als das flüssige laufen
Viele Grüße derweil
Erich
