3.0.8_b1

sl1200mk2 wrote:
Regarding the double-clic function to set value in the Fx Editor or the MLink Editor, i think we will face an issue:
with the new @Mode functions, when you hit a number, DL automagically add [CH] in front of it as generally when you hit numbers it's to define a channel.
And thus, it become complicated to assign by double-clic to times for example something called [CH] [1] (if you hit 1).
Don't doubt that @Mode will be present in both of these editors!

a workaround can be to disable leading [CH] when it's not explicitely specified.

Could this be a User-set option - a tickbox (with a shortcut too!) ( *in the main window* ) which can let you quickly switch between auto-prepending [CH], or having to type [CH]. I suspect most consoles most times assume [Channel] unless you specifically type something else or hit a relevant button, but a selectable option might be a good thing - allowing you to quickly switch back and forth as the context of your work changed.

sl1200mk2 wrote: what do you think ?
(it can be nice if experienced @Mode users also give their opinion)

++

Regards

Colin

@Colin,
it could be that way but is it really usefull to auto prepend [CH]?
why not just define that a single number is always under the control of the active selected 'mechanism' (ie Channel, Group or Sub)
This morning, i added the [+] [3] (3 for the example) possibility to the @Mode way.
thus if last command was refering to Groups, it add all channels of the Group 3 to the current selection. If last command was referering to Channel, it would have added the Channel 3 to the current selection.

it can also be that way for 'empty leading' numbers, if the last command refers to Group, DL assume you want Group selection, idem for Channels and Sub.

++

@Nico

