You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dans la mesure où l’interface web est presque prête à être donnée au public. Mais aussi car elle risque de devenir l’interface privilégiée même pour nous (en développement et en spectacle), il faut régler rapidement tous les soucis que posent l’integration des commandes (*bip*, *info*, etc.) à cette interface.
Ça veut dire revoir un peu la mécanique de ces commandes. Voir totalement les repenser (jusqu’à leur syntaxe).
Deux types de commandes
On peut distinguer deux types de commandes.
1- celles qui doivent avoir un effet visible (ou audible). Les commandes output
- bip
- music
- chant
- info
2- celles qui font quelquechose en arrière plan. Les commandes système
- todo
- setmaxconf
- quit
Prise en charge des commandes
L’idée serait que les commandes output soient prisent en charge par les output adapters. On a commencé à faire ce travail. Il faut le systématiser. Pour les commandes système, deux options : ou elles continuent à être prisent en charge par l’objet Alan, ou on crée un nouvel objet genre command adapter . Ça permettrai d’alleger Alan.py
Cas des commandes non prises en charge.
Supposons que dans une certaine configuration, une certaine commande ne soit pas prise en charge. Par exemple la commande *music* avec un output adapter qui ne fais pas du tout de son.
Deux solutions :
1- comme c’est le cas pour l’instant, quand ça arrive il ne se passe juste rien. Donc par exemple Alan dit « et là tu m’entends si je fais bio ? » et on entend rien.
2- les répliques contenant des commandes non prises en charges sont censurées. Donc Alan tente de dire « et l à tu m’entends si je fais bio ? », la réplique est censurée et c’est celle qui a la confiance juste en dessous qui sors (d’un autre Logic adapter)
La syntaxe
La syntaxe pour l’instant c’est *command* ou `command argument1 argument2’
Je propose de passer à un balisage ouvrir/fermer donc ou le signe de fermeture est différent du signe d’ouverture.
E.g. [command] ou encore *command/* a voir une solution qui ne crée pas de conflit avec rivescript.
Le moment du traitement.
Pour l’instant les commandes sont traitées à la fin de Alan.talk donc après l’envoie du statement à l’output adapter. C’est surtout important pour la commande *quit* : il ne faut pas que le programme quitte avant de sortir la dernière réplique. Mais ça va poser des problèmes pour les commandes output qui devrait dans l’idee être traité pendant le procès de l’output adapter.
La doc
Enfin pour que tout ceci se passe bien il faut une doc de toutes les commandes bien mise à jour.
The text was updated successfully, but these errors were encountered:
Dans la mesure où l’interface web est presque prête à être donnée au public. Mais aussi car elle risque de devenir l’interface privilégiée même pour nous (en développement et en spectacle), il faut régler rapidement tous les soucis que posent l’integration des commandes (
*bip*
,*info*
, etc.) à cette interface.Ça veut dire revoir un peu la mécanique de ces commandes. Voir totalement les repenser (jusqu’à leur syntaxe).
Deux types de commandes
On peut distinguer deux types de commandes.
1- celles qui doivent avoir un effet visible (ou audible). Les commandes output
- bip
- music
- chant
- info
2- celles qui font quelquechose en arrière plan. Les commandes système
- todo
- setmaxconf
- quit
Prise en charge des commandes
L’idée serait que les commandes output soient prisent en charge par les output adapters. On a commencé à faire ce travail. Il faut le systématiser. Pour les commandes système, deux options : ou elles continuent à être prisent en charge par l’objet Alan, ou on crée un nouvel objet genre command adapter . Ça permettrai d’alleger Alan.py
Cas des commandes non prises en charge.
Supposons que dans une certaine configuration, une certaine commande ne soit pas prise en charge. Par exemple la commande
*music*
avec un output adapter qui ne fais pas du tout de son.Deux solutions :
1- comme c’est le cas pour l’instant, quand ça arrive il ne se passe juste rien. Donc par exemple Alan dit « et là tu m’entends si je fais bio ? » et on entend rien.
2- les répliques contenant des commandes non prises en charges sont censurées. Donc Alan tente de dire « et l à tu m’entends si je fais bio ? », la réplique est censurée et c’est celle qui a la confiance juste en dessous qui sors (d’un autre Logic adapter)
La syntaxe
La syntaxe pour l’instant c’est
*command*
ou `command argument1 argument2’Je propose de passer à un balisage ouvrir/fermer donc ou le signe de fermeture est différent du signe d’ouverture.
E.g.
[command]
ou encore*command/*
a voir une solution qui ne crée pas de conflit avec rivescript.Le moment du traitement.
Pour l’instant les commandes sont traitées à la fin de Alan.talk donc après l’envoie du statement à l’output adapter. C’est surtout important pour la commande
*quit*
: il ne faut pas que le programme quitte avant de sortir la dernière réplique. Mais ça va poser des problèmes pour les commandes output qui devrait dans l’idee être traité pendant le procès de l’output adapter.La doc
Enfin pour que tout ceci se passe bien il faut une doc de toutes les commandes bien mise à jour.
The text was updated successfully, but these errors were encountered: