3.0.6_b5

24/7

This release is mainly a bug fix.
It also introduce Midi Show Control protocol as reference here en.wikipedia.org/wiki/MIDI_Show_Control

thank you to everyone who participated.

++
nico

Merki!

@Padbol
t'as essayé le coup de la courbe du GrandMaster (parcequ'il était vraiment sioux celui-là) ?

++

Ca a l'air de marcher, je viens justement de faire les même manip qu'hier et ça ne bug pas, merki!

Il y avait un bug dans une des versions précédente, mais je ne sais pas si c'est corrigé maintenant :

(ça ne s'est produit qu'une fois en spectacle...)

Quand un effet reste trop longtemps en place Dlight semble ne plus tenir compte des temps de montée et descente des effets. Les projos s'allumait, mais "cut" a la fin du timing. Ça m'est arrivé une fois en spectacle, un accueil public resté en place 1h40... Un cas très rare, mais dans le doute depuis j'envoi des effets toutes les 30 minutes... Je peux arrêter maintenant?

Salut, and bravo for 3.0.6_b5

2 questions and some observation:

I sent an MSC 'GO' command from SFX6 *to* DLight, which works fine, but DLight takes no notice of a Cue *Number* - is this going to be implemented? And if it is, will Q Number from SFX6 be *Step* number in DLight, or Q Number?. (Also STOP command?)

If a DLight cue has a WAIT that is running, and receives an MSC STOP, the Wait stops immediately, but the Cue its on then runs its Fade times. Seems counter-intuitive - if you STOP a cue, surely you don't want anything to continue?

Is there a mechanism for attaching MSC commands to DLight cues? If there is to be one, I think it should allow Q LIST as well as Q NUMBER for GO and STOP, because, eg., SFX6 can have many cue lists, and I think you would need to be able to target specific cues in specific list

It's a really good development

Regards,

Colin

MSC 'Resume'

Deux plantages aujourd'hui pendant que je configurais des tablettes MIDI, je t'envoi les logs

Youhouuuuuuuu

@colin

I sent an MSC 'GO' command from SFX6 *to* DLight, which works fine, but DLight takes no notice of a Cue *Number* - is this going to be implemented?

it's implemented.
be sure that your message is ended by 00 at the end of <Q_List> or last byte of message is 0xF7.
can you post here a dissection of your message?

And if it is, will Q Number from SFX6 be *Step* number in DLight, or Q Number?

i understand you question because :Light is more step oriented but no, it's really Q number you need to send

If a DLight cue has a WAIT that is running, and receives an MSC STOP, the Wait stops immediately, but the Cue its on then runs its Fade times. Seems counter-intuitive - if you STOP a cue, surely you don't want anything to continue?

I've interpreted STOP command as Pause in regard of associated RESUME command.
maybe it's a mistake i've made, tell me.

Is there a mechanism for attaching MSC commands to DLight cues?

nope, because there's only one Q list in DL.

It's a really good development

thank you for that and your participation

++

@Padbol
ils va être chiant à tracker celui-là car je l'ai déjà vu passer et je pensais avoir fait le nécessaire avec cette beta.

peut-tu me décrire un peu comment il s'est produit?
est-ce que c'est direct quand t'as assigné le midi? direct quand t'as bougé ton fader?
etc...

++

Les controlleurs midi étaient déjà plugé, j'ai utilisé Dlight toute la journée sans aucun bug.

J'ai reconfiguré le midi en bougeant les fader a chaque fois pour vérifier que ça fonctionnait et au bout d'un moment ça a planté.
Le seul point commun entre les deux plantages c'est que j'étais en train de tester la fonction que je venais d'assigner. Mais ce n'était pas la même, ni le même fader...
Par contre a chaque fois cela s'est produit après plusieurs essais de la fonction, ça n'a pas planté du premier coup.
Demain je réessai, il y a peut être un faux contact dans ma tablettes midi, peu être que Dlight n'aime pas avoir un truc qui disparait et reviens aussi sec...

sl1200mk2 wrote: @colin

I sent an MSC 'GO' command from SFX6 *to* DLight, which works fine, but DLight takes no notice of a Cue *Number* - is this going to be implemented?

it's implemented.
be sure that your message is ended by 00 at the end of <Q_List> or last byte of message is 0xF7.
can you post here a dissection of your message?

If I send eg MSC GO CUE 4 the Sysex is as follows (copy/paste from SFX6)

F0 7F 00 02 01 01 34 00 00 F7

But, eg if the Active Register in DLight is on STEP 1 (contains Q1), the MSC Command GO runs STEP 2 (contains Q2), not STEP 4 (contains Q4)

And if it is, will Q Number from SFX6 be *Step* number in DLight, or Q Number?

i understand you question because :Light is more step oriented but no, it's really Q number you need to send

I explain myself badly; I understand that *SFX6* will send Cue *Number*; but in DLight, STEP 4 may contain CUE 7.5, or CUE 1, or any of the 'CUES' I may have created, which are visible in DISPLAY->CUE; so which which should the GO from SFX fire - STEP No 4, or CUE No 4?

