3.0.17_b1

let's go.

should fix:
*OSC message length
*cleanup channel selection across ROOMs. (1.2 [CH] means the first channel of the second ROOM)


++

J'ai fait des test :
cue 1 : tout à 0
cue 2 : circuit 1 à 512 à FF
avec le 1er temps de transition entre 1 et 2 de 30s l'osc fonctionne
avec un temps de 10s : plus rien
je n'ai pas essayé avec 2 dlight linké directement, je récupère les infos avec pure data.
Demain je ferai le test avec seulement dlight.
++
Jef

Salut Jef,
pareil test avec PD et un print vers la console:
du côté de DL pas d'erreur à signaler, les bundles de circuits sont bien envoyés.
côté PD, les niveaux arrivent avec un retard et une erreur apparait subrepticement.
du coup je me demande si il n'y a pas un buffer à régler dans PD (mais j'ai pas trouvé...)

peux-tu corroborer ces tests?

++

Du côté pure data même technique : print vers console
mais c'est le print d'où vient le problème, avec un "route /circ/1" vers un "number" ça roule quel que soit le temps de transition entre les deux cues
avec print il doit y avoir un buffer un peu serré.
Donc ça roule.
Merci.
Sinon, en écoutant les doléances de divers utilisateurs j'ai souvent entendu que ça serait chouette de :
- Pouvoir intégrer des subs aux pas de fx (fx, samples, groups, speed…)
- Pouvoir lancer un fx une fois (du pas 1 au pas x, ou du pas x au pas y) ou encore un nombre de fois de x à y ou sens inverse, ou encore restituer les pas des fx de manière aléatoire
- Pouvoir directement enregistrer l'état lumineux sur scène dans un group ou/et sub
- Et un mode flash solo serait vraiment génial pour les circuits et les subs
Je crois que c'est tout...

hello,

avec print il doit y avoir un buffer un peu serré.
Donc ça roule.

donc m^me diagnostic, c'est cool.
ça va faire l'objet d'une 3.0.17 ça...

maintenant pour les nouveaux trucs, j'ai rien contre mais j'aimerais vraiment avant pouvoir bosser sur un module (simple) pour les asservis. En ce moment avec le boulot et l'été qui arrive, c'est pas facile de s'y mettre...
et puis ce mois ci, les dons se montent à 30€....
donc ça va être stand by jusqu'à l'automne...

- Pouvoir intégrer des subs aux pas de fx (fx, samples, groups, speed…)

ce qu'il faudrait c'est pouvoir créer des séquences identiques au séquentiel principal dans la forme (avec MLink, temps entre les pas de séquence, contenu) mais avec des registres de Cue autonomes.
le déclenchement pourrait se faire via des subs pour l'instant puis via une nouvelle fonction qui pourrait s'appeler MACRO qui définirait un pool d'action à associer aux pas séquences.
une macro possible à enregistrer sur un pas de séquence serait de lancer une séquence en parallèle de la séquence principale.
ça pourrait être aussi un moyen de faire des scénarios de séquence.

- Pouvoir lancer un fx une fois (du pas 1 au pas x, ou du pas x au pas y) ou encore un nombre de fois de x à y ou sens inverse, ou encore restituer les pas des fx de manière aléatoire

tout ça c'est ok, ça me serait bien utile aussi

- Pouvoir directement enregistrer l'état lumineux sur scène dans un group ou/et sub

dans un submaster vide (ou avec des circuits affichés) on pourrait avoir une fonction en inverse du Live qui ferait entrer dans le sub les niveaux de l'Output.
du coup, un petit record et t'as un groupe à l'identique du registre de sortie chargé dans le sub.
c'est pas con ça non?

- Et un mode flash solo serait vraiment génial pour les circuits et les subs

pour les subs il y est déjà et ne fonctionne que sur les subs. c'est à dire que tu peux avoir un état de scène ET le mode solo activé pour les subs.
après pour les circuits, je vois pas comment...

++

ou encore un 'com' -> 'group' ou 'sub' -> 'record'/'modify'/'delete' ?

pour les circuits en flash solo j'imagine que ça doit se faire avec le midi en mode note sur un circuit, en plus je crois qu'on peut souvent décider du fonctionnement de la touche midi en mode note sur les consoles, si elle reste 'on' le temps de l'appui ou si il faut ré-appuyer pour l'éteindre.

