More about the the pan_l pan_r members

[oddtime]

When we decided to keep pan_r and pan_l members in Note and Instrument class, we did it to maintain compatibility with the old song/drumkit files (see #665).

But actually we could maintain the compatibility deprecating those members (replaced by a unique pan member in [-1;1]) in Note and Instrument class, but still saving and importing the pan in the old way (using the pan law functions we have in Sampler class).
This avoids some conversions in the sampler, and simplifies the pan input/displaying in the GUI code reducing chance of errors.

Right?

[theGreatWhiteShark]

With the design decision of early days to have two values and by maintaining backward compatibility we are bound to have some additional complexity somewhere in the code.

I agree that keeping both members will cause confusion and in the worst case even bugs. But having the classes and their file counterparts contain differing fields will cause confusion too.

With more XML knowledge up my sleeve than when I commented in #665 I would suggest to hide this complexity in the XSD file for validating the .h2pattern and drumkit.xml files and the method loading them.

[oddtime]

So you would save single "pan" in xml files?

[theGreatWhiteShark]

So you would save single "pan" in xml files?

Jupp. (Since fusing them to a single value is what I thought you were intending to do).

[oddtime]

Yes