3.0.6_b5

a fair start could be just sending the current cue number as general MSC GO <specific cue> that is loaded/xfaded into x1, and in any "slave" program do the "maths" (exact sequence) of what to do.

yep that's a start.
for example:
s0 q1
s1 q3 ---- X1
s2 q4 ---- X2
s3 q6

let's say q3 in in red register, a Go command in DL can send MSC GO Q4

IF we use outgoing DL MSC, then it would be highly advisable (and, once again, industry standard à la ETC Express) to set an incoming and an outgoing MSC device id; if you really choose so, you can set them to the same, but in some scenarios it's vital to have them separate (just to avoid confusion).

we can also you the broadcast byte 0x7F. usefull for example when 2 or 3 software/devices are aware of DL midi speech

Unless a _generic_ GO is called (without <specific cue> parameter), it should only ever react IF it has the specific cue that is called, not perform a generic GO.

this is the limit of my english knowledge... i don't understand -it should only ever react-

what i understand is that you think that DL should not respond to MSC GO unless there's a Q number specified.
if so, can you explain me why? (and does Colin is agree with that?)

++

sl1200mk2 wrote: yep that's a start.
for example:
s0 q1
s1 q3 ---- X1
s2 q4 ---- X2
s3 q6

let's say q3 in in red register, a Go command in DL can send MSC GO Q4

agreed.

sl1200mk2 wrote: we can also you the broadcast byte 0x7F. usefull for example when 2 or 3 software/devices are aware of DL midi speech

as an option, yes. I believe, that would simply be 127 in the field (or 0? but I think that might be an actual specific id, 0...)

sl1200mk2 wrote: this is the limit of my english knowledge... i don't understand -it should only ever react-

what i understand is that you think that DL should not respond to MSC GO unless there's a Q number specified.
if so, can you explain me why? (and does Colin is agree with that?)

Misunderstanding, I think - my fault

Here is what I said in examples:

DL receives:
- Case 1: GO. SO, DL performes xfade on whatever is in X2
- Case 2: GO LX 1.2 ; DL _has_ LX 1.2 in its lists. SO, it loads LX 1.2 into X2 and performes xfade
- Case 3: GO LX 2.4 ; DL _has not_ LX 2.4 in its lists. SO, it should not do _anything_. It should _not_ perform a generic GO on whatever is in X2.


....

I think . Better not bring the wrong lighting state up, rather do nothing.

@Freddy

sl1200mk2 écrit:

we can also you the broadcast byte 0x7F. usefull for example when 2 or 3 software/devices are aware of DL midi speech

as an option, yes. I believe, that would simply be 127 in the field (or 0? but I think that might be an actual specific id, 0...)

0x7F wich is broadcast hexa code is 247 in base 10.
that means we do not associate outgoing message to ingoing ones.
i'll first try to broadcast outgoing message from DL

DL receives:
- Case 1: GO. SO, DL performes xfade on whatever is in X2
- Case 2: GO LX 1.2 ; DL _has_ LX 1.2 in its lists. SO, it loads LX 1.2 into X2 and performes xfade
- Case 3: GO LX 2.4 ; DL _has not_ LX 2.4 in its lists. SO, it should not do _anything_. It should _not_ perform a generic GO on whatever is in X2.

agreed, i've modified things for the non floating points Q and scenario you've described is the actual one

++

flk wrote:

sl1200mk2 wrote: yep that's a start.
for example:
s0 q1
s1 q3 ---- X1
s2 q4 ---- X2
s3 q6

let's say q3 in in red register, a Go command in DL can send MSC GO Q4

agreed.

I disagree

I think your 'Script' parameter for a step is the best method. DL should *not* send a generic GO. You have much less control over what you want to happen if you have worry about what the GO will do.

If possible, the new parameter field would offer

1) a drop-down to select 'type' of script (eg MSC, Other Sysex, Telnet, Serial, whatever)

2 If eg MSC is selected, then a seies of Drop-downs to select eg Device ID, Commands, Cue Number, etc. That way, people who are less 'MIDI-savvy don't have to worry tto much about writing Sysex.

(I will try and attach a screenshot from SFX MSC Cue proprties window to show what I mean)

Best wishes,

Colin

sl1200mk2 wrote: @Freddy

sl1200mk2 écrit:

DL receives:
- Case 1: GO. SO, DL performes xfade on whatever is in X2
- Case 2: GO LX 1.2 ; DL _has_ LX 1.2 in its lists. SO, it loads LX 1.2 into X2 and performes xfade
- Case 3: GO LX 2.4 ; DL _has not_ LX 2.4 in its lists. SO, it should not do _anything_. It should _not_ perform a generic GO on whatever is in X2.

agreed, i've modified things for the non floating points Q and scenario you've described is the actual one

++

OK - question - what happens in Case 3 if/wnen you use eg Q 2.4 several times in later steps...? :S

Best wishes,

Colin

@Colin
that's incredible how both Qlab and SFX are similar....
happily :Light is crossplatform and no one can fork it

I think your 'Script' parameter for a step is the best method. DL should *not* send a generic GO. You have much less control over what you want to happen if you have worry about what the GO will do.

'Script' is a plan for future. how near, i cannot tell... but i agree that with such function, it's much more cleaner than spreading GO all around the world.

if both of you are ok to wait the 'script' functionnality, i'll pass on the outgoing MSC message for now

colinc wrote:

sl1200mk2 wrote: @Freddy

sl1200mk2 écrit:

