Based on a discussion with @damazter I would like to put forward the concept of a configuration parameter.

What is a configuration parameter?

• Behaves like a manual parameter but if it gets set changes flag _configure_required to True.
• Some other parameters call a configure() method whenever _configure_required==True.

What problem does this solve?

• Some instruments require configuration before a measurement can be started. Examples include the ATS driver and the Signal Hound. The configure command usually uses a set of parameters to at once upload/set some configuration.
• The configuration parameter allows interacting with all parameters of the instrument as if they are normal parameters while simultaneously ensuring that the instrument gets reconfigured whenever required.

I think this is a sufficiently common problem that it warrants a new parameter class. The current instruments that need it both have a different solution.

The signal hound driver solves this problem by using manual parameters and the requiring the user to call the configure command by hand. The ill documentation of this functionality, combined with the missing of a simple getable parameter that represents a measurement (based on my shoddy port of an existing qtlab driver) is what initiated this discussion.

The ATS driver solves this problem by introducing an unsetable AlazarParameter that can only be changed using either the private method or the configure command.

I would argue that the concept of a configuration parameter is the prefered solution to this problem. However, I explicitly put this forward as a point of discussion as introducing a new concept must not be done lightly.

( @giulioungaretti, Probably intentional but I am no longer able to apply labels to issues, would make it easier to structure things a bit.)

P.S. as this issue was motivated by the low quality of a driver that I ported this raises a separate issue as to who will work on improving existing drivers, maybe an interesting subject for a discussion on Slack.