Question: should the presentation half be rebuilt on PsychoPy, in a separate repository?

Companion to #1. That issue records the scoping decision — this repository reads NewStim data structures and files, and does not present stimuli, because presentation in vhlab-NewStim-matlab runs on Psychtoolbox and Psychtoolbox is MATLAB-only. This issue is the question that decision leaves hanging: should the presentation side be rebuilt in Python on PsychoPy, and if so, where?

It is a real question rather than a rhetorical one, because Python does have an answer to Psychtoolbox — PsychoPy covers much the same ground (windowing, frame-accurate flips, gratings and element arrays, hardware triggering through ioHub) and is the tool most labs moving off MATLAB land on.

What would actually have to be rebuilt

From vhlab-NewStim-matlab at 0ae6822:

• 19 stimulus classes under Stimuli/. Every one has a getparameters.m (the data face, in scope for this repository) and 18 of the 19 have a loadstim.m (the Psychtoolbox face). The interesting ones are not thin wrappers — @periodicstim alone carries loadstim, loadstimPTB3, animate, customdraw, customdraw_overlay, customdraw_plain, makeclippingrgn, spatialphase2gratingimage and its own private/.
• Display calibration — @displayprefs, @displaystruct, GammaCorrectionTable, MonitorScreen. Getting stimuli that are the same stimuli means reproducing this, not just drawing gratings.
• Triggering and rig hardware — NewStimServices (62 files) holds VHTrig, PCI6224Trig, PCI6224sTrig, StimPCIDIO96, StimSerial, StimTrigger, FitzTrig. These talk to specific cards; PsychoPy would not port them so much as replace them.
• RemoteCommunication (19 files) — the protocol between the stimulus computer and the acquisition machine.
• NewStimDisplayProcs (17) and NewStimTestProcs (4).

49 files call Screen( directly; the lineage that reaches them is larger.

The case for

New experiments could be written in Python end to end, which is where NDI and the rest of the lab's analysis stack are heading. It removes a MATLAB licence from the rig. And the stimulus definitions stop being trapped in a language the analysis side is leaving.

The case against, or at least for care

• Timing parity is the whole game. A grating that looks right but drops frames differently is not the same stimulus, and every dataset recorded with it is incomparable with the MATLAB-era ones. Any port needs frame-timing validation against the MATLAB rig — photodiode traces, not screenshots — before it records real data.
• The hardware layer barely ports. Trigger cards and the remote protocol would be rewritten against whatever the rigs run now, which is a rig-engineering project, not a translation.
• Cost is concentrated in a few classes. @periodicstim, @stochasticgridstim and @hartleystim carry most of the science and most of the drawing code.
• It may not be needed. If new experiments will be run in some other framework, or the MATLAB rigs will simply keep running until the stimuli themselves are redesigned, then the reader in this repository is the whole requirement and this work never pays for itself.

If the answer is yes

It should be a separate repository (vhlab-NewStim-psychopy, or similar), not a subpackage here. This repository is deliberately dependency-light — its README promises no hardware interaction, and the analysis stack (vhlab-library-python, NDI-python) will depend on it to read old stims.mat files. Pulling PsychoPy, and eventually device drivers, into that dependency chain to serve a use case none of those callers have would be a mistake.

The two would share the parameter vocabulary: the structures this repository defines to read a periodicstim out of a stims.mat are the same structures a PsychoPy implementation would need to present one. That is an argument for doing the reader first regardless — it produces the shared layer either way.

What is being asked

1. Is a PsychoPy presentation port wanted at all, or are the MATLAB rigs staying as they are?
2. If wanted, is it for new experiments (design freedom, timing must merely be good) or for reproducing existing protocols (timing must match the MATLAB rig, and that has to be demonstrated)?
3. If wanted, is a separate repository the right home?

No work is blocked on this. #1 and the reader can proceed either way; this is on record so the question is asked deliberately rather than by whoever first wishes NewStim ran in Python.

🤖 Generated with Claude Code

https://claude.ai/code/session_016P5BgMWNXp1mGckW4WXk6q

Start by reviewing the referenced vhlab-NewStim-matlab commit, especially Stimuli/@periodicstim, NewStimServices, RemoteCommunication, NewStimDisplayProcs, and NewStimTestProcs. Determine whether a PsychoPy presentation port is wanted, whether it targets new or reproducing experiments, and whether it belongs in a separate repository. Done means those scope and repository decisions are recorded; no implementation is currently requested.