View Full Version : looping lower third for TIMES SQUARE TICKER

06-21-2010, 05:17 PM
Hello everyone, I want to know the best method of creating a looping Times Square type text ticker that I will haave running on the upper perimiter of a set, which will allow me to constanly update the text in the ticker without lengthy stop downs.

Is this something that can be accomplished in Live Text?

06-21-2010, 06:22 PM
Yes you would make a crawl but with LT2, you could use the built-in data capability to poll a text file for the crawls information. This would mean the crawl would never need to stop in theory. I say in theory only because I have not upgraded my LT to LT2 yet.

06-21-2010, 06:38 PM
So this is a no go if we only have Live Text, and not Live Text 2?

06-21-2010, 06:42 PM
Sorry no, that is not what I meant to convey. Yes you can load a text file with the text typed with no carriage return (just type a continuous line). Then using LT, load the text file and make it a crawl and send it live to the TriCaster.
LT2 would allow you not to have to stop the crawl, load the next text file and repeat the process is all.

06-21-2010, 06:47 PM
I use this font;
It gives it that real ticker look :)

06-22-2010, 06:27 AM
LT2 would allow you not to have to stop the crawl, load the next text file and repeat the process is all.Testing this, I find that it is possible to update the text without visibly interrupting playback of a crawl page, but to be candid it is not entirely seamless.

What happens is that the current text immediately takes the place of the previous text. If you're ok with that, good. If, though, you want the change to occur off-screen, it's more than a little tricky.

For example - if the Crawl end mode is set to "Over", and you wait for the text to clear the screen before updating it - the new text simply replaces the outgoing text as respects its current position. In practice, if the new text line is longer than the previous one, the tail end suddenly appears in view on the screen. It's not exactly a bug, I guess, inasmuch as it makes sense that this happens, but it would be nicer if the update was entirely hidden from view ... let's call it 'a design flaw'. If you're ok with the update occurring in full view, it works just fine. Otherwise, it takes some finesse, and even then you can't always get it right.

I'll write this up, btw - no need for a feature request ...

06-22-2010, 06:52 AM
Just as an example on how I would like it to work, in BluffTitler, you can design a crawl that gets it text from a text file, XML or RSS feed. Once the crawl is designed, you enable loop and then play. What Bluff does is automatically checks the data and populates the crawl text every time it loops. This eliminates the need to manually refresh. When I use it for a ticker, I try my best to have text at the start and at the end the same. Example Todays Stocks at the start and end. This way the tail end matches up.
Wonder if that same technique would work on LT2 Steve (start and end text the same).

06-22-2010, 07:24 AM
Wonder if that same technique would work on LT2 Steve (start and end text the same).The problem is that the complete text line would have to be exactly the same length every time for that to work, in addition the update being carefully timed manually.

Unlike Bluff, DataLink needs to monitor for updates constantly, not just 'after each pass'. This makes things a bit tricky. I think there are a couple ways to deal with it, but really it needs to be built-in.

The "Over" end mode gives you a clear screen, briefly, between passes. At that point, two things need to happen. The 'old' text line needs to be cleared momentarily, to prevent the problem that happens when the new line is longer than the old one (i,e,, when the tail end of the new line flashes onto the screen). The update (to the new line) needs to be delayed until after right after that 'clear' operation, instead of occurring immediately when the file change occurs per usual.

This would only work properly for a page with one line of text - but I think it covers >95% of cases anyway, and might be adequate.