Rockbox Development > Feature Ideas
Discussion: Pros & Cons of a potential WPS Tag Feature Request
[Saint]:
--- Quote from: JdGordon on December 06, 2009, 01:23:07 PM ---yes... I'm thinking a nice compromise is adding a conditional for how far over 0 the volume is which would please almost everyone..
--- End quote ---
Finally, someone gets it!!!!!....I stayed away from this forum for fear I was going to get into some form of argument with someone and say something I'd ultimately end up regretting.....(ie: beginning this thread in the first place, but I don't anymore now there's a small glimpse of compromise)
Given the levels of indescion surrounding this topic, and it's heated debate, it's obviously an area that could at least deserves a review....no?
I think focus has been lost on what I was originally trying to achieve, (which was NOT a huge bickering festival, rather an opportunity for Me to gauge whether or not I'm the ONLY one that has some "issues" with the way it works currently.)
I think I can safely say that I'm not, but the odds of finding a solution that suits all in "every percievable way" are apparently very slim.
One issue a lot of You seem to have is that of "hiding information from the user", which I don't necessarily agree with but can see the merits of....but I am also of the opinion that (on targets capable of >0dB at least) the current system "hides information" from the user also....
If I were to say make a volume conditional that represented a distinct state of change for all volume levels from mute to 0dB, then (depending on the player) there would be "information hidden" from the user as soon as they were to reach 0dB+, the hidden info being...."How far over this level am I?"
It's all very well and good to know when your player is clipping, but depending on replay gain, recorded line level, and a host of other sound variable features that RockBox offers.....the player in question may not even *BE* clipping or distorting in any way.....and the user would have no way of being able to visually discern "how much" over >0dB He/She is...
Making JDGordons suggestion about the best possible sollution to keeping both camps happy....no?
At least if His idea were implemented, people who want to display the players "maximum possible volume" can, and those happy with the current dB range as it is, are not affected adversly nor lose any functionality.
The problem is, not everyone that uses RockBox is going to have any, or even a limited idea, of the way dB works.....I didn't.
But everyone, every man woman and child can assertain an approximate level of volume based on a representative scale of 0 to 100%, I believe this is the reason that most every major manufacturer of DAP's has chosen to display the volume in this manner.
One other option would be to allow the user to specify a "User Defined Maximum Volume Level" that cannot be exceeded....like the iPods and probably a few other players can do....that way He/She would always know that they were displaying a volume range that they themselves have set, know to be within a safe range depending on their individual sound settings, and are familiar with.....
But that'd be yet *ANOTHER* feature idea I fear....
Give Us the choice at least, and let the end user make up His/Her own minds about how the volume is displayed. Code could easily be written that allowed the user to choose how they wanted this information to be presented to them.
Thankyou for staying objective Gordon, whilst remaining true to Your own beliefs, and for being able to compromise.
yapper:
The best solution I seen so far with current code is the widecabbie theme by Jonas Häggqvist for the E200v1. This uses the standard cabbiev2 volume graphic, but during volume changes there is a larger version of the standard graphic displayed along with the numeric volume setting (in dB).
Llorean:
Again, what useful information does "how far over 0db am I?" actually provide?
A percentage scale can only give you a loose approximation of what's going on anyway, and is only useful for giving the user a very rough "is it going to be loud or quiet when I put these headphones on."
What actual use does a changing display above 0db of information that is not actually measured in meaningful units actually give?
While "staying objective" you've neglected to give anything but "I'd like it" opinions, which are subjective by definition.
What information does a user not receive from the decibel scale currently presented to them that they would with a percentage scale and what can they accomplish with it that they can't now?
This isn't about "sticking to your beliefs" or "trying to make everyone happy." It's also about not overloading Rockbox with every idea every single person has - things need to be left out sometimes.
Is the current volume as presented in images making something hard to do? If so, what is this something, what exactly is hard to do, and can we discuss other ways to make this easier to do that don't involve creating an entirely redundant system for it?
The question of "information hidden" relates to which information actually provides meaning to a user. 1db through 6db don't provide specific meaning of much value. The fact that they're over 0db does give useful information (that it's above line level). The approximate graphical representation below 0db gives the user a rough idea of whether their earphones will be loud or soft. A mute image makes it clear there will be no sound at all. Whether clipping occurs after it or not, line level is a value that needs to be known by many users.
Your percentage scale on the other hand only provides the ability to easily give the user mute and a soft-loud scale. It hides line level and above line level from the user - thus it presents less total of the useful information.
What purpose does actual steps above 0db as visible images serve? What problem, specifically, do they solve?
[Saint]:
I guess, ultimately it's an accuracy thing, it's for the fact that it's *WAY* easier (or would be) to assign an image based on increments of say 1-10%, 11-20%, 21-30% etc. (as with the battery for example, if one were to be completely anal about the accuracy of it, 100 seperate images & conditions could be assigned to display a seperate image every time the battery level rose/fell) than it is to display *ACCURATE* representations of an arbitrary value between 1-99% of the "safe, no clipping, volume levels".
I understand completely that every functionality of the %pv tag as it is now is completely fine the way it is....I never proposed a change to the way it works.
I can see the benefits of a seperate image for mute, line level, and for values above that...so lets put that to the side as it's not in dispute.
My problem comes in when wanting to display the volume level in a similar fashion to the way the battery level is displayed.
But there's currently no way to for Me to do that without displaying at least one image twice, actually I believe to make it look even remotely correct I needed to display 2 images twice:
%?pv<%xdCa|%xdCa|%xdCb|%xdCc|%xdCd|%xdCe|%xdCf|%xdCg|%xdCh|%xdCi|%xdCi|%xdCj>
Is what I found I needed to use to get it to *look* right....but it still isn't nearly as accurate as I'd like it to be.
The second problem comes in when I want to display the volume in TEXT as a percentage (again, entirely similarly to that of the battery), as the current WPS I'm working on is based around the aspect of visual symmetry, and having one value displayed as a percentile, and one in dB just looks......weird.
I'd tried to do it using conditionals:
%pv<0|1|2|3|4 etc.
but it's not possible to do this unless the percentile range is that of "mute to 0dB" and not "mute to Total DAP volume".....I mean, it could be done (via skipping a few increments, or displaying a few twice or something) but implementing it is basically a nightmare to do the way it is now, compared to how easy it could be.
Compare it to the battery for example
text: %bl%%
Image: %?bl<-|%xda|%xdb|%xdc|%xdd|%xde|%xdf|%xdg|%xdh|%xdi|%xdj>
I don't need to tell any of you probably that that will display the battery level in a percentile and a seperate image will be displayed for each and every 10% increment of battery level.
Now,
If one wanted to do this for the volume however......
It becomes a total nightmare.
One *CAN* display the volume in text as a percentile, but the code will be a mile long, and You can only do this as far as 0dB, and would then be forced to display the same value for how ever many increments are past this point.
And that isn't a percentile, well it is, it's just not a percentile of the volume level, it's a percentile of a percentage of the total volume.
and if You look at the code I'm using for My volume "slide bar" it's no more accurate doing so with the images....
I can live with things the way they are, but all this mess and bickering was just in the pursuit of an answer to the question...."Is there an easier way this can be done? and if not, why not?"
It's not like I'm campaigning for a change that HAS TO BE MADE, of course I'm not.
And I know that not every user suggested change can be implemented, I just didn't think that this particular feature would be so difficult to replicate via other means if a way to do it directly wasn't immediately apparent.
You know, I've never meant to frustrate anyone here......and I know it's not about "sticking to Your values, not relenting, or not giving up", it's not about that on My part at all.
I would just genuinely like to be able to display My volume level not only graphically, but in text as well, as a percentile of the "Maximum Target DAP Volume", and I beleived that others may of liked this feature as well.
Evidently I was wrong, in part at least, and I appologise.
Sincerely,
[St.]
Llorean:
How are percentages *more* accurate since behind the scenes they'll be approximated to DB values anyway? Of those 100 steps for 100%, as many as half of them won't even change the volume. Possibly more.
Also, what problem does having an accurate image-based display solve? Unless you can count the pixels, you still can't re-set the volume to the same level as before without seeing numbers.
Basically, you didn't answer my question about what problem it solves.
You've basically instead gone off on a tangent about how to use percentages to make a completely inaccurate volume display while calling it "more accurate" because yes, it will display a consistent amount of images for every player, but either it will have to skip images (because the volume will need to jump in db-sized steps anyway) or button presses will need to not change volume (because there aren't as many db as there are percentages).
Either way it's physically impossible for a percentage scale to be as accurate as simply displaying the db number while still presenting a consistent number of steps for every player.
So trying to use accuracy as an argument for it doesn't work - the players simply don't work that way. Showing it as percentage doesn't change the fact that behind the scenes it's using db, and thus the step sizes are tied to the db steps.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version