Nouveau tread sur l'addon pack matrix

joffo78 · Unread post by **joffo78** » 15 Mar 2011, 23:41

Bonjour

Ne sachant pas comment créer un tread (je ne dispose sans doute pas des autorisations pour le faire) je poserais mes questions ici.

j'entreprends de créer un espèce de jeu d'orgue pour piloter de la lumière mais aussi du son et de la vidéo.
l'idée est simple: un sous patch composé d'une matrice (buffer) stock différentes valeurs pouvant être rappelées par un preset manager (ou le conducteur je ne sais pas trop encore). je dispose ensuite de deux autres matrices (une de préparation et une de restitution) je peux doser dans une matrice de sortie le contenu des deux matrices que nous appellerons x1 (pour la restitution) et x2 (pour la préparation). grâce à la lecture de deux courbes, je peux automatiser la descente de x1 et la monté de x2 (avec des temps différents. Un fader nommé cross over me permet de passer de x1 à x2 en conservant les temps relatifs des deux.
les valeurs des cellules sont affichées dans les cellules elles même grâce à l'aide de 23fx23 (script array to comma text).
je peux rappeler le contenu de mes mémoires (buffer) dans x1 ou x2. la logique étant: je rappelle ma mémoire dans x2 et je "crossfade" de x1 à x2. Je peux également modifier le contenu de x1 et le sauvegarder dans un preset. Voilà où j'en suis rendu.
Si vous voulez vous faire une idée, vous pouvez consulter ce patch : my lighting patch
Les valeurs pourront êtres transmises à un réseau dmx via le module enttec de "levraibernardo".

Voici à présent ce que je souhaiterais faire et là où je sèche :

j'aimerais que lorsque je lance la lecture de mes deux courbes, le fader de crossfade suive l'évolution de la plus longue.
lorsque le transfert est arrivé au bout (x1 à 0 et x2 à 1), il s'effectue la séquence suivante:
copie le contenu de x2 en x1 puis ré-initialise les courbe au début ainsi que le cross fader, passe à la scène suivante du preset manager ou du conducteur et charge le contenu de la matrice buffer en x2.
Ainsi je suis près à commencer une autre séquence.
Il me semble que cette logique bien qu'un peut compliquée à comprendre pourrait bien ouvrir des perspectives intéressantes à tout à chacun.
il s'agit en fait du meilleur mode de lecture séquentielle de valeurs pouvant être attribué à n'importe quel objet (son, midi, osc , dmx).
dans un deuxième temps j'aimerais également pouvoir réaliser un go back qui me permettrait d'effectuer l'opération inverse (c'est à dire chargé en x2 la mémoire précédente dans mon preset manager et crossfader avec x1).
je souhaiterait aussi (et c'est pourquoi j'ai besoin que mon crossfade suive) pouvoir "prendre la main" sur un transfert automatisé en saisissant le crossfade à la souris et terminant le transfert manuellement.

Passons maintenant à ce qui nous intéressait initialement à savoir la partie matrice.

Actuellement, je ne parviens à afficher que les valeurs contenues dans les cellules. je souhaiterais pouvoir voir en plus dans chaque cellule la valeur fixe correspondant au numéro de cellule.

