On Mon, 9 May 2011 12:44:54 +0000 Jacob Meuser <jake...@sdf.lonestar.org> wrote:
> On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: > > On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser <jake...@sdf.lonestar.org> > > wrote: > > > On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: > > >> * sorted output looks cleaner, prettier; > > >> * it's easier to find the variable you're looking for in a sorted > > >> output; > > >> * hierarchical variable names yet unordered? doesn't make sense; > > >> * this way mixerctl's behaviour will be closer to other *ctl programs > > >> which output variables in an ordered fashion (audioctl, sysctl, > > >> wsconsctl). > > > > > > these are all matters of opinion, except for "hierarchical variable names" > > > which is not technically the case here. > > > > > > > Okay, but what about making mixerctl more similar to other *ctl? > > *sigh* > > $ wsconsctl > (blah) Permission denied > > $ usbhidctl > usage: (blah) > > $ ikectl > missing argument: > > $ gpioctl > usage: (blah) > > or how about, what other *ctl program is almost entirely hardware > dependent? > mixerctl uses audio(4). audio manpage: "audio, mixer - device-independent audio driver layer" > > >> Before: > > > > > > note how the controls are grouped (mostly) by "widget". please read > > > azalia(4). > > > > I did notice that. > > Unfortunately, I can't access my amd64 machine right now. It has > > like 2 to 3 times the amount of variables shown here and I think I saw > > some vars there, for which I couldn't figure out by which criteria were they > > ordered. > > If mixerctl's intention is that the most important thing is the widget, > > then the widget's name should've been placed in front. > > I tried this just now, putting widget in front, then the mixer class -- > > it looks horrible, completely unscannable. > > Maybe the mixer class is the most important thing after all, since > > this is the most generic thing you can group various widgets by. > > ok then, why do some devices have 'outputs.dac' yet others have > 'inputs.dac'? what is the difference to the user? which is more > correct? why? > I have absolutely no idea. I'm not an audio equipment manufacturer. I don't understand how are these questions even relevant. > this has been the case since long before azalia(4). if you cannot > explain this, then you just don't understand. > > > > > > >> s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl > > >> outputs.hp_source=dac-0:1 > > >> outputs.hp_dir=output > > >> outputs.hp_boost=off > > >> outputs.line-in_source=dac-2:3 > > >> outputs.line-in_dir=input > > >> outputs.mic_dir=input-vr80 > > >> outputs.spkr_source=dac-2:3 > > >> outputs.spkr_dir=none > > >> outputs.spkr_boost=off > > >> inputs.dac-2:3_mute=off > > >> inputs.dac-2:3=152,152 > > >> inputs.dac-0:1_mute=off > > >> inputs.dac-0:1=152,152 > > >> inputs.sel_source=mic > > >> outputs.sel=126,126 > > >> inputs.sel2_source=line-in > > >> outputs.sel2=126,126 > > >> inputs.sel3_source=sel > > >> inputs.sel3_sel=119,119 > > >> inputs.sel4_source=sel2 > > >> inputs.sel4_sel2=119,119 > > >> record.adc-0:1_source=sel3 > > >> record.adc-0:1_mute=off > > >> record.adc-2:3_source=sel4 > > >> record.adc-2:3_mute=off > > >> inputs.beep=85 > > > > > > and at the end are the "pseudo" controls. the ones most people are > > > most interested in. so even if the rest of the controls scroll by > > > when you do a simple "mixerctl", you see these controls. > > > > > > > Just by looking at these variables, I cannot distinguish which ones are > > "pseudo" and which aren't. This is an implementation detail, I think > > the user of an interface shouldn't have to care about implementation > > details. > > I cannot provide any evidence that most people are or are not > > interested in those "pseudo" vars, but I thought most of the time > > people are interested in something like "play an mp3 file", "watch a > > video", simple stuff like that. In this case one would probably be most > > interested in outputs, volume controls... > > as in, 'outputs.master' ... the one that's tied to the keyboard keys on > laptops. this is by far the most important, most used mixer control. > Suppose I have bought a new computer, can I predict where exactly these controls will pop up in the output? > It's possible to adjust > > sorting and output these vars last, by modifying the cmp function. > > that is ridiculous. > > > And I can argue that it is still easier to find what you're looking for > > when the output is sorted, especially considering that the output of > > mixerctl can vary widely between different computers. > > please do give an example of how sorting them makes "finding what you're > looking for" easier. please. and it better be easier than piping > through sort/grep. I'll repeat that you cannot rely on 'inputs' or > 'outputs' having true meaning. sorry, but you can't. trust me on > that one. > Binary search. I might not remember the exact name of the variable. Why should I be suffering if someone has broken hardware? From all the computers I owned -- there wasn't a single time when vars were labeled incorrectly. Even if I have broken hardware, I will know this the first time I use it. No need to tell me that over and over again. This will not fix my hardware. > > >> outputs.hp_sense=plugged > > >> outputs.line-in_sense=unplugged > > >> outputs.spkr_muters=hp,line-in > > >> outputs.master=153,153 > > >> outputs.master.mute=off > > >> outputs.master.slaves=dac-2:3,dac-0:1 > > >> record.volume=0,0 > > >> record.volume.mute=off > > >> record.volume.slaves=adc-0:1,adc-2:3 > > >> > > >> After: > > >> s@d630:0:/usr/src/usr.bin/mixerctl$ ./mixerctl > > >> inputs.beep=85 > > >> inputs.dac-0:1=152,152 > > >> inputs.dac-0:1_mute=off > > >> inputs.dac-2:3=152,152 > > >> inputs.dac-2:3_mute=off > > >> inputs.sel2_source=line-in > > >> inputs.sel3_sel=119,119 > > >> inputs.sel3_source=sel > > >> inputs.sel4_sel2=119,119 > > >> inputs.sel4_source=sel2 > > >> inputs.sel_source=mic > > >> outputs.hp_boost=off > > >> outputs.hp_dir=output > > >> outputs.hp_sense=plugged > > >> outputs.hp_source=dac-0:1 > > >> outputs.line-in_dir=input > > >> outputs.line-in_sense=unplugged > > >> outputs.line-in_source=dac-2:3 > > >> outputs.master=153,153 > > >> outputs.master.mute=off > > >> outputs.master.slaves=dac-2:3,dac-0:1 > > >> outputs.mic_dir=input-vr80 > > >> outputs.sel=126,126 > > >> outputs.sel2=126,126 > > >> outputs.spkr_boost=off > > >> outputs.spkr_dir=none > > >> outputs.spkr_muters=hp,line-in > > >> outputs.spkr_source=dac-2:3 > > >> record.adc-0:1_mute=off > > >> record.adc-0:1_source=sel3 > > >> record.adc-2:3_mute=off > > >> record.adc-2:3_source=sel4 > > >> record.volume=0,0 > > >> record.volume.mute=off > > >> record.volume.slaves=adc-0:1,adc-2:3 > > > > > > I do not find this more useful. prettier, perhaps, but not more useful. > > > in particular, this (further) breaks the widget-wise grouping on some > > > devices. please read azalia(4), "inputs" and "outputs" is really just > > > a hint, and making it more precise is much more difficult than adding > > > sorting to mixerctl ... > > > > > > > Well it doesn't add any new functionality or anything, sure. I'm just > > trying to improve my user experience. > > For me, this would be useful because I wouldn't have to append "| sort" > > to mixerctl every time I use it, and because I wouldn't have to > > remember that it works slightly differently than other *ctl programs. > > *sigh* > > THE MIXER CONTROLS ARE NOT HEIRARCHICAL. > It doesn't matter how mixerctl and other *ctl are _implemented_. They should behave as similar as possible. > > It would also be more aesthetically pleasing, making my computer just > > that little bit friendlier, easier to use. > > Besides, there's "correctness" mentioned in project goals, the reason > > it looks prettier is because it is more correct, I think. > > ok, now I'm absolutely positive know you don't understand the issue > and just want to add more junk to what is supposed to be a VERY SIMPLE > program. write yourself a new mixer program if you feel the need; > adding sorting to mixerctl IS NOT GOING TO HAPPEN. > Fine. > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org