I think that *most* users of 'traditional' style syntax expect that unless specifically told otherwise, the desk will always assume that [Channel] is what is being called for. (The Jands Vista software for example, appends 'Fixture' - their alternave word - to the Command Line when you type a number, unless you type eg 'Group' or similar first.) The ETC desks, and the Strand also prepend 'CH' or 'Channel'. (I don't know GrandMa or Avolites and similar.). But the Jands lets you turn the command line off, and then typing a number works in the context of the window or cell your in.

I think it might be frustrating if you come in some morning, starting to set levels, and find that because perhaps you had been working on eg 'Groups' the night before, that you have to remember to get back to 'Channel' control. I think that most of the main hardware desks start up with the 'Channel' button hi-lighted, and you consciously have to press the other group, sub, whatever buttons to take you out of that

Anyway, just my thoughts...

Regards,

Colin

Colin,
I tend to be agree with you except on two points:
-DL is a computer based lighting desk, and thus we have to think about the way you work on a computer.
double-clic is a common practice and i hear them very much when user say it's their way to assign time by double-clic (i admit to do so sometimes...)
-in DL, even in the RPN way, when you're in Group 'mechanism', the next entry will be assign to Group, no matter if you specified it. So i'll be a huge difference between @Mode and RPN if they do not behave equally.

from your example, what happen if user consciously hit Group button for a command, validate by Enter and after press a number? If it goes back to Channel, i think it's a program limitation because when you're on Group control (control is a good word for that purpose - instead of mechanism ), you work that way... hitting Group button each time is no good at all.

we discuss about that because of one number entry that can be assigned to times or whatever by double-clic, but i think we have to find the appropriate behaviour of one number entry in the command line.

Best regards,
Nico

Hello Nico

sl1200mk2 wrote: Colin,
I tend to be agree with you except on two points:
-DL is a computer based lighting desk, and thus we have to think about the way you work on a computer.
double-clic is a common practice and i hear them very much when user say it's their way to assign time by double-clic (i admit to do so sometimes...)

I agree - Computer != Traditional Hardware...

But...

You open your laptop; the lighting designer shouts "2 at 60"; so, which is quickest:

Tap '2', tap '@', tap '50' on your key board

or

Look at the screen; select Ch 2 with the mouse; type '2'; doubleclick or press <enter>

So I think in one essence, Computer Software is not so different from 'Traditional' Hardware (and let us not forget that traditional hardware is often based on 'traditional' operating systems - old Strand was based on DOS, new Strand is based on Win XP, Chamsys MagicQ uses Linux, etc, etc.)

sl1200mk2 wrote: -in DL, even in the RPN way, when you're in Group 'mechanism', the next entry will be assign to Group, no matter if you specified it. So i'll be a huge difference between @Mode and RPN if they do not behave equally.

from your example, what happen if user consciously hit Group button for a command, validate by Enter and after press a number? If it goes back to Channel, i think it's a program limitation because when you're on Group control (control is a good word for that purpose - instead of mechanism ), you work that way... hitting Group button each time is no good at all.

we discuss about that because of one number entry that can be assigned to times or whatever by double-clic, but i think we have to find the appropriate behaviour of one number entry in the command line.

Best regards,
Nico

I think that the assumption that it is [Channel] data until otherwise asserted is the right one

Regards,

Colin

Hi guys,


I tend to agree with Colin on this - for me, assuming CH until otherwise specified is not only the expected behaviour from previous consoles, but also preferable, as it is probably the most common tasks to perform - setting a channel.

But, if we follow the analogy of the ETC, there are the illuminated buttons - in a software, that could translate to checkboxes.

So, if the standard (each time you open :Light, no matter what you did) would be a tick next to CH, but there would be options for i.e. group, time in, time our... than a simple click could change the behaviour.

Now, if someone would simply preface a command by "Group" (not checking the check box, but using the short cut or clicking on the group button), then the next command would still assume that the checked standard would be next (i.e. CH).

But if somebody checks "group" up there, the opposite is true - type/click CH, number, AT, intensity, ENTER - in the next command it would assume group automatically.

While that would be (as Colin pointed out) different to what people from the classic LX boards are used to, I think that is a feasible compromise, as if you don't want to use the feature, you don't, and it still behaves the way you are used to (reverting to CH each time).

My 2 cents


Freddy

P.S.:

Also, I had a look at control - I like that it's free, I think the surface is slightly uglier than TouchOSC, but I'd like to try and fiddle - nico, where can I get your file for this software?

Reading over what I wrote, the functionality I describe is more like a set of radio buttons rather than checkboxes. In terms of what is already there, it could look visually like the existing red/green "LED"s that are used i.e. in the setup dialog for things like turning OSC, MIDI, and the DMX devices on/off.

@Colin and Freddy,
i'm agree with you that more current op is to set channel and i don't want to bother user with setting [CH] each time...
In fact we're facing an issue only with [+], [-], [THRU] and [@] commands because only these one can be processed without leading descriptor.
(also just to mention, did you noticed that the 'mechanism' at the top right of DL is changing its aspect whenever you select Channel, Group or Sub? it's a kind of radio button isn't it?)

so here's how it can be:
-number (without leading character) will always be treated as Channel without prepending [CH], like that user that want to double-clic to set times or whatever can do so. if they do so, command line will be erased right after their action.
-[CH], [Group] and <sub>leading character will set the selection control to their domain. if the user validate the command line (i mean if the command line is cleared after validation), next command starting with [+], [-], [THRU] or [@] will behave on the previous selection control mode. if it was [CH], [+] [3] will add the channel 3 to the current channel selection, if it was [Group], [+] [3] will add all channels from the Group 3 to the current channel selection.
-if selection control was [Group] or , for the next command, any number without leading character will set selection control to [Channel]

@Freddy
the layout for Control is in download/utility and it's called dlPad.js

++</sub>

Hi Nico

My twopence worth...

If the first thing you type is a number, nothing is prepended - *but* - if you type '+ (and)', '- (not)', 'thru' or 'at', then DL knows you are setting channels and immediately prepends [CH] to your first number. Obviously, if the first thing you type is 'Group' or 'Sub' or whatever, DL then acts accordingly; and this way, a number without a post-qualifying modifier as above will be useable in any double-click field

Regards

Colin

@Colin,
we are agree, i think this is the good behaviour.
just one more point, do you think it's necessary to prepend [CH] when the first thing in the command line is a number and there's more after?
because i think i can live without... according to what we said *always* a number in first place followed by post-qualifying modifier will be treat as channel, so i don't need to explicitely add one.
of course, users can always type [CH] in the first place if they want.

++

Salut!
I've seen something a bug : because of the @mode you can't anymore access to the step+ with the down arrow key : it opens the rpn/@mode box on the main screen.
I've seen also that you can't anymore have access to the xfade with the mouse! it could be usefull in case of hardware disconnected during the show...
A+
pipou

@pipou,
je vais checker le truc du step+/-

par contre pour le xfade, non, plus d'accès à la souris, c'est trop compliqué (pour moi...) d'arriver à gérer toutes les sources de controle du xfade, donc j'ai viré la souris

++

just to not forget:
-register :Light through Bonjour/Zeroconf network
- add multi-Universe through usb output to be able to use ultraDMX Pro from DMXKing.com
- review artnet edit window : broadcast ArtPoll to 255.255.255.255 - re-enable broadcast option - display node in TableList with checkbox to choose output one

@Nico

sl1200mk2 wrote: @Colin,
we are agree, i think this is the good behaviour.
just one more point, do you think it's necessary to prepend [CH] when the first thing in the command line is a number and there's more after?
because i think i can live without... according to what we said *always* a number in first place followed by post-qualifying modifier will be treat as channel, so i don't need to explicitely add one.
of course, users can always type [CH] in the first place if they want.

++

I think that the [CH] appearing when you type the post-modifier is a good if not necessary thing - it would let you see that you are indeed in channel mode, and this would I suspect be relatively reassuring to newcomers to the software who are used to traditional Command Line style syntax

Regards,

Colin

Salut!
Quelques petits retours :
à propos de ma remarque sur la flèche qui commande la boite RPN/@mode, en fait cela arrive une fois qu'on a cliqué dans cette boite, ce qui la sélectionne d'office et supprime les raccourci haut/bas. La solution est de cliquer dans la zone de texte en haut à droite pour la déselctionner... c'est con mais j'ai mis un moment avant de trouver!
Autre point, et pas des moindre : le Xfade ne fonctionne que dans un sens! la valeur du x2 n'est pas inversée, du coup les 2 sont à FF et la mémoire ne passe pas.
Ensuite j'ai tourné et retourné mon patch dans tous les sens, rien à faire, je n'arrive pas à envoyer le go ni le goback. Je pense que c'est du au module vvvv "OSCencoder" qui envoie l'argument 1 dans une forme que dlight ne comprend pas... mais c'est bizarre, ça marchait très bien sur les versions précédente (et j'envoyais déjà un argument 0/1...) c'est bien emmerdant, en attendant j'ai remplacé les envois OSC par du midi, mais si on pouvais trouver une solution à ce problème, ce serait formlidable. Je rappelle que les fonctions xfade ne fonctionnent pas non plus, par contre accès au grand master et check circ sans probleme.
A+
pipou
(w7 64b, vvvv, nanokontrol, touchosc)