Chameleon: An Open Platform for Developers and Users

Chameleon at its core is a database with a flexible database schema which can be used to contain almost any type of data. Through our hybrid design using the best of relational and key/value pair design, it becomes an ideal warehouse for data. And with a powerful web interface, users can organize data in unlimited ways.

What is less known about Chameleon are some of the more technical aspects, namely its capability as an open platform for developers and users. Here are some of the highlights: 

    • Chameleon API for writing graphics apps using Chameleon or external data
    • Open database design allowing 3rd parties to add parsers and other data related services
    • SDK for tight integration to Chameleon’s ticker and branding resources
    • BLADE – RESTful api providing endpoints to all containers in multiple formats
    • Community support – sharing data between instances of Chameleon
    • Dynamic Tags – foundation for extending existing data types
    • Custom data type when there isn’t a fit with one of the other standard data types
    • Query data type for creating dynamic playlists using any and all Chameleon data
    • Scripting support for html5 Designer
    • OEM Support and Interface Skinning/Feature Hiding

Chameleon.api

All the rendering for our html5 graphics is done on the client side (JavaScript on a client’s browser). But there’s a pipe of data between an application we call the Chameleon Web Server to tell JavaScript what project, scene and data mappings to use for each render.

The Chameleon.api is an interface to the Chameleon Web Server to allow it to do more than just tickers. This interface listens for commands to show a scene with a set of key/value pairs to map to fields in the scene. The api is a simple interface to load projects, set scenes online or offline, update an existing scene and a callback to signal the end of a render.

The Chameleon.api is available in nuget to integrate into 3rd party applications. Those applications might be scorebugs, sequencers or any custom requirement for rendering graphics. In fact, Bannister Lake uses this api for some of their own applications like the Branding and Elections Player.

We encourage developers to use the Chameleon.api to create the next great graphics application.

Open Database

Chameleon uses MySQL as its database system. It is an open-source relational database management system. It is a free and open-source software under the terms of the GNU General Public License and is also available under a variety of proprietary licenses. There are derivatives to MySQL such as MariaDB and others.

We learned early on that Bannister Lake could never provide all the data resources to populate our database. Language limitations limit our capability of writing resources for datafeeds of character sets like Kanji. We certainly can contain that data in Chameleon but without language experts, we have no way of interpreting the data.

For this reason, our goal was to open up the Chameleon database to internal and 3rd party developers to create parsers or any other data script for our Chameleon customers. For that purpose, we have made access to the Chameleon database open by providing common MySQL credentials to allow access to MySQL Workbench and MySQL connection tools for any type of software development. We even provide sample source code to parsers.

SDK

All of Chameleon’s data/containers can be used in a loose fashion through BLADE. It’s a powerful way to support all platforms including web widgets, character generators and digital signage. However, Chameleon allows for tighter integration of graphics through its SDK. This allows for tickers to use rundowns and branding assets.

Tight integration also requires publishing information about graphics to the database. This provides templates for generating bugs or snipes. It also provides the magic to include data containers for a rundown’s zones.

The SDK itself is on the playout side for creating players that can use all these database resources for tickers and branding. For tickers, it allows mapping containers to graphic zones in a ticker making it as simple as dragging a data container into a rundown. The SDK covers all the work behind the scenes to make this all work.

For example, here is a rundown for a zone in a show (our term for a group of zones)Zone Selection Rundown

Using the information in the database when graphics are published, rundowns know what types of containers it can support. This tight integration of graphics also extends to branding assets. Here’s an asset defined to provide a countdown clock bug to Christmas:

Asset Editing - Countdown

When a platform supports these graphics-based resources in the Chameleon database, we call the platform tightly coupled. Once tightly coupled, a platform has some magic behind it where tickers and branding are all defined in Flow, Chameleon’s web interface.

The interface to the SDK for providing tightly coupled support is a series of methods that are not unlike the Chameleon.api where it supports information about bringing scenes online or offline and updating. It’s even possible to have an SDK implementation support Chameleon.api to provide additional 3rd party development support.

BLADE

