Ne garder que la valeur Start éditable et éliminer la possibilité d'éditer la valeur réelle des paramètres spatiaux ?

[NicolaGiannini]

Que penses-tu de la possibilité de ne garder que la valeur Start éditable et d'éliminer la possibilité d'éditer la valeur réelle des paramètres spatiaux ?

Par valeur réelle, j'entends celle qui se trouve par exemple juste au-dessus du cercle d'azimut.

Je pense que cela éviterait toute confusion entre les deux valeurs (Start et Réel) et que de manière générale l'interaction avec le dispositif pourrait être plus fluide, notamment lors de l'écriture des automations.

Voici ce que je propose, pour l'Azimut, mais cela pourrait s'appliquer aux autres paramètres.

• Seul Start est modifiable. La valeur réelle est visible, mais n'est pas modifiable.
• La valeur Range est de zéro par défaut.
• Bien qu'aucun descripteur audio ne soit actif dans la matrice, en éditant Start, je modifie la valeur réelle d'Azimuth et je déplace la source (est-ce possible ?).
• La valeur Range pourrait être grisée à l'ouverture de l'appareil et devenir modifiable dès qu'un descripteur audio est activé dans la matrice. Cependant, elle pourrait aussi être toujours modifiable, comme maintenant, et elle n'aurait toujours pas d'effet sur la valeur réelle de l'azimut lorsqu'aucun descripteur n'est sélectionné.

Cela permettrait à la fois d'écrire les automations des mouvements à la main (Range = 0 ), et d'utiliser les descripteurs pour piloter le paramètre (Range pas égal à zéro).

Qu'en penses-tu ?

[jpjullin]

V0306

J'ai testé en supprimant la possibilité d'éditer la valeur réelle, mais ça complexifie beaucoup le code pour pas grand chose.

Je pense que garder la valeur réelle éditable pour justement écrire des automations, et garder la valeur de Start modifiable est sans doute le plus simple et clair. Pareil pour la valeur Range: si elle est èa 0 par défault, je pense que les utilisateurs ne vont pas comprendre pourquoi ça semble ne pas fonctionner. Griser cette valeur et l'activer en fonction d'un descripteur actif dans la matrice rend le code assez lourd pour pas grand chose également.

J'ai quand même modifié les possibilités, il reste désormais seulement Start et Range pour les paramètres de SpatGRIS. Pour le reste, le code devient assez complexe et c'est certain qu'il y aura des bugs. Est-ce que ça irait comme ça, en gardant la possibilité d'écrire des automations avec la valeur réelle directement?

[NicolaGiannini]

V0308 Merci beaucoup pour tous ces tests ! En ce qui concerne le paramètre Range, je suis d'accord pour le laisser comme ça.

Concernant le paramètre Start, comme on s'en est rendu compte dans cet issue https://github.com/jpjullin/MapSPAT/issues/4 maintenant si on veut créer des trajectoires manuelles, par exemple avec l'azimut et ensuite piloter le même azimut avec des descripteurs, le seul moyen est d'enregistrer des automatisations du paramètre Start.

Personnellement, je trouverais plus intuitif de pouvoir éditer un seul paramètre Azimut, qui peut être contrôlé soit manuellement, soit via un descripteur. Cette approche, je pense, rendrait également plus claire la présentation du fonctionnement dans le manuel d'utilisation.

Cependant, je comprends les complexités techniques et les bogues potentiels qu'un tel changement pourrait introduire. Si tu penses que ce changement est trop complexe, nous pouvons laisser les choses telles qu'elles sont.

Dans tout cas, merci beaucoup !

[jpjullin]

V0309

J'ai tenté une variante:

Tant qu'un paramètre de Spat n'est pas assigné à un descripteur dans la matrice, les paramètres de Start et Range sont grisés. Seul le paramètre de valeur actuelle est disponible.

Si le paramètre est contrôlé par un descripteur, alors la valeur actuelle reste visible mais devient grisée. Les paramètres de Start et Range deviennent disponibles.

Est-ce que tu penses que ça pourrait être assez clair?

[NicolaGiannini]

V0309 Merci beaucoup pour cela.

Avec cette version, si j'enregistre une automation manuelle sur Azimuth et que j'active ensuite un descripteur sur Azimuth, les deux valeurs d'azimut (Start et réel) entrent en conflit et le problème de l'Override de l'automation se pose à nouveau.

https://github.com/jpjullin/MapSPAT/assets/35705913/b65c2b5c-0cf7-4997-8b89-0c91a6a2a2a5

[jpjullin]

C'est bien ça qu'on veut non? Si on passe en mode descripteur, l'automation enregistrée se grise et n'est plus active.

Si on veut avoir des automations ET des descripteurs, alors on peut choisir nos descripteurs et quand on veut une automation alors on met le range à 0% et on change le start

[jpjullin]

