Simultaneous or queued OSC fault - Izzy does not send all messages.
-
I am running a show with about 70 cues (each with a corresponding scene- I am mixing audio at the same time so I am not looking at Izzy, just programming commands for every scene, mostly controlling other devices but also playing video., all is going OK but then I wanted to add some more OSC to control a bunch of other devices automatically as I enter a scene. So far I have been stacking up OSC MultiTransmits from an enter scene trigger and they are sent fine- these are one off sends of a single value to various addresses. As I needed to run a fader (stupid setup but i wanted to control my blackmagic ATEM from one of the faders of a soundcraft SI performer digital audio desk so I had everything in front of me). I did the required stupidity outside of Izzy to get the communication going and then got midi from the fader into Izzy and sent OSC out to my ATEM. All was OK, but I noticed that when I had this setup in a scene none of the one off triggers would fire, but the fader would be active.
I went a bit mad tracking the fault (I wish Izzy had a breakpoint debugger!), and realised when the continuously updated OSC was running Izzy would miss the one off cues, even though the one off related actors were above and to the right of the continuous sender (this is the processing order right?).I could not put a gate on the continuous sender as that meant my fader position was wrong and I got a jump in my fades, putting a delay of more than half a second worked, but these one off commands were to set the preview and program outputs of the ATEM so obviously that was also not possible as I would be fading on last scenes IO settings.I would be great to smooth these things out. I have not used Izzy for a job for a while and when I get down to little details things get a bit hazy- the video playback is now smooth as silk, this is great, but these simple details make it a pain. I am sure there is probably another way to do this, and I maybe this is bad programming but it follows the logic of Izzy intuitively. The execution order of actions is really finicky for fine timing, I find I am using hundreds of trigger delays just to let the system know what things should happen in which order. As I mentioned a debugger that lets you step through the execution order would help, but I somehow feel like the execution order is not reliable as one in 20 the setup I had to excavate worked.... -
Can you enter a support request?I would like to see your patch, and try to emulate the number of OSC messages locally.
