Solo safe vs mute safe sur une console de son live

TL;DR — Le solo safe maintient généralement un chemin audible lorsqu’un autre chemin est soloé, tandis que le mute safe protège généralement un chemin contre les commandes de mute indirectes comme les mute groups, les DCA, l’automation ou les scènes. Les noms et le périmètre varient selon la console. Testez le modèle exact avec toutes les destinations actives, distinguez une dérogation temporaire d’exploitation d’une exigence enregistrée dans le show, et documentez le chemin protégé, la source de commande, l’état attendu, le comportement des scènes, le responsable et la condition de réinitialisation.

Table des matières

1. Définir les deux protections
2. Choisir le bon safe
3. Comprendre le périmètre et le routage
4. Tester l’état de la console
5. Documenter la passation
6. FAQ

Définir les deux protections

Le solo safe, aussi appelé solo isolate sur certains systèmes, empêche normalement un chemin d’être implicitement coupé lorsqu’un autre canal ou bus est soloé. Un exemple courant est un retour d’effets : soloer une entrée voix reste utile si le retour de réverbération associé peut encore être entendu.

Le mute safe protège normalement un chemin contre une ou plusieurs commandes de mute indirectes. Selon la console, ces commandes peuvent provenir de mute groups, de mute DCA ou VCA, de l’automation, des scènes ou de macros. La touche mute propre au canal peut encore fonctionner, ou son état de mute actuel peut être verrouillé. Le comportement du fabricant doit être vérifié.

Ces protections résolvent des problèmes de contrôle différents. Elles ne réparent pas le routage, n’empêchent pas l’écrêtage et ne garantissent pas qu’un chemin atteigne toutes les destinations.

Choisir le bon safe

Conserver un effet avec une source soloée

Si une entrée est soloée dans un mode qui supprime les chemins non soloés, son send peut toujours alimenter une réverbération tandis que le retour de réverbération est implicitement coupé. Passez le return en solo safe uniquement lorsque l’écoute du contexte wet est le comportement de diagnostic recherché. Vérifiez que le return n’expose pas d’autres sources alimentant le même effet.

Protéger un chemin d’une commande de groupe

Le mute safe peut maintenir un talkback, une annonce, du timecode, un playback ou un chemin de communication d’urgence en dehors d’un large mute group. Cette exception doit être volontaire. Un canal safé peut surprendre un opérateur qui s’attend à ce qu’un seul bouton coupe la scène.

Protéger des réglages contre un rappel de scène

Utilisez recall safe, recall scope ou des filtres de paramètres lorsque l’exigence concerne des snapshots plutôt que des mute groups ou la logique de solo. Protégez uniquement les paramètres nécessaires. Safé l’ensemble d’une entrée alors que seul le gain de préampli doit rester fixe peut conserver un EQ, un routage ou des états de mute obsolètes.

Éviter les safes permanents pour un dépannage temporaire

Une dérogation temporaire de line check doit être retirée lorsque le contrôle est terminé. Sinon, la scène suivante, le mute group ou une action d’urgence peut se comporter différemment de la répétition. Attribuez un responsable et un point de réinitialisation à chaque exception temporaire.

Comprendre le périmètre et le routage

Un safe agit sur une relation de contrôle, pas nécessairement sur le chemin audio complet. Avant de vous y fier, identifiez :

• si le solo est destructif pour le mix principal ou s’il alimente uniquement un bus de monitoring ;
• si la console utilise PFL, AFL, SIP, additive, exclusive ou un autre mode de solo ;
• quelles sources de mute le mute safe ignore ;
• si la touche mute directe reste disponible ;
• si le safe s’applique aux chemins d’entrée, de bus, de matrix, de retour d’effet ou de sortie ;
• si les sends pré-fader, les direct outputs, l’enregistrement et les sorties réseau suivent le mute ;
• si les chemins liés ou stéréo partagent l’état de safe ;
• si les scènes rappellent le safe lui-même et quelles permissions utilisateur peuvent le modifier.

