Ignition
IGNITION is an agile development framework targeted at the efficient creation of highly functional graphics control systems using best practice architecture.
IGNITION implementations can be quickly built using Microsoft Visual Studio, C# and XAML - industry standard tooling, and industry standard coding languages and UI mark-up.
Agile
Implementation assemblies are loaded dynamically, resulting in zero downtime during deployment. The NoSQL object store means no need for relational schema definitions.
Robust
IGNITION looks after your data - all operations are fully atomic and transactional, and the Mirror service ensures that the backup server tracks all data changes.
Extensible
The connector model allows us to deal with disparate delivery mechanisms in a standard way.
Monitorable
Standard interfaces (at both architectural and UI levels) provide configuration and health monitoring.
Reactive
The client automatically tracks changes in server state in real-time.
Performant
Ignition runs compiled code not interpreted script, and sits over an in-memory object store.
Background
Idonix has many years’ experience in controlling and rendering real-time data driven graphics for live television and presentation, working on flagship projects for major clients such as the BBC and Disney.
One of the keys to our success has been a consistent focus on efficient data management, workflow and control systems. Elections, game shows, weather and sport – all rely on real-time data feeds - so graphics systems need to be able to integrate data from disparate sources – user input, databases, web feeds, social media, news wires, weather feeds and audience feedback systems. Aggregation and filtering rules have to be applied, and prediction and analysis sub-systems need to be incorporated. And all of this functionality has to be built quickly and efficiently in order to meet those inevitable tight deadlines.
Our IGO automation software - originally built for the BBC’s 2001 General Election coverage - was reaching end of life, so we engaged on a major new project – to create a next generation control software: IGNITION.
We knew from our very first design meeting exactly what we wanted from IGNITION. Everything had to start with a great user experience.
Contemporary Look
We’ve used great typography and subtle animated elements to make an intuitive and efficient interface.
Performance
Ask anyone what their biggest bugbear with computers is—and their answer will almost certainly be “it’s too slow”. IGNITION has been designed from the ground up with speed in mind. Everything happens instantly. Searches return relevant results in a flash.
No Refresh Buttons!
All client screens update automatically as server side data changes – and all searches are “live” - results update on the fly as underlying data falls in and out of the defined criteria.
Graphics Previews
“Mimic” renditions of graphics are drawn using our core UI libraries – but with the ability to include authentically rendered graphics previews where required—for example Vizrt or Chyron
IGNITION screens are generated from dynamically compiled XAML, bound to data using Idonix’s innovative Fusion binding technology and LINQ to Object queries. Ignition’s templating model paired with standard custom controls in Ignition’s Windows library allow for speedy development and consistent styling. The client side data model is mirrored to Ignition’s server side reactive object store using a WCF communication layer.
Workflow
IGNITION can be used to build custom workflow solutions to fit specific needs: to increase productivity and minimise staffing requirements. Custom user interfaces can be built to provide search, stacking and play out tools relevant to each role – minimising training requirements. We pride ourselves on the fact that an operator can be playing live graphics to air after just a five minute introduction to Ignition.
Here are just some of Ignition’s workflow features:
Custom Roles and Screens
Screens are quick and easy to build in IGNITION, so every operator can be given an interface that is tightly coupled to their role, be it Name Super input, Full Form stacking and TX, VR stack building—or indeed any other that you can dream up!
Automated Workflows
Have Ignition react to external events - a message arriving on a TCP socket, or a file being dropped into the file system.
Editors and Stacks
The power of IGNITION’s mark-up based UI authoring makes it easy to build custom editors for each graphic type. Guides can be included to indicate when text will squash or clip in the rendered output.
Speeding Data Entry
In this example a new “State Exit Poll” graphic has been dropped into the timeline. Notice how it has automatically inherited the Year (2012) and State (Colorado) properties from it’s predecessor. These properties can of course be overridden in the editor
Rather than using generic screens and workflow elements, Ignition’s tooling allows you to quickly create custom functionality for each user role in your project. The ability to use standard Ignition components and to extend these where necessary using C# code or even tools such as Windows Workflow Foundation gives immense power.
Data
You can’t have data driven graphics without data — so data management is at the heart of Ignition. Instead of the more conventional relational database (such as Microsoft SQL Server, MySQL or Oracle), with Ignition we have adopted the NoSQL model, so the server sits over an efficient and optimised object store.
Models
IGNITION is an object orientated system. Simply create a class based model of the real world objects that you need to represent in your graphics — and persistence of these objects will then be transparently managed by Ignition’s object store.
Acquisition
Incoming data feeds can be ingested in any format that can be dealt with by the Microsoft .NET framework and it’s supported development languages. XML? Easy. Tabular? No problem. But the clever part is in the Ignition framework. Ignition provides tools and handlers for all the standard delivery mechanisms: TCP sockets, web services, file system watchers, FTP, message queues and more
Storage
Ignition’s object store lives both in memory and on disk. In memory because we want fast reads, writes and queries. And on disk because we want to keep stuff when we shut the server down! And Ignition’s Mirror service will safely keep a constantly up-to-date copy of your data on a backup server.
Queries
Microsoft LINQ to Objects technology — executed client side where appropriate — allows data to be retrieved from Ignition in a fly. A RESTful API exposes all of this data to the outside world.
When you create a class, and have it inherit from Ignition’s “ManagedObject” base class, Ignition will look after it for you. Code injection will ensure that all its properties are binary serialised to the object store - and to the Windows client.
Graphics Rendering
IGNITION is all about automating data driven real time graphics - so we’ve worked hard to give it the features it needs to streamline this process, but without tying to any particular vendor’s rendering technology: Ignition supports any graphics renderer that has a published API.
Graphics and Commands
Using base IGNITION classes and interfaces, create a “model” of all the graphic elements you’ll need, for example a “NameSuper” that has “Name” and “Designation” properties, and “TakeIn” and “TakeOut” methods. A XAML template in the Ignition UI binds to these objects, giving users buttons to take the graphics in and out.
Renderer Abstraction
A graphic object would normally expose a single method that generates the correct syntax to drive your renderer of choice, be it Viz, Chyron, Brainstorm or Acme Corp. However, there’s nothing to stop you from supporting multiple renderers all from within the same implementation.
Stacks, Scenes and Connectors
IGNITION “Stack” objects give users the ability to create ordered sequences of graphics (complete with drag-drop functionality on the client), Scene objects allow developers to model the scene graph in the renderer architecture (encompassing transition logic as required), and an IGNITION TCP Connector can be hooked up to send commands to the engine.
Renderers and Pools
IGNITION makes it easy to deliver commands to a pooled renderer, either based on style or language of the graphic, or, in the case of file-based workflows, renderer configuration and availability.
Connectors stream incoming and outgoing messages to clients using the same compact binary format as any other IGNITION object. Any object that implements the “IMonitorable “ interface exposes it’s state to the system health monitor.
Configuration and Monitoring
Having built your implementation you’ll need to configure it for a particular scenario, and once it’s up and running, keep an eye on it.
Users and Roles
Having created the classes and screens needed by each role in your implementation, it’s time to associate these roles with users. As an administrator it’s easy to create a new user, and assign them one or more roles - with each role instantly appearing as a discrete tab in their client screen.
Connectors
Create connectors in code or through the GUI, and configure parameters such as watch folders, character encoding, port numbers and more. Whether your connector is for ingesting data or driving render engines, the process is just the same.
Monitoring
Oversee system health with “traffic-light” indicators. Keep an eye on connector state, and monitor data flowing in and out of the server in real-time, from any client on the network
Logging
All messages and exceptions are traced to the Ignition system log, and can be viewed from any client.
