< Back to IRCAM Forum

Pourquoi ces "nil" apparaissent?

Bonjour,

Je ne comprends pas pourquoi viennent se glisser parmi les résultats des “nil”.

Il ne devrait y avoir que des fonctions lambda, n’est-ce pas ? :thinking:

Merci !

Lisa

pourquoi des “nil” ?.omp (5.3 KB)

Bonjour Lisa,

Les fonctions sort-list, permut-random et rotate sont bien en mode lambda. Quand le om-ramdom retourne une condition satisfaisante cela retourne une lambda fonction appliquee a RIEN… donc nil

Que voulez vous faire au juste. On ne sait pas a partir de ce patch quoi appliquer a ces lambda fonction. Il manque donc une entree de liste pour appliquer ces lambda fonction. (Peut-etre meme pas besoin)…

Amities
K

Bonjour Karim,

Oui en effet, mon petit arbre est censé renvoyer :
lambda sort-list si om-random donne 0
lambda permut-random si om-random donne 1
et lambda rotate si om-random donne 2

alors pourquoi parfois, cet arbre donne-t-il nil ?

Cet arbre est connecté en aval à funcall, ainsi la fonction lambda choisie aléatoirement s’applique sur une liste. Mais si, sans que je le comprenne, un nil apparait au lieu d’une fonction lambda, cela perturbe évidemment le processus. En sortie de conditional il ne devrait y avoir que des les éléments qui passent dans les trois omif, ici des fonctions lambda, et jamais de nil ou autre chose.

Par exemple dans le patch ci-joint, je donne une liste de liste et om-loop applique une fonction lambda choisie aléatoirement sur chacune des listes. Si par chance, seules les fonctions lambda sortent, cela fonctionne, mais si un grain de sable nil s’immisce dans la machine, tout s’enraye. Mais je ne comprends toujours pas d’où vient ce grain de sable…

J’ai mis en capture d’écran un résultat OM Listener où l’on voit bien que cela fonctionne lorsqu’aucun nil ne sort de mon conditional. Seulement il a fallu évaluer quelques fois avant car un nil inexpliqué se glisse aléatoirement.

Merci par avance !

Lisa


pourquoi des “nil” ?.omp (11.8 KB)

Chere Lisa,

Je crois que tu te compliques la vie :slight_smile:
On peut faire bcq plus simple: Pas la peine de generer par om-random de 0 a 2 puis les tester pour trouver quelle operation appliquer. Tu peux utiliser nth-random. Bcq plus economique:


J’envoie aussi le patch ici:
Patch 2.omp (5.8 KB)

J’espere que c’est ton intention. A propos, le sort-list n’est pas “interessant” ici car ta liste de liste (dans ton exemple est deja sorted.

Amities
K

…Et pour VRAIMENT repondre a ta question, pourquoi des nils? et bien tu as raison ce n’est ni normal ni logique. Il doit y avoir quelque part une sorte de bug dans l’objet conditional. Je vais regarde de mon cote.

Merci en tous les cas de l’avoir trouve.

Amities
K

Ah oui, en effet, c’est beaucoup plus simple et économique ainsi… :woman_facepalming:
C’était tout à fait mon intention. Le sort-liste étant utile car je l’applique sur des accords qui ne sont pas toujours sorted, pour former ensuite des profiles mélodiques linéaires (en aval avec d’autres patchs qui créent des figures mélodies-rythmique).
Au moins mon esprit tordu n’aura pas été vain, s’il peut révéler des bugs et faire avancer la programmation !

Merci et à bientôt !

Lisa

Bonjour, le patch se comporte de cette manière car la boîte om-random renvoie une valeur différente à chaque fois qu’elle est évaluée. Il est donc très probable que les valeurs testées dans chacune des branches de conditional soient différentes, et donc aussi que les trois tests de suite soient faux!

2 Likes

Bonjour,

Vous voulez dire qu’à chaque omif en entrée du conditional, de gauche à droite, une nouvelle valeur om-random est envoyée ? Ce n’est jamais la même valeur qui parcourt les trois omif de gauche à droite ? Dans ce cas il faudrait mettre om-random en mode 1 n’est-ce pas ?

Lisa

Mais oui mais c’est bien sur !om-random est evalue 3 fois. super Jean! Merci… Pas pense a cela…
eval once s’impose donc.