je souhaiterais également en x1 pouvoir réaliser la saisi des valeur autrement qu'en glissant sur la case avec la souris.
Le mode de saisi pourrait être les frappes suivante : "12+" choisi la cellule 12, "25/" monte à la valeur 0.25.
Le must serait de pouvoir travailler sur plusieurs cellules en même temps du genre : "1+12+23+" sélectionne les cellules 1,12,23 "53/" met ces trois cellules à la valeur 0.53.
Bon je n'invente rien, je me contente de reprendre la syntaxe des jeux d'orgues de théâtre.
Les principales innovations de mon système sont :
la possibilité de dessiner des courbes de monté de x2 ou de descente de x1 de la forme que l'on veut.
la possibilité d'attribuer à chaque cellule le contrôle que l'on désir (un circuit d'eclairage mais aussi le déclenchement d'une video ou la lecture d'un sample ou encore le changement de position d'un son dans l'espace...)

Désolé pour ce roman mais j'ai besoin de votre aide. Notamment pour le travail sur les matrices.

Bien à vous.
JF

joffo78 · Unread post by **joffo78** » 15 Mar 2011, 23:43

euh sinon les mec y' a pas moyen de chatter avec vous ?

joffo78 · Unread post by **joffo78** » 16 Mar 2011, 00:24

Bon voici une nouvelle version plus avancée où les fonction de rappel séquentiel logiques fonctionnent ainsi que le contrôle du cross fade (grâce au module rampe).
du coup vous devriez mieux comprendre de quoi je parle:

testez en faisant go: les mémoires de matrice s'enchainent.
modifiez le contenu de x1 et "storez" votre mémoire corrigées....

23fx23 · Unread post by **23fx23** » 16 Mar 2011, 02:35

sympa comme systeme.
faut que tu te mettes au script, tout ce qui est relatif a matrix est souvent beaucoup plus compliqué/ impossible par patch.
c'est souvent lié a des fonctions répetitives, d' operations de texte,.
genre voir le N° de telle cellule + sa valeur en patch c chaud, en langage script c tout con une fois que ta les bases. Au debut ca parait chinois, mais c assez simple une fois que t'as capté. genre sur celui que tu as deja tu peu facilement modifier:

au lieu de SL1.strings:= IntToStr(trunc(getDataArrayValue(ArrayIn,i)));
tu mets SL1.Strings:= 'cell_nb:' + IntToStr + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i)));

sinon g pas capté pour le reglage des valeurs, tu veux taper ça au clavier physique ou clavier virtuel sur la matrice?
Perso pour allez vite et sans se prendre la tete, je basculerai la matrice en mode draw, avec un big fader pour controler la draw value. comme ca tu regle le big fader sur une valeur et bam ta juste a cliquer sur les cellules une a une, tu peux meme dessiner une ligne pour faire des purs effets de rampes progressives, tout ca super vite fait. si ya que 127 valeurs, un big fader c rapide et precis.

joffo78 · Unread post by **joffo78** » 16 Mar 2011, 07:05

Salut 23fx23
Merci pour tes conseils.
Effectivement le script m'intéresse de plus en plus . J'ai essayé de suivre la page wiki et je comprends le système, le principe
mais je bloc un peu pour commencer à en élaborer (ta proposition de remplacer
SL1.strings:= IntToStr(trunc(getDataArrayValue(ArrayIn,i))) par
SL1.Strings:= 'cell_nb:' + IntToStr + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i))); ne me parle pas). Je n'arrive pas à comprendre encore comment cela peut être plus efficace que le patch.
A vrai dire j'attends avec impatience un workshop qui aborderait ce sujet. Etant donné mon emploi du temps j'espère que je pourrais y assister.
Pour la saisi des valeurs il s'agit d'une vraie saisie au clavier. Je suis parti de la logique des jeux d'orgues traditionnels. la syntaxe est rédigé sur le clavier et il me semble que c'est la plus rapide. si par exemple je veux mettre 5 cellules à 0.23 je n'ai qu'à écrire par exemple 1+12+16+24+25+23/.
Sur les jeux d'orgue ont dispose aussi d'un "trhu" qui permet de saisir la valeur de cellules qui se suivent du genre 1+45t(thru) sélectionne les 45 premières cellules , 23/ placent leur valeur à 0.23.
Mais bon je vai tester ta méthode draw elle m'intéresse bien

joffo78 · Unread post by **joffo78** » 16 Mar 2011, 07:09

euh la fonction draw value fonctionne mal sur mon patch. si quelqu'un veut bien avoir la gentillesse de tester sur la matrice x1
(placer la matrice en draw mode,mettre en fade et essayer de changer la valeur des cellules avec cette methode).

joffo78 · Unread post by **joffo78** » 16 Mar 2011, 07:12

re salut 23fx23
quand je remplace les ligne et que je re compile le script il me dit cela :
Not enough actual parameters
Line 30 : SL1.Strings:= 'cell_nb:' + IntToStr + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i)))

martignasse · Unread post by **martignasse** » 16 Mar 2011, 10:15

ok, resalut joffo78,

bon, j'ai jeté un premier coup d'œil vite fait (pas trop le temps là), ca a l'air ambitieux comme projet, mais bon, t'as déjà une bonne base

première série, pour aller à l'essentiel :

1°)

Not enough actual parameters
Line 30 : SL1.Strings:= 'cell_nb:' + IntToStr + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i)))

petite erreur de la part de 23fx23 (il l'a fait de tête je suis sur )
ca devrait être :

Code: Select all

SL1.Strings&#91;i&#93;&#58;= 'cell_nb&#58;' +  IntToStr&#40;i&#41; + 'val&#58;' +  IntToStr&#40;trunc&#40;getDataArrayValue&#40;ArrayIn,i&#41;&#41;&#41;

note les parenthèses au lieu des crochets pour 'cell_nb:' + IntToStr(i).

ensuite, y a moyen de mettre les infos que tu veux, c'est pas vraiment le problème, normal que tu capte pas au début, mais on va t'aider et ca viendrat

Mais la vrai limitation de ce système, c'est que tu ne pourras pas afficher le texte sur plusieurs lignes dans la cellule, faudrait que je vois si je peux rajouter ca au niveau du module matrix.

Je n'arrive pas à comprendre encore comment cela peut être plus efficace que le patch

ben pour simplifier, disons que c'est plus efficace parce que c'est pré-compilé (pré-digéré si tu préfère) et que usine a plus qu'a faire le boulot, alors que pour les patch, il doit les réinterpréter constamment et ca prend du temps.
en plus, c'est beaucoup plus simple et puissant de traiter des séries, liste, array par script, par patch, on est vite limité.

dans un premier temps, pour t'aider a aborder la logique des script, essai de décomposer ce que tu veux faire en langage parlé et étapes simple, sans tenir compte du langage script.
pour reprendre l'équivalent de la ligne de code au dessus, ca donne :

Code: Select all

cell caption est un text composé de &#58;
 -le terme 'cell_nb&#58;'
 -suivi de l'index de la cellule
 -suivi du terme 'val&#58;'
 -suivi de la valeur de la céllule

toi, tu voudrais plutôt un truc comme ca ?

Code: Select all

cell caption est un text composé de &#58;
 -le numero de colonne
 -suivi d'un point
 -suivi du numéro de ligne
 -suivi d'un deux points
 -suivi de la valeur de la céllule

déja, ca te permet d'avancer au niveau logique de se que tu veux faire sans être embrouillé pas la syntaxe du script, et puis si tu nous donne un truc comme ca, c'est royal, on le code en deux secondes et toi tu peux comprendre l'équivalent en script.

a noter que ca marche pour tout, pas seulement pour décrire une chaine de caractère.
et ca marche aussi pour faire des patch, subpatch, ca aide a garder un patch logique et cohérent (voir juste en dessous

)

2°)

la fonction draw value fonctionne mal sur mon patch

normal, car ta matrice est complètement commandé par l''array in' connecté sur 'cell in' (y a pas de 'pass if change'). de plus, le fait d'avoir deux trucs branché sur 'cell in' est pas logique et un nid a embrouilles, il faut que tu traite le 'array in' a un autre niveau, comme ca :

c'est plus 'lisible' non

et en plus, ca résout ton soucis

3°)
sinon, deux questions à se poser concernant la saisie clavier :
-tu est obliger de selectionner un champ text pour saisir dedans, donc des manips à la souris en plus du clavier.
-plus le fait d'avoir à interpréter la ligne de commande que tu tape, ca peux devenir vite compliquer.

donc si le 'draw cell value' te convient et est assé ergonomique, je te conseil de partir la dessus dans un premier temps, la fonction saisie pourras toujours être rajouté plus tard (pour te conformer au usages du métier) mais devient moins prioritaire.