Chameleon has an endless supply of data containers. Those containers might be a broadcast channel’s program schedule, world news, league scores, stock index quotes or weather for a group of cities. Each container has an endpoint for acquiring the data from a url to be used with any platform whether it’s a ticker (broadcast, digital signage, streaming,…), website, branding or character generator.

BLADE (Bannister Lake Active Data Exchange) is a RESTful api to all that data. There is a url to pull any Chameleon container. Not only that, Flow provides a page to discover the urls. For example, if we wanted to find the json url for getting the Dow Jones 30 components, Flow’s BLADE discovery page makes it easy. No docs to read. Just pick what you want:Bannister Lake BLADE UI

The url discovered here is an active and live resource located on one of our cloud instances and formatted in json. Go ahead and give it a try:

https://lightbulb.blcloud.net/blade/financial/topic/25/Dow-Jones-30/?format=json&pretty=true&dynFieldDefaultAttr=false

Originally, BL created a central location to store useful information like sports scores or weather forecasts. This was intended as a data resource for our customers. We also opened it up so that data providers could login to an instance of Chameleon and edit their own data for broadcasting purposes.

But we went further with this idea. What we came up with is a way to share data between any Chameleon instance. Basically, Community Support provides a way of syncing a container with a container from another Chameleon instance (another database) or even between content groups of the same Chameleon instance. We call these container to container syncs maps.

In Flow, users can setup maps by defining the Chameleon instance source and then mapping a source container to a destination container:

In this example, we’re mapping the Chameleon instance located at https://lightbulb.blcloud.net all the sport scores for leagues MLB, MLS, NBA, NFL and NHL. We support mapping of most Chameleon containers, even query source containers (mapped to Custom).

Dynamic Tags (aka Dynamic Fields)

Early on in the design of Chameleon, we found the need to extend existing data types with additional fields. For example, each sport has unique data beyond team names, scores and status. While baseball might need information on who is up to bat, the count, team errors and so much more, a sport like hockey might need shots on goal, hits, penalty/power play information. There are 2 ways to approach this problem. Either add new fields to a relational data table (forever) or attach additional data to a core data type. We chose the 2nd method. All of the Chameleon data types have support for extending data by attaching dynamic tags to records. These dynamic tags can be text, numbers, dates, boolean, json or media. We even went all in on this idea by having a data type we call Custom which is essentially just dynamic tags.

For example, here’s a simple dynamic tag providing a logo for episodes of Bonanza:

And here are dynamic tags for an NHL player:

Note that we are working on a new data type for dynamic tags: set. Basically, a set is a set of dynamic tags. This is a way for any dynamic tag to reference a set of dynamic tags providing full hierarchy of data. This could be used to store season or game information for players or teams. It could also be used to store different language versions for a story.

Custom Data Type

Not all data fits into standard Chameleon data types such as story, weather or finance. That’s where the Custom data type comes in. It is essentially key/value pairs attached to records. Chameleon calls these key/value pairs dynamic tags or dynamic fields. Although all the other data types have key/value pair support, the Custom data type is exclusively key/value pairs. Any 2 dimensional data is a good candidate for using the Custom data type. For example, a spreadsheet is a good example of what is a good fit for Custom where each column is a field and each row are the values to a record.

A good example of the use of Custom is containing COVID-19 data. For example, here is Canadian COVID-19 data organized by province: Here we’re showing some of the fields for the province of Quebec.

Another example is organizing medal counts for events like the Winter Olympics:

Like all dynamic tags in Chameleon, key/value pairs can be strings, dates, numbers, booleans or media. Custom data is organized in topics and is just another container to Chameleon where it can be used like any other container.

Query Data Type

Query is Chameleon’s method for creating dynamic playlists and to format data in a precise way. For example, if we had all the Dow Jones components in a Financial container ordered ascending by symbol: 

What if we wanted the data sorted descending by volume? One could create a playlist and manually order by volume but when the markets are open, the data is highly dynamic. That’s where Query comes in. It can create dynamic playlists. And these playlists are treated like any other container in Chameleon with the difference being the query behind it gets executed whenever utilizing the container. 

