Add abstract modulator class

[gjover]

Having in mind experiments where light is modulated in a series of patterns or parameters (as SIM experiments) I am proposing an abstract modulator class for light modulators that may iterate over a sequence of parameters.

The idea behind is to have an interface class for a cockpit modulator device that can be used in experiments.

[iandobbie]

I know this is 2 years after the fact. I was moving country and otherwise distracted. I am now trying to deal with loads of older issues and get them dealt with, closed or at least progressed.

We do actually have an implementation for an SLM which we use. This was the first new device we built when planning microscope. This prototype, then influenced how we did all the other devices, unfortunately we never quite reached the point of integrating the SLM device itself into microscope.

In theory this would be relatively easy and should definitely be done. I keep meaning to look at doing this transition but never quite got to the top of the todo pile.

[juliomateoslangerak]

I also would like to work on this. I had worked on the changes brought by the new SDK of boulder non linear (BNL now Meadowlark) SLMs so that is relatively fresh in my mind. I remember I proposed to do this in some of our meetings but never got the time to work on that. One of the points of discussion was how we should send the patterns to the device. Currently it is the device-server that generates the patterns specifically for SIM. That is not very extensible or flexible. We discussed a number of options. Out of my head:

• the client sends the pattern as a numpy array along some required information, like the wavelength. We considered the performance implications of this but, is it a real problem?
• send the function to generate the patterns. We decided that that was not a good idea.
• A third package, like AOtools would be in charge of this.

While writing the updated device server for BNL SLMs I also cranked in some routines for calibration of the SLM and using a microscope-camera, not very neat and finished, but it would be great to have a little app, in the spirit of BeamDelta, to do these calibrations.

I could start to write down the interface based on a camera device and my version of the SLM device.

[iandobbie]

I see two separate tasks here.

1) Move the current SLMserver code to microscope allowing the removal of the independent server and custom communication code and the duplication.

2) Fully define the modulator API for microscope and decide exactly what functionality we need and where it is hosted (cockpit versus microscope versus AOtools).

I suggest that we separate the work into these two tasks, then it will be relatively easy to ensure that we continue to maintain the current functionality while we do this improvement and make it easier to add additional modulators in future.