In diesem Beitrag sind “KI”-generierte Inhalte zu finden. Verantwortlich dafür zeichne ich, denn das gesamte Projekt ist ja auch auf meinem Mist gewachsen. Die “KI” war hier ein reines Hilfsmittel sowie ein Erklärbär. Daraus werde ich zitieren.
Das nachfolgende Script wurde zwar von einer “KI” erstellt, aber von zwei anderen Sprachmodellen revisioniert und von mir in der Praxis getestet.
Liebe Community,
das hier veröffentlichte Script ist gedacht für Anwender von mAirList-Setups ohne Mischpult, also mit Interfaces oder USB-Mikrofonen im Mikrofon-Eingang, während Player und Cartwall auf den Encoder geroutet sind.
Die Idee
Die Idee dahinter ist, dass man mit dem Mikrofon-Button und der automatischen Absenkung (“Ducking”) des Pegels von Player und Cartwall nicht immer gut fährt. Manchmal möchte man ohne ducking in die Industrieblende eines laufenden Titels hineinmoderieren oder eine langsam lauter werdende Ramp nutzen, ohne gleich den Pegel wegzudrücken - das kann mitunter abgehackt klingen.
Warum das Ganze?
Ich möchte das Mikrofon öffnen können, ohne dass das automatische ducking einsetzt. Damit kann das Mikrofon schon auf sein, ohne dass der Pegel des gerade laufenden Elements beeinflusst wird. Möchte ich nun das ducking haben, aktiviere ich den Ducking-Button: Der Pegel wird abgesenkt, so wie wenn ich am Pult den Fader für den Player runterziehe.
Beende ich das Talkover für eine kleine Pause, lasse das Mikrofon aber offen, muss ich nicht ständig das Mikrofon öffnen und schließen, sondern lasse es einfach offen bis zu meiner nächsten Kurz-Moderation. Wie eben auch am Pult.
Denkt einfach nur mal an lange auslaufende Titel, wo für fast eine Minute nur noch instrumental der Beat verlängert wird… und direkt im Anschluss kann ich ohne ducking weiter moderieren, bis ich den nächsten Titel starte und dort - dann wieder mit ducking, falls notwendig - einen sauberen Ramptalk direkt aus der Moderation abliefere.
Das klingt viel flüssiger!
Eure Hörer werden euch diese Fahrweise danken.
So eine Fahrweise und der entsprechende Sound ist damit kein Mischpult-Privileg mehr. 
Handwerk 
Einen Wermutstropfen habe ich dann doch: Das erfordert ein gewisses Maß an Konzentration und Mikrofondisziplin. Handwerk eben.
Also nichts für die Spielkinder, bei denen ein im Hintergrund laufender Fernseher oder das Haustier oder der über einen Lautsprecher mitlaufende Stream vom Mikrofon mit aufgenommen wird.
Wir reden hier über ein Hilfsmittel für engagierte Selbstfahrer ohne Pult.
Vorbereitung
Zu diesem Zweck braucht es zwei Buttons: Einen Mikrofon-Button (das kann der aus dem Encoder-Status sein oder ein separater Erweiterter Button (letzteres wird empfohlen)). Der andere Button ist für das ducking zuständig - wie der heißt, ist fast egal (Ducking?). Auch das soll ein Erweiterter Button sein. Beide sollten als Umschalt-Button konfiguriert sein.
Wichtig!
Eine Vorbereitung braucht es auf jeden Fall: Die automatische Absenkung abschalten.
Diese Checkbox bitte deaktivieren.
Im Ducking-Button müssen wir jetzt noch zwei Befehle in den Aktionen unterbringen:
-
TALKOVER ON
(wenn aktiv) -
TALKOVER OFF
(wenn deaktiviert)
Diese werden im Script wiedererkannt.
Das Script (na endlich!)
Nun zum Script:
{
Hintergrund-Script zur separaten, flexiblen Absenkung ("Ducking") des Player-Pegels in mAirList,
unabhängig vom statischen Ducking, das an normalerweise einen Mikrofon-Button gekoppelt ist.
! In den Encoder-Optionen "Player-Lautstärke absenken wenn das Mikrofon aktiv ist" abschalten/deaktivieren.
Einsatz in einem Bildschirmobjekt "Erweiterter Button":
Aktionen wenn aktiviert: TALKOVER ON
Aktionen wenn deaktiviert: TALKOVER OFF
Individuelle Anpassung der Parameter DUCK-LEVEL (Zielpegel (in dB)), STEPS und STEP_DELAY (in ms)
ist nach Belieben möglich.
Hinweis: STEP_DELAY sollte nicht geringer als 10 ms sein; Begründung im mAirList-Forum.
Berechnung der Absenkungs-Geschwindigkeit: STEPS * STEP_DELAY = FADE_DURATION.
Berechnung der STEPS bei vorgegebener Absenkungs-Geschwindigkeit: FADE_DURATION / STEP_DELAY = STEPS
Getestet mit mAirList v8.0.
Erstellt mit sog. Künstlicher Intelligenz ("KI"), Modell "Claude Sonnet 5" by Anthropic
Vorgabe, Prüfung und Korrekturen: Uli Nobbe, August 2026
Kreative Anregung und Vorarbeit: Community im mAirList-Forum, https://community.mairlist.com/
}
var
fading : boolean;
procedure OnExecuteCommand(Command: string);
var
i, STEPS, STEP_DELAY : integer;
DUCK_LEVEL, vol : single;
p1, p2 : IPlayerControl;
begin
if (Command <> 'TALKOVER ON') and (Command <> 'TALKOVER OFF') then Exit;
if fading then Exit;
DUCK_LEVEL := -12;
STEPS := 12;
STEP_DELAY := 20;
fading := true;
try
p1 := CurrentPlaybackControl.GetPlayer(0);
p2 := CurrentPlaybackControl.GetPlayer(1);
for i := 0 to STEPS do
begin
if Command = 'TALKOVER ON' then
vol := DUCK_LEVEL * i / STEPS
else
vol := DUCK_LEVEL * (STEPS - i) / STEPS;
p1.SetVolume(vol);
p2.SetVolume(vol);
if i < STEPS then Sleep(STEP_DELAY);
end;
finally
fading := false;
end;
end;
Alles schon dagewesen?
Jetzt werdet ihr vielleicht einwenden: “Ja Moment, das gibt es doch schon im Forum, vielleicht sogar mehrfach!”
Stimmt.
Allerdings in unterschiedlichen Ansätzen, die man natürlich für seine Zwecke anpassen kann. Und auch als Zweiteiler: Ein Script für die Absenkung und eins für die Wieder-Erhöhung. Manchmal ist die Absenkung unsichtbar (schwer zu kontrollieren im Fehlerfall) und dann wiederum die sichtbare Variante am Pegelsteller des bzw. der Player.
In der hier veröffentlichten Variante braucht es nur ein Script, das trotzdem über die beiden Aktionsfenster im erweiterten Button ansprechbar ist. Das ist etwas einfacher als das doppelte Script - vor allem dann, wenn es darum geht, die Werte für die Absenkung selbst und die Länge der Absenkung (“Fade Duration”) zu verändern.
Auch hier beschreitet das Script andere Wege als die, die ich bisher gesehen habe: Es lässt freie Wahl bei der fade duration. Es gibt beispielsweise ein Script, das macht je Schritt 1 dB leiser oder lauter (plus eventueller Pause zwischen den Schritten).
Soll heißen: Je stärker die Absenkung, desto langer die fade duration (weil mehr Schritte notwendig sind). Das entspricht jedoch nicht der ursprünglichen Idee der Konfiguration, in der man die Absenkung und die Geschwindigkeit festlegen kann:
Dieses Script hingegen erlaubt die freie Kombination von Absenkungswert und Geschwindigkeit (der Länge). Damit kann man den Wert der Absenkung verändern, ohne die Geschwindigkeit automatisch mit zu verändern. Ganz so wie in der Konfiguration.
Am Ende sind daraus drei frei veränderbare Werte entstanden:
DUCK-LEVEL,STEPS
undSTEP_DELAY.
“Siehe Forum” - Eine Einschränkung
Im Kommentar des Scripts gebe ich den Tipp,
STEP_DELAYsollte nicht geringer als 10 ms sein
Die Begründung dafür liefert die “KI”, denn das war mir bislang auch noch nicht bekannt:
Zur Kenntnis genommen und so an die Community weitergegeben.
Vielleicht vermisst ihr die Variable “Absenkungs-Geschwindigkeit (ms)” wie im Screenshot.
Diese ergibt sich aus STEPS * STEP_DELAY.
Ich zitiere erneut aus der begleitenden Dokumentation der “KI” im Chat zur Erstellung des Scripts.
Es gibt aber auch praktische Hinweise, dass man es bitte nicht übertreiben möge:
Grundsätzliches
Dann noch ein paar eigentlich selbstverständliche Hinweise, die ich deshalb schreibe, weil übereifrige, prüfende "KI"s gerne so etwas anmeckern. Für Nachahmer ein Fingerzeig.
-
Wir gehen hier von zwei Playern in einer Playlist aus. Bei abweichenden Konfigurationen ist das Script entsprechend anzupassen.
Eine “KI” hat tatsächlich vorgeschlagen, die Zahl der Player zu prüfen, um Fehlermeldungen abzufangen, wenn sich zwischenzeitlich die Zahl der Player geändert hätte oder gar0sei.
-
Fest vorgegeben: Der Pegel des Players steht vor dem ducking bei
0und nicht bei einem manuell veränderten Wert.
Begründung: Das Script geht immer von einem Ausgangswert von0aus und kehrt auch dahin wieder zurück. Es findet keine Abfrage eines individuell eingestellten Pegels des Players statt. Wäre das erwünscht, müsste das Script erheblich ausgebaut werden. -
Das Script sollte nicht während einer Live-Sendung verändert werden. Anpassungen sollten während Wartungsfenstern in unmoderierten Sendestrecken erfolgen.
Was so eine “KI” uns zutraut und wie wenig Ahnung sie vom ordentlichen Radiobetrieb hat - das ist schon bezeichnend.
Namensgebung
Es wäre ungeschickt, dem erweiterten Button, der die im Script genutzten Fernsteuerbefehle enthält, selber die Fernsteuer-ID TALKOVER zugeben. Denn im Script wird auf die Kommandos TALKOVER ON und TALKOVER OFF geachtet. Soll der erweiterte Button trotzdem die Fernsteuer-ID TALKOVER erhalten, müssen die entsprechenden Kommandos abgeändert werden.
Praxistipp
Unabhängig vom Script wäre es eine gute Idee, die beiden Buttons in Abhängigkeit zueinander zu setzen.
-
Beim Einschalten des Ducking-Buttons sollte auch das Mikrofon mit eingeschaltet werden
(Befehl ausführenMIKROFON ON) -
Wird das Mikrofon ausgeschaltet, sollte auch das ducking beendet werden.
(Befehl ausführenDUCKING OFF)
Das erspart Arbeit und vermeidet Fehler.
Abschließend
Das soll es gewesen sein. Für technische Rückfragen steht meine “KI” gerne zur Verfügung.
Abschließend hat sie mich, beinahe demütig, noch um etwas gebeten:
Na ja.
Ja, ich habe immer wieder Verständnisfragen gestellt und damit zum Rundschliff beigetragen, statt einfach nur den ersten Entwurf zu schlucken. Aber direkten Einfluss habe ich nicht genommen; vielmehr entwickelte die “KI” aufgrund meiner Fragen und Unklarheiten eigene Strategien zur Verbesserung des Scripts.
Technische Daten
- Erstellende “KI”: Claude Sonnet 5 by Anthropic
- Prüfende “KI” #1: ChatGPT-5.6 Sol by OpenAI
- Prüfende “KI” #2: Gemini 3.5 Flash by Google
- Praxistest: mAirList v8.0.9
- Ideengeber: @Tondose, @shorty.xs und viele andere Forenschreiber im hiesigen Forum
… sowie der hier noch nicht angemeldete Kollege, mit dem ich gemeinsam an einer Optimierung der jeweiligen mAirList-Instanzen gearbeitet habe (bei ihm: noch v7.4.12).
Viel Spaß!
Gruß, Uli