Manuel Taranis/OpenTX/… (epub)

Kilrah a écrit:Euh... c'est bien pour ça qu'il y a un [E]!

bah, dommage, alors il n'est pas suffisant pour différencier car il n'est pas vu comme discriminant.
Le fait qu'il soit - sur l'écran - en inverse, le sépare totalement du 'nom' qui lui est pris comme identifiant.
(D'autant plus que quand on édite, le nom - sans ambiguïté, n'est pas '[E]Gaz', mais 'Gaz')

Le nom n'est pas perçu comme '[E] + Gaz', mais comme 'Gaz'
La preuve, s'il en est : je n'ai pas vu la différence
Et si je ne l'ai pas vue, d'autres pourraient faire la même assimilation.
Et qu'on ne me dise pas qu'il fallait le savoir, car le rôle d'un développeur est - justement - (en plus de tout le reste), de faire tout ce qu'il peut pour éviter les confusions

CoyotteDundee a écrit:Ce qui induit en erreur, c'est que l'entrée [E]GAZ se voit attribuer comme paramètre d'entrée...GAZ. Ceci semble être une redondance. Dès le début, certaines entrées se voient attribuer une pseudo fonction de sortie ce qui complique la compréhension.
Il eut été plus clair de dire que l'entrée [E]GAZ se voit attribuer comme valeur d'entrée "Manche Droit Vertical" (en mode 1) et que, toujours dans le même mode, l'entrée [E]Profondeur se voyait attribuer la valeur "Manche Gauche Vertical".

Merci pour ton explication très pédagogique et limpide de ta méthode de configuration de la radio qui donne tout son sens au bloc d'entrée  
Intuitivement, je n'avais jamais envisagé qu'une sortie d'altimètre puisse être traité comme une valeur d'entrée, je l'aurai plutôt configuré dans le mixeur ou dans un inter logique.

Sinon pour en revenir aux manches, de fait on a configuré la radio pour que ce raccourcit de désignation dise exactement ce que tu décris:



Maintenant que tu m'as donné le décodeur je comprends que [E3]GAZ est une étiquette libellé GAZ que je colle sur le manche D V de ma radio en mode 1, celui-ci sera affecté à l'entrée 3, et lorsque j'aurai terminé la configuration du mixer et de la sortie, le manche en question pourra effectivement commander les gaz.

mais la question reste : quand est-ce que cela amène un plus

C'est pourtant clair... En tant qu'ex-développeur, l'intérêt d'un découplage entre le les paramètres d'entrée et leur utilisation ailleurs dans le modèle de données devrait être évident...

[E]GAZ != GAZ. Ici, le problème de compréhension est majeur. On a deux notions # portant le même nom, qui ne représentent pas la même chose !

Elles ne portent pas le même nom:  l'une s'appelle [E]Gaz et c'est le nom que l'on donne à l'entrée. L'autre s'appelle GAZ et c'est la valeur, la position du manche des gaz.

Imaginons que l'équipe de développement d'openTX généralise le processus jusqu'au bout, nous pourrions avoir par exemple STLV, STLH, STRV et STRH pour Stick Left Vertical, Stick Left Horizontal, Stick Right Vertical et Stick Right Horizontal.
Dans ce cas ou pourrait écrire [E]Gaz = STRV et il n'y aurait plus d’ambigüité.

Ma première solution - mais j'aurais préféré que ce soit clairement différencié dès le début, est de renommer [E]"GAZ" en [E]"Gaz_" (on a une entrée "GAZ_" ayant pour source un manche 'Gaz')

Mais c'est déjà le cas...  Renomme l'entrée GAZ en 'GZ' et dans les mixages, elle s'appelle bien [E1]GZ...
Donc le miracle est déjà accompli...

En tant qu'utilisateur 'pour les nuls', je me montre beaucoup moins accommodant.

Ben... Le challenge n'est-il justement pas de rendre compréhensible quelque chose de moins évident ?


Coyotte

CoyotteDundee a écrit:...
Ben... Le challenge n'est-il justement pas de rendre compréhensible quelque chose de moins évident ?
...

Meuh non, meuh non !

Ce que l'on conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.

CoyotteDundee a écrit:Elles ne portent pas le même nom:  l'une s'appelle [E]Gaz et c'est le nom que l'on donne à l'entrée. L'autre s'appelle GAZ et c'est la valeur, la position du manche des gaz.…

Une fois que le problème potentiel est détecté, il n'y a plus guère qu'un problème un peu gênant, de quasi homonymie.
À mes yeux, c'est une source d'erreur, il est donc préférable de renommer pour éviter la confusion.
Et d'insister - dans la doc - sur ce point de nommage.
Mais on aurait pu éviter en accentuant la différence de nom à la création, parce que - désolé - le [E] n'a pas une grande visibilité… et quelque chose que l'on ne 'voit' pas (suffisamment), n'a pas d'existence.

