next up previous contents
Next: Le nombre d'événements à Up: Difficultés - limites de Previous: Difficultés - limites de   Contents

La gestion des notes tenues

Les états à modéliser dépendent non seulement du type de ``transitions'' décrit précédemment, mais également de la présence ou non de notes tenues au moment de ces transitions.

En effet, une transition de type ONE_RELEASE par exemple peut donner lieu à deux modélisations suivant le contexte : un N-STATE et un G-STATE s'il y a d'autres notes tenues, ou un REST et un G-REST s'il n'y en a pas.




Il faut donc, à chaque real_event, associer d'une part le nombre de notes tenues à ce moment là, et d'autre part garder les références de ces notes pour pouvoir le cas échéant modéliser un état leur correspondant.

Pour cela, lorsqu'on récupère un événement, chaque note attaquée et non terminée à l'instant t est récupérée dans un tableau. Il suffit ensuite d'ajouter à la polyphonie de la note courante les notes du tableau, qui correspondent aux notes tenues.




Le problème lié à ce traitement est qu'il est réalisé dans la fonction suivimakenet_addevent, appelée par suivimakenet_makenet et suivimakenet_refill.

Cela signifie que les notes tenues ne sont pas gardées en mémoire d'un refill à l'autre. On peut donc se trouver avec des états modélisés ne correspondant pas à la réalité si d'aventure un refill est effectué alors qu'il y avait des notes tenues...

Le mécanisme mis en place est du même ordre que celui existant pour le refill des silences que l'on n'aurait pas eu la place d'ajouter :

A la fin de chaque refill, les notes tenues du dernier état modélisé sont stockées dans une variable de la structure netlev correspondant au modèle, et ainsi récupérées lors du refill suivant.


next up previous contents
Next: Le nombre d'événements à Up: Difficultés - limites de Previous: Difficultés - limites de   Contents
Gilles Mathieu 2002-08-22