sinon, quoi d'autre...ha oui, en testant ton patch, je suis pas trop arrivé a enchainer de nouvelles memoires que j'ai sauvegardé, je les vois bien defiler dans buffer, mais x1, x2 et output n'évolu pas ?

bon, j'arrête là, je pense que tu a du grain à moudre pour l'instant

a+

23fx23 · Unread post by **23fx23** » 16 Mar 2011, 10:51

oops wi g tapé de tete, petite erreur classique

bien vu martin.

c'est une bonne methode que martin decrit; decomposer les procedés voulus, sorte de synopsis, puis essayer de les convertir en langage script.

au pire si tu as un probleme avec le draw, (mais qui je pense est resolu par le cablage de martin), tu peu rajouter un stop, qui
va stoper ce qui arrive en IN de matrix, commandé par le mouse down de matrix, comme ça ca fighte pas quand t'essaye de mettre les valeurs. Teste cela mais ca me parait vachement plus rapide que taper au clavier..

joffo78 · Unread post by **joffo78** » 16 Mar 2011, 11:19

Dans ce cas le mode fade me semble le plus approprié.
l'ideal serait de pouvoir manipuler plusieurs cellules.
Dans mon cas de figure le mode draw ne me servira pas.
En tout cas merci de votre aide j'essaie d'avancer un peu et je reviens à la charge.

joffo78 · Unread post by **joffo78** » 28 Mar 2011, 09:51

SL1.Strings:= 'cell_nb:' + IntToStr + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i)));

Bonjour et merci pour cette correction de script.
A présent comment puis je rajouter 1 à mon numero de cellule pour aller de 1à 120 au lieu de 0 à 119 ?
Merci

23fx23 · Unread post by **23fx23** » 28 Mar 2011, 12:24

SL1.Strings:= 'cell_nb:' + IntToStr(i+1) + 'val:' + IntToStr(trunc(getDataArrayValue(ArrayIn,i)));

joffo78 · Unread post by **joffo78** » 28 Mar 2011, 17:08

merci infiniment

joffo78 · Unread post by **joffo78** » 28 Mar 2011, 17:25

une autre petite question
je souhaite envoyer l'ensemble des valeurs de mon tableau au magnifique module de levraibernardo qui permet de communiquer des valeurs dmx via le module enttec.
A priori le module de gère qu'un canal à la fois.
Croyez vous qu'il est possible grâce au script unpack array d'envoyer les valeurs les unes après les autres sachant qu'elles sont susceptibles de bouger toutes en même temps ?

23fx23 · Unread post by **23fx23** » 28 Mar 2011, 18:36

mmm, ca depend de la vitesse de changement, de l'usine bloc size et de la taille de la matrice, a essayer, le script envoie les donées qui changent simultanément bloc apres bloc, donc si 64 datas, bloc de 128(3ms) ça prend 64 blocs x 3 ms = 192ms, les changements doivent etre plus espacés que ça. test en etant en 32 blocs. mais j'ai peur que le fade actuel opere constament a chaque bloc, faudrait une sorte de quantize adapté, genre la valeur est updatée seulement chaque 64blocs, avec une clock genre bloc counter, il doit y avoir un script sur le forum de ce nom sinon jpourrait te le filer.

teste tel quel de tt facons, ça peut marcher direct.

martignasse · Unread post by **martignasse** » 28 Mar 2011, 23:47

ha ben ça avance, cool

A priori le module de gère qu'un canal à la fois

Effectivement, un module = un canal. Par contre tu peux avoir plusieurs instances du module pour gérer plusieurs canaux DMX.
D'après ce que j'ai compris de ton patch, une cellule de la matrix correspond à un canal DMX, non ?

Croyez vous qu'il est possible grâce au script unpack array d'envoyer les valeurs les unes après les autres sachant qu'elles sont susceptibles de bouger toutes en même temps ?

Les 'valeurs qui bougent toutes en même temps' sont censé aller vers des canaux DMX différents, non ?

Comment est organisé ton mappage DMX par rapport à ta matrix de sortie ?

A priori, il faudra que tu split les données de ta matrix en fonction des différents canaux DMX vers lesquels tu veux les envoyer, ensuite tu injecte chaque valeur dans un module DMX.

