Re: [FFADO-devel] Change proposal in MatrixMixer/Automatic routing refresh

[Jonathan W. <jw...@ju...>]

Hi Phil

> > I'm finally getting a chance to go over some of this stuff.  I'm a little
> > confused about the patchs you've sent through, the ordering (if relevant)
> > and so on.  Would you be able to resend a definitive patch set that I can
> > use to test against the RME devices?  Of primary importance is probably the
> > matrixmixer changes; the others are smaller, simpler, and close to being
> > ready for merging already I suspect.
> 
> Enclosed are the patches in the relevant order. I tested them today
> against the last version of Adi git repos which seems to be almost up to
> date. Hope it will work.

Thanks for this.  I tested the 0001 patch (enhanced matrix mixer) which
patched head fine, although one chunk had a fuzz value of 2:

  patching file support/mixer-qt4/ffado/widgets/matrixmixer.py
  Hunk #5 succeeded at 398 with fuzz 2

I haven't looked into why.  It's undoubtedly a minor thing.

I've run the revised matrixmixer widget against the FF800 as a test.  It
worked better than I expected to be honest, and didn't crash even in the
"single row" case.  The existing scrollbars still work fine.  Good stuff -
it's a solid base to build on.  The following are some comments to guide
further development; many of these overlap what we have previously covered.

 1) The font size used for the channel names in the matrix view is too small
    to read.  The font resizing code will definitely need some revision.

 2) Probably the most significant new issue is the realisation that the use
    of columns and rows for the RME is not the same as for the Saffire.  The
    new code assumes that each column represents an output and each row an
    input.  However, the RME druver uses the matrix mixer in a manner that's
    closer to a traditional monitor mixer board: each column is an input
    channel, and each row represents an output.  This means that the present
    code's "output" tabs are actually showing faders for a particular input.

    To fix this, we really need a way to tell the matrix mixer what is
    represented by a row: an input or an output.  The tab code could then
    adapt accordingly.

 3) There is a small issue in the "single row" case used by the RME mixer to
    represent output master fader values.  Contrary to the "input" and
    "playback" mixers, here each "column" is an output so each "tab"
    correctly includes a single fader.  However, there's something funny
    going on.  At the top of the "Out:01" tab for example, I have:

      Mixer/Out:01
      (Line out 1)

    followed by an empty frame.  This is in fact the label used for the
    first column in the matrix view.  Under that, in a smaller font I have:

      Mixer/In:01
          ()

    Then comes another empty frame, and finally (under that) is the fader. 
    Something's not quite right here.

 4) For completeness, here's what I'm seeing for the 28x28 "input mixer",
    with reference to the "Out:01" tab. There's a blank space at the top of
    the tab, followed by an empty frame which spans the width of the tab
    area.  Under that come the respective faders.  These show:

      Mixer/In:01
      (Line out 1)

    an empty frame the width of the channel strip, and then the fader
    itself.

    All in all, I'm not sure what the empty frames are meant to be.

    This example also highlights the switching of the meaning of rows and
    columns in the RME mixer.  The "Out:01" tab shows the faders
    from input 1 to each output - so it's really a per-input view rather
    than a per-output view.

 5) To deal with the single-row case, having the option to disable the
    per output tabs would be useful I think because in this case they
    don't provide anything that the standard matrix view doesn't.  This
    is a low priority though: it could always be added after the initial
    patch is merged.

I like the user channel naming ability this patch adds - it will require
load/save functionality before it becomes truly useful but we definitely
need this.

All in all, this patch greatly enhances ffado-mixer for devices which make
use of the matrixmixer widget.  Once the rough edges have been dealt with I
think it can go in.

> I am now at home and able to improve the modifications following your
> recommendations.

Sounds good - I look forward to seeing the revision of this and the other
two (which deal with the automatic mixer adjustments in response to routing
changes on the relevant interfaces).

Regards
  jonathan