Von vielen gewünscht, von manchen ersehnt, kommt hier ein Skript für das automatische Plazieren von Drops über die Ramp eines Titels im Automatikbetrieb.
Wie funktioniert’s?
Folgende Elemente werden in der dieser Reihenfolge eingeplant:
Ein Steuerelement der Länge null mit einem bestimmten Titel (kann in der Konstante BTCAPTION geändert werden), Standard ist ++ Drop ueber Ramp ++,
das Element, auf dessen Ramp der Drop gesetzt werden soll und
der Drop selber.
Zu beachten ist:
Der zu rampende Titel muß je einen Ramp1- und StartNext-Marker besitzen und
der Drop darf nicht länger sein als die Ramp des Titels.
Ist all dies erfüllt, wird beim Start eines Titels jeweils geprüft, ob danach das Steuerelement eingeplant ist. Ist das der Fall, wird der StartNext-Marker so verschoben, daß der Drop mit dem Ramp1-Marker abschließt. Anschließend wird der Pegel der Ramp um ein definiertes Maß (einstellbar in der Konstante RAMPLEVEL) abgesenkt.
Nun besteht aufgrund der mAirList-Architektur das Problem, daß das Programm „dumm“ (sorry, @Torben, Du weißt, wie es gemeint ist) auf das nächste Ende (oder StartNext) eines laufenden Elements reagiert und daher den folgenden Titel am Ende des Drops (und nicht des zu rampenden Titels) abfährt. Es muß also das ursprüngliche StartNext irgendwie wiederhergestellt bzw. so hinausgezögert werden, daß es mit dem ursprünglichen StartNext übereinstimmt.
Dies geschieht, indem ein Container gebaut wird und dahinein sowohl der Drop als auch eine Stille, die bis zum Ende des ursprünglichen StartNext reicht, gepackt wird.
Es laufen also nach dem Drop also zwei Player parallel, in einem jedoch lediglich die Füllstille.
Mein Dank gilt @calypso60, der die entscheidende Idee hatte.
Das Steuerelement ist ein Dummy (ich auch, da ich vergessen hatte, es zu erwähnen), dessen Titel entsprechend gesetzt wird. Dann kommt der zu rampende Titel (der mit Ramp1 und StartNext versehensein muß) und dann wiederum der Drop.
Da die ganze Maschinerie angelaufen ist, wird das Skript das Steuerelement wohl erkannt haben.
Hast Du beim Testen nach dem Drop noch weitere Titel in der Playlist gehabt?
Und (zum Testen) davor noch einen weiteren Titel, der Dir Zeit zum Anschalten der Automation gibt?
Edit: Ich kann den Fehler nachvollziehen, wenn hinter dem Drop kein weiteres Element eingeplant ist. Demnächst versuche ich, das abzufangen, bis dahin bitte genügend Elemente in die Playlist stecken.
Beim zweiten Test jetzt ja. Auch davor nun einen weiteren Titel angehängt.
Als Dummy hab ich einen Platzhalter verwendet.
Die Meldung “Drop is to long” war weil ich den Drop selbst nicht in der Playliste hatte.
Bin leider ein wenig ratlos.
Hab auch getestet, ob der Drop auch wirklich als Element Drop definiert sein muss. Leider keinen Unterschied. Ach ja und meine Version ist die V6 Home Studio.
Danke, leider bin ich gestern nicht mehr dazu gekommen. Werde es heut Abend noch testen.
Ich meine mitbekommen zu haben das der START NEXT Punkt bedeutend wichtig für den Mechanismus ist. Jetzt ist es leider so, das ich bis jetzt in meiner Datenbank nie diesen definiert habe, da in der Konfiguration FadeOut = StartNext behandelt wird. Funktioniert das trotzdem?
Mal schauen wie ich das umsetze. Ansonsten muss ich diesen Punkt eben auch noch bei tausenden Titeln setzen.
Heute konnte ich endlich das Skript testen.
Funktioniert auf den ersten Anschein recht ordentlich. Nun geht ein wenig ans Feintuning mit Absenkung und Ramp Zeiten.
Hey! Richtig cooles Script Danke Dir für Deine Arbeit.
Eine kleine Frage hätte ich aber noch. Ist es möglich, dass wenn der Sweeper/Dropper nicht spielbar ist, dass er automatisch aus der Playlist gelöscht wird?
Deine Frage hat jetzt aber nicht wirklich mit dem Skript zu tun, oder verstehe ich da etwas falsch? Wenn ein Element nicht spielbar ist, gibt es meines Wissens einen Fehler (ERROR im Player), der auch protokolliert wird.
Meine Antwort mag vielleicht arrogant erscheinen, aber ich sehe es so, daß der Benutzer selber verantwortlich für das Material ist, was er in die Playlist füttert. mAirList spielt die Sachen nur ab, und ich finde, es ist nicht dessen Aufgabe, für Ordnung im Musikarchiv zu sorgen.
Wenn jemand doch so etwas programmieren mag: In der procedure OnPlayerStatChange auf den Zustand psError prüfen und bei Bedarf das entsprechende Element löschen. Das hätte zur Folge, daß beim Versuch es in eienen Player zu laden das Element sofort verschwände, ohne daß der Benutzer wüßte, was überhaupt los ist. (Ja, man könnte eine Zeile ins Log schreiben, aber die Überraschung bliebe.)
Ich verstehe nicht, warum man überhaupt ein Radio betreiben will, wenn eh alles automatisch gehen soll? Aber das liegt vielleicht an mir.
ich glaube, da gibts gerade ein kleines Missverständnis Mir ging es darum, dass der Drop ausgeplant wird, wenn er nicht auf die Ramp passt. Verstehst Du was ich meine?
Mir ging es darum, dass der Drop ausgeplant wird, wenn er nicht auf die Ramp passt. Verstehst Du was ich meine? 