Midi Show Control Problem

Hi Richard,

 I don't have answers for you. May I have question about the MSC. I tried to connect two congo with Midi cable & check the MSC box. two consoles' ID set to "1". It doesn't work (check that the Midi cable is OK). 

Have any stuff I need to do?

Can the MSC use with one Congo console and one Express console?

Thanks,

KK Yeung, I'm not sure that what you're trying to do is possible, I don't think the desk sends MIDI Show Control just responds to it.

After some investigation of the problem I'm having, I have a slight correction to the problem.

Say we have two cues,1 & 2 with fade times of 10s each. A GO command to cue one is sent and the cue starts fading normally. At, say, 7 seconds into the fade a GO command for cue 2 is sent the desk will jump to the state of 7 seconds into the fade to cue 2 and then continue the fade normally.

I'm assuming this is incorrect, as I'd expect it to behave like pressing the GO buttom on the main playback, i.e. cue 1 would stop faing and cue 2 would fade in over 10s.

 

richard_cooper:

Say we have two cues,1 & 2 with fade times of 10s each. A GO command to cue one is sent and the cue starts fading normally. At, say, 7 seconds into the fade a GO command for cue 2 is sent the desk will jump to the state of 7 seconds into the fade to cue 2 and then continue the fade normally.

Hi Richard,

If you want to change this behavior, you need to change the cue1 to lookfade in the sequence list. This looks all channels which are changing in cue 1  and they are not affected by the following cue. I use this all the time for dusk till dawn fades on my cyc.

Florian 

Hi Florian,

I'm not sure I'm managing to explain this properly, it's not a cross fade/lock fade thing.

 A bit more investigation reveals that a MSC "Go Cue x" command is similar to a "x GOTO" on the desk. You can see the issue I'm having without using midi. Record two presets in a sequence say 1, channel 1@100% fade time 20s, cue 2 channel 1@0% Channel 2@100%.

Type "1 GOTO" will start the fade, at about 10s channel one will be at about 50%, type "2 GOTO"  channel 1 will snap to zero, channel 2 snaps to 50% and then continues fading up in the remaining 50% of the time.

 I'm sure this can't be correct, well maybe it's correct behavior for the intended use of the GOTO button, but not not of a midi show control GO message. If I do the same on our other desk (520i) via MSC I will get Ch1 getting to 50% in about 10s then when the second go command is sent Ch1 will fade down to 0, from the 50% it had reached, over 20s, whilst Ch2 will fade up in 20s.

Richard 

Hi Florian,

I'm not sure I'm managing to explain this properly, it's not a cross fade/lock fade thing.

 A bit more investigation reveals that a MSC "Go Cue x" command is similar to a "x GOTO" on the desk. You can see the issue I'm having without using midi. Record two presets in a sequence say 1, channel 1@100% fade time 20s, cue 2 channel 1@0% Channel 2@100%.

Type "1 GOTO" will start the fade, at about 10s channel one will be at about 50%, type "2 GOTO"  channel 1 will snap to zero, channel 2 snaps to 50% and then continues fading up in the remaining 50% of the time.

 I'm sure this can't be correct, well maybe it's correct behavior for the intended use of the GOTO button, but not not of a midi show control GO message. If I do the same on our other desk (520i) via MSC I will get Ch1 getting to 50% in about 10s then when the second go command is sent Ch1 will fade down to 0, from the 50% it had reached, over 20s, whilst Ch2 will fade up in 20s.

Richard 

I understand your problem now. You are correct in that Go Cue x actually makes a # GOTO on the Congo. This is how it is currently implemented.

We should probably consider changing the behavior of the Go Cue x to allow for a Go Ahead (starting the next fade on top of the existing one in a smooth way). Currently, this isn't possible.

Anders,

Thanks for the reply. I definitely think the behavior of the Go Cue x command needs looking at, as in its current form it makes MSC rather unpredictable in a live setting.

Just out of interest, I'm trying to work out the rational behind how the x GOTO command behaves in this instance? It seems to be of no benefit for GOTO to behave in this manner.

Thanks

Richard 

I agree that we should consider changing the basic behaviour of GOTO (which would "fix" the Go Cue x problem as well). I cannot see the rational behind it skipping ongoing cues.