"piano smell"-Pistes de diagnostics des problèmes techniques

[BluePhoenix05]

Comme évoqué dans ce post, il est important de détecter (de préférence tôt) les mauvais gestes techniques de façon à les éviter, et les corriger s'il faut les désapprendre.

Un prof peut nous indiquer lorsqu'on prend un mauvais chemin, mais il faut bien bosser seul entre 2 cours et trouver des solutions pour ne pas rester bloqué !

Pour ceux qui n'ont pas entendu parler des "code smell" en informatique (c'était d'ailleurs mon cas jusqu'à récemment), il s'agit des "symptômes" d'un programme qui fonctionne bien en l'état actuel, mais risque de générer des erreurs si une évolution demande la modification d'une autre partie du programme.

Par exemple, trop de copier-coller dans un code signifie qu'on gagnerait à rassembler cette fonctionnalité dans un même endroit afin de pouvoir la modifier facilement en cas de besoin. (Pour rappel, un code informatique est une littérature écrite par des humains POUR des humains et des machines, et non pas uniquement pour des machines )

De façon analogue, on pourrait essayer de faire une liste permettant de détecter un problème technique, et il ne s'agit pas uniquement de s'arrêter là, mais d'identifier le problème sous-jacent et proposer des solutions de travail si possible. Evidemment, les indicateurs ne sont pas forcément des indicateurs "absolus" de problème, mais des signes potentiels de difficulté à jouer un certain passage ! Sachant qu'un geste est toujours adapté à un contexte.

J'imagine que le sujet parle à beaucoup de monde, et qu'il est peut-être très vaste, mais on peut essayer de mieux cibler au fur et à mesure des contributions de chacun.

Par exemple, pour commencer :

DOULEURS (là, c'est sûr que quelque chose cloche !)

- douleur au bout des doigts : mauvaise inclinaison du doigt lors de l'attaque ? (angle > 45% ou oblique?) attaque trop percussive ? (cf. Heinrich Neuhaus qui disait que pour pousser une porte d'un doigt, on ne jette pas le doigt sur la porte !) fait de continuer à appuyer sur la touche déjà enfoncée ?

- douleur sur la face antérieure de l'avant-bras : trop grande mobilisation des fléchisseur ? solutions : lever plus le poignet ? dégager le coude ? relâcher d'autres muscles de la main sans doute crispés en même temps ?

- douleur au biceps : biceps trop contracté. lié à l'épaule, à l'avant-bras ? solution(?): mettre un main sur le biceps, jouer en contrôler l'excès de contraction.

- douleur au poignet ?


GESTES SUPERFLUS :
comment savoir si un geste est "en trop" ? pas toujours évident...

