Hi Jonathan,

Le dimanche 23 juin 2013 à 23:03 +0930, Jonathan Woithe a écrit :
Hi Phil

This will probably be a quick response since it's getting late here.  Not
everything I write will necessarily make sense. :-)

> 1.a Fix the rule that columns are inputs and rows are output in
> libffado. ffado-mixer and further the user himself will decide how is
> represented the matrix in his own view. There is no need to change the
> name of the interface function: to make things clear, I will probably
> keep the indirect functions getInName and others in ffado-mixer, which
> will reduce to the call to interface.getColName and so on.
> 
> 	- such a rule requires no modification for RME. The modifications
> required for DICE EAP devices are easy to implement.

To be honest I'm not sure that this is any different to what is currently
the case.
Presently, RME returns input informations for any call to getCol..., DICE EAP return output informations.
Let me recall I had to correct dice_eap.cpp some months ago because there were bugs related to this kind of confusion, so this is clearly a source of confusion.
In the present revision, this yet induced complexification of the implementation in ffado-mixer. Trying to add a choice of the user will lead to additional complexity and probably much confusion for any further devel. If DICE EAP implementation is modified for conforming the same rule than RME, this leads to many simplifications.

  The underlying dbus matrixmixer control makes no assumptions at
all about what its rows and columns represent.  This is one of the reasons
that getColName() and getRowName() exist.  
dbus is not involved here. How getColName() and getRowName() (among others) are implemented in libffado is the question. What is the present usefulness that RME and DICE EAP implement opposite rules while sharing the same UI except adding complexity, and much more complexity for a user choice to be provided ?

Ultimately there is embedded
knowledge of what a row and column represents when a matrixmixer dbus
control is put in place, and it's up to the ffado-mixer UI (or any other UI
which interfaces to this) to work out the best way to represent the control
visually.

So to summarise I can't see what is being changed here: it's just restating
what the present situation is.  As far as I can tell libffado doesn't have a
rule "that columns are inputs and rows are output".  Rows and columns can
already be whatever is required to suit a particular purpose.
The main reason this has come up is that the "per output tab" implementation
obviously requires that ffado-mixer have prior knowledge of whether rows or
columns are considered outputs.  There is really no way around this other
than to have the mixer code explicitly tell the matrix mixer widget which
case applies (that's the purpose which Columns_are_inputs etc serves).  I
guess an additional dbus control could be added so the driver itself
communicates this information, but I don't thing the added complication is
worth it in the long run.

Given that as far as I can see the current situation already matches your
idea, perhaps I've misunderstood something.  Could you clarify?

DSP mixer have inputs and outputs which are what libffado is aware of; in other words, "rows" and "columns" make no sense for libffado which should only be able to interface something like getInCount(), getInName(), etc ...
"Rows" and "columns" just refer to a particular graph the ffado-mixer (or any interface) developer choose to represent the different controls.
Now, for some historical reasons,  the interface functions are named getRowCount(), getRowName(), etc ..., so ffado-mixer does not know which ones are the inputs and which ones are the outputs since they are presently implemented differently depending on the device. And there is no usefulness for such different implementations which additionally lead to confusion (and the past experience shows that  it is really confusing) and make the ffado-mixer implementation yet more complex.
In view of implementing a choice for the user, I find that simplifying at first is largely desirable and lead to no functionality loss.

> - the argument Columns_are_inputs then just refer to the default view
> (for DICE EAP, it is preferable that the old convention is kept in
> apparence for the user).

Again, isn't this pretty much the current sitation?

No, presently "Columns_are_inputs" must match what is implemented in the libffado interface functions: typically, using Columns_are_inputs for DICE EAP devices would lead to the wrong behaviour.

> 1.b The full name for each row and column should be exclusively the one
> given by the libffado interface.

I have no problem with this.

> - The shortened naming In:.. or Out:.. will remain as a choice for the
> user.
> - As well hidden rows/columns remain with their simple numbering.

No problem.  I can see that in certain situations users may well want to
shorten the name as much as possible.

> 1.c The present font size button will be replaced by a more complete pop
> up menu (including the font size change or the use of shortened names.

Agreed.  Plus whatever other display options might turn up.

> 2. An alternative for hiding "per output tab", as well as matrix view
> (in an exclusive OR framework) has to be implemented, including a
> default as an argument of MatrixMixer.

Yes.  There could well be uses of the matrix mixer for which the "per output
tab" makes no sense.  Being able to hide these tabs has obvious benefits.

> 3. There is a need to unify the linear/decibel conversion for the
> different kind of sliders, the present implementation being rather a
> "hack" (the way round-off errors are taking into account).
> Deciding for a specific accuracy (typically +-0.1dB, as in ardour for
> instance - which look like the limit of human perception) would be of
> help.

What "different kind of sliders" are there at the moment?  All present
controls relate to volumes, making them all volume faders.  Are you thinking
of future requirements?

Presently, three different linear/dB conversion are implemented in MatrixMixer at different locations, which round-off differently: this is indeed a problem because the "sliders" interact the one with the other. There is whatever a need to change the situation: at least, each conversion should be a call to the same conversion function to avoid any undesirable recursion.

This will require more thought.  One fairly significant issue is that at the
hardware level fader values are often expressed using a linear scale.  This
immediately means that the resolution of the faders is not constant when in
dB space.  If one implemented high-resolution faders (to 0.1 dB for
example), most devices would appear very jumpy at low dB values because the
hardware will only change volume at 3 dB intervals or there abouts.  It
turns out that the present implementation of the matrix cells is the closest
match to what most hardware presently does.
Presently, the faders of matrix view apparently have a 0.01 dB resolution (in some cases, for a reason I don't presently know, even larger resolution can be encountered: typically a number like 0.00134 in the spinbox !).
The faders in per output tab have only a 1dB resolution: so I was rather asking for a more limited resolution for faders !


Regards,

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