@giulioungaretti
Taking a look at the parameter.CombinedParameter
The way it works now is that it settable only to a certain index of a set array.
I would argue that it would be more useful if these parameters are settable to any tuple.
Then it would also be logical to implement a get function for these parameters that return a tuple as well.
I thought that this was also the solution we discussed in the our last QCoDeS meeting.

The reason why I would like this implementation is the following.
There are two different sorts of combined parameters in my mind.
The first kind is just a collection of individual parameters combined in a vector as is implemented in QCodes Now.

The other is a single parameter with many vector components. Setting this parameter only calls a single set function. (An example of this is the magnetic field. It has three components, but they can only be set together, not seperately.)

Then, it should be possible to get and set this parameter as any other, but instead of scalars, one would have tuples.

As for implementation. (this is just my humble oppinion)
Rather than implementing vector parameters around the CombinedParameter, I would like to see that the behaviour of parameters is generalized to being able to handle vecotr values.

Combining two parameters (of dimension 2 and 3 for example) should then give a parameter (let'
s call it par) which can be set like
par.set([[1, 2], [9, 8, 7]])

As a summary:
I think the problem with the current implementation of CombinedParameter is that it does enable native support for vector-like parameters, it only covers the (although very useful) single usecase for a path-like sweep of parameters that already exist.