V0310

J'ai changé le fonctionnement pour que si tu passes du mode manuel à descripteur, les automations restent et Live ne passe pas en mode override. Par contre évidemment les automations n'ont plus d'effet, à moins d'enlever le descripteur qui fait les changements dans la matrice.

Est-ce que tu préfères comme ça?

[NicolaGiannini]

V0310 Merci pour toutes ces propositions ! J'ai essayé cette dernière version et je ne trouve probablement pas très intuitif le fait que si j'enregistre une automation manuelle et que j'active ensuite un descripteur, je perde l'automation enregistrée.

Mais à part ça, j'ai trouvé une idée, qui, je pense, pourrait fonctionner si elle est expliquée dans le manuel (qu'il faudra qu'il soit inclus avec le dispositif et je peux m'en occuper).

L'utilisation principale est d'utiliser les paramètres spatiaux avec les descripteurs, donc cela implique de manipuler le paramètre Start. À mon avis, nous pourrions régler les 4 paramètres spatiaux sur Loud par défaut, avec le Range réglé sur zéro.

L'utilisateur-rice pourrait alors manipuler le paramètre, augmenter le Range, enregistrer des automations manuelles et sauvegarder des presets en travaillant uniquement sur Start. S'iel veut changer le descripteur, iel peut le faire à partir de la matrice.

En expliquant tout cela dans le manuel, je pense que cette solution pourrait fonctionner et être compréhensible pour l'utilisateur-rice, je pense que potentiellement aucune automation ne pourrait être perdue, ni aucun bug créé. Dans ce scénario, la valeur réelle resterait toujours grise et non modifiable, tandis que la valeur Start serait toujours modifiable.

Qu'en penses-tu ?

Sinon, si tu n'es pas d'accord, je reviendrais à la version où tout pouvait être édité dès le départ.

[jpjullin]

En fait si tu enregistres une automation puis que tu active un descripteur, tu ne perds pas l'automation enregistrée. Elle est simplement cachée, tu peux la retrouver si tu désactives le descripteur.

Après réflexion, est-ce que ce comportement ne serait pas intéressant? Il permettrait de passer d'une automation, à un preset avec descripteur, puis de retrouver une automation si on passe à un preset sans descripteur. J'ai l'impression que c'est pas mal flexible, et personnelement j'ai la sensation que déplacer le paramètre start et jouer avec le range est moins intuitif.

Aussi, si on met un desripteur de base dans la matrice (ici loudness), alors à chaque fois qu'on place un nouveau device sur une piste, les informations envoyées à SpatGRIS vont changer. Ce n'est pas forcément grave, mais si on place une source précisément avec ControlGRIS par exemple, puis qu'on place notre device sur une nouvelle piste, on perd la position de ControlGRIS (si c'est le même numéro de source).

Pour l'instant j'ai l'impression que le plus intuitif serait de laisser les choses comme ça, et de voir comment est-ce que les gens s'en servent? Peux-être que @guillaumeMyre pourrait nous donner son avis la dessus?

[NicolaGiannini]

En fait si tu enregistres une automation puis que tu active un descripteur, tu ne perds pas l'automation enregistrée. Elle est simplement cachée, tu peux la retrouver si tu désactives le descripteur.

Pardon, ma faute ! Je n'avais pas bien compris le fonctionnement. Merci pour l'explication. Mais peut-être y a-t-il encore quelque chose qui m'échappe. Je n'arrive pas à revenir à la lecture de l'automation manuelle après avoir basculé sur un preset avec un descripteur. Il semble que pour réactiver l'automation, je doive appuyer sur "Renable automation" dans Ableton. Voici un exemple :

https://github.com/jpjullin/MapSPAT/assets/35705913/b3c79e65-9319-4d2d-af9f-3ff6ce34c0c9

\\

Je remarque aussi que dans mon cas, la création d'un preset avec un descripteur rend les paramètres Start et Range gris, et les deux paramètres ne semblent plus fonctionner.

https://github.com/jpjullin/MapSPAT/assets/35705913/e2d76aa0-5e1f-4fa9-bd82-d26597253998

La même chose se produit si je ferme et rouvre Ableton. Et cela m'arrive aussi sans avoir créé de preset. Exemple : j'insère MapSPAT dans une piste > J'active le descripteur Loud > Je sauvegarde la session et je redémarre Ableton. Start et Range deviennent gris et ne semblent plus fonctionner.

\\

j'ai la sensation que déplacer le paramètre start et jouer avec le range est moins intuitif.

Pour cela, je m’inspirais aux matrices de certains synthés numériques. Imaginons de contrôler l'amplification d'un synthétiseur avec un LFO. L'utilisateur dans ce cas n'a qu'un seul paramètre de volume (notre start), qu'il peut contrôler via un LFO ; si le LFO est à zéro, le volume reste constant. Je suis d'accord pour dire que les matrices démarrent généralement sans affectations préétablies, mais cela ne semblait pas si contre-intuitif.

