Le jeudi 08 août 2013 à 22:02 +0930, Jonathan Woithe a écrit :
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

This bug should be fixed in revision 2367.

I've had a really quick look at the code and can't see any obvious reason
for the change in behaviour.

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.
There is possibly something more robust to do (that matrix cell and slider exchange reduces to dB values for instance), I will try to think about this later.

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.

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.


Best regards,

Philippe Carriere <la-page-web-of-phil.contact@orange.fr>