CoyotteDundee a écrit: Ben... Le challenge n'est-il justement pas de rendre compréhensible quelque chose de moins évident ?

Effectivement, c'est le challenge, sachant qu'une évidence n'est jamais la même pour tous.
Et une évidence que l'on ne voit qu'après explication, ne parait pas si évidente que cela…
Le point qui est intéressant (pour moi, dans le cadre d'une présentation en pas à pas), c'est que cela va me faire inverser l'ordre (et un peu la manière). i.e. présenter d'abord un exemple avec le seul mixer et rajouter - seulement ensuite - la partie 'entrée' avec des cas ou cela n'apporte pas grand chose et d'autre ou cela peut être important.
-----
Je suis preneur d'un exemple d'un " AF butterfly" avec son écran mixer et son entrée si quelqu'un a cela ou peut le réaliser facilement.
Mais, expliquer pourquoi ce n'est pas systématisé (en particulier, via l'assistant) pourrait devenir 'hard'…

elj4Taranis a écrit:Mais on aurait pu éviter en accentuant la différence de nom à la création, parce que - désolé - le [E] n'a pas une grande visibilité… et quelque chose que l'on ne 'voit' pas (suffisamment), n'a pas d'existence.

Comme tu le dis si bien...

elj4Taranis a écrit:une évidence n'est jamais la même pour tous.

En l'occurrence c'est la première fois que j'entends quelqu'un qui ne voit pas un gros symbole bien marqué qu'il n'y a dans aucun autre cas...

En 2.1 Chaque type de source a son symbole, donc encore moins de confusion possible vu que quand tu choisis le manche de gaz tu as le symbole de manche à côté.

elj4Taranis a écrit:Mais, expliquer pourquoi ce n'est pas systématisé (en particulier, via l'assistant) pourrait devenir 'hard'…

Ca c'est clair qu'au vu de ce que tu as mentionné de ton historique ça doit piquer... mais ici on est pas dans un centre de développement mais dans du volontariat, et si on a du plaisir à faire ça c'est précisément parce qu'il n'y a personne pour diriger, et qu'on bosse (ou pas) sur ce qui nous plaît sans obligation, les gens viennent, contribuent et partent comme bon leur semble.
Y'a un gars un jour qui s'est dit "je vais faire un assistant", il l'a fait, c'est cool, mais on l'a plus trop vu depuis et comme ça intéresse personne d'autre bah il a pas évolué. C'est la vie. Si ça te dérange tu peux le mettre à jour plutôt que te plaindre

Kilrah a écrit:En l'occurrence c'est la première fois que j'entends quelqu'un qui ne voit pas un gros symbole bien marqué qu'il n'y a dans aucun autre cas...

Oui, cela paraît évident… à certains.
Mais si une personne ne voit pas, d'autres ont peut-être le même problème, sans le savoir.

Ce que j'ai dit reste valable, il faut simplement attirer l'attention dessus.
Accessoirement (citation):
"L'autre vision consiste à voir la loi de Murphy comme une règle de conception : on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout système comme si la loi était vraie. En particulier, un équipement doit être à l'épreuve, non seulement des accidents les plus improbables, mais aussi des manœuvres les plus stupides de la part de l'utilisateur. Elle justifie donc les principes de la conception sécuritaire préconisant de planifier et d'éliminer d'emblée les possibilités de mauvaise utilisation, par exemple à l'aide de détrompeurs."

Et cela reste valable quel que soit le mode de développement.

Maintenant, si la programmation (future) peut en tenir compte facilement, tant mieux, sinon je mettrai seulement un WARNING gros comme cela tant que le risque perdurera.
J'ai un gros avantage : je découvre la Taranis, ce qui me rend capable de faire toutes les erreurs possibles et inimaginables, ce qui rend le moment rêvé pour faire la doc, AVANT que l'habitude gomme ce qui peut être bizarre pour un 'newbye'. Un vieil habitué n'aura pas ce problème (il s'encroutera peut-être dans ses habitudes), mais une doc est faite à la fois comme référence et pour accélérer le (bon) contact pour ceux qui découvrent.
Note : je suis aussi pilote et dans ce métier, on traque toute erreur d'interprétation … si on a détecté qu'il pouvait y avoir erreur d'interprétation
Bon, les conséquences sont moins graves sur nos micro-modèles

