Vizati Integration: Data Flow, AR/VR, and Playlists

Vizati Integration Notes: Data Flow, AR/VR, and Playlists

• CMS editorial data entry feeds a ticker scene and full-frame graphics; editors can push supers, breaking news, and flashes via CMS.

• Ticker application controls: one app can play either Tanzania Presidential or Zanzibar Presidential data; an on/off toggle and a checkbox allow looping of Tanzania and/or Zanzibar data.

• Full-frame graphics: options for two-way/three-way rendering; editorial inputs (supers, news, breaking) come from CMS; editor sits at the same location as the publishing system for data entry.

• VR/AR focus: templates for AR linked to data endpoints; WizArc used for VR; AR data to be wired into the VR/AR pipelines via the same or a dedicated channel.

• AR integration questions: placement in virtual set using a graphics channel vs direct AR data input; decisions depend on situation and architecture.

• Data flow options:

  • Push model: editor app/socket connection to engine via local server; direct commands to engine on port $6900$; language used for app is C#; channels and commands differ for graphic channel vs render start.
  • Pull model: browser/plugin approach to pull JSON data from a local server or endpoint and update Vizati scenes live without pushing each command; considered faster and safer for live updates.

• Data formats and endpoints:

  • Currently manual data entries into an SQL database; no public API is exposed; JSON data endpoints can be added if needed.
  • Four engines plus a website typically pull data from local data pools; each engine fetches its own data (region, constituency, presidential/parliamentary data) and maps to its graphics.
  • Data points/naming conventions should be aligned with client system (e.g., Yogan) to enable direct linking of keys to visuals (candidate names, region IDs, etc.).

• Data channels and commands:

  • If using the graphic channel, commands flow through a differently structured Vizati command set; rendering commands may include a render start vs a graphic channel data push.
  • If using direct engine access (no graphic channel), port remains configurable (e.g., $6900$) and render/start/updates are sent directly.

• Data updates and reliability:

  • Pushing commands every second can stress the engine; a pull-based approach via a browser plugin or data-pool is preferred for live text fields because it reduces risk of engine crashes.
  • For live content like ticker, a hybrid approach can be used: ticker updates via push for fast data, full-frame via pull where possible.

• Data templates and playlist logic:

  • Editorial must prepare data templates in advance (data points, keys, naming conventions) and create a playlist that sequences templates (e.g., presidential → parliamentary → back to presidential).
  • Transition logic (TL) vs linear scenes: TL provides layered transitions; ensure compatibility with Julian’s setup and whether templates are TL-based or linear; if TL is required, all transitions should be defined in Vizati playlists.

• Region/constituency data flow:

  • Regions, constituencies, map colors, and related data require multiple endpoints or data points; design an API surface or data-pool structure to feed all necessary visuals (region maps, constituency lists, party data, etc.).

• Training and rollout:

  • Editorial/trainings will be needed for playlist creation, data point naming, and how to assemble on-air stories using Vizati templates.

• Reference deployments:

  • Turkish election and US election templates have been used as references; lessons apply to Tanzania/Regional elections with similar structures.

• Next topics to finalize with Julian:

  • Confirm preferred data flow: push vs pull, or a hybrid approach per scene.
  • Decide on AR/VR integration method (graphics channel vs direct AR input) for virtual sets.
  • Agree on API endpoints, if any, and data naming conventions to align with Yogan’s system.
  • Validate version compatibility (browser plugin availability vs Vizati versions: 3.1, 4.0, 4.4, and 5.5).
  • Establish a rollout plan, training schedule, and a final meeting to lock requirements.

• Key quick references:

  • Port examples: $6900$ for direct engine commands.
  • Version references: $3.1$, $4.0$, $4.4$, $5.5$.
  • Live polling frequency: $f = 1\ ext{Hz}$ (every $T = 1\text{ s}$) when pulling data via browser plugin.
  • Data formats: JSON for pull-based data; SQL database for manual editorial entries.
  • Scenarios discussed: push (editor app to engine) vs pull (browser plugin to Vizati); mixed approaches based on location and workflow.