\\

L'utilisation conjointe de Start et Range permet également d'influencer le mouvement manuel avec un descripteur (ce qui est déjà possible maintenant de toute façon). Par exemple :

https://github.com/jpjullin/MapSPAT/assets/35705913/9bd6526f-8145-4f68-9dde-1df0439a1612

\\

Aussi, si on met un desripteur de base dans la matrice (ici loudness), alors à chaque fois qu'on place un nouveau device sur une piste, les informations envoyées à SpatGRIS vont changer.

Tu te réfères à la possibilité d'avoir des doublons de canaux OSC ? Si je comprends bien, je pense que cela se produit toujours lorsque l'on utilise MapSPAT en conjonction avec ControlGRIS sur le même canal et qu'on commence à utiliser MapSPAT. Alors dans le manuel, on pourrait dire de faire attention à ne pas envoyer des signaux deux fois sur le même canal OSC. Mais il y a peut-être quelque chose qui m'échappe.

[jpjullin]

Merci pour tout ça.

Bon clairement le fonctionnement des paramètres Start et Range en grisé ne fonctionne pas. Les 2 premières vidéos que tu as envoyé ne font pas le fonctionnement attendu.

Est-ce qu'on supprime complètement la valeur réelle (ou simplement en visu) et on ne garde que Start et Range? C'est ce que tu proposais au début, mais au moins on aura essayé d'autres possibilités! Si tu penses que c'est assez intuitif, ça me va d'y aller avec ça.

Pour la dernière question je parlais bien des doublons de canaux OSC. Mais même si ce n'est qu'une fraction de seconde (le temps de changer le numéro de source dans MapSPAT), ça va quand même envoyer des informations inutiles à SpatGRIS si un descripteur est activé. J'aurais tendance à ne pas avoir de descripteur actif de base.

[NicolaGiannini]

Est-ce qu'on supprime complètement la valeur réelle (ou simplement en visu) et on ne garde que Start et Range? C'est ce que tu proposais au début, mais au moins on aura essayé d'autres possibilités! Si tu penses que c'est assez intuitif, ça me va d'y aller avec ça.

Allons-y avec cela ! Probablement, je garderais la valeur réelle visible, mais non modifiable.

Pour la dernière question je parlais bien des doublons de canaux OSC. Mais même si ce n'est qu'une fraction de seconde (le temps de changer le numéro de source dans MapSPAT), ça va quand même envoyer des informations inutiles à SpatGRIS si un descripteur est activé. J'aurais tendance à ne pas avoir de descripteur actif de base.

C'est vrai, mais si je comprends bien la question, n'est-ce pas exactement ce qui se passe quand on fait glisser une nouvelle instance de ControlGRIS dans Ableton ? Cette nouvelle instance, tant que nous ne changeons pas le canal OSC, envoie des données sur les canaux 1 et 2 de façon continue (même sans audio ni trajectoire, je viens de vérifier avec le Show OSC Monitor dans SpatGRIS) et donc un doublon est créé s'il y a déjà une instance de ControlGRIS réglée sur 1 et 2. Une fois le nouveau canal inséré sur la nouvelle instance de ControlGRIS, SpatGRIS retourne recevoir les données de la première instance de ControlGRIS et les sources retournent alors à leur place.

Par ailleurs, j'ai remarqué qu'une lorsqu'on glisse MapSPAT sur une piste, il envoie des données OSC sur le canal 1, même si l'on ne fait rien. Il n'envoie cependant pas de données en continu.

Voici les données OSC générées par MapSPAT et détectées par le Show OSC Monitor.

Essentiellement, l'envoi d'éventuels doublons d'OSC ne me semble pas si problématique que ça, surtout si on compare MapSPAT à ControlGIRS, mais peut-être que quelque chose m'échappe ?

En tout cas, peut-être pourrions-nous donner la possibilité d'activer et de désactiver les données OSC (comme dans ControlGRIS) à l'aide d'un bouton situé à côté de la source ?

Par exemple :

Par contre, ne pas avoir de descripteurs actifs par défaut, au niveau de l'interaction et de l'interface, je suis d'accord que ce serait probablement plus propre. Serait-ce difficile à mettre en place ? Qu'en penses-tu ?

[jpjullin]

V0311

1. Désormais la valeur réelle est juste visible, on ne peut plus la modifier.
2. Il n'y a plus de données OSC envoyées quand on crée un device. Merci pour l'info, je n'aurais pas pensé à regarder ça. En soit rien ne t'échappe, ce n'est pas vraiment problématique mais je préfère que tout ça le plus clean possible.
3. J'ai ajouté un bouton OSC (On/Off) pour activer ou désactiver l'envoi de données. Je l'ai placé proche des valeurs de Host/Port, ça me semblait plus clair comme ça (comme on choisit d'envoyer ou non des informations à cette adresse là)
4. Je ne suis pas sur de comprendre ta question, il n'y a pas de descripteur actif par défault dans la matrice