- doigts qui se lèvent trop haut et ralentissent le mouvement - comment définir "trop" ? "trop" par rapport à la hauteur minimal suffisante... (mais c'est tautologique!)

- à partir d'où un poignet est-il trop haut ?


DEPLACEMENTS

- rater systématiquement une note : vérifier la note de laquelle on part ou même les précédentes (c'est comme quand le compilateur nous indique l'endroit d'une erreur dans le code, en fait le vrai bug se situe parfois plus en amont )

- vérifier la souplesse du rotation du poignet, mais qu'il n'est pas totalement "lâche".
- "lâcher" la note qui vient d'être jouée, l'oublier, pour se préparer à jouer la suivante.

...


Ces quelques idées sont encore dans un état totalement embryonnaire...

[Okay]

Vraiment une excellente idée de fil. L'analogie avec la programmation est aussi amusante que pertinente.

Il est intéressant de pousser l'analogie en notant qu'il existe des langages informatiques "compilés" et d'autres qui sont "interprétés". Les informaticiens en rectifieront ma compréhension grossière si besoin est.
- Lorsque l'ordinateur exécute un code en langage interprété, à chaque fois qu'il tourne, il examine ligne après ligne les instructions et les transforme en un langage exécutable, son langage. Le code n'est qu'une interface entre le programmeur et le langage de la machine. En raison de tous ces allez-retours, c'est a priori plus lent. Aussi, la machine redécouvre les instructions à chaque fois qu'elle les exécute. De plus, elle se lancera de toute façon dans l'interprétation/exécution du code, même si celui-ci présente un bug grossier à l'avant dernière ligne, qui empêche la procédure d'aboutir.
- Au contraire, un langage compilé va d'abord pré-examiner l'ensemble avant toute exécution. En l'absence d'erreurs de syntaxe (ce qui n'empêche pas le code d'être éventuellement très mal conçu), la machine va digérer la totalité des instructions, qu'elle va traduire dans son langage direct. Ces instructions compilées seront stockées une fois pour toutes quelque part, de telle sorte que la machine peut désormais se passer du code du programmeur, qu'elle a définitivement digéré. Le moment venu de l'exécution, la machine ne redécouvre pas le code puisqu'il a déjà été interprété, mais en dispose et peut traiter les instructions plus efficacement.

Le pianiste agit-il comme un interpréteur ou un compilateur ? Les deux. Le morceau est toujours exécuté par les doigts, mais les instructions que ces derniers reçoivent résultent d'un comportement d'interpréteur et de compilateur. L'intéressant c'est qu'au contraire d'une machine, ces comportements interviennent en proportions variables. La répartition interprétation/compilation change avec le stade du travail, et l'expérience. Lorsqu'on découvre un morceau, c'est essentiellement de l'interprétation (au sens du code). On découvre mesure après mesure, on se reprend sur les fausses notes. Plus on accumule d'expérience, plus on dispose de code compilé à sa disposition pour traiter plus efficacement les nouvelles instructions (intuition harmonique, doigtés prêts à l'emploi, déplacements familiers, etc). Pour l'informaticien, ce seront des classes compilées et prêtes au réemploi.

Qu'est ce qu'on peut en tirer à des fins de diagnostic ? La partie interprétée est la plus simple à rectifier. La vigilance est là, les fausses notes exaspèrent les oreilles, un confort physique est désagréable. Les signes sont évidents, et les solutions souvent à portée de main. Plus pernicieux, un code compilé qui accepte de s'exécuter (pas de fautes de textes par exemple), mais qui a été mal conçu. Le code compilé se traduit pour nous en habitudes inconscientes et fortement ancrées (les instructions digérées que la machine n'a plus besoin de traduire). Dans un morceau, une habitude efficace dans un autre donnera un résultat bancal (c'est la classe que l'informaticien utilise pour la première dans un contexte nouveau). Comment débugger ? Par définition, un code compilé ne se débugge pas. Donc inutile de se battre contre le défaut en l'état. Par exemple s'obstiner à jouer lentement le même passage qui reste terriblement inégal à l'oreille. Il faut déterrer le code source que la machine a interprété il y a parfois trèèèès longtemps. Recoder/réorganiser ce qui ne va pas, puis recompiler. Pour nous, identifier la mauvaise habitude, se déshabituer, introduire un nouveau comportement, s'y habituer.

La conclusion de tout ça, c'est qu'un problème qui persiste malgré beaucoup de travail au piano, c'est un problème qu'il faut attaquer sous un angle différent, à un niveau plus fondamental, avec un regard neuf. La difficulté, c'est soit une nouvelle habitude à programmer, soit une ancienne habitude qui n'est pas efficace. Donc il ne s'agit pas de ralentir le tempo ou de changer de doigté (un débogage ligne à ligne ne sert à rien pour un code qui tourne déjà, mais n'est pas efficace). Il faut se reprogrammer mentalement à la base. Peut-être que ces doubles croches écrites par 4, il faut les penser par 2 ou par 3 pour débloquer les doigts. Ce passage qu'on veut jouer legato mais qui reste plein d'à-coups, peut-être que le problème c'est de chercher à jouer legato.

[JPS1827]

Tu développes ici des analogies très intéressantes.
La différence c'est que quand l'ordinateur est en mode compilation, il fait ce qu'il a à faire sans se poser de question (ce n'est pas lui qui s'est programmé). L'ingénieur qui est devant se borne à vérifier que "ça marche". Dans le cas du pianiste, il faut qu'il développe comme tu le dis des stratégies efficaces qui le fasse passer en mode "compilation", mais de plus il doit acquérir peu à peu une véritable confiance dans ce mode. En réfléchissant bien, beaucoup des problèmes que j'ai pu avoir en jouant en public sont liés à l'absence de confiance dans ce mode, avec la tentation de repasser en mode interprétation/exécution. En fait quand on est jeune on n'a le plus souvent pas l'ombre d'un doute sur l'efficacité du mode "compilation". Je ne sais pas quels sont les mécanismes qui font qu'à certains moment on perd la confiance dans le mode "compilation", et qu'on peut la retrouver ensuite.
Quoi qu'il en soit, beaucoup de déboires rencontrés par les débutants, y compris celui qui consiste à ne pas pouvoir rejouer le morceau récemment appris après seulement quelques jours d'arrêt du travail sur le morceau, sont liés au fait qu'ils restent en mode interprétation/exécution, et que l'exécution de la moindre mesure continue à demander une concentration quasi-surhumaine. Ils pensent à tort que celui qui "joue facilement" est capable d'intégrer beaucoup plus de données à la seconde, alors qu'il est en mode "compilé" tout simplement.

