hier noch was aus StudioA: Player1 läuft, Player2 wird gestartet. Wenn ich jetzt Player1 runterfade bis zum Anschlag und sofort wieder hochziehe bekommt mAirList den Start-Impuls nicht immer mit, gleiches auch bei schnellem Start/Stop drücken. Grund: Der Player bleib noch einen Moment im Pause-Modus, bevor ent- und neu geladen wird.
Belegt sind die Player mit
Pult-Kommando Pause/Stop
Auto Entladen bei Stop
Auto Entladen bei EOF
Auto Anhalten bei EOF
Pause aufheben, wenn anderer Player aktiv
Gerade als Jingle/Beitragsplayer kann das bei zeitkritischen Moderationen ins Auge gehen…
2.2.2 / 545 hat mein angelegtes Tempo sehr gut vertragen.
Das liegt an dem neuen asynchronen Lademechanismus. Der Player geht ja zunächst in Zustand “LOADING” und lädt das Element im Hintergrund. Währenddessen ignoriert er natürlich sämtliche Start-Befehle, weil es nichts zum Starten gibt.
Bei mAirList 2.2 fand das Laden komplett im Vordergrund-Thread statt. Die ganze GUI hing, bis das Element weiter war, und ebenso die Verarbeitung der Faderstart-Befehle.
Gute Frage! Als Workaround kann man erstmal auf die Cart zurückgreifen.
Nur wird auch die beste Cart unübersichtlich, wenn’s auf 20 und mehr Elemente geht.
Prinzipiell würde ich an Deiner Stelle auch gerne beim asynchronen Thread bleiben - so dass die GUI weiterläuft.
Gäbe es die Möglichkeit, dass die Player nicht nur den aktuellen Track puffern oder in der Hinterhand haben, sondern auch den nächsten unf ggf. übernächsten noch nicht geladenen?
Nur was passiert, wenn beide Fader zeitgleich OFF und ON gedrückt werden?
Fakt ist jedenfalls, dass es spätestens dann kritisch wird, wenn ich als Mod die “Hau den Track bei Ende raus”-Option nicht drinne habe, vergesse den Kanal zu schließen, nach meiner bunten Meldung wieder was über den selben Kanal abspielen will und das dann halt sehr schnell mache. Dann kommt nämlich nix und ich habe ein Sendeloch…
So leid es mir tut, Torben, aber an DER Stelle geht für mich als User die Zuverlässigkeit der Reaktion auf meine Steuerung absolut vor, auch wenn die GUI eine Sekunde hakt.
Oder kannst Du nicht einen Puffer einbauen, der den Befehl für eine gewisse Toleranzzeit (500 ms) auffängt?
Nur sind wir damit auch wieder bei Latenzen, die es eigentlich zu vermeiden gilt.
Daher würde es doch bei der Kapazität der heutigen Rechenmaschinen passen, wenn mAirList zumindest die ersten Sekunden der nächsten zwei bis drei noch nicht geladenen Elemente in der Playliste für jeden Player bevoratet
Ich habe tatsächlich vor, durch geschickte Puffer-Verfahren das Laden der Titel zu beschleunigen. Aber trotzdem, der Effekt kann noch immer auftreten, wenn jemand besonders schnell drückt. Was also tun?
Zunächst könnte ich mit einem Handgriff den alten Zustand wieder herbeiführen. Auch als Option (deaktivierbar).
Alternativ, und das wäre die hübschere Lösung, könnte man dem Player noch einen neuen Zustand “wait” o.ä. verpasen. Wenn der Titel noch geladen wird, man aber schon START schickt, geht der Player dann in diesen “wait”-Zustand. Sobald das Element bereit ist, wird es dann sofort abgespielt. Wie wäre das?
Die WAIT-Funktion wäre für den Normalbetrieb die denkbar beste Lösung - käme ja quasi meinem Befehlspuffer gleich.
Nur, welche Parameter soll WAIT am Besten haben? Kann ich dann einfach zwischen STOP und WAIT wechseln, wenn’s mal länger dauert?
Ob eine Option zu synchronen Playern (dann noch) sinnvoll ist? - Lass mich darüber noch mal das WE nachdenken…
Zumindest wäre das die kurzfristige Lösung - sollte vielleicht auch nicht per Haken konfigurierbar sein, da es ja nur selten umgestellt werden sollte…
Du bist der Chef im Ring und weißt, wie lange die hübsche Lösung noch dauern wird…
ich bin zu der Überzeugung gekommen, dass es einfach darauf ankommt, wann Du mAirList 3 als stable raushauen willst. Wenn bis dahin der Modus WAIT implementiert ist und getestet worden ist, brauchen wir das synchrone Gehampel nicht mehr.
Bis dahin wäre eine Option schick, falls mAirList schon mal bei mir on Air in die Beta geht. Denn da muss es funzen!