@fred 

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

@dusx

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:

1. Launch the patch on the Leader computer.
2. The patch checks whether or not there's a heartbeat from a Leader.
3. The patch doesn't see a heartbeat already, so it knows it's supposed to become the Leader.
4. The patch, running on the Leader computer, starts sending out a heartbeat.
5. Launch the patch on the Follower computer.
6. The patch checks whether or not there's a heartbeat from a Leader.
7. The patch sees a heartbeat, so it knows it's supposed to become a follower.
8. The patch, running on the Follower computer, starts operating as a follower.
9. 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.
10. 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.

@dusx said:

proprietary

@armando

It is difficult to find the real issue from here. I would follow a standard procedure with several test on Network, OS and software level.

two tests which come directly to my mind.

Check the Network connection between the TD PC and the sending Isadora Mac:
In the terminal (MacOS) / Command Window (Win), use the 'ping' command in both directions.
      ping 192.168.10.x

If both work, go to the next step.

Start a different OSC software e.g. isadora on the TD PC, to see if the commands work there. If this is the case, some setting might be wrong in TD or the sending Izzi (like not matching OSC Port #).

I guess I don't need to say, check all settings, especially the sending and receiving port numbers.

Do I get this right:

Mac1 Izzy -> PC TD not working
Mac2 TD -> PC TD working
Mac1 Izzy -> Mac2 TD working

What about Mac2 Izzy -> PC TD?

Mac1 Izzy and Mac2 TD using the exact same OSC sending settings?

My test mentioned above would mean: Mac1 Izzy -> PC Izzy and maybe 

Mac1 Izzy <- PC Izzy

Your are right - i found out why. You have to go into in screen settings you have to go to advanced settings and then and the show all resolutions. After that you will get a list off all resolutions an d you can select the right one...

@em_tx Have you tried to install emu ?

@ Dusx @juriaan @Fred @DillTheKraut. Sorry I just mistyped here in the forum (but not in izzy) Itas 192.168.10.XXX The proof being that the mac with Touchdesigneer was receiving OSC. Fred, thanks as always, I am aware of the carriage return as an invisible character that might render invalid an IP address like a space. But in my case, the mac was receiving the OSC values in Touch. That is why I am sure it must have been something else in the pc network prefs.... I'll give it another go.

@woland said:

Try setting "Display Refresh" (to the right of Target Frame Rate) to "Off"

 Yes, this!