nsm: send client label instead of session name as nsm display_name #174
Conversation
|
Je suis assez d'accord, c'est pas con. Je réflechi deux ou trois jours histoire de pas prendre ce léger changement d'API à la va-vite, mais c'est en bonne voie ;) |
|
cool :)
Le 27/04/2023 à 18:57, Houston4444 a écrit :
…
Je suis assez d'accord, c'est pas con. Je réflechi deux ou trois jours
histoire de pas prendre ce léger changement d'API à la va-vite, mais
c'est en bonne voie ;)
—
Reply to this email directly, view it on GitHub
<#174 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIESZ45OPN5VWU4K6DHITDXDKQRPANCNFSM6AAAAAAXOBJUZU>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Ça pose quand même problème en fait. Le 'label' n'existe pas forcément (il peut être vide), de plus le label peut être changé côté RaySession, il ne sera pas mis à jour côté client, alors que le nom de session lui ne peut pas changer pendant qu'elle est chargée. |
|
Ça me semble tout de même plus pertinent que de passer le nom de la
session dans la mesure ou redémarrer le client est une action assez
simple, et on peut toujours passer le nom de la session s'il n'y a pas
de "label". L'alternative serait pour le client d'utiliser le
"client_id", mais du coup ça rend le "display_name" plutôt inutile
(d'ailleurs je ne suis pas certain qu'il soit beaucoup utilisé
actuellement, en tout cas je ne vois pas trop son intérêt en l'état).
Le 2023-04-29 14:42, Houston4444 a écrit :
Ça pose quand même problème en fait. Le 'label' n'existe pas forcément
(il peut être vide), de plus le label peut être changé côté RaySession,
il ne sera pas mis à jour côté client, alors que le nom de session lui
ne peut pas changer pendant qu'elle est chargée.
--
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Je viens de lancer toutes les applications NSM dispo sur ma machine. Je n'ai vu le display_name utilisé que par Non-Mixer-XT, Non-Timeline et Qtractor. Détail intéressant, dans Non-Mixer (l'original), ce n'est pas le display_name qui est utilisé, mais le nom de client JACK (donné par le serveur NSM). C'est donc un choix délibéré du dev de Non-Mixer-XT, peut-être que ça vaudrait le coup de voir de son côté s'il peut changer ou accepter différentes options. Moi ça m'arrangerai, je suis pas chaud chaud pour une valeur qui selon les cas n'évoque pas la même chose, ni pour une option de plus qui affecterait le comportement visuel de 3 programmes seulement. |
|
C'est moi qui ai fait ce choix dans non mixer xt. À mon avis il faut le voir dans l'autre sens : seules 3 applications utilisent le display_name (pour des raisons sémantiques vraisemblablement) mais dans l'état actuel des choses il est inutile, dans l'exemple d’implémentation du fichier nsm.h c'est carrément marqué en commentaire (https://github.com/jackaudio/new-session-manager/blob/e90fa99a5b94f9a93cf209003aad486a37bea07c/extras/nsm.h/nsm.h#L22-L38), donc un tel changement n'aurait qu'un effet bénéfique (-> donner un nom d'affichage au client spécifique au client). Après c'est effectivement une zone d'ombre dans l'API, il n'y aucune explication/destination officielle pour cette variable, et je pense que l'utilisation de plusieurs instances d'un même logiciel dans une session nsm est une possibilité qui avait simplement été éludée, en tout cas d'un point de vue interface utilisateur. Pour moi l'alternative sera de faire en sorte que non-mixer-xt utilise le client_id ou le nom du répertoire qu'il charge pour en déduire le nom de session à afficher, c'est pas vraiment un problème mais ça fera une appli de moins à utiliser le display_name et il me semble que ça prouve un peu mon point ;). Je comprends quand même la réserve que tu avances, donc je n'insisterais pas plus si ça te semble insuffisant. |
Non-Daw uses it as display name (non-timeline and non-mixer. Non-sequencer just being neglected probably). It functions here as display name similar to what Ardour would display, but then for a modular daw. So it's no surprise that the comment is not in the original version: |
|
If I understand it correctly from the discussion, you're using multiple instances of non-mixer in one session.I was wondering why exactly. Every mixer strip in non-mixer is in fact a JACK client in itself (multi jack client) isn't it? @jean-emmanuel |
|
Yes, there are currently 45 instances of non mixer running in the session you're referring to, it's that way for multiple reasons:
|
|
The third reason is interesting, I didn't think of that. While I'm not sure if non-mixer is designed to use multiple instances in one session, you've a very special setup with special needs probably. Also one could argue that non-mixer shouldn't crash, but shit happens. I would say the NSM api has the label feature for this use case. This is what NSM-Proxy is using. The user is able to set a label in NSM-Proxy, which is send to the NSM GUI via the NSM server. It's the responsibility of the NSM client to (re)store the label. I don't think Ray-Session is supporting this feature though (which I doubt is the best thing to do for compatibility reasons). |
|
Every software crashes eventually ;). Anyway I solved the issue in my non-mixer build. |
Ça semble plus utile pour distinguer plusieurs instances d'une même application lorsque celle-ci utilise l'argument
display_namede la commande/nsm/client/openpour afficher un nom de session dans son interface (par exemple non-mixer-xt).