Personnaliser et automatiser le lancement des sessions audio

- Aumix Scripts bash par ardoisebleue ALSAMixer TM Launcher GlossaireL Portail Système

Accueil Systeme > Portail Système > Scripts Bash

Avant-propos : cette page se veut à mi-chemin entre une documentation sur l'écriture de scripts bash et un tuto expliquant comment créer des scripts de lancement de vos applications audio.
Les concepts généraux de la programmation sous bash seront introduits, et des exemples prêt à l'utilisation seront fournis.
Cette documentation ne prétend pas se substituer à un cours sur bash (pour cela se référer à des sites plus complets), mais elle détaillera particulièrement les commandes qui nous intéressent pour arriver à notre but final : la création d'un gestionnaire de session audio hautement personnalisé.

Intro

Comment faire pour qu'une session de travail soit rétablie telle qu'on l'avait quittée et reprendre rapidement le travail ? Telle est la raison d'être de cette page qui aborde le B.A.BA des scripts bash sous Linux ainsi que les différents endroits où ils peuvent se placer.

Les scripts bash

Un script est un fichier texte qui contient une série d'instructions qu'on pourrait passer via la console.
Ces fichiers textes doivent être exécutable par l'utilisateur. Pour rendre un script exécutable :

chmod +x mon_script

l'exécution sera rendue possible par tous les utilisateurs.
Si cela ne vous convient pas, cf

man chmod

Les variables

Pour modifier ou créer une variable, il suffit de procéder ainsi :

mon_repertoire="/home/Documents/"

On a affecté à "mon_repertoire" la chaine de caractère "/home/Documents/"
Pour appeler cette variable, on utilise le caractère clé $ :

echo $mon_repertoire #affiche /home/Documents/

dans la sortie standard (la console).

Séparer/enchainer des commandes (& && ;)

pour exemple, on essaiera de lancer jackd et yoshimi à sa suite, avec une pause entre les deux

Séparer les commandes

Dans une console, pour lancer plusieurs commandes à la suite les unes des autres en une seule fois, il faut un séparateur spécial.
Les deux séparateurs spéciaux ";" et "&&" permettent de lancer une commande, attendre la fin de son exécution et puis lancer la commande suivante

dans une console

$ sleep 5 ; yoshimi
''...ou alors...''
$ sleep 5 && yoshimi

la différence entre ces deux commandes, c'est qu'avec la première yoshimi sera toujours exécuté, et qu'avec la seconde yoshimi ne sera exécuté qu'à la condition que sleep se déroule correctement
pour mieux cerner la différence essayer les commandes volontairement foireuses suivantes :

dans une console

$ echoooo "première commande" ; echo "deuxième commande"
''...et...''
$ echoooo "première commande" && echo "deuxième commande"

dans un script, on peut aussi utiliser ces éléments, le séparateur ; étant un équivalent d'un retour à la ligne

l'avant plan/l'arrière plan

dans un shell, il y a deux possibilités pour lancer des commandes : en avant plan, et en arrière plan

Une commande lancée en avant plan empechera toute autre manipulation dans le même shell avant la fin du processus invoqué

dans une console

$ jackd ; sleep 5 ; yoshimi
''...déroulement de jackd...''
''...ne se termine qu'à la fermeture du terminal...''
''...ou alors en appuyant sur "Ctrl-C"...''
''...sleep ne se lance qu'à la fermeture de jackd à la main...''
''...puis yoshimi refuse de démarrer seul...''

dans un script

#/bin/bash
jackd
sleep 5
yoshimi
''...meme effet : script inefficcace...''

Une commande lancée en arrière plan permet l'exécution d'autres commandes en parallèle. C'est facile, il suffit d'ajouter le signe & (un seul &) à la suite de la commande

dans une console

