Hi Phil > I committed some works around our last discussions as revision 2358 to > 2365. I've had a quick look at the result. These look good. > There is still some work to do, especially enabling the transpose view > of the matrix mixer. Also, I have to re-read our previous email exchange > to see what is possibly missing. I should have some time for other fixes > before the end of next week. No problem - I look forward to the next steps. > In between, there is of course a need for testing these changes, > especially for the RME device you use to own. Sure. I have tested this briefly. I like the display of the fader value under the per-output faders - that looks good. The biggest issue I see at present is probably due to a round-off error in the coversion to/from dB. In the matrix mixer, if I select "3 dB", what I end up with in the matrix cell is 2.2 dB. I also notice that for the RME, which has a maximum (linear) setting of 0x8000, the matrix cells and per-output faders insist on calling this 5.7 dB. Along similar lines, "0 dB" maps to 0 correctly, "-3 dB" becomes -2.9 and "-20 dB" becomes (correctly) -20. I haven't had a chance to look at the dB mapping function but I expect that there's a roundoff effect in there, given that the mappings used to be fine and 6 dB was the maximum displayed in the matrix view.
This is related to the interaction between the matrix cell and the corresponding slider in the per output view. Any change in the first one must propagate to the latter (and reversely) thus leading to a Qt signal, then entering a recursive process which stops when the values are strictly identical. Since both matrix cell and slider work in the dB space, there is a succession of dB to linear and linear to dB conversion we must ensure that they leads to a unique linear value.I've had a really quick look at the code and can't see any obvious reason for the change in behaviour.
Oh, sorry: but your new implementation looks like more robust and flexible, so it is a clear improvement and will make easier the further devel I planned.I also discovered that the more complex widget hierarchy now in use broke the mute and invert functionality. This was because the MixerNode's parent was no longer the top-level MatrixMixer object, so the corresponding dBus interface object couldn't be found via parent(). I've introduced a separate member to keep track of this now, so any future widget changes won't upset it. See revision 2366.
Philippe Carriere <firstname.lastname@example.org>