running 2 instances of izzy at once for 2 discrete functions
-
Hey all -
wondering if anyone else is trying to run 2 different systems on the same machine, if it compromises performance, causes bugs, or if it's just fine...
Specifically: I am finding that if I want to control lights and video in a theatre or dance context, I need to trigger scenes / cues at separate times, and given that I already need an active scene for lighting, it makes control extremely complex.
(I haven't had a chance to go deep enough into either javascript or data arrays to enable lighting control by reading from external files, which would be an amazing advancement.)
So: I run 2 instances that don't overlap in function: one for lights and one for video. As long as I keep my midi and go triggers discrete it seems to work, but I still get occasional crashes.
Anyone else?
trevor
-
if your lighting control is all in one scene, you can keep that active whilst you run the rest of the show in other scenes. but i guess you are running through a cue list for your lighting as well, so i would recommend separate machines, rather than 2 instances of Isadora on the same machine.
-
my standard setup consist in Isadora as master program for video, interaction and so on. But lights are on QLC+ (more relible in some way and more important with ready made fixtures). Of course go triggers are given by isadora through loopMIDI that is very very stable and allow you to have the flexibility of Isadora AND the common programming style of QLC+
In my experience for the purpose you described that is the better option
-
What I normally do if I got a theatre job.
- ETC Nomad for Lighting (EOS Family Software) (Since every single technician knows how to operate the lighting board)- Cue based on OSC messages come in Isadora (> Video Out) or when content has been delivered in an other program like (Resolume) I would use Isadora as main control program that sends a OSC message / MIDI message to Resolume.
-
I have run two instances of Isadora simultaneously on many occasions. In fact, it is my preferred method. As you suggest, I use one for control and one for "cues". The advantage of this over just having one scene active in the background is that you can always access the control scene. When you have an active scene in the background, you can't click into it without interrupting the show. Similarly, if you have the control scene active and just trigger activate and deactivate scenes, then you can't actually go into the scene in question without deactivating the control scene.
The other beautiful thing is that broadcast and listeners work between the two instances, so I usually setup a user actor system to trigger jumps from the control instance to the "cues" instance. I can provide more detail if needed.
Craig -
Thanks all for the insights! - and the tips on partner programs for LX control, @Juriaan and @Maximortal. Although familiar with Nomad (well, with ETC boards, and therefore the syntax), I haven't shelled out for it (yet); and I've never heard of QLC+ - something to try
I sometimes run in parallel with Qlab for theatre-friendly sound Q-ing - although that arrangements has its own kinks.
@CraigAlfredson : clever approach to being able to see the "activated" scene in this way!
...so, is "2 instance izzy" is a hack? or just a riskier way of running?
Win10 64bit, i7-7700HQ, 16gb, nVidiaGTX 1060 || MBP M1 max, 64gb, OSX 12.7.2
-
@plastictaxi said:
...so, is "2 instance izzy" is a hack? or just a riskier way of running?
The fact that you are experiencing program crashes probably answers this. I guess we learn our own methods and developments when putting shows together. It is really wonderful that Isadora allows the flexibility for each user to craft a unique system.
Technical theatre operators in my city are still apprehensive about my methods when I work in their theatres. They are unfamiliar and skeptical about a software that controls all the technical aspects of the theatre in one box. One of those concerns is really valid, and that is the question of is the system prone to crash? And how long will it take to reinstate the system when if it does?
If you are using Isadora and experience a program crash, even once, during a public showing in a large theatre it is going to be hard to recover from that in terms of the level of trust and anticipation of risk when approaching the next production.
There are many ways to mitigate the risk, such as assigning a solid black desktop color and setting projectors to a black screen so that you are not suddenly projecting unintended logos and desktop images in front of audiences if Isadora crashes.
I tend to develop total theatre projects where all of the elements interact and it all happens in primary and secondary active scenes within Isadora. I am more inclined to run multiple instances of Isadora on separate computers and network them together. Often I will have a patch on a machine that is focused on audio and running visuals and another machine that is running lighting through a dmx interface and running more visuals. I have used KVM switches to monitor and access each machine but generally building one control interface that can be extended to a wireless controller such as TouchOSC.
But I would say that using Isadora enables great diversity in application that extends far outside the standard formats of technical theatre and well beyond the architecture of the theatre itself.
We may have to accept that with great flexibility we are prone to programming in less stable territory. And it might be that the openness and diversity of valid approaches possible when developing with Isadora is also a reason that it is underestimated and perhaps undervalued by the sector?
I am speculating.
Best wishes
Bonemap