$ jackd & yoshimi
''...lance jackd en arrière plan et yoshimi immédiatement après (en avant plan)...''
''...si on ajoute le temps de pause...''
$ jackd & sleep 10 ; yoshimi
''...lance jackd (arrière plan), puis tout de suite après 10 secondes de pause (avant plan)...''
''...qui une fois éxécutées autorisent le lancement de yoshimi (avant plan)...''

dans un script

#/bin/bash
jackd &
sleep 10
yoshimi

logging : redirections de messages

Lors du lancement d'un programme dans la console, on verra apparaitre des messages, ou pas.
En général, un programme simple, comme par exemple mv, n'imprimera rien à l'écran si toutes les opérations se sont bien déroulées : il s'agit d'un design simple et élégant.
Lors d'une erreur, les messages s'affichant dans la console sont appelés "standard error" (stderr, sortie standard pour les erreurs).

Il existe souvent une option "bavard" que l'on peut ajouter aux commandes, par exemple mv -v. Celle-ci permet d'avoir des informations sur le déroulement des opérations en cours, qu'elles se passent bien ou pas. Ce qui s'imprime alors est appelé "standard out" (stdout, sortie standard générale).

Des programme plus compliqués, comme jackd, affichent des messages dans la console dans tous les cas.

Lorsque l'on lance un script, les messages s'affichent dans la console avec laquelle le script a été lançé. Celà peut être pratique pour repérer d'éventuelles erreurs d'écriture lors de la conception du script et des premiers essais, mais une fois que tout fonctionne correctement il peut être interressant de cacher les messages habituels et de les rediriger dans un fichier texte consultable à la demande.
En gros on veut créer un log, un journal des messages pour chaque application démarrée par notre script.

Voilà pour l'introduction, place aux exemples :

Exemple n°1

jackd

les messages généraux et d'erreurs apparaissent dans la console

console

JACK server starting in realtime mode with priority 70
JackFFADODriver::ffado_driver_wait - unhandled xrun

Exemple n°2

jackd __>__ /var/log/jackd_msg.log

seuls les messages d'erreur apparaissent dans la console, les messages généraux sont copiés dans un fichier

console

JackFFADODriver::ffado_driver_wait - unhandled xrun

jackd_msg.log

JACK server starting in realtime mode with priority 70

Exemple n°3

jackd __2>__ /var/log/jackd_err.log

seuls les messages généraux apparaissent dans la console, les messages d'erreur sont copiés dans un fichier

console

JACK server starting in realtime mode with priority 70

jackd_err.log

JackFFADODriver::ffado_driver_wait - unhandled xrun

Exemple n°4

jackd __&>__ /var/log/jackd.log

rien n'apparait dans la console, tous les messages sont copiés dans un fichier

console

jackd.log

JACK server starting in realtime mode with priority 70
JackFFADODriver::ffado_driver_wait - unhandled xrun

Les chemins pour lancer des scripts

Pour lancer un fichier, il y a deux possibilités :

en spécifiant le chemin d'accès :
- le chemin relatif : le répertoire de référence est celui où l'on se trouve
- le chemin absolu : le répertoire de référence est le répertoire racine /
en mettant le script dans un répertoire connu par bash pour contenir des exécutables

spécifier le chemin d'accès
Il est préférable d'utiliser le chemin absolu, car le chemin relatif devra être modifié si vous déplacez de répertoire le script bash, ou si vous mettez le script en crontab
(Pour ceux qui ne connaisse pas crontab, c'est un programme qui permet d'exécuter des scripts, des commandes... automatiquement en configurant l'heure et la date d'exécution)
Exemple:
On a cette arborescence :

/home
         /Documents
                           /scripts
                                      /mon_script

on vérifie d'abord dans quel répertoire on se trouve, grâce à la commande "pwd".
On suppose qu'on se trouve dans le répertoire /home et on veut lancer mon_script.
Il suffit de taper dans la console

chemin absolu

/home/Documents/scripts/mon_script

chemin relatif

scripts/mon_script

si on se trouve dans le répertoire script/ lui-même, alors la commande mon_script ne fonctionne pas car il faut toujours spécifier le répertoire avant la commande. on utilisera alors :

