DMX Nodes en rapportDMX (Network Artnet Receiver) |
Le protocole DMX transmet 512 canaux par univers, ce qui équivaut dans vvvv à un spread de 512 slices.
Les valeurs DMX sont des entiers variant entre 0 et 255. vvvv utilise quant à lui des valeurs entre 0 et 1 (pensez à faire la conversion). Gardez à l’esprit que l’on utilise ici du 8bits, on ne peut donc avoir que 256 pas (en incluant 0 et 1). Art-Net est un standard permettant la transmission de DMX via Ethernet. Vvvv utilise la spécification Art-Net II permettant un total de 256 univers : 16 subnets de 16 univers chacun. Des exemples dans votre dossier vvvv\girlpower\ :
Voir également : |
Nodes en rapport |
vvvv peut interagir avec n’importe-quel périphérique HID (Human Interface Device). Il peut s’agir de joysticks, manettes de jeux ou boîtes à boutons, gants envoyant des données ou n’importe-quel appareil connecté en USB.
Pour plus d’informations, regardez les helppatches des nodes HID et la page du Wiki concernant ces nodes. |
Nodes en rapportHTTP (Network Get) |
vvvv est capable d’envoyer des requêtes GET et POST pour obtenir/envoyer des données depuis/vers des serveurs. vvvv peut aussi jouer le rôle d’un serveur grâce à la node HTTP (Network Server). Des exemples dans votre dossier vvvv\girlpower\ :
|
International Laser Display Association Nodes en rapport |
vvvv peut communiquer avec les lasers compatibles ILDA grâce à la node Lumax (Devices). Pour plus d’informations, étudiez son helppatch. |
Le protocole MIDI Nodes en rapportMidiNote (Devices) |
Dans le jargon du MIDI, les contrôleurs correspondent à : des potards de volume, des roues de modulation (modwheel), une pédale, etc. L’instrument dans sa totalité s’appelle un périphérique, et envoie ses données vers un numéro de canal donné.
vvvv décompte les canaux MIDI de 0 à 15 et les notes de 0 à 127. La vélocité d’une note et les valeurs de contrôle sont définies entre 0 et 1. La pin Buffer Length des nodes d’entrée MIDI définit le nombre maximum de messages MIDI en file d’attente pour ressortir dans le patch. Notez que seul un message par frame sera traité par le patch, alors que dans la durée d’une frame, plusieurs messages peuvent arriver.
Un patch très pratique pour recevoir et comprendre ce qu’envoie votre périphérique MIDI :
Un exemple sur comment recevoir des notes et control values différents sur différents canaux :
Enfin, vous pouvez regarder les différents exemples liés au MIDI :
Il existe aussi mapper MIDI et OSC très pratique appelé TodoMap. Vous pouvez regarder les tutos vidéo de cette contribution par vux et antokhio. Les nodes TodoMap sont maintenues par vux et sont disponibles dans l’addonpack. Modules MIDI pratiques : |
OSC Nodes en rapportOSCEncoder (Network) |
Le protocole OSC peut être utilisé pour établir une communication entre vvvv et d’autres logiciels comme Live, Pure Data, Max/MSP, Resolume … bref, vous voyez le truc. OSC peut s’avérer pratique si vous voulez envoyer différents paramètres via un seul port UDP. OSC ajoute une « adresse » à vos données que vous pouvez facilement filtrer côté réception.
Il existe aussi mapper MIDI et OSC très pratique appelé TodoMap. Vous pouvez regarder les tutos vidéo de cette contribution par vux et antokhio. Les nodes TodoMap sont maintenues par vux et sont disponibles dans l’addonpack. |
TUIO protocol Nodes en rapport |
TUIO est un protocole et une API destinée aux surfaces multitouch. Il encore des données de contrôle provenant d’une application tracker (par exemple basée sur la vision par ordinateur) et l’envoie à n’importe-quel client capable de décoder le protocole. Vous pourrez facilement tester la communication via ce protocole grâce à l’un de ces simulateurs logiciels (scrollez en bas de page). La node TUIODecoder (Network 1.0) est maintenue par Abomb et est dispo dans l’addonpack. Des exemples dans votre dossier vvvv\girlpower\ :
|
Nodes en rapportUDP (Network Client) |
La principale différence entre UDP et TCP, c’est qu’alors qu’UDP peut transmettre des données très vite mais sans garantir leur intégrité, TCP tend à être un peu plus lent mais garantit que l’intégralité des données envoyées arrivera à destination. Par conséquent, UDP sera plus utilisé pour des flots de données où il n’est pas très grave qu’une ou deux infos soient perdues, alors que TCP conviendra pour une application où chaque donnée doit impérativement arriver de l’autre côté.
UDP vous permet aussi de broadcaster vers des récepteurs. Cela peut être fait en utilisant une adresse IP de broadcast comme x.y.z.255 (où x.y.z représente votre subnet, par exemple 192.168.0) sur la pin Remote Host. Lorsque vous voulez envoyer plusieurs paramètres via UDP (ou TCP) sur un seul port, préférez l’usage du protocole OSC. Il ajoutera une « adresse » à vos données que vous pourrez facilement filtrer côté réception. Du moment que vous n’avez qu’un seul paramètre par canal, vous vous en tirerez bien avec UDP/TCP. Des exemples dans votre dossier vvvv\girlpower\ :
|
anonymous user login
~2d ago
~8d ago
~8d ago
~9d ago
~22d ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago