CasparCG countdown clock

[bern333]

Hi Klaus

No, no player - just a button called player1 which sends a one off command -

Code: Select all

write  field "tMedia" & format("\r\n") to socket cgAdd

to the CasparCG server, which plays a clip. it also sets off the showTime handler above, which you helped with, which should provide an accurate countdown to the end but doesn't - though it did till I decided to have a separate card with the counter on it.

It may be just too much for Livecode to update the clock etc in the time, though that seems very unlikely, as CasparCG happily runs a complex HD block of sound and vision nearby. I've check my Resource Monitor and the computer isn't even breathing heavily so it isn't that.

Bernie

[Klaus]

Hi Bernie,

ah, OK, looks like I did not get the whole story.

to the CasparCG server, which plays a clip.

But where on your machine is this clip displayed?
In a browser window? Sorry, I have no idea really.

Whatever, I think the internet communication via sockets may cause
a little delay and thus the out-of-sync stuff.


Best

Klaus

[Klaus]

Addendum: And no, LC is fast enough for all this!

[bern333]

Here's a video demo of the version before the countdown clock. It works extremely well, though the demo is about as basic as it could possibly be (said the highly experienced tv producer, slightly embarrassed). It was made to show a couple of colleagues.

http://www.tech-ops.co.uk/bern/caspar.html

CasparCG - which you can download and use for free - has it's own screen window and console, and using a Blackmagic Decklink card it provides sound and vision output for use as required. You can run a complete tv channel from your PC. There's also a supplied client application that allows you to use all of CasparCGs many facilities. The client is extensive, but not user friendly for studio use. Hence people writing their own for specific purposes, such as mine.

When you first run my Livecode client it tells CasparCG to run a clip so that the user can tell it's working,which you see in the left window. Then you can move around the client screens (cards) running clips and putting supers on and off. It can be used perfectly well as it is, but I thought that a countdown clock would be a useful extra.

In an ideal world CasparCG would send simple timing info, but it only does that via OSC, which is well beyond my abilities.

B

[[-hh]]

Attempt was in vain.

[bern333]

Hello -hh

That's rather impressive by my standards! I'll put together a branch and give it a try.

What matters to me is that the countdown is accurate - and it isn't so far. That is either because something in my code slows things up, or that something in Livecode is slowing it up. The current loop code is only a few lines. It's different to the -hh version but whether that makes a difference to the accuracy I can't tell till I try it.

The current version -

Code: Select all

   -- its going to loop every 500msecs
   subtract 0.5 from totalsecs
   
   -- do the time maths
   set numberformat to "xx"
   put totalsecs div 3600 into xhrs  
   put (totalsecs mod 3600) div 60 into xmins  
   put trunc((totalsecs mod 3600) mod 60) into xsecs  
         
      --put the numbers on the screen
   put xhrs into  field "xHr"  of card "pop1" of stack "pop"
   put xmins into  field "xMin"  of card "pop1" of stack "pop"
   put xsecs into  field "xSec"  of card "pop1" of stack "pop"
   
   -- getting out of loop - is the clock >0 and is the clip running (stop button not pressed)   
   if (totalsecs >1 and the cMediaOnFlag of stack "main"  is 1)   then    
      send "showTime" to me in 500 milliseconds

      --     else do exit stuff

..and Klaus - it only talks to the socket once, at the beginning of the count, then it's free running.

B

[bern333]

Running my 7.44 test clip I can see the Livecode countdown against the clip timecode. LC starts ahead and by about 2 mins into the clip they are running in sync. By the end LC is somewhat behind - ie it runs slow.

I ran an extra test and opened Photoshop whilst the clip was running, then took a Snip of the LC Message Box a couple of times. All that CPU exercise didn't make any difference to the countdown or the video.

The reason for it was doing this -



Can anyone decode this?

These grabs from the message box are about a minute apart whilst the clip is running . I have no idea what they mean apart from the number in the second one being larger.

B

[[-hh]]

Attempt was in vain.

[bern333]