./mon_script

il faut savoir que :

./ signifie "le répertoire courant" (scripts/)
../ signifie "le répertoire du niveau supérieur" (Documents/)
../../ signifie "le répertoire encore un niveau supérieur" (home/)

répertoire PATH
une des variables dite d'environnement est la variable PATH.
Elle définie les différents chemins d'accès pour les exécutables de votre système.
C'est grâce à elle que vous n'avez pas besoin de taper "/usr/bin/nano" pour démarrer cet éditeur de texte bien connu.
À la place de cela, tapez simplement "nano", et bash se charge de rechercher un exécutable nommé "nano" dans les répertoires de la variable $PATH.
Pour connaitre ces répertoires tapez :

echo $PATH

chez moi par exemple, le résultat est :

/usr/local/bin :/usr/bin :/bin :/opt/bin :/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 :/usr/games/bin

ce qui signifie que bash recherche des exécutables dans les dossiers suivants :

/usr/local/bin
/usr/bin
/bin
/opt/bin
/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
/usr/games/bin

(ils sont séparés par ":")
la plupart des programmes que vous installerez grâce à votre gestionnaire de programmes habituel (synaptic, portage...) se trouveront ensuite dans le répertoire "/usr/bin".
le répertoire "/usr/local/bin" est, quant à lui, réservé aux programmes que vous installez "à la main", c'est à dire qu'il n'est pas modifié par les mises à jour ou installation de votre système, et est donc l'endroit idéal pour placer vos scripts fait maison, car ils ne seront pas menacés par un écrasement ici !
essai, on place notre script "mon_script" dans "/usr/local/bin/" (en root).

cp mon_script /usr/local/bin/

quelque soit le répertoire courant (celui dans lequel on est actuellement), la simple commande suivante démarrera notre script :

mon_script

"mon_script" devient alors accessible facilement par tous les utilisateurs du système.

sudo

La commande "sudo" permet de changer d'identité d'utilisateur. Sous les distributions Ubuntu, ça "sudo-ite" à tout va, car seul l'utilisateur root a le droit de toucher aux fichiers du système, et on ne peut pas se connecter en root sous ubuntu. (Note : si si, on peut : sudo su + passwd root)

Donc, si vous tapez une commande et que vous êtes rejeté pour raison de droit, retapez là en mettant sudo au début. Le système demandera de saisir le mot de passe, et le tour est joué.

Si malgré cela vous êtes toujours rejeté pour raison de droit, il va falloir voir du coté des droits propres au fichier ou répertoire avec la commande chmod.

L'en-tête

Un fichier bash commence toujours par une ligne de commande qui donne le chemin de la bibliothèque à utiliser pour que le système comprenne le script. Le chemin est précédé par #!.

Dans la grosse majorité des cas, la première ligne doit être :

#!/bin/bash

Si votre bibliothèque bash ne se trouve pas dans le répertoire /bin, essayez dans /usr/bin, ou /sbin, ou encore /usr/sbin.

Les commentaires

Les commentaires sont toujours les bienvenus dans un code ou un script!

En bash, c'est # qui permet de mettre un commentaire.

Quelques commandes

killall

Cette commande permet de mettre fin à un processus. Elle est pratique par exemple si l'on souhaite redémarrer une session en nettoyant au préalable les anciennes instances des programmes qui auraient pu rester bloquées (ex: un synthé jack zombifié). "killall" s'utilise en précisant en argument un numéro correspondant à la nature de l'interruption qui l'on envoie au processus. Souvent "-9" est utilisé car c'est l'interruption la plus puissante, le deuxième argument est le nom du programme.

killall -9 jackd

sleep

Cette commande permet de demander au système d'attendre avant de lancer un programme et ainsi éviter qu'un programme jack (ex: Ardour 3) se plaigne de ne pas trouver un softsynthé (car son lancement aura pris du temps).

start-stop-daemon

...

Comment les invoquer