joffo78 · Unread post by **joffo78** » 29 Mar 2011, 05:56

En effet c'est bien ce qu'il me semblait. Du coup si je veux gérer 120 circuits dmx il me faudra 120 instances du module !
ma matrix de sortie contient 120 cellules. elle est configurée en mode fade. J'ai rajouté un multiplicateur *256 pour les valeurs dmx.
Pour le moment j'ai testé le système sans utiliser les module enttec mais en envoyant directement la sortie de la matrix via un send byte en udp à un logiciel tierce (schwartzpeter). Celui ci récupère mes 120 valeurs et assure l'interfaçage avec le dmx. Mais
c'est un peu idiot car j'utilise un logiciel de jeu d'orgue pour faire fonctionner mon logiciel de jeu d'orgue !
Pour dresser un petit bilan de mon travail (je ne suis pas sur mon ordi perso et ne peux donc pas vous transmettre ni patch ni screenshots) je suis parvenu à créer un registre qui contient les mémoires. un registre x2 dans lequel est stockée la mémoire en préparation et d'un registre x1 qui restitue un etat (composé d'un ensemble de valeurs).
Je peux basculer d'un état à un autre (x1 à x2) de manière automatisés (via de curves with points, un pour la montée de x2 et l'autre pour la descente de x1).
quand la courbe dont la durée est la plus longue est arrivée à la fin x1 revient avec le contenu de la mémoire précédemment chargé en x2 et x2 retourne à 0 et le contenu de la mémoire suivante est chargé.
il me reste à trouver une solution pour pouvoir faire un retour à la mémoire précédente (go back), une pause en cours de transfert et en enchainement de la mémoire suivante en cours de transfert (hum pas simple).
à terme je souhaiterais utiliser une partie des valeurs de la gille non pas pour contrôler seulement de la lumière mais aussi pour piloter un logiciel de diffusion vidéo (via osc) puisque il n'existe pour le moment quasiment pas d'objet gèrent la vidéo dans usine (et ça c'est bien dommage).

martignasse · Unread post by **martignasse** » 29 Mar 2011, 10:33

joffo78 wrote:En effet c'est bien ce qu'il me semblait. Du coup si je veux gérer 120 circuits dmx il me faudra 120 instances du module !
ma matrix de sortie contient 120 cellules. elle est configurée en mode fade. J'ai rajouté un multiplicateur *256 pour les valeurs dmx.

c'est clair que ca va être fastidieux...fait un subpatch de 8 avec tout ce qu'il faut pour assigner les channels, puis duplique, ça te feras 15 banques de 8.
Ca sera peut être un peu lourd aussi, 120 instances du module dmx, je sais pas.

C'est peu être l'occaz de demander a LeVraiBernardo un update de son module (bien qu'il doive être débordé

)
Qu'on puisse choisir le nombre de canaux à gérer quand on pose le module (faisable avec le query system du SDK), l'entrée Value deviendrai une array et hop plus de tringlerie fastidieuse

Pour le moment j'ai testé le système sans utiliser les module enttec mais en envoyant directement la sortie de la matrix via un send byte en udp à un logiciel tierce (schwartzpeter). Celui ci récupère mes 120 valeurs et assure l'interfaçage avec le dmx. Mais
c'est un peu idiot car j'utilise un logiciel de jeu d'orgue pour faire fonctionner mon logiciel de jeu d'orgue !

Yep, mais t'as pu te concentrer sur ton système sans te prendre la tête avec le dmx, donc bien joué.
Maintenand, faut tordre le coup au dmx

Pour dresser un petit bilan de mon travail (je ne suis pas sur mon ordi perso et ne peux donc pas vous transmettre ni patch ni screenshots) je suis parvenu à créer un registre qui contient les mémoires. un registre x2 dans lequel est stockée la mémoire en préparation et d'un registre x1 qui restitue un etat (composé d'un ensemble de valeurs).
Je peux basculer d'un état à un autre (x1 à x2) de manière automatisés (via de curves with points, un pour la montée de x2 et l'autre pour la descente de x1).
quand la courbe dont la durée est la plus longue est arrivée à la fin x1 revient avec le contenu de la mémoire précédemment chargé en x2 et x2 retourne à 0 et le contenu de la mémoire suivante est chargé.