Pour les modes d’écoute, comparez PFL et AFL. Pour le comportement des groupes, lisez DCA vs subgroup. Ces articles expliquent des concepts de signal et de contrôle adjacents ; aucun ne remplace le test d’état safe.

Tester l’état de la console

1. Sauvegardez ou notez l’état de départ connu du show.
2. Nommez le chemin, chaque destination et la commande qu’il doit résister.
3. Envoyez un signal test faible et identifiable à travers le chemin.
4. Vérifiez l’action normale de solo ou de mute avant d’engager le safe.
5. Engagez uniquement le safe prévu et répétez cette commande.
6. Contrôlez la FOH, les retours, les effets, les matrices, l’enregistrement, le stream et les feeds de communication.
7. Chargez les scènes concernées et vérifiez à la fois le paramètre protégé et chaque paramètre non protégé.
8. Testez séparément le contrôle direct, le contrôle de groupe, le contrôle DCA/VCA, les macros et l’automation lorsque c’est applicable.
9. Effacez les safes temporaires et prouvez que les contrôles normaux du show fonctionnent à nouveau.
10. Sauvegardez le fichier approuvé et consignez le modèle de console, le firmware, la scène, l’opérateur et le résultat.

Ne testez pas un comportement destructif de solo-in-place ou de mute de sortie via une sono ouverte sans plan maîtrisé. Commencez en mode muet ou à un niveau d’écoute sûr et suivez le manuel de la console.

Documenter la passation

Dans Techrider.live, gardez le nom du chemin cohérent avec la liste d’entrées et les notes de routage. Invitez l’ingénieur responsable à modifier et sauvegarder le même Rider, puis inspectez l’historique après les changements de décision du show-file. Exportez un PDF daté pour la passation hors ligne au lieu.

Checklist d’état safe

• Définir la commande de contrôle exacte qui est contournée.
• Confirmer la terminologie de la console et le comportement du firmware.
• Protéger le plus petit chemin ou ensemble de paramètres utile.
• Tester toutes les destinations et scènes concernées.
• Vérifier le flux direct de mute et le workflow d’urgence.
• Étiqueter les exceptions temporaires et leur point de réinitialisation.
• Sauvegarder et documenter uniquement l’état vérifié.

FAQ

Qu’est-ce que le solo safe sur une console de mixage ?

Le solo safe empêche généralement un canal, un bus ou un return d’être implicitement coupé lorsqu’un autre chemin est soloé. Certains fabricants appellent cela solo isolate, tandis que d’autres utilisent « solo safe » différemment, donc vérifiez la console précise.

Qu’est-ce que le mute safe sur une console de mixage ?

Le mute safe protège généralement un chemin contre des commandes de mute indirectes comme les mute groups, les mutes DCA/VCA, l’automation ou les macros. Son effet sur la touche mute du canal lui-même et sur le rappel de scène varie selon la console.

Quelle différence entre solo safe et mute safe ?

Le solo safe modifie ce qui se passe pendant le monitoring en solo ; le mute safe modifie ce qui se passe quand une commande de mute arrive. Recall safe est une troisième fonction qui protège des paramètres contre les scènes ou les snapshots.

Faut-il mettre les retours d’effets en solo safe ?

Oui, parfois, lorsqu’un ingénieur doit entendre une source soloée avec son effet. Vérifiez si d’autres sources partagent ce return, car le fait de le laisser audible peut révéler plus que la source visée ou compliquer l’isolation de panne.

Les mute safes sont-ils rappelés avec une scène console ?

Cela dépend du modèle de console, du firmware, de la structure du show-file, du recall scope et des réglages utilisateur. Testez si l’état safe est global, stocké dans le show ou rappelé par scène au lieu de l’assumer.

Rendez chaque exception visible

Construisez un Rider unique et à jour dans Techrider.live, nommez chaque chemin protégé et sa condition de réinitialisation, et fournissez au lieu une passation qui explique pourquoi une exception apparente de mute ou de solo existe.

---

Dernière mise à jour : 2026-09-21 · Vérifié pour les distinctions solo, mute, recall, routage et passation de show-file.