Evaluate per-channel square overrides with shared defaults

Start by reading typed_config.py and the current tests and config overlays to trace how stimulus.pulse, stimulus.square, and channel settings are validated and combined. Then inspect doric_light_source.py, hardware_setup.py, stim_controller.py, preflight_ui.py, and console_display.py to map the affected paths. Done means documenting the override scope, precedence, UI impact, and estimated test/config churn, with a recommendation on whether to proceed.

Summary

As of 2026-04-15, the runtime supports per-channel current_ma in stimulus.channels, but the remaining square/sequence parameters still come from the shared stimulus.square block.

This follow-up is intentionally design-only for now. We are not implementing it immediately.

Goal

Evaluate whether the config should support per-channel square overrides while retaining stimulus.square as shared defaults.

Example target shape:

stimulus:
  channels:
    ch1:
      index: 1
      current_ma: 50
      period_ms: 200
      time_on_ms: 10
    ch2:
      index: 2
      current_ma: 30
      period_ms: 100
      time_on_ms: 5
  square:
    nb_of_seq: 65535
    nb_of_pulses_per_seq: 20
    starting_delay_ms: 0
    delay_between_seq_ms: 3000
    ttl_output: true

Why shared defaults matter

A full migration away from stimulus.square would make configs verbose when channels share the same waveform. Shared defaults with per-channel overrides keeps common cases compact while still supporting asymmetric channels.

Questions to answer

• Which fields should be overrideable per channel: only period_ms and time_on_ms, or the full square/sequence set?
• Should ttl_output be allowed per channel, or remain global?
• How should merge precedence work between stimulus.pulse.*, stimulus.square.*, and per-channel overrides?
• Should preflight/live UI display both effective shared defaults and per-channel resolved values?
• How much test/config churn would this introduce relative to the value it adds?

Expected scope if we choose to do it later

• typed_config.py: channel schema + merge/validation logic
• doric_light_source.py: per-channel hardware settings structure
• hardware_setup.py, stim_controller.py: build resolved per-channel settings
• preflight_ui.py, console_display.py: show resolved per-channel pulse settings
• tests and config overlays

Current decision

Keep current behavior for now. Use this issue to decide whether the design is worth the added complexity before implementation starts.