erstmal ein großes lob für die neue version. langsam nimmt die generation 1.6 gestalt an
habe jedoch noch ein paar kleine fehler gefunden.
im ASSIST modus wird für den fortschrittsbalken der FADE OUT punkt als bezug genommen. d.h. der gründe balken läuft bis zu diesem punkt, lied läuft aber weiter bis zum CUE OUT, wie es in diesem modus ja auch sein soll.
ein ähnliches problem ist beim backtiming im ASSIST Modus.
dann noch ein kleiner wunsch bezühl. des fortschrittsbalken: könnte man es nicht so einrichten, dass nach dem CUE, bzw. FADE Out punkt ausgegraut wird, anstatt den grünen balken nach hinten zu setzten. besonders im PFL-Modus irritiert dies. weitergehend könnte man dann zum beispiel den bereich zwischen FADE und CUE Out im AUTOMATIK modus z.b. in gelb darstellen. und von OUTRO bis FADE/CUE Out einen 2-Balken einzubauen, vergleichbar mit RAMP.
Ist es eigentlich noch geplant, die FADE zeiten dynamisch durch die jeweiligen punkte zu gestallten, oder wird immer der wert aus der config genommen?
Du hast recht, auch wenn die Cue-Punkt-Verwaltung (also das Definieren und Verstellen) nun mehr oder weniger fertig ist, fehlen noch einige Sachen, u.a.:
Fading von FadeOut bis CueOut (wie von dir erwähnt)
Visualisierung aller Ramps “gleichzeitig”
Visualisierung von CueOut
Visualiserung von FadeOut
Den von dir angesprochenen “Fehler” würde ich aber gerne noch etwas ausdiskutieren. Du hast richtig bemerkt, dass beim Ausspielen der grüne Balken am FadeOut-Punkt endet. Das ist Absicht. Denn dies ist ja genau der Punkt, an dem der Titel sozusagen “zuende” ist und die nächste gespielt werden soll. In der Automation sowieso. Und im Assist-Modus zeigt der Balken dem Moderator an: Das Lied ist nun effektiv zuende, der Rest ist zu “ignorieren”, du kannst also den nächsten Titel starten oder deine Moderation beginnen.
Habe ich da einen Denkfehler drin? Ich fand das so eigentlich relativ sinnvoll.
Torben
PS: Ich hab mal die Versionsnummer in den Betreff eingefügt, damit man später noch weiß, auf welche “neue Version” du dich hier beziehst
Das einzige Problem hierbei dürfte aber sein, dass man nicht mehr erkennt, wie weit der CUE Out-Punkt noch entfernt ist, wenn der FADE-OUT Punkt überschritten ist.
Was ich oben noch vergessen hatte:
Ist es Absicht, dass im PFL-Diallog noch soviel Freifläche ist? Könnte man dort nicht die Verwaltung der Mengenwertigen Punkte einbauen. Bei dem Popupfenster ist das Problem, dass es immer wieder verschwindet, wenn man irgendwo anders hinklickt.
Oh je, wenn du wüsstest, wie viele Nerven mich dieser PFL-Dialog in den letzten Wochen gekostet hat …
Zunächst: Wo sind denn da große Freiflächen? Wenn, dann höchstens dadurch, dass die neue Version bei einem nicht gesetzten Punkt nicht mehr “0:00:00” anzeigt sondern einfach gar nichts.
Ansonsten ist es so, dass jeder Cue-Punkt-“Streifen” ein grafisches Objekt für sich ist, das dynamisch erzeugt wird. Zur Zeit haben wir fünf Arten von Cuepunkten, also gibt es fünf dieser Streifen, die untereinander in den Dialog gepackt werden. Die Verwaltung der “Alternativen” muss sich also entweder innerhalb des Streifens oder in einem Popup-Fenster abspielen. Außerdem war es mein Ziel, diese Funktionen weitesgehend zu “verstecken”. Denn nicht jeder nutzt die Mengenwertigkeit, und wirklich häufig wird man sie nicht benötigen. Daher die Sache mit dem klickbaren Positions-Label.
Nun aber zu dem Popupfenster: Ursprünglich wollte ich einfach nur ein kleines Popupmenü haben zur Auswahl, so wie ein Kontextmenü. Leider gab es ein Problem: Wenn das Menü gerade geöffnet war und der PFL-Dialog geschlossen wurde (z.B. durch einen Hotkey-Befehl), gab es eine Exception. Weil nämlich plötzlich das Fenster weg war, zu dem das Menü gehörte, was Windows gar nicht passte. Es gibt zwar extra einen Win32-API-Befehl, um alle gerade geöffneten Menüs zu schließen (“EndMenu”), der hat aber irgendwie nicht geholfen. Trotzdem Access Violation. Also schied diese Variante aus.
Dann habe ich etwas gebastelt, wo bei aktiviertem Positions-Button die drei SET/0/TEST-Buttons mit der Alternativ-Auswahlliste überdeckt wurden. Das war aber herzlich unergonomisch.
Nun also das Popup-Fenster als Kompromiss. Dass das in den Hintergrund geraten kann, ist leider nicht zu vermeiden. Denn der PFL-Dialog selbst ist ja schon ein “immer im Vordergrund”-Dialog. Und noch einen konsistent darüber legen geht leider nicht, oder, um die Delphi-Hilfe zu zitieren:
fsStayOnTo: This form remains on top of the desktop and of other forms in the project, except any others that also have FormStyle set to fsStayOnTop. If one fsStayOnTop form launches another, neither form will consistently remain on top.
Oh, tatsächlich, im Extra-PFL-Dialog ist etwas viel Platz zur Zeit Ich hatte den etwas größer gezogen, damit der neue PFL-Dialog da “reinpasst”. Betrachten wir das mal als Bug
Zunächst: Bei der Version 1.5.7 handelt es sich um den Test-Release. Da kann sich immer mal was ändern, und die Benutzung geschieht eh auf eigene Gefahr
Dass die XML-Daten anders sind als in der Vorgängerversion, hängt mit der internen Verwaltung der Daten und auch mit dem Aufbau des PFL-Dialoges zusammen (den ja mehrere Leute kritisiert hatten). Ziel ist es natürlich, ein festes Format zu etablieren. Manchmal lässt es sich aber nicht vermeiden, dass man dazu auch mal etwas über den Haufen werfen muss.
Konvertierungsroutinen für alte Dateiformate zu schreiben ist immer kompliziert und arbeitsaufwändig. Ich halte es deswegen so, dass ich garantieren werde, dass jeder stabile Release auch die Daten der vorherigen stabilen Releases lesen kann (also wird die Version 1.6 die Daten der 1.4 lesen können, usw.).
Torben
PS: Wie du gesehn hast, hatte ich wegen dieser Angelegenheit extra im Vorfeld einen Thread im Allgemein-Forum gestartet. Da sich in vier Wochen niemand gemeldet hatte, war ich davon ausgegangen, dass für Konvertierungsroutinen kein Bedarf besteht.
wenn das so kompliziert ist, muss es auch nicht sein, dass es kovertiert wird.
Und wenn die Stables sauber erkannt werden, sollte es ja auch reichen.
Wie sieht es denn nun mit dem XML-Format aus?
Kann damit rechnen, dass sich da noch viel ändert oder soll es für 1.6 so bleiben wie 1.5.7 (bzw. kopatibles Derivat)?
