Hi Andrew,

I'm really sorry I didn't respond to the original issue in a timely fashion - it came in when I was on holiday and then dropped out of my attention ... I'll follow up with more detail shortly (probably on the original issue), but the main thrust of my thoughts are as follows:

• you'll hit the limitations of pure-software point-scanning pretty quickly, and it would be good to structure things so that the architecture continues to work even when you have more deterministic scanning (the simplest here would likely be to have position command voltages and sensor reads running from a constant clock in an DAC card, arduino, or something else with deterministic timing). It's very likely in this case that you would want to buffer an entire frame on the ADC card and read that buffer in one go.
• my gut feeling is that going through the scope.state mechanism might have some undesired wrinkles (notably automatic camera restarting when changing some state variables)
• there seems to be some duplication in the motion logic with the existing point_scanner class currently used for tiling (this was originally written to do half-assed confocal using a small ROI on camera and summing the pixels).

Best wishes,
David

Working towards a more sane/complete implementation. As it stands now the BaseScanner class outlines an interface for a mirror/stage scanner to hold a buffer of frames, and a PointscanCamera class acts like a ~normal camera class pulling frames from the BaseScanner instead of e.g. a camera FPGA.
There are two init_sim_X.py scripts in a pointscan_shim folder for testing/debugging.

Followed your suggestions, @David-Baddeley , for multichannel, signaling 1 frame for each channel to be read in by the frameWrangler. The Preview in PYMEAcquire is a bit odd, but for now this is a really nice improvement for me to be able to use the spooling/saving framework.

I modified PYME/Acquire/SpoolController.py and protocol_acquisition.py to check for the number of channels of the PointscanCamera and mofidy the shape accordingly. If there's one thing to review early / provide some feedback on, @David-Baddeley , it'd be nice to know how bad I hacked it there ;)

@barentine - as noted above, SpoolController changes will need revisiting. Need to think a bit about best way to handle this, but is likely to depend on your exact requirements, specifically whether your colour acquisitions need to be ProtocolAcquisition instances (or subclasses), or if they would be better as an XYZTCAcquisition subclass. To help answer this there are 2 questions:

• Do you know the sequence length in advance?
• Do you need the protocol features (e.g. modifying laser powers during acquisition etc ...)?

If the answers are yes and no respectively it would likely be better to use XYZTCAcquisition as a base class. Using ProtocolAcquisition might also bring some interesting complexity linking events to frame numbers with the emitting multiple frames paradigm.

If you still think that ProtocolAcquisition is the correct acquisition type, a short term workaround (although possibly still not a final one) would be to move the logic you have in SpoolController into ProtocolAcquisition. This would avoid the XYZTC breakage, but would not, e.g., let you do colour z stacks.

Really appreciate the help, @David-Baddeley !

I don't have the best overview of the acquisition backends, so I appreciate your patience.

In answer to your questions,

• at some point it would be nice to image until bleach without knowing ahead of time how long that will be. This is a less immediate need, and possibly not urgent to have undetermined series lengths at the same time as Z stepping
• I would like to use protocols for laser shuttering/unshuttering and possibly triggering an acquisition on an ~overview camera in a separate instance

It seems like maybe a reasonable thing to do is move logic out of SpoolController into ProtocolAcquisition, at least for short term, because I'm comfortable with protocols and might want to use them.

I think I see now how to register my own acquisition type for the subclass XYZTCAcquisition approach (will try and remember to call some of this out in configuring PYMEAcquire doc at some point). That said, it seems odd for me to subclass just to use an argument, channel_settings that already exists in XYZTCAcquisition, but as far as I can tell doesn't get used anywhere. How/where should one be presenting channel_settings so they'll get used appropriately?

For now channel_settings is just a stub, but we should really flesh it out a bit. It's stubbed in the base class to allow the maximum flexibility for how channels could be implemented, and I haven't put any effort into fleshing it out so far. There are at least 4 different legitimate ways to implement multi-channel acquisitions:

• Monochrome camera + filter wheel and/or control of lasers / LEDs
• Colour camera
• A combination of the above two
• Something else entirely (e.g. OIDIC phase shifts - if you still have access to the BewersdorfLab github, there is an example XYZTC subclass in the pyme-oidic repo).

In the reasonably short term we should probably add a channel implementation to the default XYZTC acquisition, but maybe by making a subclass the default that gets used for z stacks etc rather than modifying the base.