CoyotteDundee a écrit:A la création d'un modèle, il faudrait se demander
1) Quelles sont les fonctions utilisées par mon modèle ?
- Par exemple : Gaz, Ailerons, Profondeur, direction, train rentrant, lumières, flaps, crochet de largage, ...
Ceci détermine les voies utilisées dans l'écran de mixage
2) Ensuite quelles sont les commandes que je veux utiliser pour piloter mon modèle ?.
Gaz, ailerons, direction, profondeur, flaps,  crochet de largage.
Pour chacune des commandes, une entrée devrait être créée dans la page Entrées avec les caractéristiques (dual rate, courbe, ...)
Ensuite, on attribue ces entrées aux voies dans la page mixages.

elj4Taranis a écrit:Le point qui est intéressant (pour moi, dans le cadre d'une présentation en pas à pas), c'est que cela va me faire inverser l'ordre (et un peu la manière). i.e. présenter d'abord un exemple avec le seul mixer et rajouter - seulement ensuite - la partie 'entrée' avec des cas ou cela n'apporte pas grand chose et d'autre ou cela peut être important.

Si la procédure indiquée par CoyotteD est bien adaptée à la structure d'OpenTX (3 blocs Entrées->Mixages->Sorties) est-ce qu'il ne serait pas préférable de démarrer directement avec cette méthode érigée en règle plutôt que de faire l'impasse, en période d'apprentissage des bases, sur le bloc d'entrées alors que l'on peut le court-circuiter si facilement pour beaucoup d'organes de commande ?
Car ici il s'agit plus de règles de programmation que d'impératif pour obtenir un résultat puisque nous avons 2 ou 3 façons d'obtenir le même résultat (les différences portent davantage sur la maintenance du code ou la facilité de programmation).
Par contre, c'est clair que de programmer des organes de commandes à la fois dans le bloc d'entrées et dans le bloc de mixages, c'est bordélique et seulement dans le bloc de mixages c'est une mauvaise habitude qui ne se justifie pas (c'est curieux de vouloir autant challenger le bloc d'entrées qui est fait pour gérer les entrées!).
Une des règles de programmation pourrait être : on programme tous les organes de commande dans le bloc d'entrées.

Hello Dev.Fred

c'est curieux de vouloir autant challenger le bloc d'entrées

Je me suis fait la même réflexion...

Comme toi, je pense que donner d'abord un exemple "sans les entrées" puis un exemple qui les utilise va pourrait ajouter à la confusion. Et ce d'autant plus que l'assistant d'OpentTx crée les entrées pour un modèle de base. Il faudra donc les expliquer (ou les supprimer; ce qui , d'un point de vue pédagogique, n'est pas glop non plus )

Se passer des entrées reviendrait à dire à un programmeur débutant de se passer de la déclaration des constantes ou des #define . Evidemment il est possible de vivre sans, mais c'est tellement plus facile, plus clair et plus souple lorsque ces fonctions  sont utilisées.
(Mille excuses aux non-informaticiens pour cet exemple technique)
Autant prendre tout de suite les bonnes habitudes, en sachant pourquoi.

Je dois reconnaître qu'au début, l'intérêt de l'écran Entrées ne m'a pas frappé. Mais depuis que j'en ai découvert la portée, je trouve que c'est un plus énorme apporté au logiciel.  (Et il y a certainement encore un paquet d'avantages à découvrir...)

Bons vols,

Coyotte

Bon je ne comprend pas où est le problème...

La logique OpenTX est:
ENTREES → MIXAGES → SERVOS → OVERRIDE (Remplacer Chx)

C'est ce qui est expliqué partout.

OpenTX est suffisamment flexible pour faire autrement, MAIS ce n'est pas comme cela que le firmware a été conçu. Le messages qui devrait être passé dans la doc c'est celui-ci et rien d'autre. Après, lorsque l'utilisateur sera suffisamment expérimenté, à lui de faire autrement.

Juste pour illustrer ce que devrait programmer le Wizard s'il avait été écrit en suivant une règle donnant la priorité à l'utilisation du bloc d'entrées:



On doit pouvoir simplement expliquer que le wizard est un peu daté mais qu'un programme bien écrit doit utiliser le bloc d'entrées en priorité.

Et si l'on veut pouvoir régler ses volets de façon dissymétrique comme le Wizard:

LapinFou a écrit:...
La logique OpenTX est:
ENTREES → MIXAGES → SERVOS → OVERRIDE (Remplacer Chx)
...

C'est la logique d'OpenTx et elle est très bien ainsi car elle permet cette programmation tellement, simple, souple et puissante.

Toutefois, il ne faut pas oublier que cette logique n'est que la traduction pour OpenTx d'une approche inverse :
- quels sont les composants de mon engins (SERVO ou sortie, je préfère le terme) :
 - ai-je un moteur, deux moteurs ou pas du tout,
 - ai-je une profondeur et une dérive ou un empennage en V,
 - ai-je des ailerons, des volets, des volets intérieurs ou rien de tout ça,
 - ai-je un train rentrant, une roulette de direction,
 - etc...

- ensuite, il faut déterminer avec quoi on contrôle tout ça (ENTREE) :
 - les gaz, les met-on sur un manche, un interrupteur ou un curseur,
 - idem pour le train rentrant, sur quel interrupteur les met-on,
 - les gaz, les coupe-t-on une fois atteint une certaine altitude ou passé un certain temps (F5J)
 - le train rentrant, le rentre-t-on dès une certaine altitude atteinte, ou au contraire, les sort-on en dessous de telle altitude,
 - etc...

- et finalement, on doit déterminer comment contrôle-t-on tout ça (MIXAGE mais aussi phase, courbe, interrupteur, fonction spéciale et script LUA) :
 - lorsqu'on manœuvre les ailerons, doit-on aussi manœuvrer les volets,
 - lorsqu'on braque les volets, doit-on aussi braquer les ailerons,
 - etc...

Il y a donc un travail intellectuel à faire pour passer d'une description de "que doit-on contrôler ?", "avec quoi contrôle-t-on tout ça ?" et "comment contrôle-t-on tout ça ?", en Phase, Entrée, Mixage, Servo, Courbe, Interrupteur et Fonction spéciales, et dans des cas très particuliers, en Script LUA.

On pourrait se dire mais alors pourquoi ne pas faire un soft qui permette de décrire directement le "quoi", "avec quoi" et "comment" !

Ben c'est que font la plupart des autres softs et dans les cas complexes, ça devient très très compliqué, il faut que le programmeur aie pensé à tous les cas et les aie programmé aussi. Pour l'utilisateur, ce n'est pas simple non-plus car s'il est guidé pour les cas simples, il doit trouver dans le labyrinthe de multiples écrans, où se trouve le cas qu'il veut mettre en œuvre. Et l'utilisateur se retrouve facile avec des cas qui ne sont pas prévus et soit il fait preuve d'ingéniosité et de persévérance pour s'en sortir, soit il fait l'impasse et se satisfait de ce que lui a fourni le programmeur.

C'est la force d'OpenTx (et aussi ses ancêtres), c'est d'offrir un jeu de brique de base simple et facile à programmer pour traduire ce "quoi", "avec quoi" et "comment" en un modèle fonctionnel et aussi en appliquant de "bonnes pratiques" qu'il peut trouver sur le net ou qu'il peut élaborer lui-même à sa convenance.

Là où les wizard peuvent jouer un rôle utile, c'est dans la mise en commun de "bonne pratique" pour les "fonctions" les plus habituelles. C'est un travail que j'avais commencé ce printemps, que j'ai mis en suspens cet été pour profiter des beaux jours mais que je compte reprendre dès que la météo ne se prête plus pour aller en montagne : https://frskytaranis.forumactif.org/t1893-projet-nouveau-wizard-pour-mettre-en-commun-notre-experience

Super ton projet de Wizard, je le découvre  j'ai hâte de le voir redémarrer (de + vous avez un super graphiste dans l'équipe) .
J'espère qu'il fabriquera du code qui ne court-circuite pas le bloc d'entrées

Super, autant l'explication que le remaniement du Wizard, j'avais pas vu non plus

Elj4Taranis a écrit:Je suis preneur d'un exemple d'un " AF butterfly" avec son écran mixer et son entrée si quelqu'un a cela ou peut le réaliser facilement.

Tu as le tuto très complet de ici : https://frskytaranis.forumactif.org/t1486-tuto-programmation-d-un-bixler-2-avec-option-volets#14148
L' AF butterfly ou aérofrein croco est ici paramétré par une variable globale.
Note que l'anglais est un faux ami, car on dit plutôt empennage papillon et aérofrein crocodile AKA croco, enfin tout ce qui évoque un V comme les Anglais, mais pas avec les mêmes bêtes.

@dev.fred

dev.fred a écrit:

Elj4Taranis a écrit:Je suis preneur d'un exemple d'un " AF butterfly" avec son écran mixer et son entrée si quelqu'un a cela ou peut le réaliser facilement.

Tu as le tuto très complet de ici : https://frskytaranis.forumactif.org/t1486-tuto-programmation-d-un-bixler-2-avec-option-volets#14148
L' AF butterfly ou aérofrein croco est ici paramétré par une variable globale.
Note que l'anglais est un faux ami, car on dit plutôt empennage papillon et aérofrein crocodile AKA croco, enfin tout ce qui évoque un V comme les Anglais, mais pas avec les mêmes bêtes.

Kilrah a écrit: butterfly. […]

elj4Taranis a écrit: (butterfly => ? empennage papillon ou => AF du type [volets descendants & ailerons qui se lèvent ? 2nd, i presume)

Bon, pour le faux ami, je l'avais détecté et déclaré en tant que tel (cf plus haut)

Pour ce qui est de mes demandes, je vais quand même mettre les choses au clair, si cela est possible
C'est gentil de me dire qu'il y a là ou ailleurs, quelque chose. Généralement, je prends l'info et j'apprécie.
Mais là, ce n'est pas ce dont j'ai besoin, en priorité parce que j'ai 50.000 (euh, moins) choses sur le feu.

J'aimerai : un exemple expurgé de tout le reste.
Si je dois refaire l'analyse de tout ce qui a été dit, c'est possible, mais cela commence à me 'brouter'.
i.e. j'apprécierai que les gens m'aident en m'apportant ce que je demande, des exemples clairs.
Me dire : il y a là un exemple, est bien (même si - en général, j'ai parfois déjà vu).
Mais il y a mieux à faire, car je perds mon énergie à rechercher et à synthétiser.

@lapin (fou ou sage)

LapinFou a écrit: La logique OpenTX est: ENTREES → MIXAGES → SERVOS → OVERRIDE (Remplacer Chx)
C'est ce qui est expliqué partout.

Sauf que c'est faux (ou insuffisamment vrai)
Doublement :
- Dès lors que l'on peut court-circuiter les entrées, c'est faux parce que l'on peut faire autrement.
- Les entrées n'existaient pas, dans une version antérieure d'openTX, donc ce n'est pas intrinsèque.

Ensuite, on oublie, un point majeur, que l'on admette (ou non) la notion liée à l'écran entrée
l'origine, la seule (l'entrée PRIMAIRE), c'est le seul actionneur (stick, inter, capteur…).
Les schémas possibles (réels) sont donc :
- entrée primaire (actionneur) -> Entrées -> Mixer
OuX
- entrée primaire (actionneur) -> Mixer
sauf à interdire la possibilité de mettre un actionneur en tant que 'source'. Ce qui n'est pas!

Je m'intéresse à deux choses - relativement divergentes :
- ce qui est, est possible
- ce qui pourrait être 'au mieux'
mais ce sont deux choses différentes, donc à différencier.

elj4Taranis a écrit:
Sauf que c'est faux (ou insuffisamment vrai)
Doublement :
- Dès lors que l'on peut court-circuiter les entrées, c'est faux parce que l'on peut faire autrement.
- Les entrées n'existaient pas, dans une version antérieure d'openTX, donc ce n'est pas intrinsèque.
[...]
Les schémas possibles (réels) sont donc :
- entrée primaire (actionneur) -> Entrées -> Mixer
OuX
- entrée primaire (actionneur) -> Mixer

Et ça c'est faux aussi sur le principe... Tu as l'air de chercher une liste exhaustive de ce qu'on peut faire... mais justement tout peut être fait d'une multitude de manières différentes, donc ça ne peut pas exister. Ton OuX n'a pas de sens, on peut (et beaucoup de gens le font) combiner les 2.

elj4Taranis a écrit:
Je m'intéresse à deux choses - relativement divergentes :
- ce qui est, est possible
- ce qui pourrait être 'au mieux'

Ce qui pourrait être "au mieux" c'est ce que LapinFou t'a donné:

LapinFou a écrit: La logique OpenTX est: ENTREES → MIXAGES → SERVOS → OVERRIDE (Remplacer Chx)

Ce qui est possible, est... sans limite. Il y a autant de manières d'utiliser OpenTX que d'utilisateurs d'OpenTX. C'est pour ça que dans la doc l'important c'est d'expliquer ce que chacun des éléments fait et qu'ils peuvent être liés dans tous les sens, pour que l'utilisateur puisse comprendre par lui-même une manière de les utiliser pour arriver à ses fins... et de donner un exemple de ce que l'on considère comme idéal, tout en sachant que ceci peut de nouveau varier d'une personne à l'autre.
On peut pas vraiment simplement dire "fais comme ça".

Hello,

Les entrées n'existaient pas, dans une version antérieure d'openTX, donc ce n'est pas intrinsèque.

Avec un tel raisonnement, aucun logiciel ne peut évoluer, toute fonction n'existant pas dans une version antérieure n'étant pas à prendre en compte...  

Désolé mais vu d'ici c'est un peu... comment dire...  Portnawak ?

Pour enlever une agrafe, je ne suis pas obligé d'utiliser la patte prévue pour ce faire le long de mon agrafeuse. je peux utiliser un tournevis ou un marteau... Mais c'est tout de même plus facile avec l'outil ad-hoc.
Dans mon traitement de texte, je ne suis pas obligé d'utiliser les styles pour formater mon texte... (Et comme ces styles n'existaient pas dans les premières versions ce n'est pas une fonction intrinsèque...) N'empêche que c'est vachement plus facile de changer le format de tous mes titres lorsque je leur ai affecté un style...
(un bon bouquin d'initiation t'invitera à les utiliser. Et si ton bouquin ne le fait pas, change de livre... Ces gens là ne cherchent pas à te simplifier la vie )

Les schémas possibles (réels) sont donc :
- entrée primaire (actionneur) -> Entrées -> Mixer
OuX
- entrée primaire (actionneur) -> Mixer
sauf à interdire la possibilité de mettre un actionneur en tant que 'source'. Ce qui n'est pas!

Pourquoi interdire ? Qui peut le plus, peut le moins.
La souplesse est justement de pouvoir faire ce qui est le plus adéquat en fonction de la situation. Ce qui n'empêche pas de prendre de bonnes habitudes dès le départ.

Lorsque tu étais responsable de développement, tes développeurs pouvaient taper des paramètres "en dur dans l'application" (ce qui n'est "interdit" par aucun langage)  ou les stocker dans un fichier pour plus de souplesse...
Je suppose que tu privilégiais l'option fichier et que tu n'as jamais dit à tes gars : "Faites -moi une version 'en dur' et ensuite je vous expliquerai comment utiliser un fichier de paramètres". Tu les diriges vers la bonne option dès le début. En tout cas, c'est comme cela que je procède   )

Je n'arrive pas à comprendre pourquoi cet écran te pose tant de problèmes.
Certes, il est possible de s'en passer mais pourquoi le faire puisqu'il est fait pour simplifier la vie en appliquant une logique claire.
Le vrai "problème" (et je le mets bien entre guillemets car problème n'est pas le mot adapté)  d'OpenTx est qu'il est tellement souple et et paramétrable qu'il existe plusieurs manière d'arriver à un résultat comparable.
... C'est comme pour Rome où de nombreux chemin y mènent... Tu peux t'y rendre à cloche pied, à reculons, sur les mains, ...
Mais la meilleure façon de marcher, c'est toujours de mettre un pied devant l'autre...
L'écran "Entrées" est le pied gauche, et l'écran "Mixages" le pied droit de ta marche sur Rome

Bons vols !

Coyotte

CoyotteDundee a écrit:

Les entrées n'existaient pas, dans une version antérieure d'openTX, donc ce n'est pas intrinsèque.

Avec un tel raisonnement, aucun logiciel ne peut évoluer, toute fonction n'existant pas dans une version antérieure n'étant pas à prendre en compte...  

Traduction incorrecte de ce que je veux/voulais dire (ou mauvaise formulation de ma part) :
Ce que je veux dire : "cela n'existait pas avant, cela a été introduit" (i.e., ce n'est devenu une des philosophies d'OpenTX que depuis l'évolution la version n, pas depuis toujours), donc je cherche les raisons (le(s) pourquoi) et mieux un genre de questions/réponses que pourraient/devraient se poser une personne voulant paramétrer openTX :
Q : quand est-ce indispensable
R (incomplète) : - quand on utilise plus d'une fois dans un écran ultérieur, quand on applique une transformation sur l'entrée 'physique' pour obtenir une entrée 'logique', …
Aparté : le nom de l'écran devrait mieux indiquer le 'logique' par opposition au physique. Pour moi 'Entrée' => 'Entrée primaire' (physique). Mais ce n'est qu'un détail, de plus facile à régler.
Q : Quand peut-on s'en passer; R : utilisé une seule fois dans cas simples
Q : Pourquoi systématiser, même si on peut s'en passer; R : pour être sûr, adaptabilité, souplesse de réemploi

Q : pourquoi alors garder la possibilité d'utiliser directement
R : …
Et là, je sèche. Car ce qui est présenté comme souplesse implique pour moi un risque. Je suis issu du milieu/sérail aéronautique et pour moi, trop de souplesse tue la sécurité dès lors que l'on peut écrire des choses contradictoires.
Quand ces choses contradictoires sont dans le même écran - du genre appliquer une courbe et l'inverse de la courbe, cela me pose déjà un léger problème
Quand c'est dans "la 2e étoile à droite, au fond de la Galaxie" que l'on peut écrire éventuellement une chose contradictoire, cela devient difficile à débuguer.

CoyotteDundee a écrit:Je n'arrive pas à comprendre pourquoi cet écran te pose tant de problèmes.
Certes, il est possible de s'en passer mais pourquoi le faire puisqu'il est fait pour simplifier la vie en appliquant une logique claire.

En fait, je ne veux pas m'en passer ! - même si je me fais parfois l'avocat du diable pour que les avis s'expriment - je cherche des raisons 'logiques', un argumentaire pour clairement expliquer que c'est une mauvaise idée de le faire la plupart du temps (les questions à se poser).
Et je peste toujours sur la possibilité de court-circuiter, parce que cette 'souplesse' entraîne un risque.
Parce que si on peut déclarer : "OpenTX permet de faire ceci (court-circuit des entrées), mais c'est une mauvaise idée de le faire", cela devient quelque part un peu contradictoire, voire franchement 'bordélique', comme si deux programmeurs avaient chacun travaillé de son côté, sans vision d'ensemble. (ou que l'idée de base a changé, mais que l'on n'en a pas tiré toutes les conséquences)
Cela devient donc pour moi une faiblesse de pouvoir le faire, à moins de pouvoir indiquer des règles d'usage claires d'usage/non usage.
Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

elj4Taranis a écrit:...
Et je peste toujours sur la possibilité de court-circuiter, parce que cette 'souplesse' entraîne un risque.
Parce que si on peut déclarer : "OpenTX permet de faire ceci (court-circuit des entrées), mais c'est une mauvaise idée de le faire", cela devient quelque part un peu contradictoire, voire franchement 'bordélique', comme si deux programmeurs avaient chacun travaillé de son côté, sans vision d'ensemble. (ou que l'idée de base a changé, mais que l'on n'en a pas tiré toutes les conséquences)
Cela devient donc pour moi une faiblesse de pouvoir le faire, à moins de pouvoir indiquer des règles d'usage claires d'usage/non usage.
Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

Il existe un cas où le fait de court-circuiter les entrées permet de faire une chose qui serait laborieuse si l'on devait passer par les entrées, on en parle sur le forum. Dans ce cas, ce que tu considères comme une faiblesse, est au contraire une des forces d'OpenTx.

Ceci-dit, rappelle-toi comment on faisait avant d'avoir les entrées sous la forme actuelle lorsque l'on avait besoin de formatter les manches/curseurs/interrupteur/potentiomètre autrement que de manière basic (dual-rate/expo). Pour cela, on utilisait un mixage sur une voie inutilisée. Ca fonctionnait très bien et on peut même se demander pourquoi ces entrées sont apparues dans OpenTx.

elj4Taranis a écrit:
Q : quand est-ce indispensable

R: Jamais

elj4Taranis a écrit:
Q : Quand peut-on s'en passer

R: Toujours

elj4Taranis a écrit:
Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

C'est pourtant la philosophie de base d'OpenTX, va falloir t'y faire On peut recommander une "bonne pratique" mais ça s'arrête là. Y'aura toujours une bonne raison de faire des exceptions, et on est pas là pour l'empêcher - Si OpenTX existe c'est justement à cause d'un raz le bol des limitations imposées par les autres systèmes du marché.

Et accessoirement:

elj4Taranis a écrit:
Q : pourquoi alors garder la possibilité d'utiliser directement

R: Parce que sans ça la migration de modèles de 1.x à 2.x n'aurait pas été possible, une conversion d'un jeu de mixages en entrées n'étant pas possible automatiquement.

Sacre100 a écrit:

elj4Taranis a écrit:...Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

Il existe un cas où le fait de court-circuiter les entrées permet de faire une chose qui serait laborieuse si l'on devait passer par les entrées, on en parle sur le forum.

Lequel, merci, ou, sur quel sujet précis.

Kilrah a écrit:

elj4Taranis a écrit:
Q : quand est-ce indispensable

R: Jamais

elj4Taranis a écrit:
Q : Quand peut-on s'en passer

R: Toujours

elj4Taranis a écrit:
Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

C'est pourtant la philosophie de base d'OpenTX, va falloir t'y faire

Et bien non, je ne m'y fait pas, parce que je considère qu'élever un principe de 'bordel' en primauté, ne me satisfait pas.

Pour ce qui est des matériels que j'ai acheté, je vais faire 'mauvaise fortune, bon coeur'.
Pour ce qui est d'expliquer, de cautionner ce que je considère comme une atrocité (hors phase de 'migration'), non merci.
Dont acte.
Divorce sur le fond.
Arrêt.

elj4Taranis a écrit:

Sacre100 a écrit:

elj4Taranis a écrit:...Parce que dire, "faites comme vous voulez, tout est possible", ça, je suis incapable de l'expliquer rationnellement !

Il existe un cas où le fait de court-circuiter les entrées permet de faire une chose qui serait laborieuse si l'on devait passer par les entrées, on en parle sur le forum.

Lequel, merci, ou, sur quel sujet précis.

Par exemple, détecter si un manche a été bougé pour reprendre automatiquement la main sur un appareil piloté par un élève ou détecter si deux manches sont dans des positions particulières par exemple pour entrer dans un mode "setup des servos". Si tu fais ce genre de tests sur l'entrée et non sur le manche, le trim, le ratio, etc... peuvent t'empêcher de le faire correctement.

Hello,

elj4Taranis a écrit:Cela devient donc pour moi une faiblesse de pouvoir le faire, à moins de pouvoir indiquer des règles d'usage claires d'usage/non usage.

Cela fait plusieurs messages que tu reçois des exemples (personnellement, je préfère 'exemple' à 'règle') d'utilisation justifiée de l'écran en question.

elj4Taranis a écrit: ... ce que je considère comme une atrocité...

heu... tu ne pousses pas un peu là ?
A ce rythme, dans trois posts, on va parler de crime contre l'humanité...  lol

elj4Taranis a écrit:...qu'élever un principe de 'bordel' en primauté,...

Et dans la foulée, un petit peu de respect pour le travail de l'équipe d'OpenTx ne serait pas du luxe.
Ne pas être d'accord ne doit pas empêcher pas de rester correct et le bordel n'est pas une conséquence obligée de la liberté.

elj4Taranis a écrit:Pour ce qui est des matériels que j'ai acheté, je vais faire 'mauvaise fortune, bon coeur'

Il te reste toujours la rubrique "Vente et recherche de matériel"... J'en connais plus d'un qui serait heureux de te débarrasser de cet atroce matériel bordélique...

elj4Taranis, je n'arrive vraiment à comprendre ta réaction...
Oui il est possible de se passer des entrées, mais ce n'est pas conseillé...
Au même titre qu'il est possible d'écrire du code C illisible... C'est possible, mais pas conseillé...
De même qu'un marteau servant à enfoncer les clous peut défoncer le crâne d'un importun... C'est possible et toujours pas conseillé..
A te lire, tu n'écriras jamais de manuel de C car il est possible d'écrire du code bordélique. Au lieu d'expliquer comment bien écrire, tu n'expliqueras rien... C'est dommage.
Et il existe des manuels de bricolage qui expliquent l'utilisation (normale) d'un marteau...

A la place des règles et des contraintes, je préfère la liberté et le bon sens.
Nous vivons dans un monde où l'on pense pour nous 24h/24h... Voici ce qu'il faut manger, lire, boire, penser, voter. Ne réfléchissez pas, on s'en charge pour vous...

Vous avez un avion ? un planeur ? un hélico ? GrauFulPlex nous disent "Voici les templates possibles". Vous pouvez changer ceci ou cela, un peu de couleur, quelques paramètres...
C'est l'Ikéa de la radio.
Mais ces contraintes peuvent être rassurantes. (Je suis certain que mon frigo va rentrer dans l'espace prévu...)

La Taranis nous offre un établi avec une série d'outils; des scies, des gouges, des rabots, des ciseaux, des marteaux, maillets, tournevis, limes, équerres, compas, un tour, une raboteuse, ...
Et nous pouvons créer le modèle en toute liberté.
Oui, pour enlever de la matière, il vaut mieux utiliser un maillet et un ciseau...
Mais si j'ai une bonne raison pour utiliser un tournevis affûté (parce que plus étroit ou mieux disposé), je suis libre de le faire.
"Libre"... pas "obligé"...
Pour faire un cube, la scie semble plus appropriée... mai je peux utiliser le tour si cela me semble plus approprié...
A l'arrivée, j'aurai un modèle, probablement pas académique (surtout les premiers ) mais je pourrai l'améliorer, le peaufiner avec l'amélioration de mes connaissances et un peu de bon sens. (Ben oui, je suis encore à penser que si l'on invitait les gens à réfléchir un peu plus par eux mêmes, les choses pourraient aller un peu mieux...    )

Et donc je préfère dire "oui, il est possible de créer un mauvais modèle sur Taranis, mais comme vous n'êtes pas obligé de le faire, on va vous expliquer comme procéder correctement" plutôt que jeter le bébé avec l'eau du bain.

Après, c'est une question de choix personnel... Les uns sont fait pour "l'Ikéa", les autre pour la liberté... Personne n'a raison, personne n'a tort.

Bon retour dans un monde plus rassurant pour toi et bons vols (après tout, c'est la seule chose qui compte),

Coyotte