[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-video] Goals, wishes and suggestions for Debconf8.

> > " a lamp on the camera which says whether or not the cam's on "
> I have a pic programmed to do this, when faced with different characters
> at a serial port. 

As we've discussed on IRC, I myself don't see this as the right solution. The use of a PIC is needlessly complicated, it introduces cabling requirements (although the cabling requirements to make RS-232 frames transmit correctly admittedly aren't stringent), there could be serial port problems, you can only run one camera per serial port, many machines nowadays dont even have serial ports..

I suggest using a single I/O line off the parallel port, as it can be programmed to act as an 8-bit general-purpose TTL-level output.

> However, tally lights go further than this; we should have preview (pvw) and
> programme "monitors" in dvswitch. When a camera is cut to a pvw monitor,
> the tally light should show green or amber; when the camera is cut to
> transmission (Tx); the tally light should be red. 

So, this is like A/B bus on the Helsinki video switch? Where one would select a source for bus A, and a source for bus B, and switch between them? The source for the inactive bus is the pvw source?

I'm not sure how useful this is for now. IMAO, buses only really make sense if you're fading between the sources or making other transitions. If you're just cutting between them, I don't see any point at all... or am I wrong on this?

> However, talkback is more important, as there have been several cases
> where a camera operator has not been able to produce a useful shot; and
> some direction would've been useful.

I agree. In essence, tally lights would be only a very primitive talkback system.

> We should be able to organise the talkback with asterisk next year
so it should be fine.

Are you sure the added complexity of Asterisk is worth the out-of-the-boxed-ness? It seems to be a very large system, with transcoders and CPU-intensive things... Considering we'll have gigabit between the machines, we could just write some near-zero-latency program which will push 48KHz 16-bit PCM directly from the ADC of the dvswitch box to the camop boxen... return comms could be largely accomplished with hand gestures - having camops talking during a talk is probably not the best thing.


Reply to: