"Jumping" Cues with MIDI control bug?

Hello,

Since we cannot thus far get our console to respond to MSC only, we are using two Program changes to set and fire the cue. While cumbersome, it does work until you want to "jump" a cue, i.e. interrupt a running cue and jump to the next (or any) cue. For example, I may have a long sunrise cue (Cue 5) that I have intentionally written to take longer than scene. I then want to take a slow fade (Cue 6) whenever the actors finish the scene, which will always be before Cue 5 completes.

So, to start cue 5 I will send Program Change 4, followed instantly by Program Change 125 (GO)

When it is time to jump to cue 6, I should be able to send Program Change 5 followed by Program Change 125

I would expect for the console to immediately take Cue 6, (as all other ETC consoles I've used do), or to ignore the GO entirely. Instead, it jumps to Cue 6 being in the Live slot (without actually taking the cue) and GO'S onto Cue 7.

Where this behavior really becomes a problem is if the operator jumps a cue inadvertently, and ends up a cue ahead in the stack without knowing it.

Is this a bug, or is it a designed behavior?

Thanks,

Parents

Anders Ekvall over 14 years ago

Using Program Change Jump+GO commands like this during ongoing crossfades is a bit problematic. It isn't really designed for this.

Regarding the non-working MSC function: What software version do you have in your console? MSC sounds like the proper solution in this case.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Reply

Anders Ekvall over 14 years ago

Using Program Change Jump+GO commands like this during ongoing crossfades is a bit problematic. It isn't really designed for this.

Regarding the non-working MSC function: What software version do you have in your console? MSC sounds like the proper solution in this case.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Children

newsound over 14 years ago in reply to Anders Ekvall

Console software is 2.0.1.9.0.8 - reloaded today.

I agree that MSC should solve this, and we would really like to get it working.

Also, is there any way to have the MIDI Out also act as a MIDI Thru (as most devices without dedicated Thru's do? I was under the impression that this was part of the MIDI spec.) (Or should I start a new topic for that question?)

Thanks,

El
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
Anders Ekvall over 14 years ago in reply to newsound

Unfortunately, it is not possible to get MIDI Out to act as a MIDI Thru (this isn't a part of the MIDI standard). We have considered it but decided that it would make the configuration of the small consoles like SF and SFML unnecessary complicated. Now it is very straight-forward and there is no risk of getting into a loopback situation.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
newsound over 14 years ago in reply to Anders Ekvall

Ok, thanks for the information on the thru. Makes sense I guess.

Since the MSC issue doesn't look like it will be resolved soon, is there any way to fix the double GO described originally?

Thanks for your help,

El
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
Anders Ekvall over 14 years ago in reply to newsound

The problem with the double GO will have to go through the same testing and release process. There is no workaround, except to avoid sending these commands while a crossfade is running.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel