Ideas for closer integration of servers

Hi all on this forum

I am part of the development team for ChamSys Ltd (www.chamsys.co.uk) and we are looking for feed back on ideas for closer integration of video servers and lighting consoles. At PLASA we demonstrated the live retrieval of thumbnails from a video server onto the touch screen of our MagicQ console.
(the images are not stored in the console as some systems do, but requested from the video server when required)

The architecture of our system means we can easily add hardware and software to support any type of fixture. If anybody reading has ideas on a hardware user interface ( in addition to touch screens) or software changes that would improve the control of servers we would appreciate the input to our current project.

Regards

Mac

what kindof protocol do you use?

something really simple? please?
udp?

its a lot easier to manage connectionless packets in this kindof environment.

We do not plan a set of protocols for Video server developers to adopt, rather we are planning on adding both hardware, as a video wing, and software to the lighting console to make control easier. We will then add a software layer to adapt to each video server supplier's mode of operation and interface to try and achieve a consistent working environment.

We have had a number of suggestions and requests for features, and the purpose of this is to involve as many Video server users as possible in defining a versatile product.

On the hardware side a video wing may have a number of extra playback masters as well as an area dedicated to improving the programming / playback of video content.
One example could be to add flying faders or encoders that can be assigned a selected number of parameters (with offset and scaling) that are active when a cue stack is activated, giving manual control or busking during play back. This would not involve the programmer(s), they would remain free for other use. The selected parameters would be assigned in the programmer during programming for use when the cue or cue stack is run.
Another might be to add a set of layer select key switches, to speed up programming.

The system we currently demonstrate uses both UDP and TCP sessions, but as you say sticking to UDP makes coding a lot simpler.

simple things are much more likely to be adopted by a broad range of developers.

for example if you wanted to get thumbnails of video clips stored on the server, then you could send a udp packet as a request, and then i could reply with a thumbnail image, in rgb format - something that fits into a single udp packet of 1536 bytes if possible.

i have implemented getting thumbnail file/folder preview using an http request in v4.

sending an http request to a catalyst host at 192.168.0.5-
http://192.168.0.5:8080/catws/Images/000_001.jpg

will get you a thumbnail of folder 000 file 001

to get other files change the file name

for example folder 5 file 10

http://192.168.0.5:8080/catws/Images/005_010.jpg