Nein, stets gleich. Bei Jingles / Promos / Trailern / Musikbetten etc. soll das Delay kurz ausfallen, und vor der nächsten Musik soll das Delay dann wieder größer werden.
Wie auch immer, jedenfalls mehr als ein Elementtyp.
In meinem Fall würde ich das Skript zur Erzeugung der Variable direkt einbinden. Die Variable wird an anderer Stelle gar nicht benötigt, so dass RuntimeData überflüssig wäre.
Das Delay beträgt $mindestzeitabstand plus Zufallswert im Bereich $range. Dieser Wert wird alle $minuten plus Zufallswert im Bereich $sekunden neu ausgewürfelt.
Sprich: Ich habe keinen blassen Schimmer, wie oft der Verzögerungswert worauf neu bestimmt wird.
Streng genommen reicht es, nach der Elementtyp-definierten Reduzierung der Verzögerung die Berechnung der neuen, langen Verzögerung neu anzustoßen.
Die Speicherung der alten Variable ist die einfachste Lösung, fürwahr. Aber ich möchte mitunter dieses ominöse “mehr”.
if (Item.GetItemType = pitPromo) OR
(Item.GetItemType = pitTrailer) OR
(Item.GetItemType = pitJingle) OR
// ...
(Item.GetItemType = pitBed) then
begin
// do somethiing
end;
Deine Zufallskonstruktion umzusetzen ist mir im Moment wirklich zu aufwändig, es geht auch so. Kein Hörer wird anrufen, weil die Verzögerung bei allen entsprechenden Elementen gleich ist.