DL receives:
- Case 1: GO. SO, DL performes xfade on whatever is in X2
- Case 2: GO LX 1.2 ; DL _has_ LX 1.2 in its lists. SO, it loads LX 1.2 into X2 and performes xfade
- Case 3: GO LX 2.4 ; DL _has not_ LX 2.4 in its lists. SO, it should not do _anything_. It should _not_ perform a generic GO on whatever is in X2.

agreed, i've modified things for the non floating points Q and scenario you've described is the actual one

++

OK - question - what happens in Case 3 if/wnen you use eg Q 2.4 several times in later steps...? :S
Colin

the first one will be used.
moreover, it's a capabilitie of :Light to be able to load same cue several times, but it's a bad practice as Q Number is the most use 'sequential way'.

i initialy thought it could change but from what i saw, i was wrong.

++

OK - question - what happens in Case 3 if/wnen you use eg Q 2.4 several times in later steps...? :S

Best wishes,

Colin

the first one will be used.
moreover, it's a capabilitie of :Light to be able to load same cue several times, but it's a bad practice as Q Number is the most use 'sequential way'.

i initialy thought it could change but from what i saw, i was wrong.

Well, I would assume that the cue number is unique across the whole list, or is it not?

- as in, even if the same cue number would appear as a later step, it would be the _same_ cue, right?
I mean, you couldn't program two different cues with the same cue number in DL, right?

'Script' is a plan for future. how near, i cannot tell... but i agree that with such function, it's much more cleaner than spreading GO all around the world.

if both of you are ok to wait the 'script' functionnality, i'll pass on the outgoing MSC message for now

Yes, happy to pass that on for now ... In fact, I believe in "one way" when it comes to my shows, and QLab being the master program; It's just more logical that way, as it does control sound _and_ av, plus can do applescripts, as well as sending MIDI and MSC cues... ... so DL would definitely be... erm... my slave ;P

And thus, just really do what you feel like on the "sending" issues.

0x7F wich is broadcast hexa code is 247 in base 10.
that means we do not associate outgoing message to ingoing ones.
i'll first try to broadcast outgoing message from DL

I thought 7F is 7 times 16 plus 15 (F) = 127 ?


Anyway, really like where this is going...

Freddy

@Freddy,

Well, I would assume that the cue number is unique across the whole list, or is it not?

yes, a Q number is unique
i guess that issue Colin wanted to emerge is when the same cue is loaded several time in the sequence.
in that case, the first step where desired cue appears will be processed

I thought 7F is 7 times 16 plus 15 (F) = 127 ?

absofuckinglutely, my mistake, i've computed F7.

++

ok guys,
in the Download/Alpha section, i've putted a snapshot of what can be 3.0.6 if you all are agree.

@Colin && Freddy
can you please test all the MSC stuff

@Padbol
est-ce que tu peux essayer les trucs Midi du xfade

thank you for your participation,

++
nicolas

J'ai justement eu un plantage hier, en passant un effet en manuel.

Les deux fader (vert et rouge) bougeait en même temps (avec les même valeurs)
Dlight a planté en arrivant en bout de course je crois.

Je test la nouvelle version c'est aprem'

Avec la dernière 3.0.6, celle dans la catégorie Alpha, le Xfade manuel (avec l'utilisation de deux fader sur mon korg) ne fonctionne plus... Arrivé en bout de course c'est l'effet initial qui se remet en place, pas le suivant.

Et si je "rattrape" un effet lancé, Dlight perds la tête, les fader ne fonctionne plus de façon cohérente. Le Xfader reste bloqué sur le chiffre a partir duquel j'ai pris la main.
Dlight ne plante pas, par contre

Le bug de la 3.0.6 B5 c'etait : Dlight plante en fait de course quand on reprend un effet en manuel.

Bon courage!

En pièce jointe : Le crash de la 3.0.6 B5

sl1200mk2 wrote: ok guys,
in the Download/Alpha section, i've putted a snapshot of what can be 3.0.6 if you all are agree.

@Colin && Freddy
can you please test all the MSC stuff

@Padbol
est-ce que tu peux essayer les trucs Midi du xfade

thank you for your participation,

++
nicolas

Hi Nicolas,

I've installed the 3.0.6 Alpha. Observations:

The STOP and RESUME commands work as they should, ie STOP on a cue with WAIT pauses Wait and does not run TI/TO, and RESUME restarts Wait; further STOP/RESUME command do properly, and STOP/RESUME on TI/TO work as they should;

The GO Q Number(Integer) and Q Number (Decimal) work ok

BUT - In SFX6, a GO with *no* cue number *does not work*

In SFX6, a GO with *no* cue number looks like this:

F0 7F 00 02 01 01 00 00 F7
^^^^^
ie, it insists on putting in the two delimiting 00's (which are used when specifying CUE LIST or CUE PATH), and DL will not accept this - it will only accept F0 7F 00 02 01 01 F7 (I tested with Bome's SendSX). I know DL does not have this, but would you allow the MSC command set for DL to accept these delimiters please. (When using SFX6 with hardware consoles, I sometimes don't put cue numbers into MSC GO commands as consoles can start numbering differently, or not allow point cues)

Otherwise, it's looking good...

Regards,

Colin

@Padbol,
oups....,
je viens de reposter une version pour MacOS dans Alpha, peux-tu l'essayer?

@Colin
thank you for your hints, i'll check why it behave like that
you'll have to wait a little bit for the windows installer (i think later in the day), i'll let you know