3 computers, 1 console: sync'd HD playback.

| No Comments | No TrackBacks
 

the internal wiring of the console in progress...


This was a glacial project, fraught with loose ends.  There was to be a 16 button interface console, all with feedback, controlling 3 sync'd HD video servers.  Well, once again, we turned mac minis into servers...

ISSUE 1:  Memory leak! 

The beta application would crash hours after launching.  As standard protocol, i tweaked the code and assumed that i was debugging ID10T errors.  But as time went by, it was clear that the app was sucking up ram with each new movie--never clearing out the memory.  The jitter object responsible was jit.qt.movie--specifically with direct to window playback.    Fortunately, the people at Cycling '74 are super awesome.  I posted a test patch as proof of a memory leak, which was then quickly confirmed by the developers.  They provided me a work around, and then we were on our way.  As for max/msp/jitter, the next revision eliminated this bug.

ISSUE 2: Erratic Triggering!

The Phidgets 0/16/16 I/O board was not playing well.  Everytime the status of one button would change, it would send a quick hit to the rest of the buttons, even though the input led's for those buttons remained off!   In effect, a debounce structure had to be built in.  i suppose its not really an issue.  standard fare.  though, getting this structure built involved the phidgets object crashing max/msp endlessly.  

grab1.tif
an rudimentary incorrect sync calculation

ISSUE 3:  No sync!

The content was delivered in several releases.  All were encoded differently.  This severely effected the quality of sync as the movies all had differing time bases.  Two identical movies may have had the same fps and duration, but QT would see one as slightly longer than the other.   i ended up re-writing the control structure in the midnight pre-release hours--adding a udp sync pulse with one machine as master and the other two as slaves.  It probably should have been done this way from the beginning, but in my dev tests, everything worked perfectly without it.  But in the tests, the content was encoded uniformly.

The rest:

Wiring up the console was really fun!  It may seem humdrum, but the task of terminating a whole mess of cable in a logical fashion is rather relaxing; it gives a sense of craftsmanship.  No soldering on this job, all crimping and terminals.  The main cabling itself is also done in telecom-style wire-harness lacing.  This is elegant, better for the environment and less likely to induce zip-tie cuts on the hands.  As this project was mostly finished, then mothballed, then brought back out, i was sure happy that all of the wires were labeled correctly when it came time to terminate them into the main board.  always label everything!

The hap buttons contain old school lamp bulbs.  The buttons are disabled when the initial selection is made by killing the sample rate to the phidgets board.  The supply voltage is also killed as a double redundancy lockout to prevent anyone from "confusing the system."  They blink when the selected video is playing and get slightly warm.  In total, the buttons draw around 4 amps of current; future plans involve swapping in low-current LED's to reduce load, heat, etc.

The triggers are distributed to the minis via the built in network service of the phidgets max/msp object.  

The audio, eh, whatever.  standard stuff:  3 unbalanced & summed signals passed through a compressor and then to a networked amplifier.

Lastly, and isn't it always the case, i would do this differently if I were to do it again!



Enhanced by Zemanta

No TrackBacks

TrackBack URL: http://www.imlichenit.com/cgi-bin/mt/mt-tb.cgi/9

Leave a comment

About this Entry

This page contains a single entry by admin published on February 2, 2011 11:43 PM.

max/msp based show control system was the previous entry in this blog.

Light to Frequency toy/noise generator is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.