Ok, it's sorted. Thanks to all who have contributed to my latest angst.

The answer is that "send xxx to me in yyyy seconds" is never going to be accurate. So all those answers about implementing timers I've read are wrong.

I started to think laterally and wondered if Livecode has access to Unix Time - the number of seconds or milliseconds since 00.00.00 on 1st January 1970. I've used it before in other contexts. As it turns out Livecode does have access called, somewhat unhelpfully, "the milliseconds". And whilst searching on this I came across a posting which explains exactly why sending stuff is never going to be accurate in itself. Thanks to hliljegren on Stackoverfow

http://stackoverflow.com/questions/2933 ... n-livecode

Basically your send command will be in a varying sized queue so you need to refer to something accurate - Unix Time - or at least your computer time, which is based on seriously accurate clocks. Then although you "send xxx to me in yyyy seconds" you refer to an accurate time in each loop, and the result comes out working correctly.

This is my new version, based on the answer in Stackoverflow

Code: Select all

-- @@@@@@@@@@@@@@@@@@@@@@@@@  

 local lStartTime, lTimerTime

on showTime
   put the milliseconds into lStartTime --put current Unix time into a variable
   put lStartTime +  totalsecs * 1000 into lTimerTime -- add to it the start duration of the clip in milliseconds
   runTimer -- run the handler below
end showTime

on runTimer
   put lTimerTime - the milliseconds into tTimeLeft 
    -- So, subtract the current Unix time which is bigger now,  from the result in showTime above which is lTimerTime. 
   -- The difference is smaller - so we're counting down

  -- to keep consistency with the rest of the system I put the current duration in seconds back into totalsecs
   put tTimeLeft/1000 into totalsecs

  then  
          -- do the time maths
      set numberformat to "xx"
      put totalsecs div 3600 into xhrs  
      put (totalsecs mod 3600) div 60 into xmins  
      put trunc((totalsecs mod 3600) mod 60) into xsecs  
      
      --put the numbers on the screen
      put xhrs into  field "xHr"  of card "pop1" of stack "pop"
      put xmins into  field "xMin"  of card "pop1" of stack "pop"
      put xsecs into  field "xSec"  of card "pop1" of stack "pop"
      
      --then 
      send "runTimer" to me in 100 milliseconds
      -- this loops in a nominal 100mSecs but it doesn't matter if it's inaccurate
   
   else  -- we're done with this
         -- change the button setup
   set the disabled of button "player1"  of card "clipper" of stack "main" to "false"
   --reset everything
   set the cMediaOnFlag of stack "main" to 0        --reset the clip running flag  
   set the visible of field "board1"  of card "clipper" of stack "main" to "false"  -- don't show the "clip playing" sign
   put 00 into field "xSec"  of card  "pop1" of stack "pop"  -- put 00s on the screen
   put 00 into field "xMin"  of card  "pop1" of stack "pop"
   put 00 into field "xHr"  of card  "pop1" of stack "pop"
   put 0 into xsecs    -- reset the variables
   put 0 into xmins  
   put 0 into xhrs 
   end if
end runTimer  
      

Ok, on to the next problem.....

bernie

[[-hh]]

Attempt was in vain. And 100 milliseconds are still exactly 0.1 seconds

[jacque]

The "seconds" function is also based on Unix time. Unless you really need millisecond accuracy, you'd get a more responsive app by spacing your time checks to the seconds. By putting your calls so close together you're creating an unnecessary amount of overhead.

[bern333]

Thanks Jacque - I don't need it to be really often, but I do need more than a second, otherwise somewhere it'll hop. I've made it loop every 500 milliseconds now. It's incredibly satisfying watching the Livecode countdown clock and reverse timecode on a clip counting down together!

Now I just have to work out how to do a pause button, so that the countdown stops then restarts at the same point. No, don't tell me - I have to go through a week or two of mental pain and anguish before I give in, and I might even be successful.

B

[jacque]

No, don't tell me - I have to go through a week or two of mental pain and anguish before I give in, and I might even be successful.

I think we're all like that.