[NicolaGiannini]

V1.0 Je donne l'exemple de l'azimut, mais cela s'applique également aux autres paramètres spatiaux.

Maintenant, la valeur réelle n'est pas modifiable via les chiffres, mais elle l'est via la barre bleue. Cette valeur réelle, si elle est modifiée, n'est pas sauvegardée avec le projet.

En principe, je pense qu'il devrait être facile pour l'utilisateur-rice de faire deux choses : 1) Positionner une source en un point de l'espace. 2) Pouvoir influencer cette position par l'analyse des descripteurs.

Je pense que la solution la plus intuitive serait d'avoir une seule valeur d'azimut qui détermine la position d'une source fixe, si le range est zéro. Si, au contraire, le range n'est pas nul, la source se déplace. Cette valeur serait sauvegardée avec le projet. Visuellement, les deux valeurs (réelle et de départ) pourraient encore être visibles. C'est-à-dire que lorsque le range est nul, une seule barre est visible. Lorsque le range est différent de zéro, une barre est fixe et l'autre se déplace. Il peut également être suffisant de ne voir que la valeur réelle.

Si pour faire cela il est nécessaire qu'une affectation de mappage soit déjà active, pour moi cela ne poserait pas un grand problème.

En tout cas, pour sauvegarder une position fixe, maintenant il faut activer un mappage et mettre le range à zéro.

Qu'en penses-tu ?

[jpjullin]

Je n'avais pas pensé au fait qu'on puisse déplacer la source avec la barre bleue. Ce n'est pas prévu, je pensais avoir complètement désactivé l'interaction directe sans passer par un descripteur. Je pensais qu'on ne voulait pas que les utilisateurs puissent changer la valeur réelle.

Je ne suis pas certain de comprendre. La valeur start permet de placer la source à un endroit précis si le range est à 0, et en augmentant le range on peut graduellement influencer cette position avec les descripteurs.

J'ai enlevé la possibilité de changer les barres bleues dans la v1.01. Pour sauvegarder une position fixe, il faut changer start ou range et le sauver dans un preset.

Est-ce que simplement ça répondrais à tes besoins?

[NicolaGiannini]

V101 En ce qui concerne mes besoins, tout fonctionne bien et je réussis à faire tout ce dont j'ai besoin. Cependant, je pense que pour quelqu'un-e qui utilise le dispositif pour la première fois, il pourrait ne pas être très intuitif que pour positionner une source sans l'effet d'un descripteur il faut activer un descripteur. Cela dit, il est toujours possible d'expliquer les étapes à suivre dans le guide sur GitHub.

Juste avant de clore la question, j'aimerais considérer une dernière fois avec toi deux alternatives :

1. Faire en sorte que "Start", même si aucun descripteur n'est sélectionné, contrôle quand même la valeur réelle. Je l'imagine comme si "Start" était mappé à un descripteur "vide" à Range zéro. Une fois qu'un descripteur est sélectionné, tout fonctionnerait comme actuellement. Cependant, je me souviens que tu avais dit que cette solution nécessiterait beaucoup de travail de programmation et pourrait introduire des bugs, donc je comprends si c'est problématique.

2. Une autre option serait d'avoir tous les paramètres spatiaux activés par défaut sur "Loudness" avec Range à zéro. Cela permettrait de manipuler immédiatement les paramètres spatiaux avec un effet sur la spatialisation. Je sais que ce n'est pas une solution très élégante, mais peut-être que je la trouve un peu plus intuitive que l'actuelle.

Sinon, si tu penses qu'il vaut mieux laisser tout tel quel, nous pourrions rendre la valeur réelle grise, pour ne pas donner l'impression qu'elle est modifiable.

Qu'en penses-tu ?

Merci beaucoup en tout cas !

[jpjullin]

v1.02 J'ai fais en sorte que si aucun descripteur n'est activé dans la matrice, start change directement la position de la source. La 2e solution me paraît demander trop de modifications pour faire qu'un descripteur contrôle une position, ce qui serait je pense contre productif.

Je pense que celle actuelle est la solution la plus clean, dis moi ce que tu en penses.

[NicolaGiannini]

v1.02

Ça me semble parfait !

Je me demande seulement si nous ne devrions pas changer la couleur de la valeur réelle, juste pour indiquer qu'elle ne peut pas être modifiée. Mais dans tous les cas, c'est parfait, merci !

[jpjullin]

Parfait!

Pour l'instant je vais laisser ces couleurs, parce que sinon avec les thèmes Live il risque d'y avoir des combinaisons où le texte ne sera plus lisible.