Mixing was already supported through backend kwargs in STAR and Vantage. These are now deprecated in favor of the new universal mix parameter. I added a deprecation error when still using the old parameter.
The API uses a new Mix dataclass. This is slightly more annoying to type than having 3 separate parameters, but since the 3 mixing parameters (volume, repetitions, flow_rate) must always occur in a group it’s standard practice to use a data class so it’s all or nothing. This reduces ambiguity around cases like volume being specified but repetitions being 0. In the days of AI and cmd . in vscode it’s not a big deal to import it.
my thinking is that there is less risk around mix_volumemix_cycles and mix_speed having a different number of parameters or even worse, non-matching parameters. with the new api it’s clear which belong together (although in your specific case repetitions and mix_speed are the same between mix volumes)
Also agree. I see this being similar to how we use the Coordinate object for offset parameter, where users may stash a couple Mix variables to be called in aspirate/dispense: