Smartfade Midi bug

I have a smartfade that is being triggered by midi from qlab. There is a very nasty bug. When a midi go is sent when a fade is running the fade will jump in without fading, as will every subsequant q until the desk is turned off and on again. It would be best if the midi  go exhibited the same behavoir as the go button where a cue will fade from where it has got to if the go button is pressed when a fade is running.

Can this be rectified?

Thanks

Roger

Parents
  • On further investigation there are a number of issues. The problem is with the MSC go implementation not with the Midi program change 125 go implementation. MSC go works fine as long as there is not a fade running at the time the go is sent. If a fade is running the implemtation has some very bad behavior. when the go button is pressed or a Midi program change 125 go is sent, the current fade stops, the the current state goes into the out fade, the new state goes into the in fade and the new fade starts. when the MSC go is sent, if there is no q number, nothing happens, if there is a q number then the new q is dumped into the in fader without the fade being stopped first and then continues on from midway through the fade. This has the effect of jumping the levels to where they would be at the point in the fade that has been reached. If the previous fade is nearly complete the fade becomes a snap.
    The next issue happens when the new fade occures at the point where the last fade should complete and causes the fade to hang at that point. The fade shows as being complete, and if the rate button is pressed then it shows a time left of 0. At this point it should step over to the next q. Once a q has hung like this then all subsequant qs will snap in and the cross fade will remain hung and not step to the next q.
    The third issue is unrelated to the go problem, but does not help. When the desk is powered down and restarted instead of returning to the point that the desk was in when stopped it will snap to the next q in the stack. Where shutting the desk down fixes the hanging problem with the MSC go implementation it is less than useful that it does not return to the point where it was shut down.
    At this point I have worked out that moving the crossfaders and returning them to the top will complete a q that has hung and step to the next q as it should.
    Would it be possible to fix the MSC go implementation and the desk restart problem?
    Thanks
    Roger
Reply
  • On further investigation there are a number of issues. The problem is with the MSC go implementation not with the Midi program change 125 go implementation. MSC go works fine as long as there is not a fade running at the time the go is sent. If a fade is running the implemtation has some very bad behavior. when the go button is pressed or a Midi program change 125 go is sent, the current fade stops, the the current state goes into the out fade, the new state goes into the in fade and the new fade starts. when the MSC go is sent, if there is no q number, nothing happens, if there is a q number then the new q is dumped into the in fader without the fade being stopped first and then continues on from midway through the fade. This has the effect of jumping the levels to where they would be at the point in the fade that has been reached. If the previous fade is nearly complete the fade becomes a snap.
    The next issue happens when the new fade occures at the point where the last fade should complete and causes the fade to hang at that point. The fade shows as being complete, and if the rate button is pressed then it shows a time left of 0. At this point it should step over to the next q. Once a q has hung like this then all subsequant qs will snap in and the cross fade will remain hung and not step to the next q.
    The third issue is unrelated to the go problem, but does not help. When the desk is powered down and restarted instead of returning to the point that the desk was in when stopped it will snap to the next q in the stack. Where shutting the desk down fixes the hanging problem with the MSC go implementation it is less than useful that it does not return to the point where it was shut down.
    At this point I have worked out that moving the crossfaders and returning them to the top will complete a q that has hung and step to the next q as it should.
    Would it be possible to fix the MSC go implementation and the desk restart problem?
    Thanks
    Roger
Children
Related