The room has a main screen and now it has an LED wall down the side, or a foyer display, or a stage-left panel that needs different content. ProPresenter is already doing the main screen from one Mac. The instinct is to buy a second machine.

Sometimes that is right. Often the Mac has plenty of headroom and the actual obstacle is thinking in outputs when you should be thinking in sources.

The output-shaped problem

ProPresenter drives screens. You assign a screen, it takes a display, it puts pixels on it. That model is clean and it hits two walls:

  • Physical outputs run out. A Mac has a finite number of displays it will drive, and the number is lower in practice than on the spec sheet. There is a whole article in that — the honest limits of multi-screen playback.
  • The destination may not want a display. An LED processor wants a specific region of a specific frame. A streaming encoder wants a source. A mapping tool wants a canvas input. Handing each of them a whole display output is wasteful and sometimes impossible.

The alternative is to let ProPresenter produce a source that other software on the same Mac, or another machine, subscribes to.

Route one: ProPresenter’s own NDI output

ProPresenter can output over NDI directly, and this is the simplest thing to try first. A screen configured as an NDI output announces itself on the network; anything with NDI input can take it.

What this gets you:

  • An output that does not consume a physical display connector.
  • Something a second machine can pick up, if you do end up adding one.
  • Audio travelling with the picture, which matters for video playback in the presentation.

What it costs:

  • Encode time on the same Mac that is rendering the show. This is the important one. At 1080p60, full-bandwidth NDI encode is real work, and it is happening on the machine whose job is to not drop a frame during the sermon or the keynote.
  • A frame or two of latency through encode and decode.
  • Chroma subsampling. ProPresenter content is largely text, and text is what subsampling handles worst. Thin white lyrics on a dark background over NDI look slightly soft compared with the main screen. Side by side, people notice.

If the destination is another machine, that cost is unavoidable and worth paying. If the destination is on the same Mac, it is a tax for nothing.

Route two: keep it on the GPU with Syphon

When the receiving application is on the same Mac — a mapping tool, a streaming app, a compositor — the frame does not need to be encoded at all. Syphon shares the texture directly.

ProPresenter does not publish Syphon natively, so the hand-off is: give ProPresenter a screen, and publish that window or display as a Syphon source. That is what SpectraBridge does — it takes a window, an application or a display and makes it available as a named Syphon source.

Practically, that means you can point ProPresenter at a display that does not physically exist. A cheap display emulator on a spare Thunderbolt or HDMI port gives macOS a real display to render into, ProPresenter puts a screen on it, and the source is captured from there and handed to the receiving app losslessly. Nobody ever looks at that display.

The result is full-range RGB, no encode load, no network, and text that is as sharp on the LED wall as it is on the main screen.

Which stage output should feed the wall

Worth pausing on, because it is where these rigs go wrong conceptually.

ProPresenter distinguishes audience screens from stage screens. If the side wall is showing the same thing as the main screen, you can share one screen across both destinations. If it is showing something different — a lower third, a countdown, a logo bug, house content between sessions — it needs its own screen in ProPresenter, with its own layers.

Get that decision made before you build any routing. “Same content, two destinations” is a one-source problem. “Different content” is a two-screen problem, and no amount of clever routing turns one into the other.

The full path to an LED wall

Putting it together for the common case — ProPresenter on a Mac, main screen on a projector, and an LED wall down the side that needs a cropped or differently-composed version:

  1. ProPresenter drives the projector on a real output. Untouched, highest priority, nothing clever in the path.
  2. ProPresenter drives a second screen into a display emulator, composed for the wall.
  3. That screen is published as a Syphon source.
  4. SpectraMap takes the Syphon source into a canvas built at the wall’s real panel resolution, positions and masks it, and sends the result out — over SDI to the processor if you have a DeckLink, or over NDI if the processor takes it.

The canvas step is the one that earns its place. The wall is probably not a standard resolution, and getting one canvas pixel onto one panel pixel is what stops it looking soft. What an LED processor actually wants from your Mac goes through that in detail.

Where this approach runs out

Be honest about the ceiling. One Mac doing all of this is fine until it is not, and the failure is a dropped frame during the thing everyone came for.

Stop and add a machine when:

  • Video playback is central. Rendering multiple 4K video layers and encoding NDI on one machine is asking a lot. Text and stills are cheap; video is not.
  • The destinations need genuinely independent timing. Two things that must roll at different times are two shows.
  • You need redundancy. One Mac is one point of failure regardless of how elegantly it is configured. What a redundant setup looks like is a separate conversation.
  • The operator needs the machine. If someone is editing slides live, they are competing with the render for CPU and for the operator’s attention.

Before the service or the show

Three checks that catch the failures specific to this rig:

  • Power-cycle the display emulator and see what happens. macOS rearranging displays is how ProPresenter screens end up on the wrong output. An emulator that stays present through a processor reboot is worth its cost several times over.
  • Confirm the Syphon source is live, not frozen. Receivers hold the last frame when a publisher stops, which looks identical to working. Change something and watch it change.
  • Check permissions after any update. Screen capture on macOS depends on a grant that a rebuild or a reinstall can invalidate — see the permission prompt that stops your show.

Originally published on the SpectraRig blog.