[BluePhoenix05]

Okay, ton analogie est très intéressante ! Si tu veux bien, je la reprendrai pour m'en servir et l'approfondirai aux moments opportuns

En gros déchiffrage à vue == "code interprété" et apprentissage == "compilation de code".

Et pourquoi pas : en concert, l'exécutant qui a bien intégré et assimilé une pièce ("bien compilé") recrée la musique sur le vif en repassant en partie en mode "interprété". A moins que la capacité à créer l'illusion de recréer la musique sur le vif (comme si c'était improvisé) soit aussi un mode compilé qu'on puisse travailler ?

Et quand on a tellement travaillé une pièce qu'on est proche de l'overdose, on a trop "compilé" ? comment retrouver cette fraîcheur, cette spontanéité du mode "interprété" ? En allant "compiler" beaucoup de travail sur d'autres oeuvres ?

@JPS1827, j'avoue que je ne comprends pas totalement ce que tu essaies d'exprimer, même si je sens une grande expérience de la scène derrière. On atteint peut-être aussi les limites de la métaphore filée...

Quoi qu'il en soit, je vois bien que le sujet que j'ai abordé est transverse et à la croisée de nombreux thèmes, et je fourmille d'idées à la lecture du post d'Okay. On gagnerait sans doute à rentrer moins dans des considérations générales à travailler sur des exemples précis. Le but du fil est d'arriver à trouver des éléments pratiques permettant de travailler plus efficacement, que l'on travaille sans prof' ou entre 2 cours.

Permettez moi encore une remarque générale : l'assymétrie entre "détecter un mauvais geste" et "reconnaître un bon geste".

Par exemple, en chant, on apprend que quand on sent que quelque chose mal (inconfort dans le larynx, par ex.), c'est certainement que l'émission est mal réalisée. Il faut être à l'écoute de ses sensations et ne pas continuer à forcer. Quand on ne sent aucune gêne, ce n'est pas pour autant qu'on peut être sûr que l'émission vocale est saine (les cordes vocales sont très peu innervées, on peut ne rien sentir avant de se flinguer la voix au bout de plusieurs années). Il faut le contrôle d'un prof expert.

Nous n'avons pas encore vraiment défini ce qu'est un "mauvais geste technique" au piano. Ni ce que serait un "bon geste".

Il m'arrive régulièrement (par chance!) de tomber sur (ce que je crois être) de "bons gestes", c'est-à-dire me donnant un son qui me plaît, une liberté de contrôle et parfois une facilité déconcertante (déblocage soudain). Je travaille alors pour essayer de le reproduire et le fixer (le compiler? ), mais sans vraiment savoir comment je fais pour réussir ce geste! Ce qui est assez excitant de réussir quelque chose et en même temps me laisse dans la crainte de ne plus savoir le reproduire le lendemain. Un interprète peut se contenter de "ne pas savoir comment bien jouer", mais sans doute pas un aspirant professeur.

Peut-être qu'à un niveau très avancé, on trouve plus facilement et plus régulièrement ces bons gestes, et s'inquiéter moins des mauvais. Je n'en suis pas encore arrivé là... On peut continuer à parler des bons gestes dans un autre fil si vous voulez, pour ne pas s'éparpiller.

Concernant les mauvais gestes : comment savoir si on ne fait pas fausse route, si on ne devrait pas expérimenter autre chose ?

Etudions un exemple : le trait introductif de l'étude Révolutionnaire de Chopin (op.10 n°12).

Au début de mon travail sur ce trait, je constate qu'à cause de l'alternance entre des touches blanches et des touches noires, j'ai la main gauche qui fait une sorte d'aller-retour à la fois de haut en bas et d'avant en arrière (je sais pas si vous voyez bien ce que je veux dire ). Un peu comme une machine à écrire, un mouvement assez inesthétique , peut-être encombrant, mais tout à fait détendu.

Ce mouvement est-il superflu ? Ou bien est-il simplement l'exagération d'un mouvement nécessaire et qui peut se réduire à un micro-mouvement une fois le trait totalement assimilé ? Faut-il continuer à travailler ce trait ainsi ou bien s'en pré-occcuper ?

Par exemple, sur la vidéo de FrankiisKo, on ne voit pas ce genre de mouvement , la descente est très linéaire.
En même temps, j'avoue que maintenant j'ai résolu la façon de jouer ce trait introductif d'une façon qui m'est pour le moment assez satisfaisante, je ne constate plus vraiment le mouvement exagérée dont j'ai parlé, et je me pose aussi beaucoup moins de questions à ce sujet , mais c'est typiquement le genre d'interrogations qui survient pendant le travail, et la détection anticipé d'un événtuel "piano smell" pourrait être tout à fait profitable.

Bon j'ai beaucoup parlé de moi ! que pensez-vous de cet exemple ?

Avec les "piano smell", on fait vraiment du piano un art complètement kinesthésique !

[Okay]

Oui JPS, tu traduis très bien ce que j'ai essayé d'exprimer, c'est vraiment tout à fait ça.
Je partage au plus au point ton expérience du doute sur ce qu'on a compilé. Je ne me posais pas autant de questions avant, j'y allais beaucoup plus tête baissée et ça ne se passait pas si mal. Je crois que l'expérience offre un savoir qui peut être autant utile que pesant, et ce revers de la médaille s'appelle la lucidité. J'ai l'impression qu'elle m'a autant renforcé que fragilisé. On voudrait à tout moment être capables de reprendre le contrôle car on sait très bien tout ce qui peut dérailler, on refuse d'en laisser trop au pilote automatique. De même, un enfant se pose moins de questions qu'un adulte lorsqu'il est en haut du plongeoir. Même s'il sait bien plonger, il est excité par le contact avec l'eau, la vitesse de sa chute, les éclaboussures et le "plouf" qu'il va produire. L'adulte peut se demander s'il y a assez de profondeur dans la piscine par rapport à la hauteur du plongeoir, il va aussi penser à assurer son geste pour ne pas faire un plat, coordonner sa respiration pour ne pas boire la tasse, voire vérifier si le maître nageur est à son poste au cas où ! Pas la même perspective...

Au piano, lorsqu'on a l'esprit clair, le corps détendu mais disposé à la vivacité, ça peut être extraordinaire. Finalement, ça se produit le plus souvent pour moi lorsque j'ai la chance de pouvoir me mettre au piano à froid en début de journée (impossible après une grosse journée de boulot, donc max 4 à 5 fois par mois).

Pour retourner à mon propos initial et rebondir sur les interrogations partagées avec JPS, aujourd'hui ce qui me rassure et semble être "ma" solution, c'est d'être capable de mettre des mots sur les procédés mis en oeuvre par mon compilateur (connaitre le nom des classes, leurs méthodes, sur quels objets elles s'appliquent, et surtout leur usage polymorphe). L'idée c'est que je sais ce que j'ai fait en travaillant, donc je peux faire appel à certaines conclusions.
Exemple : je sais que pour tel trait, le penser à peine crescendo me permet de lui donner l'élan et la sécurité nécessaire, je peux donc laisser le soin des doigtés au pilote automatique. Autre exemple, les points de repères et les départs. Lorsque l'écriture change complètement de texture, je prends le plus grand soin à poser le début de cette nouvelle texture, que je concientise un infime instant en amont (compilant surement à mon insu ce dont j'ai besoin). Finalement, ce que je fais, c'est que je tente de rester le plus souvent en mode compilé, sauf que mes classes sont plus nombreuses et plus éclatées qu'avant. C'est le prix à payer pour une relative sécurité technique preservant une relative spontanéité. C'est une façon de dire que je suis concentré, mais pas dans cet état épuisant d'hyper-concentration. Je pense qu'un jeu intelligent et serein, c'est celui d'un pianiste qui sait exactement quand il peut lâcher du leste, et quand et sur quoi précisément il doit relancer sa vigilance.
Il faut trouver cet équilibre compilation/interprétation, la clé c'est de savoir quand l'interpréteur peut recourir au compilateur. Après tout, un morceau peut se concevoir comme une succession de compilations, l'interpréteur est alors essentiellement en charge de gérer les appels et de contrôler les réponses.

Pour ton exemple de la révolutionnaire BluePhoenix, la solution aurait pu être que ton interpréteur t'ordonne de jouer les accents par temps écrits par Chopin. Rien de plus. A mon avis, ça aurait littéralement empêché ta main gauche de faire ces va et vient entre la profondeur et le bord du clavier. A priori, jouer ces accents doit appeler à ton insu un bout de code compilé qui a intégré la position naturelle de la main.

[Gracou]

C'est intéressant de voir comment ceux qui ont l'esprit scientifique approchent certains paramètres de l'art. J'avais été frappé à la lecture de "Principes rationnels de la technique pianistique" de Cortot, par exemple.

J'ai une collègue prof qui est très méthodique dans son enseignement. Elle prend des notes sur chaque élève à la fin de chaque cours. Qu'a-t-il eu comme problèmes, comment y remédier, quelle est la progression, etc. A l'arrivée, c'est une prof efficace. Pas plus que les autres peut-être, mais pas moins. En tout cas c'est sa méthode.

Fin de l'aparté.

[Okay]

Je trouve que ce sont là davantage des questions d'attitude mentale qu'une approche réellement scientifique, bien que les analogies développées aient une très forte connotation scientifique. Ces analogies sont plus un pretexte qu'autre chose, finalement.

Mais à un moment donné, ce type de reflexion peut apporter des briques importantes à notre pratique musicale. Il ne s'agit pas de tomber dans une démarche purement analytique, qui serait par définition anti artistique. Mais parfois, regarder avec distance nos comportements au microscope peut apporter des pistes, qui au final serviront des fins artistiques.

Si j'enseignais le piano, je passerais volontairement ces aspects sous silence. Par contre ils me seraient personnellement précieux pour trouver des solutions. Je ne montrerais que la partie emergée de l'iceberg, je focaliserais l'attention de l'éléve sur un ou 2 points maximum bien choisis. Pour faire une autre analogie, cet enseignement serait plutôt une médecine thérapeutique que préventive. Mais l'éléve réaliserait que les mêmes médicaments reviennent très souvent, et en tirerait ses propres principes préventifs. C'est ce type d'enseignement que je crois avoir moi-même reçu.

[bach_addict]

je ne suis pas persuadé que ces analogies éclairent vraiment quelqu'un qui ne ferait pas régulièrement de la programmation informatique

(il se trouve qu'il m'arrive encore de programmer dans mon job, donc ce n'est pas une remarque d'un anti-geek debaze...)

[Okay]

Pour ma part, je n'ai jamais programmé régulièrement, je me suis juste penché sur ce sujet il y a quelques années car j'en ai eu besoin. Mais ça reste un domaine de connaissances comme un autre.

On peut remplacer point par point cette analogie par le pilotage à vue d'un avion, comparé au pilotage automatique. J'imagine que les differentes phases d'un vol et les conditions météorologiques requièrent une combinaison variable d'intervention directe et de délégation à la machine.
Cette analogie est peut-être même encore meilleure, car on a le tableau de bord en prime. Je doute que le pilote regarde tous les cadrans en même temps. Certains sont certainement plus importants que d'autres selon le contexte, le tout est de savoir quoi regarder et pourquoi, et de sereinement décider comment agir en conséquence.

[Oupsi]

Je vous rassure, l'analogie me paraît tout à fait compréhensible, bien que je ne sois ni programmatrice ni même de formation scientifique.

Pour l'aspect enseignement, j'imagine que la nécessité de "conscientiser" ce processus dans ses moindres détails se fait différemment sentir selon les personnes, les morphologies, les traits ou les difficultés travaillées, de sorte que le professeur décortique la chose selon les besoins qu'il repère chez l'élève. Il se peut aussi qu'un élève adulte ait davantage besoin de "désapprendre, reprogrammer, archiver". Mais je remarque que le processus en lui-même se modélise, dans le sens où une fois qu'on a pigé un paradigme de solution, on peut essayer de l'appliquer pour résoudre d'autres problèmes, et le jeu des équivalences, analogies et relations réciproques s'élargit.

[BluePhoenix05]

Il faut déterrer le code source que la machine a interprété il y a parfois trèèèès longtemps. Recoder/réorganiser ce qui ne va pas, puis recompiler. Pour nous, identifier la mauvaise habitude, se déshabituer, introduire un nouveau comportement, s'y habituer.

Oui, et ça ne signifie pas forcément que tout est à déconstruire. Un petit détail qui nous aurait échappé peut améliorer considérablement les choses.

Pour ton exemple de la révolutionnaire BluePhoenix, la solution aurait pu être que ton interpréteur t'ordonne de jouer les accents par temps écrits par Chopin. Rien de plus. A mon avis, ça aurait littéralement empêché ta main gauche de faire ces va et vient entre la profondeur et le bord du clavier. A priori, jouer ces accents doit appeler à ton insu un bout de code compilé qui a intégré la position naturelle de la main.

mmm... donc toi aussi tu soupçonnes que le mouvement de va-et-vient est un geste néfaste ? Je n'ai pas encore réussi à le déterminer avec certitude.

Je reste sceptique quand à la "solution" que tu proposes. A l'heure actuelle, j'ai tendance à penser qu'un accent doit pouvoir se rajouter ou s'enlever comme on veut, le mouvement directionnel sous-jacent de la main restant presque le même. On voit souvent des gens jouer un endroit comportant un accent de manière bien trop appuyée, qui prend le dessus sur le reste.

C'est comme pour un passage forte, on doit être capable de le jouer mezzo, voire piano.

[BluePhoenix05]

Si j'enseignais le piano, je passerais volontairement ces aspects sous silence. Par contre ils me seraient personnellement précieux pour trouver des solutions. Je ne montrerais que la partie emergée de l'iceberg, je focaliserais l'attention de l'éléve sur un ou 2 points maximum bien choisis. Pour faire une autre analogie, cet enseignement serait plutôt une médecine thérapeutique que préventive. Mais l'éléve réaliserait que les mêmes médicaments reviennent très souvent, et en tirerait ses propres principes préventifs. C'est ce type d'enseignement que je crois avoir moi-même reçu.

Pourquoi faire volontairement de la rétention d'informations ? Et si l'élève te presse de questions, demande plus d'explications ? Des preuves à ce que tu avances ?
Cacher ce genre de "secrets", ça fait un peu "viens avec moi, au bout de 10/20/100 ans tu connaîtras le mystère ultime du piano" ...

Ce que tu cherches à dire n'est-il pas plutôt : "pour les élèves doués (i.e. travaillant intelligemment), le professeur n'a qu'à esquisser le début d'une solution pour que l'élève trouve tout seul le reste".

Cela ne doit pas nous empêcher de chercher les outils, les clés qui, mises à disposition de n'importe quel élève, pourrait le faire progresser.

[Okay]

Simplement pour préserver la clarté du message. C'est ce qui compte finalement.
Ce n'est pas de la rétention d'information, c'est offrir sur un plateau la conclusion d'une réflexion, dont le cheminement n'apporterait que confusion. Après si des questions fusent, je n'aurais rien à cacher.

Je conçois le rôle d'un prof comme un guide dont le but est de transformer l'élève en son propre prof. Une fois qu'il a donné plusieurs fois un conseil similaire dans des contextes différents, l'élève commence à réaliser des synthèses. Petit à petit l'élève détecte lui même les situations, et devance les conseils du prof, qui se raréfient naturellement.

[JPS1827]

J'ai regardé hier soir le trait initial de l'opus 10 n°12. Pour moi le travail se fait sans l'ombre d'un doute en en tenant enfoncé le pouce et le 2ème doigt jusqu'à ce que le 4 ait joué, ce qui empêche de lever les doigts trop haut et équilibre la main et permet de commencer à la déplacer au bon moment, quand le 3 joue. Par ailleurs, le fait de tenir dans l'exécution finale le 2 légèrement plus longtemps que les autres doigts permet de faire entendre l'accent écrit automatiquement sans aucun effort ni à-coup. Par ailleurs, si on a déjà des doigts qui marchent (dans le cas contraire il vaut peut-être mieux travailler autre chose pour la main gauche) le travail doit beaucoup plus se concentrer sur le mouvement latéral du poignet et la "tenue" dans le clavier que sur l'action individuelle des doigts (le travail lent et fort note à note souvent préconisé n'aboutit ici qu'à la fatigue et à l'impression de "se battre" avec le clavier).

Sur le plan de la "compilation", on peut rapprocher ça de ce qu'on appelle en neurologie "une praxie". La marche par exemple est une praxie : on se concentre vers l'endroit où on va, si on tourne à droite on s'intéresse au but à atteindre, on ne se dit pas "je fais des pas plus long avec le membre inférieur gauche qu'avec le doit pour tourner à droite". On doit atteindre un état semblable quand on joue du piano.