Ce que j’aimerais pouvoir faire, tout simplement : « Gladys, mets l’album de Daft Punk dans le salon », ou dans une scène, « À 7 h, lance ma playlist du matin dans la cuisine ». Et que ça marche quelle que soit la source de la musique (mon Navidrome, Spotify, Plex, une webradio…) et quelle que soit l’enceinte (Sonos, ampli, Chromecast…).
Message édité par Pierre-Gilles le 20/10 pour garder la demande sans l’implémentation
Salut @guim31, merci pour cette proposition super complète, c’est clairement une brique qui manque à Gladys !
Je ne sais pas si j’aurais le temps de m’y pencher avant mon congé paternité, mais voici rapidement ma vision
Oui, c’est du cœur. Les sources et les enceintes sont réparties entre plein d’intégrations, c’est justement au cœur de faire le lien entre les deux.
Il faut un nouveau jeu de fonctionnalités, à réfléchir. Le vrai sujet, c’est de savoir si on crée plein de fonctionnalités séparées pour un lecteur, comme on l’a fait pour Sonos (play, pause, suivant, etc.), ou si on s’appuie sur les supported_options, qui n’existaient pas à l’époque et qui permettent de faire beaucoup plus simple. C’est ce qu’on a fait pour les caméras motorisées : une seule fonctionnalité move, et chaque caméra déclare ce qu’elle sait faire dans ses supported_options, au lieu d’une fonctionnalité par direction. La spec docs/specs/camera-ptz-control.md peut te servir de modèle.
Il faut adapter le widget « Musique » existant pour avoir un beau lecteur dans l’interface, plutôt que d’en créer un nouveau.
Bref, avant tout développement, il y a un vrai travail de spécification et de modélisation des données à faire, et c’est ça qui fera la force de cette feature La spec devra notamment trancher :
comment on décrit un lecteur et ce qu’il sait faire (fonctionnalités séparées ou supported_options) ;
comment on représente « joue ça » : aujourd’hui, une commande d’appareil, c’est une seule valeur (une URL pour play_notification), alors qu’un média, c’est une source, un type, un identifiant… ;
play_media ou play_notification étendu (ta question 2) : une notification est un son court qui s’intercale, alors que lancer un album remplace ce qui joue, ce n’est pas la même chose ;
où on stocke l’état « en cours de lecture » (titre, artiste, pochette) dont le widget aura besoin ;
comment une source se déclare, côté cœur comme côté intégrations externes.
Si tu veux écrire la spec comme tu le proposes, fonce ! Et n’hésite pas à solliciter d’autres développeurs de la communauté pour la review, surtout pendant mon absence
J’ai travaillé hier sur une grosse refonte du widget musique du dashboard. Aujourd’hui, il se limite à trois boutons et un volume. L’objectif est d’en faire un vrai lecteur, au niveau de ce qu’on attend d’une app comme Spotify ou Sonos.
Ce qui est en cours de lecture : pochette, titre, artiste et album, avec une barre de progression qu’on peut faire glisser pour avancer dans le morceau.
Toutes les commandes : lecture/pause, précédent/suivant, aléatoire, répétition, sourdine et volume. Une radio s’affiche « En direct ».
La file d’attente et la recherche s’ouvrent dans un panneau par-dessus le dashboard (depuis le bas de l’écran sur téléphone). Un mini-lecteur y montre tout de suite ce qu’on vient de lancer. On peut parcourir ses playlists, albums et radios, lancer un album entier ou ajouter un titre à la file.
Dans les scènes, une nouvelle action « Lancer une musique sur une enceinte » permet par exemple de lancer sa playlist du matin dans le salon à 7h.
Le tout fonctionne en clair comme en sombre, sur ordinateur, sur tablette murale et sur téléphone.
Via le store : les lecteurs de musique passeront par les intégrations externes du store. Une intégration Sonos est la première prévue, Spotify devrait suivre. Les intégrations actuelles (Sonos, Google Cast, AirPlay) restent telles quelles, et vous pourrez migrer vos appareils vers les nouvelles sans perdre vos widgets ni vos scènes.
Respect de la vie privée : votre navigateur ne charge jamais une image depuis Spotify ou depuis votre enceinte. Les pochettes passent par Gladys, qui les vérifie et les garde en cache.
Léger pour votre installation : rien n’est historisé pour la musique, et la position du morceau n’est pas envoyée toutes les secondes. Gladys la reçoit quand la lecture démarre, se met en pause, change de morceau ou quand on avance, et le widget fait avancer la barre tout seul. La file d’attente et le catalogue sont lus à la demande, jamais stockés.
Spécification d’abord : comme pour les autres grosses fonctionnalités, la spécification a été écrite et relue avant le code. Elle est dans le dépôt, dans docs/specs/external-integrations/capabilities/music.md.
Testé avant la relecture : j’ai testé le widget avec une fausse intégration qui simule trois enceintes (dont une radio), par des tests automatisés dans le navigateur, sur ordinateur, téléphone et tablette, en clair et en sombre. Ça a permis de corriger pas mal de détails avant même la relecture.
Prochaines étapes : merge master, puis le kit de développement des intégrations externes, puis l’intégration Sonos dans le store. Le nouveau lecteur ne sera donc utilisable qu’avec ces intégrations.
Super boulot. J’ai essayer de regarder un peu la PR, si je comprends bien on est vraiment sur la partie contrôle amélioré d’une enceinte c’est ça ? Avec source de l’audio qui vient uniquement de l’enceinte en elle même (ou de la connexion à l’enceinte dans le cas de Spotify connect), ce n’est pas pour diffuser à une enceinte d’une intégration A de la musique provenant d’une intégration B. J’ai bien compris ?
Je veux bien m’occuper de la migration de l’intégration airplay en externe avec ces fonctionnalités, je pense que le protocole est compatible
Edit: ok j’ai compris je n’avais pas terminé de lire la PR, envoyer de la musique depuis Gladys semble être dans les objectifs secondaires Later leads