@dillthekraut Thank a lot ! That would have been what I would have done (more or less) but I was in a production so I didn't have time and resources to test it in that way. I'll definitely look into it and report it here as soon as I can. Interesting case
@mark_m Ahah same thing happening to me ! As I'm trying to push more and more of our live events over to Isadora (We mostly use Watchout and/or Disguise on larger productions) but for most corporate gigs, of all sizes, I would say 95% of them would be abundantly well-served with Isadora. But the last standing blockade is always the redundancy. Now @Woland created this ingenious way for me to solidly implement Isadora as a totally viable, relevant solution throughout our operations.
I just want to say what valuable and important work this is: I recently lost an Isadora vs Disguise argument on a production, on the very basis that Isadora didn't have a built-in automatic fallover the way that Disguise systems do. I would rather program in Isadora than Disguise, and if I can demonstrate this kind of redundancy I wouldn't lost these arguments again :-)
@bonami said:
I'm navigating your patch at the moment.
My pleasure, and thank you for prompting me to make it. I hope it will be helpful to you and others. Let me know if you have any questions as I'd be happy to answer them. I also hope I'll be able to find the time to finish the file soon...
Oh my god Woland ! Ahah this is absolutely above my expectations ! Your first answer was already very clever, I was not expecting such a detailed Izz file on top of it ! I'm navigating your patch at the moment. I had, in the meantime, created something along those lines after your reply, but nowhere near as automatic, complete, and conceptually mature as the file you provided. I'm glad I can learn from your reflexions throughout your patch. Thanks again, really.
Thank you very much Fred! I agree that step by step is the best option to learn. And small-scale simulation is an excellent way to better understand the sensing and processing processes for creating visuals.
Big hug,
Maxi-RIL
Not only that but they use the Resolume API heavily / have auth with their license server.
@dusx said:
<p>Resolume changed the FFGLs used in their software sometime ago making them both better integrated and proprietary.</p>
Well, there ya go.
H
@woland said:
I'm already working on an example file for you, but here's a basic explanation of what's coming:
Sorry, I got swamped during the week. Here's what I have so far:
redundancy-heartbeat-switch-2024-02-15-3.2.6.izz
What's really neat is I figured out a way to just use the same patch on both the leader and follower computers with zero configuration in terms of telling which one you want to be the leader and the follower. Here's the basics of how it works:
- Launch the patch on the Leader computer.
- The patch checks whether or not there's a heartbeat from a Leader.
- The patch doesn't see a heartbeat already, so it knows it's supposed to become the Leader.
- The patch, running on the Leader computer, starts sending out a heartbeat.
- Launch the patch on the Follower computer.
- The patch checks whether or not there's a heartbeat from a Leader.
- The patch sees a heartbeat, so it knows it's supposed to become a follower.
- The patch, running on the Follower computer, starts operating as a follower.
- If the heartbeat from the Leader computer stops, the patch, running on the Follower computer, will automatically become the Leader and start sending a heartbeat.
- At this point, you could re-launch the patch on the original Leader computer and it would see the heartbeat and automatically start operating as a Follower.
It's totally up to you what to trigger when the switch from Leader to Follower happens, but I got pretty far in creating a mechanism for the heartbeat and triggering the passing of the baton if the Leader's heartbeat stops.