If a DLight cue has a WAIT that is running, and receives an MSC STOP, the Wait stops immediately, but the Cue its on then runs its Fade times. Seems counter-intuitive - if you STOP a cue, surely you don't want anything to continue?

I've interpreted STOP command as Pause in regard of associated RESUME command.
maybe it's a mistake i've made, tell me.

Again I explain badly - if you try this, it will show my meaning. Create Cue 1 (Time 3); Cue 2 (Time 3); Cue 3 (Time 3 Wait 30); Active (Red Register) on Cue 1; Send MSC GO from something; Cue 2 will run over 3 secs, then the Wait on Cue 3 will start; While Wait is still running, send MSC STOP to DLight; Wait will stop immediately, but *Time* on Cue 3 will run as soon as WAIT stops; But if a 'Pause' has been ordered, surely the Q3 Time should *not* run?

Is there a mechanism for attaching MSC commands to DLight cues?

nope, because there's only one Q list in DL.

OK, but then how will DLight command other software with MSC?

It's a really good development

thank you for that and your participation

++

Salut, et bien fait!!

Love the MSC implementation!

My observations so far (the one seems to address what colinc has brought up):

have a sample sho with the following:
Step Q
0 0
1 0.4
2 1
3 2

There are a few odd things that I noted, calling it from QLab. The expected behaviour that I lay out here is what I am used to by boards like the ETC Express, so there might be things that are supposed to run differently - just putting out there what I have experienced :

- when I call a number without decimal point, it calls just whatever is the next step in line as opposed to jumping to the cue number called (here is the sysex for "0.4": F0 7F 03 02 01 01 30 2E 34 F7 ... and here is the sysex for "2" : F0 7F 03 02 01 01 32 F7 )
- when I call a cue while another one is running, it deducts the time that the _old_ cue has already run (ti / to) from the ti and to of the _new_ cue: Example, running cue 0.4 (3 / 3) until 1.7 seconds are left (1.3 elapsed), then firing cue 2.0 (5 / 0), which starts counting down from 3.7 seconds. (I would expect the full ti and to of the _new_ cue to be used, with the crossfade happen from whatever is currently part completed)
- when I STOP a cue mid-run, and then call another (or the same cue) instead of RESUME, the _newly_called_ cue completely forgets its own ti and to, and uses what remains of the ti and to of the _old_ cue.

The rest works great, especially the "race the running cue" by interrupting it with the "step+" command! exactly what will be useful!

Hope this feedback helps

Milles fois merci pour cette, erm, feature !

Freddy

@Colin

If I send eg MSC GO CUE 4 the Sysex is as follows (copy/paste from SFX6)
F0 7F 00 02 01 01 34 00 00 F7
But, eg if the Active Register in DLight is on STEP 1 (contains Q1), the MSC Command GO runs STEP 2 (contains Q2), not STEP 4 (contains Q4)

yep, Freddy also noticed that, i surelly made a mistake for cue without "." inside.

I explain myself badly; I understand that *SFX6* will send Cue *Number*; but in DLight, STEP 4 may contain CUE 7.5, or CUE 1, or any of the 'CUES' I may have created, which are visible in DISPLAY->CUE; so which which should the GO from SFX fire - STEP No 4, or CUE No 4?

if you send Q 4, DL should reach the first step containing Q 4

While Wait is still running, send MSC STOP to DLight; Wait will stop immediately, but *Time* on Cue 3 will run as soon as WAIT stops; But if a 'Pause' has been ordered, surely the Q3 Time should *not* run?

woww, fine bug
i'll fix that for the next one

OK, but then how will DLight command other software with MSC?

that's another point.
i'm thinking of a new parameter for the sequence called "script".
a script is attached to a step and will be able to perform internal or external commands (that include MSC)

++

@Freddy

- when I call a number without decimal point, it calls just whatever is the next step in line as opposed to jumping to the cue number called

my fault, i only did tests with floating points cue...

running cue 0.4 (3 / 3) until 1.7 seconds are left (1.3 elapsed), then firing cue 2.0 (5 / 0), which starts counting down from 3.7 seconds. (I would expect the full ti and to of the _new_ cue to be used, with the crossfade happen from whatever is currently part completed)

you're right, will fix that

- when I STOP a cue mid-run, and then call another (or the same cue) instead of RESUME, the _newly_called_ cue completely forgets its own ti and to, and uses what remains of the ti and to of the _old_ cue.

ok, i'll fix that too.
the newly_called cue should definitely use it's own times


thank you both for your feedbacks.
++

Fantabulous!

And re: MSC coming out of DL - 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.

Any "slave" could ignore all goes that it hasn't got (as we are always talking a specific "GO"). 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).

Actually, this _is_ something I would strongly advise for DL as well (if it is not already implemented):

When acting as the slave,

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.

What do you guys think?