Presently, RME returns input informations for any call to getCol..., DICE EAP return output informations.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.
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 ?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.
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 ...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?
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.> - 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?
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.> 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, 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 !).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.
Philippe Carriere <email@example.com>