Gibt es ein PlaylistItem welches ein Script ausführen kann?
Also ähnlich wie das “Dummy” Element, nur dass eine Aktion ausgeführt wird (z.B. Element in Playliste einfügen)
Gruss:
-Serge-
Dafür gibt es den Elementtyp “Befehl”. Als Befehl trägst du dort ein: RUNSCRIPT C:\dateiname.mls
Funktioniert allerdings nur in der Automation. Wenn du was für Live Assist suchst, oder andere Aktionen als nur Scripts ausführen willst, wirst du ein kurzes Stille-Element und da die Aktionen bei Start/Stop verwenden müssen.
Danke für die Info. Schaue mir das dann mal an.
Gruss:
-Serge-
Ich möchte das an der Stelle mal aufgreifen und wiederbeleben.
Das Stille-Element ist ja 'ne tolle Sache, aber im Augenblick macht es noch nicht ganz das, was ich mir von ihm verspreche.
Folgende Idee: Stille-Element, Typ: Moderation. Länge: 1:30, ins Logging mt einbeziehen (Sendungsname wird übertragen, sehr schön), bei Automation alle anderen Player ausblenden.
Aktionen: Automation stoppen und Datei spielen (das ist das Musikbett, dessen Tag nicht mit übertragen werden soll und für das nicht extra ein Cartplayer belegt werden muss).
Fehler: Statt die Datei einfach abzuspielen, wird sie in den freien Player geladen - die Aktion verhält sich also wie “Datei laden” statt “Datei spielen”.
Wenn der Fehler schon vor dem Bildschirm sitzt: Wo klemmts? Oder ist es doch mAirList, das nicht mtspielen will?
Gruß, Uli
Bist du zu dem Zeitpunkt, an dem das besagte Stille-Element gestartet wird, im Assist- oder im Auto-Modus?
Gut gefragt: Es war der Assist-Modus. Im Auto-Modus funktioniert die Geschichte wie erwartet - aber sie hat dennoch einen Haken.
Der Auto-Modus wird beendet - sehr gut. Ab sofort alles in Assist, wie ich das bei der Moderation auch gerne hätte.
ABER: Die zu spielende Datei (das Bett) wird in den nunmehr freien Player geladen und dort gestartet, zugleich endet das Stille-Element (unabhängig davon, wie lange es geplant war). Damit wird der ID-Tag des Bettes übertragen und nicht der Tag des Stille-Elements (“Klatsch & Tratsch mit Uli”). Hm.
Okay, damit hat sich meine Spinnerei zerschlagen.
Eigentlich wollte ich, dass das Bett still, leise und heimlich unter dem Deckmantel des Stille-Elements läuft und das Stille-Element durch seine fest definierte Laufzeit zugleich anzeigt, wann die Moderation fertig zu sein hat - mit Fortschrittsbalken, EOF-Warnung und allem drum und dran. Zugleich hätte es einen (ggf. übersehenen) Auto-Modus beendet und das Musikbett gestartet - und passt prima in die Scheduler-Planung. Nun gut, letzteres macht das Element tatsächlich… aber der Tarnkappen-Modus wäre jetzt noch das Sahnehäubchen gewesen.
Streng genommen gibt es jetzt fast keinen Unterschied mehr zu einem zeitlich zurechtgeschnittenen Musikbett.
Zugegeben, das sind nur Kleinigkeiten - aber vielleicht sind die ja irgendwo in mAirList versteckt und ich habe sie bloß übersehen. 
Gruß, Uli
Diese ganzen Aktionen à la “Datei abspielen”, “Playlist abspielen” usw. sind nur für den reinen Automationsbetrieb gedacht und funktionieren auch nur dort ordentlich, zumindest, wenn die Aktion von “extern” kommt (z.B. als Event) und nicht als Start- oder Stop-Aktion an ein Element geheftet ist. In letzterem Fall kann es zu merkwürdigen Effekten kommen, das ist bekannt.
Grundsätzlich ist das Problem. dass mAirList Dateien nicht “einfach so” abspielt. Das Abspielen muss immer in einem Player stattfinden, auch damit das Routing eindeutig definiert ist. Im Assist-Modus ist es mAirList nicht gestattet, Player von alleine zu starten (normalerweise muss ja noch ein Fader am Mischpult geöffnet werden!). Deswegen funktioniert “Datei abspielen” im Assist-Modus aus Prinzip nicht. Das einzige, was mAirList schon macht, ist der erste Teil, nämlich die Datei an die entsprechende Stelle in der Playlist einfügen. Der zweite Teil, “Automation Next”, geht natürlich schief.
Jepp, verstanden, danke!
Bekomme ich auch anders geregelt. Muss nicht immer mit Sahnehäubchen sein. 