Query is based on writing SQL SELECT statements. These statements are what get executed on the container. Any data in the database is fair game for query. Here’s an example of the SELECT statement behind a query for getting the top 10 volume leaders for the Dow Jones 30 components:

The above query gives us:

Designer Scripting

Most character generators or graphics environments have some form of scripting support. Chameleon’s web renderer is no different in that respect. It allows writing scripts to accomplish dynamic tasks. For example, here’s a script for a scene that shows sports scores. It will mark the team with the colour red if the team is leading or has won: 

Designer uses CoffeeScript as its scripting language which gets translated to JavaScript at render.

OEM Support and Interface Skinning/Feature Hiding

Chameleon’s most visible interface is Flow. Flow is the web interface which provides access to the world of Chameleon; not just the data but the operational aspects of data like triggering graphics. From the beginning, Flow provided support for skinning Flow. For example, each election, we’d provide a different skin for our election users. We also provide support for hiding features so users aren’t bombarded with things they don’t need or want.

Flow can easily hide content by turning on and off features. If an instance of Chameleon is used for only sharing/working with certain data types, it’s easy to hide features. For example, here is what is available for our Community instance:

While an instance like our Chameleon cloud instance provides more functionality for playing out graphics:

It’s also possible to skin Flow for any purpose whether it’s for OEM partners, internal customer support or distinguishing between instances. Here are a few examples of Flow headers:

In the last example, it shows an example of Chameleon as an OEM product for Ross Video. We are seeking interest from new OEM partners who wish to integrate Chameleon into their own product eco-system. Everyone needs good data so Chameleon is an excellent fit for many products.

Vern Freedlander Joins Bannister Lake

Bannister Lake is pleased to announce our newest team member Vern Freedlander. With his immense experience in broadcast newsroom operations and digital signage, he is a perfect fit in helping our products expand their reach.

Vern joins BL with extensive experience in broadcasting and digital signage. His broadcast career includes senior management roles at CTV News and Global News as a producer, director and creative director. At CTV, he helped launch CTV News Channel and worked on numerous elections, international summits and breaking news specials. At Global, Vern was part of the production team that launched the Global Television Network’s flagship newscast, Global National. While at Global he managed the network’s election data/graphics systems introducing new technologies and workflows allowing every market across Canada to produce high quality, competitive election night broadcasts.

Vern left day-to-day newsroom operations to join X2O Media, a Montreal based start-up, focused on software development serving the media, corporate communications and digital signage space. At X2O Vern combined his editorial, design and technical skills to generate new business opportunities and contribute to product development. Vern has a deep passion for live data and how it can be used to optimize content performance and distribution creating exciting business and communications opportunities for clients.

FIFA World Cup 2018

BL is pleased to once again be providing the scorebug for this year’s FIFA World Cup in Russia. TSN has the rights this year for the Canadian broadcasts of games beginning June 14th. Although the broadcast rights have changed over the years with different permutations of CBC, TSN and Sportsnet owning/sharing them, this will be the 5th FIFA World Cup in a row BL has provided the scorebug.

From the 2002 2-0 Brazil win over Germany in Yokohama, Japan in 2002 to 2014’s dominant performance by Germany to take the final game 1-0 against Argentina in Rio de Janeiro, Brazil, BL has been there to provide viewers with the crucial scoring information counting down all 64 games for each tournament.

Community will be publishing all the news and scores from the world cup. This data will be made available for all either by mapping to community from your Chameleon instance or by using BLADE (Chameleon’s RESTful api) on the following links:

We’re all looking forward to watching this year’s edition of the greatest show in sports. Good luck to TSN on its broadcast of all 64 games.

The Web Widgets are Coming!

Our customers store a ton of important information in their Chameleon databases. Adding to that wealth of data is all the useful information available on Community. Community has a wealth of weather, sports, news, financial information and more. And with our soon to be released eventful support, calendars can be stuffed with local events.

While tickers are the ultimate way to show data for broadcasts whether for digital signage or traditional broadcast, it’s not the only way to utilize all that useful data. That’s why from the beginning we included BLADE, our RESTful api, for retrieving data from our database. We support all the standard formats like xml, json, rss, csv and others. We even created a UI in Flow, our web interface to Chameleon, to help customers discover the correct BLADE url for the data they need.

