From: jellybean stonerfish on
On Tue, 29 Jan 2008 14:04:25 -0600, Moe Trin wrote:

> t depends on your data recording programs. Off the top of my head, I'd
> think of using a wrapper program around your recording applications such
> that one application listens for a specific network packet, and on
> receiving that delays a calibrated time then starts the recording. The
> sending application could be the other recording application, and it
> probably also needs a calibrated delay to compensate for it's own start
> delays.
>
> Old guy

I wonder if one wrapper could send a message to each of the recording
program's wrappers. The message could contain a time to start recording.
Each of the recording program's wrappers could calibrate itself.
The same main wrapper could start of the feed also.

stonerfish
--
Way over my head.
From: jellybean stonerfish on
On Wed, 30 Jan 2008 01:08:51 -0800, Giff wrote:

> On 30 Gen, 03:58, jellybean stonerfish <stonerf...(a)geocities.com>
> wrote:
>
>>
>> I wonder if one wrapper could send a message to each of the recording
>> program's wrappers. The message could contain a time to start recording.
>> Each of the recording program's wrappers could calibrate itself.
>> The same main wrapper could start of the feed also.
>>
>
> Yes, that's basically the idea. I posted in order to look for
> suggestions on how to implement it.

Suppose you send time n to both recording programs and the feed program.
Then use a calibration feed with a signal (clapping blocks). Start
your feed at n+x, your audio recorder can be set to start at n+y and your
video recorder set to start at n+z. If one of them starts too soon then
make y or z a larger number. If one of them starts too late then make y or
z a smaller number. If they both take too long to start, then increase x.

stonerfish