Merci mais j'évite au maximum d'utiliser les librairies externes histoire que le patch soit utilisable par tous.
L'objet Zl fait de toute façon le boulot à merveille

tobald a écrit:

Le soucis que je recontre avec la solution du [zl] c'est que balancer 8 messages midi d'un coup vers le midiout fais un peu lagger l'audio

étrange...
ça m'étonnerai que ça soit dû à zl

j'aurais fait ça avec un if
du genre


ou

[if $i1 == $i2 then $i1 64 else $i1 0]
|
[noteout]

qui t'évites append et la fin de ton patch là...

mais la solution split est très juste, je connaissais pas cet objet, il est clairement fait pour ça


sinon si tu peux te permettre de tout éteindre avant d'allumer que la led qui t'intéresse (mais du coup on se serait un peu fait chier pour rien là) il existe un message midi allnotesoff

citation :

ça m'étonnerai que ça soit dû à zl

ouep j'ai trouvé ce qui clochait entretemps , j'ai réduit le lag. Mais je suis persuadé qu'envoyer trop de données midi d'un coup vers un noteout fait lagger ton audio (en l'occurence 64 messages d'un coup). Je me demande si [speedlimit] ou [defer] peuvent pas aider.

[counter] je m'en sers pour utiliser un bouton d'un controlleur comme "sélécteur" , genre swithcher entre quatre formes d'ondes. et c'est vrai que tout ces inlets c'est moche , faudrait un simple "increase cyclique".

Hello Pschiiiit !

Il est facile de faire un compteur simple si tu ne veux pas utiliser [counter].
Je peux te le montrer s'il le faut.

du genre bang sur [inc] avec retour à 0 une fois le max atteint ?

Ton bouton de contrôle (objet Max) est paramétrable (par défaut 0-127 -> 1-4 avec un clique droite et get info).
Un [zmap 0 127 1 5] peut être aussi efficace dans certains cas.

Je suis pas sur d'avoir compris mais ton cas fonctionne si il s'agit d'un potard , dans mon cas le bouton de control c'est juste un pad (notein et non ctlin) qui n'envoie qu'une valeur unique. Mais ça c'est juste un détaile, mon gros soucis avec ce patch c'est que lorsque je renvoie 64 messages midi d'un coup j'ai mon audio qui lag. Je bidouille avec speedlim / thresh mais ça me laisse perplexe.

citation :

Si ce poste, tobald, s'inscrit dans ton projet de "pong", tu empruntes, à mon sens, un chemin quelque peu tortueux.

Héhé non , j'ai mi le pong de coté (l'histoire de reconnaissance de collision a eu raison de moi).

effectivement faudrait optimiser tout ça
pas envoyer tous les noteoff à chaque noteon, seulement le(s) noteoff nécéssaires

du coup le coup de tous les toggles c'était une chienlit mais ça permet assez simplement de faire ça avec juste un (heu ptet 64 du coup) objet [change]

bon c'est surement pas la meilleure méthode à moins de kiffer copier coller et relier des boiboites

à vrai dire je vois pas la meilleure méthode (sans 64 ctrl c ctrl v) j'arrive un peu à la limite de mes connaissances
faudrait stocker des variable dans un tableau mais en programmation graphique c'est plus compliqué qu'avec des boucles foreach

surement des zl ou des poly ...

quelqu'un ?

Tout d'abord merci de vous pencher avec tant d'attention sur mon cas J'ai utilisé ta méthode kro pour cette histoire de numéro maitre et c'est bien plus élégant , merci !

citation :

Pourquoi est-ce que tu envoie autant de messages ? Est-ce vraiment nécessaire ?

En fait j'utilise max principalement pour mon controlleur midi


Imaginons que je veuille faire un séquenceur 16 pas. La grille 8X8 du controllo ne me le permet pas. Je veux donc utiliser un bouton du ohm qui bascule entre deux grilles différentes ( 2 * (8*8)). Donc lorsque je bascule d'une grille à l'autre j'envoie 64 notes vers un midiout + les note on/off. Vu que c'est envoyé par paquet je vois pas trop comment limiter ou "delayer"chaque message.

citation :

pas envoyer tous les noteoff à chaque noteon, seulement le(s) noteoff nécéssaires

et la mon cerveau commence à fumer , mais c'est peut être bien une idée à creuser. Peut être aussi diviser la matrixctl par "x" nombre de pistes plutot que den utiliser une 8x8.

La solution des mecs de livid instruments c'est d'utiliser du sysex plutôt que du midi, mais vu que mon patch est fini et que seul ce problême de lag audio me gène ça me fait un peu iech de coder un convertisserur sysex>midi

Désolé si c'est pas très clair mais quand on a la tête dans le guidon ... Je pourrais poster le patch mais sans le controlleur ça n'a guère d'interêt.

chaque led à un "numéro identifiant" qui correspond au notenumber.

1-8-...
2-9-...
3-10- ...
4-11-...
5-12-...
6-13-...
7-14-...

J'ai un patch relié à l'inlet du  [matrixctl] qui converti les données du controlleur en coordonnées column/raw de la [matrixctl]

A la sortie de la [matrixctl] j'ai un patch qui reconvertit à l'envers  vers le midiout pour allumer les leds.

Exemple je presse sur le premier boutton avec l'id#1 , j'envoie donc le message midi suivant notenumber 1 / vel 64 (le channel on s'en fout)

(Le hic c'est que quand tu relaches ton bouton t'envoies un noteoff faut donc faire une magouille dans un autre patch pour faire tu toggle on/off)

Le message midi est converti à la matrixctl donc [ 0 0 1] j'unpack les messages de la matrixctl et les reconvertit vers le midiout du controlleur.

C'est juste pour info tout ça , ne te casse pas la tête , je finirais par trouver par tâtonnement

Ouep le toggle me parait une meilleure méthode que la matrixctl , c'est la voie que j'ai emprunté pour reommencer mon sequeneur. C'est laborieux mais c'est plus flexible. En fait plutot que de me servir des toggle j'utilise des sliders avec une range de 0 à 1 , c'est con mais c'est plus joli

Cette méthode a aussi je pense l'avantage de permettre l'ajout de delay pour l'envoi des données vers le controlleur. contrairement à la matrixctl qui envoit tout par paquet quand on fais un "recall".
Par contre c'est effectiivement super laborieux j'en suis à 8x8 pour l'instant

L'exemple ci dessous représente une piste de 8 pas.