However, to use raw BLADE data, there is a technical requirement. Software developers would have no trouble turning a json file into html using PHP. Character Generators and Digital Signage players are also adept at utilizing BLADE standard formats as is. But how to make use of BLADE for the non-technical user? How can a web master insert data much like they insert Google Maps?

Well, the answer is to follow Google’s lead and create web widgets with our data. So, instead of raw json, xml or csv from BLADE, what if that url did more? How’s this for an example:

The above isn’t a screenshot. It’s a mini-app on this page. Click the arrows, the league dropdown or the logo and they’re all active. Also, leave this web widget up and you’ll see refreshes of the scores automatically. And these are real scores coming from live Community data. No smoke and mirrors!

The web widgets we’re adding will be more than just static data. For example, this scores web widget has lots of flexibility with colours, branding (logos/links), size, leagues, refresh rate and much more. For example, looking at what we have above, there’s a league drop down allowing changing of the league. This is optional since the league can be fixed but the important point is that the web widgets are mini-apps that are easily placed on any web page much like Google has done with Google Maps.

The above scores web widget comes to us courtesy of our Community instance of Chameleon. We expect to expand our web widgets over the next few months to include all of our data types. And by default, all Chameleon customers get this support. It’s not an option. It’s just an expansion of our BLADE support.

Elector Used by Global TV for 2 Thrill-a-Minute Elections in May

May has been an exciting month for us here at Bannister Lake. Our election software, Elector, was used by Global TV for two incredibly dramatic and historic elections. On May 9th, we had the British Columbia General Election which produced a thrill-a-minute result where 2 major parties and a minor party were able to produce an unlikely minority government. Throughout the evening, we kept flipping between the Liberals and NDP gaining a majority and a minority lead in both directions. That with the Greens only contesting in 3 ridings. How was that possible? When I finally packed it in around 2am ET, there was a tie between the Liberals and NDP. By morning while Elector kept chugging along, the Liberals took it by a minority.

Next up, the May 30th Nova Scotia General Election with the polls looking like the Conservatives might spoil the Liberal’s hopes for another majority win. Early results had the Conservatives leading the way but after an hour of results, the Liberals took an edge. From there on, we were in another flipping mood where we were seeing Liberal minority move to Liberal majority and back. When I packed it in around midnight ET, it was a Liberal minority lead. I woke up in the morning while Elector was cranking away to a narrow Liberal majority win.

Elector started out with an emphasis on generating all the graphics for a standard election broadcast. But over time, it has become an editorial tool helping talent make sense of the election, mathematicians make calls, producers show the ridings graphics that matter at any particular time, augmented reality show information and graphics, news department show breaking news and websites provide the most up-to-date data.

Our web interface to Elector, Flow, is what pulls it all together. At any particular time, we may have large numbers of users using the data in different ways. And with Flow’s user classes, each type of user sees things tuned to their needs and editing privileges. Flow lets us compile the details about ridings, candidates and parties. It also has support for historical elections giving the users a way to see past election data to provide a historical perspective.

Elector has a collection of tools that work together to generate valuable insights into the real-time election results. It starts with as much of the results from the previous election as is available. From there we add information about current candidates indicating which ones are candidates of interest for reasons such as being a star candidate, a subject of a media scandal or an independent with a chance, etc. Predictions for the results in each riding are also added on a party basis. As the results start to come in, Elector goes to work to help mine the entire collection of past, present and predictions for interesting results. While users are reviewing the individual riding results in the Results Summary page the Interesting Agent is busy identifying interesting events such as an incumbent losing, close races and a party taking the lead in a riding they were not expected to win. As these events are identified they are presented to users of Elector via quick popups that identify the interesting events for the riding. As the results accumulate, Elector highlights each riding which may be ready to declare a candidate elected. An analyst can quickly popup the detailed riding results allowing them to make the final call and elect the candidate right there on the summary results page.

I’m always thrilled when I see our users utilizing our software. For example, David Akin, Global TV’s Chief Political Correspondent posted screenshots of Flow on twitter throughout the evening. He was using the screenshots to describe some of the riding results.