Manuellement

Au boot

Certaines distributions ont un script laissé au bon soin de l'utilisateur pour ses besoins personnels, il sera lancé automatiquement à chaque boot. On peut donc y placer certaines commandes personnelles, notez que vous y avez les droits root, cela peut donc servir à plein de choses.
C'est le cas du script /etc/init.d/local sous Gentoo, qui contient une section Start et Stop (pour le boot et le shutdown).

À défaut on peut aussi ajouter un script supplémentaire, et utiliser rc-update (ou la commande équivalente de votre distribution) pour l'insérer dans la liste des scripts exécutés au démarrage.

Vous vous en rendrez compte, il y a certaines limitations à utiliser les scripts au niveau des stages de démarrage car ils sont exécutés avant, ou au même moment que, le lancement de l'interface graphique, ce qui provoque des ratés.

Le dossier "autostart" des bureaux

Cette variante de la méthode précédente vous assure que vos programmes seront lancés au bon moment car c'est le bureau qui s'en charge. Malheureusement chaque bureau a son répertoire propre et cela oblige à avoir une configuration spécifique à chaque fois, bien que le fichier puisse être un lien vers un script dupliqué autant de fois que vous utilisez de bureaux différents.

Une page de documentation Gentoo (mais utilisable sous n'importe quelle distribution) donne l'emplacement de ces répertoires, ici

en anglais pour beaucoup de bureau.

KDE

Gnome

Xfce

Enlightenment

iceWM

sur developpez.com

en français.

Les icônes du bureau

Tout fichier placé dans le répertoire ~/Desktop apparaitra sur le bureau, c'est donc le répertoire idéal pour placer ses scripts personnels. On peut ainsi personnaliser à loisir des scripts correspondants à tel ou tel usage, et en profiter d'un clic de souris.
Notez que certains bureaux ont besoin que votre script porte l'extension ".sh" pour les identifier comme un script à lancer.

Automatiquement à l'ajout de matériel

udev peut servir à lancer des scripts/applications lors de l'ajout/retrait de périphériques matériel.
Par exemple, la règle udev suivante me permet de lancer mon script de démarrage de jack lors de la mise en marche de ma carte son firewire.

/etc/udev/rules.d/45-jackd.rules

KERNEL=="fw1", ATTR{model_name}=="PreSonus FIREPOD", ACTION=="add", RUN+="/usr/local/bin/mon_script_pour_demarrer_jack"

Pour plus de détails voir la page dédiée udev?.

Autres pistes

Ladish bien qu'encore en développement permet de restaurer une session composée de plusieurs applications. LASH avec un développement très très ralenti, fait la même chose. QJackCtl peut exécuter un script avant de démarrer le serveur JACK. Ce script peut être un script qui en lance plusieurs autres wink

. Voir aussi du côté de jack-session.

Si vous voulez placer auto-magiquement des écrans sur le bureau, vous pouvez aller voir la section consacré à devilspie dans Affichage expert.

Lancer des scripts avec des évènements MIDI

Puredata

Puredata est un logiciel "boite à outils" pour le musicien qui permet entre autre en utilisant l'objet "shell" de l'external ggee

(une extension qui apporte des fonctions supplémentaires) de lancer des scripts (ou des programmes). On peut alors lancer ce script à partir de toutes les sources reconnues par Puredata, et elles sont nombreuses (évènements MIDI, clavier ou souris d'ordinateur, port série ou //, liaison OSC, connexion internet, ... etc).

Cet exemple permet à l'aide de n'importe quelle note MIDI jouée sur votre clavier de lancer l'application Alsaplayer:

Used in Scripts Bash

Mididings

mididings est un logiciel plus léger dont une des fonctions est de pouvoir lui aussi lancer des scripts à coup de commande MIDI.
Contrairement à puredata qui peut être utilisé en manipulant des objets à l'écran (langage de programmation orienté objet), mididings s'utilise en écrivant de petits scripts en langage python, très similaires à bash.