Since some time, it is possible to spcify acquisition channels explicitely in measure operations. This is a very powerful interface that can be of great use, but there are some issues I noticed when playing around with this. For example, when exeucting an experiment with the `ScheduleGettable`, that has the following `Measure` operation: ```python Measure(b1, a1, acq_channel=("b1", "a1")) ``` I'd expect an output dataset from MeasurementControl that has four data variables (I+Q for each qubit), which are something like: - `y0`: I-values for qubit `b1` - `y1`: Q-values for qubit `b1` - `y2`: I-values for qubit `a1` - `y3`: Q-values for qubit `a1` Instead, the qubits are 'swapped' around. A typical use case would be two-qubit experiments (like conditional oscillations), where we'd have something like ```python target = b1 spectator = a1 Measure(target, spectator, acq_channel=("target", "spectator")) ``` I'm afraid that always ensuring we put the acquisition channels in a sorted order ourselves is very difficult, because historically we've always assigned 'roles' like this implicitely in this order already. The culprit seems to be [this line](https://gitlab.com/quantify-os/quantify/-/blob/main/quantify/measurement/control.py?ref_type=heads#L385). I understand this is useful, because you become insensitive to the order of data variables in the dataset (which can probably not be guaranteed). It does introduce the problem above, though. I see multiple solutions (probably not an exhaustive list): - Teach MeasurementControl to accepts datasets, so we don't have to do the conversion at all; - Provide the acquisition channels to the formatting function, to order them based on the specified channels instead.