Elections are a hectic and scary event for all news departments. It often requires a small army to pull it off. Elector, which got its start from a New Brunswick election in 2006, has come a long way. Not only does it include all the editorial, watchlists and number crunching tools in Flow but it has a rehearsal tool providing a way for teams to test different scenarios pre-election, a RESTful api making the data available to other sources like websites and virtual devices and data parsers which are tuned for the quickest and most accurate results.

Special thanks to Gerry Belec and Deb Zinck at Global TV for all the great suggestions, feedback and patience which has made Elector a success.

8 Years of XPression

Our CG Journey.

 

As we approach our 8th anniversary of being Ross Video XPression developers, I reflect upon how we got here.

 

Up until 2009, all of our broadcast graphics development had been on the Inscriber platform using the RTX api. It had served us well but there were concerns about whether the Inscriber platform was keeping up technically. Also, with the acquisition of Inscriber by Leitch and then Harris, there were worries about Inscriber’s future.

 

In 2008, we started our investigation into an alternative CG. We had a close look at many of the leading CGs and even a few obscure ones, some of which have faded into the sunset. They were all fine but Francis and I were never satisfied with the programming api to those CGs.

We continued our search during our annual visit to NAB in 2009. D’Arcy and Francis raved about a CG being shown in the Ross booth which came about from an acquisition of Media Refinery. I finally popped by the booth an hour before the final bell and was given a demo by my old friend Hans. Within minutes, I knew we had found our CG.

 

 

I look back at all the software, both products and custom, we have developed which use XPression. With pride, we identify ourselves as XPression developers. And we thank Ross Video for keeping XPression on the top of the charts. Unlike most acquisitions, Ross poured resources into XPression and the product continues to evolve.

It’s easy to take for granted but BL wishes to thank Ross Video for their support of XPression. BL will continue to ride the XPR wave forever.

Bannister Lake Powers Financial Broadcast Graphics for Live Video Network Cheddar

CAMBRIDGE, ON, Canada, October 5, 2016 – Bannister Lake, a leading provider of broadcast data aggregation and graphics solutions, today announced that the company’s software is powering financial graphics generation for live news and entertainment company Cheddar.

Cheddar is a live and on-demand video news network focused on covering the most innovative products, technologies, and services transforming people’s lives. The network covers this news through the lens of the companies and executives driving these changes. Cheddar broadcasts from Post 10 on the trading floor of the New York Stock Exchange, the Sprint Flatiron Building Store, and NASDAQ Marketsite. Aligning with the viewing preferences of millennial audiences, Cheddar is available through social media platforms, over-the-top (OTT) services, mobile apps, and online on its website, cheddar.com. Complementing its flagship Facebook Live streams, Cheddar announced a partnership earlier this month to bring exclusive, live ‘Closing Bell’ coverage to Twitter.

Seeking to expand and enrich its live, on-air graphics capabilities, Cheddar selected software from Bannister Lake to drive financial data management and graphics creation in conjunction with a Ross Xpression broadcast system. Seamlessly bridging Xpression with the Xignite Market Data Cloud, Cheddar’s chosen financial data provider, the Bannister Lake software gives Cheddar’s operators an easy-to-use interface to create and display up-to-the-second stock charts within their live broadcasts. Bannister Lake also generates Cheddar’s on-screen, real-time, crawling stock ticker from Xignite data, while an array of additional features allows Cheddar to trigger lower-third graphics, sequence elements into playlists, and define distinct layouts for the network’s various shows.

“The Bannister Lake software makes it easy for us to call up stock quotes and quickly create live charts for our broadcasts,” said Peter Gorenstein, chief content officer at Cheddar. “That ease and speed are critical, since financial data is time-sensitive. So many graphics solutions are inflexible, expensive, and confusing or complicated to work with. The combination of Bannister Lake software with Ross Xpression has given us the ease of use, reliability and flexibility we need as we expand our brand, programming and reach.”

