As @hay-k pointed out to me, we will need some synchronization mechanism at some point, like Zurich's play_after=.
At the moment this was provided by .start, but we are going to drop it in #682.
The reason is that there are some experiments, or even gates translation, that will require blocks of multiple pulses.
However, we know that .start is a higher level concept, and it's distant from all the drivers (with the further downside of making pulses aware of the sequence, and thus not isolated). So, I still believe that #682 is a good idea.
For the time being, if things will have to be synced, the calculation to ensure this will be fully on the Qibolab user side. And it's not that bad, considering we're not using that extensively this feature (or not at all), so we can avoid handling the further complexity for as long as it has no use case.
In a second stage, what we can do is to provide something like "bundles" that are relatively synchronized among them. Like sub-PulseSequence (already available) but with the guarantee that first pulses in there on every channel are starting at the same time.
My current advice would be to keep the PulseSequence as a simple list, of Pulses and Bundles (and other PulseSequences, but they would be immediately concatenated), and then we could compile the PulseSequence, by adding the required delay pulses to ensure the bundles are honored.
As @hay-k pointed out to me, we will need some synchronization mechanism at some point, like Zurich's
play_after=. At the moment this was provided by.start, but we are going to drop it in #682.The reason is that there are some experiments, or even gates translation, that will require blocks of multiple pulses.
However, we know that
.startis a higher level concept, and it's distant from all the drivers (with the further downside of making pulses aware of the sequence, and thus not isolated). So, I still believe that #682 is a good idea.For the time being, if things will have to be synced, the calculation to ensure this will be fully on the Qibolab user side. And it's not that bad, considering we're not using that extensively this feature (or not at all), so we can avoid handling the further complexity for as long as it has no use case. In a second stage, what we can do is to provide something like "bundles" that are relatively synchronized among them. Like sub-
PulseSequence(already available) but with the guarantee that first pulses in there on every channel are starting at the same time.My current advice would be to keep the
PulseSequenceas a simplelist, ofPulses andBundles (and otherPulseSequences, but they would be immediately concatenated), and then we could compile thePulseSequence, by adding the required delay pulses to ensure the bundles are honored.