​Simultaneous command threshold?

[kdobbe]

Hi All:

I am currently in the midst of a run of Jesus Chris Superstar where the 4 projectors and 5 robotic cameras are all controlled through Izzy via the light board operator.  I am using the MIDI Show control watcher to "watch" for the some 200 cues.  Here's the question:

On occasion... very irregularly with no pattern that I can detect, a cue will not fire.

My Izzy architecture I incorporated had a separate actor that watched for a certain Q and then did a Jump++ with a respective fade.  That mean almost 200 actors respond simultaneously to the MIDI-In from the light board.  IS THERE a MAXIMUM threshold of the number of simultaneous events that might be causing this irregular "non-fire"?  I certainly would build a delay trigger into some of the actors as to reduce or remove simultaneous processing.

Just wondering if anyone has experienced a similar situation.

Regards,

Kevin

Rochester, MN

[Michel]

@kdobbe

what is your connection from the lighting board to the computer?

Best Michel

[Woland]

@kdobbe said:

On occasion... very irregularly with no pattern that I can detect, a cue will not fire.

I've run into something similar before and what it turned out to be was that we were trying to send two MSC commands at the same time which the MIDI pipeline just couldn't handle so it just "picked" one. If two devices on your MIDI network are sending at the same time, one will be ignored and one will be properly executed. Are you also triggering the light board with MSC from anywhere, returning MSC data from Isadora, or sending MSC with QLab or anything like that? 

I'd also be happy to take a look at your Patch if you'd like to create a support ticket using the link in my signature. My workflow often involves triggering Isadora/QLab/ETC lighting console(s) via MSC so I might be able to figure out what's happening by looking at the Patch itself.

Best wishes,

Woland

[kdobbe]

The midi interface I’m using is a MOTU USB based… 

[kdobbe]

Theater has a Hog lightboard… With a  USB midi interface  out… Going to my MOTU midi in.  

Thank you… I will upload just the Izzy file for you to look at… As there are 110 GB worth of media I’m sure you don’t want to download  

[kdobbe]

@woland

I am unable to upload to the link provided as the Izzy file alone is 250 MB.  I cut the number of scenes from 200 to about 20 and the file is still 56MB and beyond the limit size set on the upload link provided.

[kdobbe]

@woland

BTW... yes to your question.  A MIDI Show control number when matched will do a "Jump" but will on some scenes send an MIDI message OUT to my Roland Video Mixer to do a camera preset for the following scene.  

Perhaps the answer is to do a simple delay of perhaps .2 sec and resend?

[Woland]

@kdobbe said:

BTW... yes to your question.  A MIDI Show control number when matched will do a "Jump" but will on some scenes send an MIDI message OUT to my Roland Video Mixer to do a camera preset for the following scene.  Perhaps the answer is to do a simple delay of perhaps .2 sec and resend?

I'd say this is the most likely culprit. Simultaneous and near-simultaneous sending of MSC data from multiple sources was the root of the issue I encountered on my production. It'd be better to have the light board sending MIDI Out to everything so that you only have one source. One source sending to multiple destinations works fine, multiple sources attempting to send simultaneously (or near simultaneously) to multiple destinations is where I hit snags in the past.

Try the Trigger Delay, but you may also want to see if there's a different way that you can go about triggering your Video Mixer if you still encounter issues (e.g. triggering it from the light board or via some other communication protocol).

Best wishes,

Woland

[barneybroomer]

I would always use a 8x8 midi unit for this. Port 1 to the lights, Port 2 to the Roland. Furthermore MSC controls are rather long , so yes sending 2 will cause problems. I don't know how Izzy would handle timing over 2 actors , sended out over 2 separate midi ports.

[kdobbe]

Thanks for the replies all.  MIDI is certainly what might have caused the arbitrary issues.  But my original question is still unknown to me.  

I had about 200 different scenes.  So my set up was to have an actor that had about 200 Show Control watchers incorporating if/then's looking for each specific board output.  So, Izzy then has to go through 120 if/then's and if matched a "true"; it would then "jump".  My question still remains: "Is there a maximum threshold of simultaneous commands that Izzy will process before a potential irregularity?"

My symptoms were that only on occasion, at different points of the show, the Show Control output of the light board was not recognized.  I do realize that the MIDI part of my patch might have been involved, but the question still remains... is there an issue with Izzy executing an unusually large number of simultaneous if/then show controls?  

Just wondering for future projects...

[Woland]

@kdobbe said:

is there an issue with Izzy executing an unusually large number of simultaneous if/then show controls?  

I think the only way for us to know this for sure would be to very closely monitor MIDI traffic in a live environment and identify places where the board sent MSC and Isadora didn't fire and see whether or not that message actually arrived and was received by Isadora. Kind of impractical. Also, as I mentioned before, if you have multiple devices sending MSC simultaneously or near-simultaneously, I have seen issues arise (not just with Isadora, but with a system that incorporated a QLab computer, two Isadora computers, and an ETC Ion).

Really I'd just suggest using a background Scene and/or a single user actor and the JumpByName plugin to control Scene Jumps so that you're only ever doing one or two if/then comparisons rather than hundreds. See my system for MSC cueing doing exactly this: https://community.troikatronix.com/topic/5543/midi-show-control-scene-navigation-cueing-system

There's always more than one way to skin a cat in Isadora, so if an approach is causing problems (or seems like it might be causing problems) I always try exploring alternative methods within Isadora to accomplish the same thing or tweak my original approach in various ways to see if I can find a way that works better.

[DusX]

@kdobbe

If you system isn't stressed (meaning your cycles rate is at least double your framerate), many logic operations like this shouldn't be a problem.
With that said, 200 Show Control Watchers is probably not the most efficient approach. Its much faster to collect the show control data once (at least for every variety of input settings), and then process all the Comparitors (hundreds if needed) to that 1 set of data.
If you are concerned about the number of links you would have to connect, you could Broadcast the Show Control Watchers outputs with the Broadcaster, and pick up the values where ever needed with the Listener actors.
Isadora is runs all these operations very quickly. It is very unlikely that if/then type logic would cause any slowdown.
Keep an eye on your cycles, this will tell you if your processing is getting heavy.

[Woland]

@dusx said:

If you are concerned about the number of links you would have to connect, you could Broadcast the Show Control Watchers outputs with the Broadcaster, and pick up the values where ever needed with the Listener actors.

 This is essentially what my template does, for the record.