un petit truc encore : je me disais que les time-group seraient plus simples à utiliser si tous les circuits présents dans le cue apparaissaient directement dans la fenêtre time-group avec les temps et délais par défaut du cue. Ainsi que lors d'un GO on puisse voir en bleu les circuits en "delay" qui font poireauter la séquence (des fois on ne sait plus ce qu'il se passe)

et encore un truc : j'avais remarqué sur une presto que quand on sélectionnait les circuits actifs (all) et qu'on mettait tout à zéro, si on remonte après les circuits remontaient proportionnellement en fonction de leurs valeurs initiales. Dans Dlight tout remonte à la même valeur. J'ai l'impression que c'est utile.

Je me demandais si il n'y avait pas une boite à idée sur le forum ? (c'est peut-être pas l'endroit)

Sinon tu programmes DLight avec quel langage ? (juste par curiosité)

ou encore un 'com' -> 'group' ou 'sub' -> 'record'/'modify'/'delete' ?

pas avec com mais avec les raccourcis claviers tu peux déjà enregistrer le contenue de l'output vers un groupe, mais après faut que tu le charges à la main dans un sub.

pour les circuits en flash solo j'imagine que ça doit se faire avec le midi en mode note sur un circuit, en plus je crois qu'on peut souvent décider du fonctionnement de la touche midi en mode note sur les consoles, si elle reste 'on' le temps de l'appui ou si il faut ré-appuyer pour l'éteindre.

j'ai pas bien compris...

un petit truc encore : je me disais que les time-group seraient plus simples à utiliser si tous les circuits présents dans le cue apparaissaient directement dans la fenêtre time-group avec les temps et délais par défaut du cue. Ainsi que lors d'un GO on puisse voir en bleu les circuits en "delay" qui font poireauter la séquence (des fois on ne sait plus ce qu'il se passe)

c'est pas con mais du coup on ne pourrait plus distinguer rapidement quels circuits sont sujets aux TGroup.
tu sais, à coté de l'extrait du séquentiel, les cases noires marqués R1, R2, R3 et R4 indique le TGroup le plus long du transfert.
donc quand ça mouline là haut, ça veut dire qu'il y a toujours quelqu'un en transfert.

et encore un truc : j'avais remarqué sur une presto que quand on sélectionnait les circuits actifs (all) et qu'on mettait tout à zéro, si on remonte après les circuits remontaient proportionnellement en fonction de leurs valeurs initiales. Dans Dlight tout remonte à la même valeur. J'ai l'impression que c'est utile.

si tu parles du fonctionnement de DL, je suis d'accord aussi.

Je me demandais si il n'y avait pas une boite à idée sur le forum ? (c'est peut-être pas l'endroit)

pas pour l'instant mais on pourrais créer un forum boite à idées...

Sinon tu programmes DLight avec quel langage ? (juste par curiosité)

en C

++

pour le flash solo l'idée était qu'on puisse attribuer une note midi à un channel pour les flash des channels, puis rajouter aussi un bouton Flash/Flash solo

Ok pour R1 R2 R3 R4, je ne l'avais pas remarqué

Sinon pendant un spectacle des fois un circuit peut être chiant : genre l'éclairage public qui a été enregistré dans plusieurs cues, ça serait pratique de pouvoir le sélectionner et de cliquer sur un bouton pour le bloquer à sa valeur (et le griser du coup) puis qu'on puisse en mettre d'autres aussi. Je crois que inhibition fait ça mais c'est pas rapide si on est speed.

Pour ce qui est sélectionner les circuits actifs (à des niveaux variables) de les mettre à zéro et de les remonter, j'ai l'impression que s'ils remontent proportionnellement à leurs valeurs initiales c'est mieux.

Bonne journée.

Un petit pb de routage en osc : lors d'un go en cut les circuits ne suivent pas, par exemple je route le circuit 1 pour le copier en circuit 2. Le circuit 1 passe de 0 à xx en 0 secondes, le circuit 2 ne suit pas. Il faut aller le chercher à zéro pour l'amener à la valeur avec un temps. Est-ce dû au principe d'accrochage des valeurs comme pour le midi ?