c'est du double buffering en gros alors ?
faudra une page wiki ou une video car avec ton premier patch, je suis pas arriver à capter le fonctionnement de tout ces buffer, mais je pense que pour un gars du metier, ca doit être évident.
En tout cas, ca m'a l'air pas mal du tout cette affaire.

il me reste à trouver une solution pour pouvoir faire un retour à la mémoire précédente (go back), une pause en cours de transfert et en enchainement de la mémoire suivante en cours de transfert (hum pas simple).

ben ca va, t'es presque rendu

mais sans avoir capté le fonctionnement général et sans le patch sous les yeux, peu pas t'aider là

à terme je souhaiterais utiliser une partie des valeurs de la gille non pas pour contrôler seulement de la lumière mais aussi pour piloter un logiciel de diffusion vidéo (via osc) puisque il n'existe pour le moment quasiment pas d'objet gèrent la vidéo dans usine (et ça c'est bien dommage).

OSC, DMX, même combat, t'auras quelques adaptations a faire, mais c'est kif kif.

pour la video dans usine, autant le moteur d'usine pourrai à priori le faire, autant c'est un domaine à par entière. Je sais pas si c'est réaliste de vouloir traiter le son et la vidéo sur la même machine, et puis faut coder tout ça, c'est une montagne de taf :rolleyes: ya déjà des très bon soft pour ça qui demande qu'a manger du osc (comme vvvv ou isadora)

joffo78 · Unread post by **joffo78** » 29 Mar 2011, 11:47

OSC, DMX, même combat, t'auras quelques adaptations a faire, mais c'est kif kif.

pour la video dans usine, autant le moteur d'usine pourrai à priori le faire, autant c'est un domaine à par entière. Je sais pas si c'est réaliste de vouloir traiter le son et la vidéo sur la même machine, et puis faut coder tout ça, c'est une montagne de taf roll ya déjà des très bon soft pour ça qui demande qu'a manger du osc (comme vvvv ou isadora)

Je suis d'accord sur le principe mais cela nécessite l'apprentissage global d'un nouveau soft modulaire et ça je n'y tiens pas trop
compte tenu du taf que j'ai déjà à faire avec usine.

Je sais pas si c'est réaliste de vouloir traiter le son et la vidéo sur la même machine

Et alors, qu'est ce qui m'empêche d'acquérir une seconde license d'usine et de la faire tourner sur un autre ordi ?

c'est du double buffering en gros alors ?

C'est quoi le double buffering ?

faudra une page wiki ou une video car avec ton premier patch, je suis pas arriver à capter le fonctionnement de tout ces buffer, mais je pense que pour un gars du metier, ca doit être évident.

Pour patienter je vous livre une version un peu plus à jour :version avancée d'un jeu d'orgue made in usine

Unread post by **LevraiBernardo** » 29 Mar 2011, 18:53

Salut les gars,
bon, je tombe un peu par hasard sur le thread.
Pour répondre rapidement, oui je suis un peu débordé mais ça va encore.
Pour le reste, le nombre de canaux utilisés est géré par le module : Il regarde quel est le plus grand canal sélectionné dans Usine, et il n'envoie du message DMX que du canal 1 à ce canal. (on est obligé de commencer au 1). Mais attention, c'est le plus grand utilisé après passage par le patch. C'est à dire que si vous ne mettez qu'un module sur le canal1, à priori, du message DMX ne sera envoyé que sur ce canal. Mais si ce canal est envoyé en 512 par le patch, alors tous les messages DMX seront envoyés. Mais ça ne devrait de toute façon pas avoir une incidence énorme sur la consommation CPU.
En ce qui concerne un patch de 8 à répliquer, oui c'est effectivement ce que je faisais aussi. Mais vous avez essayé avec la piolyphonie ? Ca devrait marcher, non ?

joffo78 · Unread post by **joffo78** » 29 Mar 2011, 19:07

Bonjour et merci pour ton intervention.
J'ai essayé le mode poly avec ton module et ça à planté du coup je n'ai pas insisté.
Je n'est pas bien saisi le principe: je mets la sortie de ma matrix (cells out) sur l'entrée value de ton module et je patch le 1 en 512 (ou 120) et le module se charge du reste ?

Unread post by **LevraiBernardo** » 31 Mar 2011, 08:59

Chez moi, la polyphonie fonctionne parfaitement (Usine 5.50.35). Je place le module DMX dans un subpatch, un fader sur l'entrée Value, et un module Current Voice Number sur l'entrée DMX channel. J'ai 32 entrées sur mon subpatch qui correspondent aux 32 premiers canaux DMX.
Pour répondre à ta question, non, ne patche pas le 1 en 512 (ni 120) dans le module. Si tu laisses ton patch à plat, le module n'enverra du message DMX que sur les canaux sollicités.

joffo78 · Unread post by **joffo78** » 31 Mar 2011, 23:09

et bien ça me convient ça. quel interet alors de faire un patch polyphonique si je peut parler à mes 512 canaux ?
Comment ton module peut savoir à quel canal je parle ? Est ce que le contenu d'un array est perçu comme les numéros de circuits ?

Unread post by **LevraiBernardo** » 01 Apr 2011, 09:19

Non, le contenu d'un array n'est pas interprété comme une série de valeurs. J'avais envisagé cette solution au départ (notamment pour le patch des circuits), mais les tableaux étaient à l'époque indexés de 0 à 511, et les circuits sont numérotés de 1 à 512. Trop de risques de confusion dus au décallage, alors j'ai changé de tactique. Aujourd'hui, les tableaux peuvent contenir jusqu'à 1024 valeurs, ce qui permettrait de revenir à cette solution. A voir...
L'intérêt du patch polyphonique, c'est que si tu changes ton patch initial, cela modifie automatiquement le patch pour toutes les entrées/sorties. En général, pour le DMX, on utilise pas mal de fois le même type de traitement pour plusieurs circuits (ce qui ne signifie pas les mêmes valeurs pour tous les circuits...). La polyphonie étanty limitée à 32 instances, tu crées ainsi un patch unique pour 32 circuits DMX.. Après, ça se gère de la même manière qu'un patch monophonique. (je t'encourage vivement à jeter un oeil au manuel pour éclaircir ce point).

