jhdkfj39929

I am new to Jitter and Max, so please excuse the basic questions...

I need to set up an exhibition that will feature several screens positioned around the room. All screen will show different portions of one still image scrolling horizontally, as if it is a continuous loop.

I have four Windows machines for the purpose and for simplicity can set the screens to run the same resolution, say 1280x1024. So, the still image will be pretty large - 5120x1024. The machines are on the TCP4 network.

Can you please give me an idea on how to go about it and point to the sample patches implementing something similar if they exist.

Any general considerations are also very welcome. For example on how to develop it on one computer first, before engaging with the network issues...

jitter-across-multiple-computers

That's a pretty big question, so it's hard to answer simply, but it doesn't sound too hard. I just wouldn't try and send an image over a network..it's far easier to send control data.

You would need one patch on each computer that just used jit.rota and then you could send udp from one computer that you consider to be the master. For this you could either use udpsend or jit.net.send..i consider udpsend to be easier.

From this master patch you would just send different offset values to each of the computers over udp, the trick would be just getting the math right to make sure they're all looping at the right point..but you probably want to send all of that information from one computer.

Basically you would want a counter run by a metro that just does an offset for each one, so:

Master computer starts at 0 and goes to 1 (aka 5120..your width)

2nd computer starts at .25 and goes around to .25 again

but this would be easy..you would just add the .25,.5 and .75 of the total width to the counter on the master that is running the from 0 to 5120

Try giving that a shot and post a patch when you get stuck

Master computer starts at 0 and goes to 1 (aka 5120..your width)
2nd computer starts at .25 and goes around to .25 again
3rd starts at .5 goes around to .5
4th starts at .75 and goes around to .75
but this would be easy..you would just add the .25,.5 and .75 of the total width to the counter on the master that is running the from 0 to 5120

Try giving that a shot and post a patch when you get stuck


Thank you for the initial suggestions. I shall give it a go.

Will keeping the images synchronized be a problem? Due to network latency, etc?

A wired network should easily be fast enough (depending on your frame rate - I'm assuming a frame rate of around 30fps and I've been involved in a production using networking to sync 5 videos - it wasn't in Max, but the technology was very similar and it wasn't an issue).

What I would advise however, is that whatever you send over the network should represent the current position in the loop, rather than just a metro clock. This way, if you lose network connection for a frame or two, or have to restart a computer or whatever, your piece will still stay in sync. In the production in question this was the type of system we used and the computers were setup to reboot if there was a crash. On one of the nights something went awry and one screen went down briefly. Once the restart was complete the patch was reloaded and the video continued in exact frame sync. In this case multiple screens were at times displaying identical video, so any timing discrepancy would have been very obvious to spot.

You should have a look at the cosm lib, it allows to synchronize different point of vue of the same scene among several computers - not sure it is available for windows.

This sounds quite similar to several projects I recently worked on. One pointer I can give you is that if you're dealing with 4 screens and have any flexibility equipment-wise, I would get one powerful machine with a dual monitor gfx card and a matrox triplehead2go, and simply output all 4 from one machine, using a single render context. This is totally doable unless you have a lot of processing running over each video. You'd be saving a lot of time, money and frustration, totally eliminating the need for network communications not to mention tons of extra hardware.

Having said that, it's very possible to sync quite a lot of machines providing you have a reliable sync signal- I'd recommend using an msp signal to drive it all. In terms of simulation, what I did to simulate the system on one computer was to break it up into a master sync patch, and named client patches with a switch controlling whether they communicate locally or through the network- this way you can instantiate several client patches on the same machine as the master patch. It's good for testing some aspects but of course the network itself does add some complications you'll need to test separately.

This sounds quite similar to several projects I recently worked on. One pointer I can give you is that if you're dealing with 4 screens and have any flexibility equipment-wise, I would get one powerful machine with a dual monitor gfx card and a matrox triplehead2go, and simply output all 4 from one machine, using a single render context. This is totally doable unless you have a lot of processing running over each video. You'd be saving a lot of time, money and frustration, totally eliminating the need for network communications not to mention tons of extra hardware. 

Having said that, it's very possible to sync quite a lot of machines providing you have a reliable sync signal- I'd recommend using an msp signal to drive it all. In terms of simulation, what I did to simulate the system on one computer was to break it up into a master sync patch, and named client patches with a switch controlling whether they communicate locally or through the network- this way you can instantiate several client patches on the same machine as the master patch. It's good for testing some aspects but of course the network itself does add some complications you'll need to test separately.


Thank you for the suggestions everyone. We cannot buy new equipment. But have a few fairly powerful machines already. So, they will have to do.

I guess I shall try to build it for two screens of one card first and take it from there.

https://cycling74.com/forums/1600x1200-horizontal-continuous-scrolling-panorama

Even though in my tests this is jerky from time to time even if it runs at 60fps on my laptop. Do you think cpuclock they are discussing (but that does not seem to be implemented) will help?

I would also be curious to know if there are better approaches given that the discussion in that thread is 4 years old.

Then I will need to add a facility to pick images from a pool.

Then to add varying zooms selected in relationship to image sizes and other characteristics...

Just wanted to point out that I started another thread on trying to do it without networking first. Suggestions are welcome as I am finding it hard to get into.

https://cycling74.com/forums/scrolling-multiple-images

Jitter across multiple computers