- Posts: 166
- Thank you received: 22
Résolution de problème : merci de consulter la FAQ et le Wiki
Aidez-nous à améliorer le contenu du Wiki et de la FAQ en les consultant. Le Wiki est mis à jour régulièrement et la FAQ permet une résolution rapide des principales embûches rencontrées. N'hésitez pas à nous faire parvenir vos suggestions d'amélioration sur le forum ou à éditer directement le Wiki ou la FAQ .
3.0.8_b1
- colinc
- Offline
Yes, [RECORD], [LOAD], [INSERT], and similar commands (eg a [DELETE] command) should come first I think - almost a 'standard' syntax now - Strand, ETC, Zero88, others, all use that form. As I've said before, people coming new to DL will find it easier to make the move...sl1200mk2 wrote: @Colin
while working on @Mode for editors, i'm wondering if existing syntax are good?
for example, does [CUE] XX [LOAD] shouldn't be [LOAD] [CUE] x.xx ?
another example:
does [GROUP] XX [REC] shouldn't be [REC] [GROUP] x.xx
or [STEP] XX [INSERT] -> [INSERT] [STEP] XX
sl1200mk2 wrote: any thoughts?
++
nico
Regards
Colin
Please Log in to join the conversation.
- dFVarela
-
- Offline
- Posts: 102
- Thank you received: 5
CUE XX.X REC and CUE XX.X LOAD is correct for direct input, but whe on commadand line it should be REC CUE XX.X
dFVarela
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
nicolas
Please Log in to join the conversation.
- colinc
- Offline
- Posts: 166
- Thank you received: 22
dfvarela wrote: There is a long time I don't work with a Strand board but from what I recall it depends if you're working with command line or direct input is used!
CUE XX.X REC and CUE XX.X LOAD is correct for direct input, but whe on commadand line it should be REC CUE XX.X
I think that may have been 'old' (DOS based) Strand - new Phillips/Genlyte Palette OS gives it the other way round - ie for command line it's [CUE] XX [RECORD] (pp 171/172 of the manual)
Regards,
Colin
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
now i'm re-writing things to accept [RECORD] [CUE] xx
wich is a less powerfull syntax (i think) but closer to spoken words
++
Nico
nicolas
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
[CH] XX [INV] or [INV] [CH] XX
the purpose of [INV] is to select channel with a level and deselect those under selection.
this command should select all channels with a level, except channel XX
wich form is suiting well ?
++
nicolas
Please Log in to join the conversation.
- colinc
- Offline
- Posts: 166
- Thank you received: 22
sl1200mk2 wrote: what about this one:
[CH] XX [INV] or [INV] [CH] XX
the purpose of [INV] is to select channel with a level and deselect those under selection.
this command should select all channels with a level, except channel XX
wich form is suiting well ?
++
I think in this case, the [CH] XX [INV] is better - or even just XX [INV] (kind of like an upside-down 'REM DIM ' command (which would be: XX [REM DIM])
Regards,
Colin
Please Log in to join the conversation.
- pipou
- Offline
- Posts: 57
- Thank you received: 4
J'ai trouvé un bug, je ne sais pas s'il a déjà été relevé, donc je t'en fais part :
Sous windows 7 32b ET 64b
cela concerne la fermeture de connexion entre dlight et l'usb dmx pro :
je lance un .sho, usb/dmx activé au lancement ou après dans le setup. Tout marche bien.
si je n'éteinds pas la connexion dmx via la LED verte avant de charger un nouveau show, la connexion se perd, dlight affiche en haut à droite un truc du genre libusb failed, no usb dmx pro found. Impossible de reconnecter sans avoir redémarré le soft. Pourtant, en chargeant un nouvelle conduite, dlight affiche bien qu'il ferme la connexion avant le chargement...donc il la ferme mal. A noter que si je ferme moi-même avant de charger la conduite, le problème ne se pose pas.
A+
pipou
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
thanx dude, je vais vérifier ça!
elle a intérêt a te plaire la beta 2 avec tous les retours que t'as fait
en ce moment je suis toujours sur l'@Mode, j'ai fini les éditeurs des Cue/Group/Sub et bientôt fini les FX.
après, je regarde tes bugs, j'essaye d'améliorer l'artnet et la détection d'interface sur iphone/android (pour autant qu'elles utilisent Control). un peu d'ascii...
*j'essaye* de mettre en place le mapping de l'OSC writer et je publie tout ça
j'aimerai bien y arriver pour la mi-Avril
++
nicolas
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
for the patch window, are you ok with
[CH] xx [@] yy
to patch dimmer yy to channel xx ?
i like it, because it's fast, you don't have to learn one more shortcut and it's close enough to spoken words.
i think i'll try also to do
[CH] xx [@] yy [THRU] zz
to patch dimmer from yy to zz to channel xx
++
nicolas
Please Log in to join the conversation.
- flk
- Offline
- Posts: 13
- Thank you received: 0
Once again, in terms what is out there (at least ETC)- funnily enough:
([DIM]) YY ([AND, THRU, NOT] [DIM] ZZ) ENTER ([CH]) XX ENTER
- which makes sense, as you are selecting several Dimmer channels first, to assign them then to a Channel once you are done...
Examples become quite quick that way, like thus:
"1 ENTER 6 ENTER" patches dimmer 1 to Channel 6
"2 THRU 7 NOT 5 AND 10 ENTER 20 ENTER" patches Dimmers 2,3,4,6,7,10 to Channel 20
does thak make sense?
Please Log in to join the conversation.
- flk
- Offline
- Posts: 13
- Thank you received: 0
([DIM] YY @ ZZ ENTER ([CH]) XX ENTER, that will be interpreted as when you bring CH XX to 100%, that DIM YY will only shine at ZZ % of its full intensity (and obviously in proportion when you take the Intensity of CH XX to i.e. 40, the formula would be 40* (ZZ/100).
Please Log in to join the conversation.
- sl1200mk2
-
Topic Author
- Away
- Posts: 11527
- Thank you received: 1061
glad you chime in here
we don't need to forget that DL must accept both RPN and @Mode notation and so we must deal with what have been done for RPN...
i mean that i agree with you that [AND] and [NOT] can be added to the patch window but in terms of compatibility with RPN and graphical window's design it's a no go.
moreover, generally, on tour, when i patch everything there's someone close to me that tells me:
"1 - 100, 2-34, 3-35 et 36" where first number is [CH] and last one are [DIMMER].
i don't quite often use the [THRU] function except to patch house lights and to set curve for all dimmers.
so i don't think i'll add [NOT] and [AND] functions to patch for this release.
it can be done for the future but i need to change patch window's design to make it looks like all the other editors. and something is still prevent me to do that is that with patch as list i have a quick overview of what is patched and which dimmers are free....
so at this point we still have several solutions:
[CH] xx [@] yy [ENTER] or [CH] xx [DIMMER] yy [ENTER]
i'm still happy with the first solution because in DL you can patch in channel->dimmer way or dimmer->channel way, and thus for the second case i think that [DIMMER] xx [@] yy [ENTER] will fit well to patch dimmer xx to channel yy.
more commands will be allowed
[CH] xx [@] yy [THRU] zz [ENTER] to patch dimmers from yy to zz to channel xx
[DIMMER] yy [THRU] zz [@] xx [ENTER] (available in dimmer->channel way) for the same purpose
of course in the channel->dimmer way single number will be prepending by [CH] if you not type it, and in dimmer->channel way, single number will be prepending by [DIMMER]
of course as you've noticed the use of [@] prevent his use to set dimmer level but as it's not an available feature in DL it's ok for now.
any thoughts?
best,
++
nicolas
Please Log in to join the conversation.
- flk
- Offline
- Posts: 13
- Thank you received: 0
How funny - when on tour, I usually get the opposite, people saying:
"100 into 1, 34 into 2,...", which is probably also due to the culture of widely using ETC Jargon. hmm...
not too fussed about not having "AND" and "NOT straight away, but am I understanding you correct that you just want to _add_ @mode syntax _on top of_ RPN? As opposed to having the switch in Setup to use only RPN or only @mode? To me, the second option would make more sense, if you are an @mode kinda guy, you'll want to use it through the whole program, similarly if you are RPN and want to stay that way, that probably goes for the whole program, am I right?
In which case you wouldn't need to pay too much attention what's going on on the "other" side? I am just saying, what's the benefit of introducing the option and then not go all the way to make it familiar to the @mode people
In having said that, I do understand that there are program limitations, and proportional patching is certainly not a priority...
Thinking though, I use "THRU" mainly to unpatch portions of a 1-to-1 patch, so granted, not necessarily relevant or important.
The "NOT" is not really that important, agreed.
The "AND" I do use quite often when patching, I often put the intensity of a set of LED ParCans on one channel i.e., but again, not a priority.
What would be important to me (as an @mode user
sooo.... could it be, that when the program is switched to @mode, the patch would understand when I say
"20 @ 2 ENTER"
that I mean DIMMER 20 to be patched into channel 2?
That would make me happy
a+
Freddy
Please Log in to join the conversation.
- vbs
- Offline
- Posts: 88
- Thank you received: 1
i tend to agree with Freddi about pachting dimmers to channel.
That is realy what happens if you visithing a veneu.
Some desk like Compulite with is used a lot in the Netherland is standard dimmers to channels (but there you can change this as well)
More dimmers to a channel would than be 12+16+45@10 enter
Dimmer 12,16,45 on channel 10
This would also make my happy
Thanks Vincent
Please Log in to join the conversation.
Français
English