joffo78 · Unread post by **joffo78** » 01 Apr 2011, 09:56

Merci pour tes conseils. Je connais le principe du patch polyphonique c'est vrai que c'est assez pratique mais cela n'épargne pas le fastidieux travail de connexions fil à fil de chacun de mes circuits dmx.
Est ce compliqué pour toi de faire une entrée array sur ton module ?
Eventuellement pourquoi pas y intégrer de base un shift array qui décalerait les valeurs d'un pas de l'index pour démarrer de 1 et non de 0 ?

Unread post by **LevraiBernardo** » 01 Apr 2011, 12:41

Pour ce qui est de l'histoire du shift array, je ne l'avais pas envisagée tout simplement parce qu'à l'époque où j'ai créé le module, cela n'existait pas dans Usine. Il est vrai que maintenant, cela serait réalisable. Du coup, on peut effectivement envisager une version avec tableau, ce qui présente l'avantage de n'avoir qu'un seul module par inteface enttec, au lieu d'un module par canal DMX. En revanche, je pense qu'on ne coupe pas (tôt ou tard) aux connexions nombreuses et fastidieuses, tu l'as dit...
Autre soucis : Si je passe les entrées en array, j'ai des doutes quant à la compatibilité entre les deux types de modules. (on va très certainement avoir des conflits violents sur les accès à l'interface si les deux modules sont chargés dans un même patch). A voir... (mais quoiqu'il en soit, ce ne sera pas pour tout de suite...)

Welcome to %s forums

Nouveau tread sur l'addon pack matrix

Who is online

Login • Register