Gorenstein’s satisfaction with Bannister Lake goes deeper than the software itself. “In a broadcast production environment, there is always a lot of integration required between many varying systems and components, and Bannister Lake has been tremendous in helping with that as our infrastructure evolved,” he added. “They have been responsive, met all of our deadlines, and have been a great partner all around.”

“Cheddar is a great example of the evolution of broadcasting, as new media companies emerge with a focus on the latest distribution platforms to fit the shifting viewing habits of their target audiences,” said Georg Hentsch, president, Bannister Lake. “Our solutions enable efficient, data-driven graphics workflows for any size of media enterprise on any platform, from online broadcasting start-ups to the largest traditional networks. We’re excited to be chosen by Cheddar and to be playing an important role in the growth and success of their innovative content offerings.”

Bannister Lake Meets Google

by Georg Hentsch

Here on The Lake, we rely on Google to get us through the day: Drive, Communities, Hangouts, Calendar, Gmail, Search, YouTube, Play and Photos. We may even have one of the most enthusiastic Google Evangelists imaginable; I won’t name names. So, it’s no surprise we’re always looking for opportunities to use Google in our software.

So, we’re proud to announce these Google api projects:

  • Google login support
  • Google Calendar support for Super Ticker
  • Google Sheets support for Super Ticker

On top of our LDAP support in Flow, we’ve added Google login support which is especially attractive for cloud users. No more dealing with yet another login/password. It even has the benefit of bypassing the login screen if the user is already logged into Google. We’re initially supporting this in Super Ticker and Community but it’ll find its way into Brando.

For Google Calendars, we’ve taken the standardization approach by supporting RFC 2445 also known as iCalendar. Since Google Calendars also support this standard, we can now read any publicly shared Google Calendar into our Events data type. This opens up 1000s of public calendars for our customers to use in Super Ticker.

Finally, we’re using the Google api for Sheets to read sheets into standard data types like scores and closings. We’ll follow that up to also support reading sheets into our Custom data type giving us a way to contain basically anything.

What’s next? I’m sure our in-house Google Evangelist will push us into more Google projects and our products will be the better for it.

The New Data Types Are Coming!

Included data

Our customers have always pushed us to provide containers that can store their unique data requirements. Take a sports score. At one point, it was enough to show the teams, score and status. But over time, customers wanted to show ball possession, the count, shots on goal, team rankings, standings and records.

We solved “Creeping Featuritis” simply and expansively: dynamic fields. And added dynamic fields to all data types.

This made it possible to contain anything using one of the existing data types. However, what also happened is we ended up hacking stories because that became the most common container for storing those “custom” data types.

So, what better way to solve a custom data type than to create a custom data type. Look for a new icon in that Content Control in the near future called Custom. It’ll be similar to stories without the story. It’ll have a way of organizing using topics and playlists as in stories but custom gives dynamic fields preferential treatment. No longer do you have to open a dialog to see them. They are given primetime.

Custom is a great way to store anything you can dream up. It’ll get all the other great data treatment like rundown, BLADE and Query support.

Query you say? What is that? Have you ever wanted to create a playlist of all close election races where incumbents are losing, scores of games in progress, stocks that are tanking or stories that include a certain keyword? That’s what we call dynamic playlists and they were essentially impossible to do until now.

We’ve added a new Query data type which is essentially a database query. If you can dream it, it can be described in SQL. And these queries also get the full data treatment: rundowns & BLADE. Here are some examples:

The reason Query is dynamic is because the actual SQL gets executed at runtime. So, when in a rundown for a player, the player executes the Query as late as possible. Same for BLADE: the query gets executes on the api call.

What’s more, Query can be shared among all Super Ticker users. If you have a Query you think is useful to others, you can publish it. Once published, users can see and deploy the query. As you’d expect, once deployed, the query can be fiddled as required. The main reason for publish/deploy of Queries is we can’t expect all users to be SQL experts. But that being said, we do provide a Query Wizard to make life easier for those less than hardcore users.

With Custom’s and Query’s inauguration, we say farewell to Ski Reports. We’re phasing that oddball out. If you want Ski Reports, use Custom!

Also, look for big enhancements to some of our other data types like Closings, Events, Media and Weather but I’ll save that for a future blog.