controleurs externes

pour répondre au post de Renaud dans :Light et Iphone:

DL accepte les floats, je pense par contre qu'il y a un souci de priorité quand au traitement de l'information reçu par les contrôleurs externes.

mon problème par exemple est que si on monte un sub ou un circuit "à la main", il faut que le controleur atteigne la valeur avant de la modifier.
et c'est le mauvais code que j'ai écrit qui fait que tu n'arrives pas à modifier la valeur d'un sub si tu envoies 255.0

peux-tu essayer par exemple d'envoyer en OSC le message /circ/1 255.0

ici avec pd, ça fonctionne.
par contre ça ne fonctionne pas avec les subs.

si tu veux participer à l'écriture de l'algorithme, j'en serais ravi

++

En fait, les subs en OSC ne fonctionnent que s'ils ont des circuits ou des memoires chargées. Il est vrai que je ne l'ai pas signalé, mais ce n'est pas génant à l'utilisation...

Le problème est que si tu envoie par exemple 122.5, Dlight ne réagira pas. Il est clair que ces valeurs ne signifient rien en DMX, mais les logiciels envoient très souvent des flottants par défault. (ex : Oscullator, Lemur etc ...)
Pour ce qui est de pure data qu'il ne fait pas de différence entre float et integer, en fait il "type" automatiquement, si c'est XX.00, il typera la variable comme "entier". C'est bien fait

Malheureusement, pour l'instant, le fait d'envoyer la valeur en OSC avec le lemur par exemple ne permet pas de controller DL car il envoie les valeurs en flottants.

J'ai fait une petite appli autonome (.app) en max qui envoie des rampes sur le circuit 1 à DLight en localhost avec le choix de n'envoyer que des valeurs entières, mais avec .00 ou pas. Cela peut peut-être t'aider à tester.



ravi de pouvoir t'aider ...

L'application était trop volumineuse pour être attachée au forum.
Elle est téléchargeable ici :

J'ai oublié de finir aussi sur ce premier point (flottant/entier)

La solution à ce premier soucis peut-être tout simplement de "re-typer" les valeurs entrantes en les tronquant tout simplement.

Qu'en penses-tu?

elle est nickel ton application pour tester.

La solution à ce premier soucis peut-être tout simplement de "re-typer" les valeurs entrantes en les tronquant tout simplement.

pas évident car le jour où on voudra qu'un soft en OSC remplisse la zone de saisie, on aura besoin des nombres à virgule (floats).

en attendant, mon réel problème est l'algorithme de priorité.
je te l'exposerai en début de semaine.

++
nico

Pour ce qui est du tronquage que je proposait, il ne faut le faire que sur les valeurs qui arrivent après les messages /circ/x et /sub/x.
Il est clair que l'on doit pouvoir spécifier des mémoires à points (par exemple) pour les envoyer.
Et pour ce qui est de l'algo de priorité je serais tout ouï la semaine prochaine si ca peut aider of course.

bon week-end

en tout cas et dores et déjà, j'ai trouvé une méthode pour accepter les floats.
je mettrai une alpha en ligne la semaine prochaine qui intègre le patch.
utilises-tu la version XQuartz ?

++

Excellent !!

J'utilise la version Quartz, yes.

voici un des problèmes que je rencontre :

dans le cas de controleurs Midi sans faders motorisés, il peut arriver que les faders ne soient pas à 0 à l'ouverture du show.
Comment assurer que le sub/circ associé au fader ne jumpe pas à une valeur quand on baisse le fader ?
tu pourrais me répondre qu'on ne prend en compte la valeur du fader que quand il passe à 0, mais cela pose le problème des faders à 0 à l'initialisation. en effet quand tu montes un fader il n'envoie pas la valeur 0, mais ses premières valeurs (1, 3, ...).

pour ce qui est des priorités, j'y ai un peu réfléchi ce week-end et je compte mettre en place un structure de priorité pour les circuits et les subs.
à savoir 1 sub possède trois tableaux de valeur :interne, Midi, OSC, dont les règles seraient les suivantes :
la règle de priorité est initialisée sur l'interne.
une action de l'utilisateur ou un calcul assigne la priorité en interne, et dès lors, les actions midi ou OSC doivent atteindre la valeur avant de prendre la priorité.
si la priorité est assignée au midi, alors l'Osc devra atteindre la valeur actuelle avant de prendre la priorité.
il n'y a pas de règle de priorité dans le cas de Flash.

voila en gros ce que je vais essayer de faire aujourd'hui !!

++
nico

une version est dispo pour tests dans la section /Downloads/Alpha

++

Hello,

Je viens de faire des tests avec la Beta6 en OSC :
• Les floats sont acceptés !! youpi !!
• Le principe de priorité fonctionne en OSC sur les subs et les circuits sans problèmes. Parfait !!

Merci Nico !!