Need Help Re: Displaying the Volume in 10% increments using Bitmap Strips

[[Saint]]

Sounds easy doesn't it?

And in theory, it is. Well the code seems simple enough:

[Example 1]

%?pv<%xd*n*a|%xd*n*b|%xd*n*c|%xd*n*d|%xd*n*e|%xd*n*f|%xd*n*g|%xd*n*h|%xd*n*i|%xd*n*j>

where *n* = the %xl ID assigned to the Bitmap Strip and a, b, c etc. the sub-image

And this code does indeed work, many WPS's use that exact same piece of code, but the problem I am having is that the first 60/70% or so (ie the first 6 or 7 sub-images in the Bitmap Strip) seems to display in equally sized increments, but then the remaining 40/30% (or the last 4 or 3 Bitmap Strip sub-images) seem to display far too quickly.
What I mean by that is that the spacing between the display of the Bitmap Strip sub-images representing approximately 70 to 100% of the total volume aren't actually *spaced out* at 10% increments, with what I'm experiencing personally it seems there is only a spacing of approximately 1-2Db between the sub-images that *SHOULD* (in theory at least) represent 30/40% of the total volume.

It just doesn't display *smoothly* between the transitions.

The only way I have found to *ACTUALLY* display the volume in 10% increments is this:

[Example 2]

%?pv<%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|
%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*c|
%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*d|%xd*n*d|%xd*n*d|
%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|
%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|
%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|
%xd*n*g|%xd*n*g|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|
%xd*n*h|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*j|
%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j>

where *n* = the %xl ID assigned to the Bitmap Strip and a, b, c etc. the sub-image
*note that there are 11 "a's" instead of 10 to accommodate for mute.

This is the only way I've found personally (so far) to *smoothly* perresent the volume in 10% increments, and in the WPS I'm building at the moment an accurate disply of the volume using a 10 position "Slide Bar" is kind of an integral feature of it.

And, unfortunately, so is an animation for the Playmode and the bloated code I have to use to display the volume in nice, smooth, equal increments uses up valuable tags that would be better suited to allow me to pack in a few more on screen animations.

I seem to of hit the limit at 1023 Tags+, so the obvious thing to reduce the amount of tags used would be to use [Example 1], but that leads to the weird behaviour I've tried to explain Re: the last 3/4 images not being spaced correctly. And the code in [Example 2] is bloated and takes up tags I'd rather use for animation.

Can anyone tell me why it is that [Example 1] isn't working like I believe it *should* be? ie. each sub image representing an equal 10% portion? I've taught myself WPS code via a lot of reverse engineering of other peoples code, so I'm very much open to being corrected, or to have a better method of doing things explained to me.

Any help with this greatly appreciated, I've been working on this WPS for a while now and I'm almost at 100% and ready to post it, but just a few things like this keep me from doing so.
Also, my apologies for the lengthy post, I'm just a *little* bit anal about attention to detail 



Sincerely,
[St.]

[EDITED BY MODERATOR TO SPLIT VERY LONG LINE]

[Llorean]

How many "last sub images" exactly? There's usually a single image for "full volume" (0db) and a single image for "greater than full volume" so these two will always be outside the percentages you expect. Also, I'm not sure what player you're doing it for (may have missed it in there). Each player has a different volume range depending on hardware and it might make some differences.

[JdGordon]

What error are you getting that makes you think you are hitting a token limit? There shouldn't be any more limits (we did a fair bit of rework here to remove these annoyances)...

[JdGordon]

does %pv do the same as "percentage" if you use 13 images (if you want 10% increments) in the order mute|10%|20%|30%|40%|50%|60%|70%|80%|90%|100%|100%|>100%   the code seems to suggest that would work

[[Saint]]

Firstly, thank You all for the prompt replies.


Re:

How many "last sub images" exactly? There's usually a single image for "full volume" (0db) and a single image for "greater than full volume" so these two will always be outside the percentages you expect. Also, I'm not sure what player you're doing it for (may have missed it in there). Each player has a different volume range depending on hardware and it might make some differences.

Not sure what You mean exactly by "last sub images".
The code I'm currently using ([Example 2] from My first post) calls the first sub-image (being a) 11 times in an attempt to accommodate for "mute to 10% of the total volume", each subsequent sub-image (being images b to j) are called 10 times each in an attempt to represent the remaining 90% total volume in 9 equal increments following the first.
I'll post a .png version of the image I intend to use so You can see what I'm aiming for.

The code *seems* to work, visually at least.

But I know for sure that if it's not just outright wrong, that there's a better way of doing it.


Re:

What error are you getting that makes you think you are hitting a token limit? There shouldn't be any more limits (we did a fair bit of rework here to remove these annoyances)...

The error the RockBox iPod Nano Simulator is giving out is:

WARNING: Maximm Tokens exceeded (1023)

When I was building this WPS I'm currently working on, I coded all the animations I planned to use first (and it was a beautiful thing I might add ), and then when it came to doing the Viewports and the rest of the information I wanted to display onscreen I found I was hitting this limit and that in order to display the elements I wanted to, I had to make some pretty drastic sacrifices in the animation department...which really sucked, but I've found a compromise between the two that doesn't seem to exceed any limits at the moment, but I'm at a point where I just CAN"T add anything more to My code, or things on the WPS just stop working when this limit is exceeded.

I had some REALLY big plans RE: animation for this WPS....it'd be nice not to have to worry about limitations in the code like that, I'd rather face running out of room on the Nano's microscopic screen lol


Re:

does %pv do the same as "percentage" if you use 13 images (if you want 10% increments) in the order mute|10%|20%|30%|40%|50%|60%|70%|80%|90%|100%|100%|>100%   the code seems to suggest that would work

No, I'm sure that %pv *ISN'T* a percentage, as the volume is displayed according to db. and in My opinion db isn't really a scale of anything in particular but rather an arbitrary number on a "pretend" scale.....correct Me if I'm wrong.

What I'm aiming for is to find a *CLEAN* code that will display 10 Bitmap Strip sub-images that will represent:

mute to 10% of the "Total Volume", and each of the 9 subsequent images to represent the following 10% increments up to 100% of the "Total Volume"


I appologise if My understanding/missunderstanding of the WPS code makes it difficult to get My point accross.
All My knowledge of the WPS code is self taught, so My understanding of things may differ greatly to someone who is fluent in the code.



Sincerely,
[St.]

[Llorean]

db is much less a pretend scale than percent volume. Decibels are a relative scale - they let you know exactly who much you're reducing the sound from line level (or if you're amplifying it above it) whereas a percentage "volume" doesn't provide any practical useful information.

Some players have a range from -54 db to +6. Others go from -74 to +12. Your percent volume on the other hand will more or less always go from 0% to 100% even if 1% is significantly louder on one player than another (especially if your WPS fits the screen of multiple targets) or if on one player 100% is line level, while on another player 100% is amplified beyond line level and causes clipping.

The last two images are 100% volume and >100% volume in the %pv conditional, which is why it may be balancing improperly - the second to last image probably only covers one "level" of volume, while the last image probably covers a set amount that doesn't correspond (in your way of thinking) to 10% at all.

Basically %pv gives you an arbitrary list. The first element is always mute. The last two elements are 100% volume, and "all values greater than 100%". So if you want increments of 10% the list must have 13 entries. Mute, 1-10%, 11-20%, 21-30%, 31-40%, 41-50%, 51-60%, 61-70%, 71-80%, 81-90%, 91-99%, 100%, >100%. You can re-use an image for some of these if you want to merge them (and the percentages may be slightly different such as 1-9%, I'm not sure how it divides them).

[[Saint]]

db is much less a pretend scale than percent volume. Decibels are a relative scale - they let you know exactly who much you're reducing the sound from line level (or if you're amplifying it above it) whereas a percentage "volume" doesn't provide any practical useful information.

A 0 to 100 percentage of Total Volume provides usefull/and valuable information, if that is the desired effect You wish to achieve.
And in My case, it is.

The problem is, I want a symmetrical effect between the battery meter (which DOES show a percentage, unless I'm wrong again) and the volume meter.
Both of these values are displayed in text on the screen in the WPS as well. I'd just like to get the volume "slide bar" working as smoothly as I can before I release it to the themes page.
As in, no odd jumps between incorrectly spaced increments of db.

I *believe* that the volume range on the Nano is -74 db which is mute to +6db, so (in My mind, with the newfound understanding of db range) the effect I want to achieve would be to display -74db as Mute or "0%", -73db as "1%" and accordingly....+6db would ultimately be "100%"

If it takes me asking blatantly, in lamens terms, How can I achieve this effect using a 10 sub-imaged Bitmap Strip? Or, what is the code I'd need to use to achieve this effect?

Well.....I believe that was Me just doing so now.

I understand what it is You're saying about the db, and it's range in comparison to a true "percentage",  but I'm not exactly up to speed on how I can achieve this effect.


I apologise if I have missed an effort on Your, or anyone elses behalf, to do so.



Sincerely,
[St.]

[Llorean]

I edited my post quite some time back explaining how many images you'd need to use.

You really, really should not try to act like values >0db are the same as values below it. They can cause clipping and sound distortion.

As well if you use the same image for the whole range from 91-100% how is someone to tell whether they've accidentally lowered the volume - it's usually good to have "Mute" and "Full volume" as distinct states of exactly one value, then everything else in between.

A 0 to 100 percentage of Total Volume provides usefull/and valuable information, if that is the desired effect You wish to achieve.
And in My case, it is.

I fear you're confusing "useful information" with "information that is aesthetically pleasing to me." There is no use that you can put a percentage volume to that you couldn't also put db volume to, while there are many uses for the decibel value that can't be replicated easily with an approximated percentage.

As I said, WPSes posted to the gallery may automatically fit into categories for multiple players. Percentage volume is non-useful as, say "80%" can be significantly different on two players, while if two players have similarly performing hardware but one only goes to -54 and one goes to -74, then -25 on both (if the DACs are similar in output capabilities, as they are for several of the players) will be in a very similar range and 0db will always be line level, whereas "100%" as per your made up scale can on some players clip (the Nano, for example, will often clip at +6 and users need a way to know when they're passing 0db so that they can avoid doing so).

Basically a percentage *hides* useful information from players if you don't take into account what the numbers behind it actually *mean* and use "1db above mute" through "0db" as your range, rather than trying to force the range to go up into positive values.

[JdGordon]

The error the RockBox iPod Nano Simulator is giving out is:

WARNING: Maximm Tokens exceeded (1023)

Which sim are you using? (where did you get the build from?)


So heres the thing... if you want exact percentage scale you cant do it (you can go between mute and 0dB with 100 steps if you are a masocist though)... this is how cabbiev2 (the deault theme) does it and it works really well and is close enough...
%?pv<%xdCa|%xdCb|%xdCc|%xdCd|%xdCe|%xdCf|%xdCg|%xdCh|%xdCi|%xdCj>

[[Saint]]

Hmmmmm....

So if I want to do it that way:

[Example 2]

%?pv<%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|%xd*n*a|
%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*b|%xd*n*c|
%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*c|%xd*n*d|%xd*n*d|%xd*n*d|
%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*d|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|
%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*e|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|
%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*f|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|%xd*n*g|
%xd*n*g|%xd*n*g|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|%xd*n*h|
%xd*n*h|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*i|%xd*n*j|
%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j|%xd*n*j>

where *n* = the %xl ID assigned to the Bitmap Strip and a, b, c etc. the sub-image
*note that there are 11 "a's" instead of 10 to accommodate for mute.

is correct? I used 101 conditionals I *believe*...it's been a while...I think I added an extra "%xd|*n*a" to accomodate for mute...do I not need to do this?

From what I've gathered from what various people including yourself have tried to explain to me, I can also achieve this by using 13 sub-images (or 13 references to the 10 images) and the code:

%?pv<mute|10%|20%|30%|40%|50%|60%|70%|80%|90%|100%|100%|>100%>

Is this correct? sorry for My need for absolute clarification.


and also Re:

The error the RockBox iPod Nano Simulator is giving out is:

WARNING: Maximm Tokens exceeded (1023)

Which sim are you using? (where did you get the build from?)

Sim I am using is the current one availabe on this site, as is the build, I usually take it from the "daily build" page so I believe it is r22799? it's the current build anyway...even does it with rb3.4 but I'm not sure this is the correct forum regarding this matter.


Sincerely,
[St.]

[JdGordon]

yes, it entirely depends on how much accuracy you want... and we dont supply sims on this site at all...

[[Saint]]

yes, it entirely depends on how much accuracy you want... and we dont supply sims on this site at all...

Ok thanks, I'll try the "13 conditional" version, play around with it, and see if I can get it to stack up visually compared to the "100+ conditional" version...I just don't want to have any (visualy percievable at least) sudden jumps in the speed of My Volume Slide Bar when scrolling through the volume.

The purpose of Me opening this thread was in order to determine whether or not there was a more effecient way to do so, as like I'd said I needed to clean up (or shorten rather) My code as much as possible due to the problems I am experiencing Re:

Maximum Tokens exceeded (1023)

And I appologise, I meant the simulator that is referenced as "trusted" by rockbox.org...

http://rasher.dk/rockbox/simulator-3.3/

I get the "Max Token Error" on the iPod Nano 1st/2nd Gen version of that Simulator, using every current build I have tried on it with My WPS including rb3.4 and the "daily builds"

I don't personally believe it's the Simulator that's at fault, as in, I don't believe the Error to be a false-positive simply for the fact that the problems I experience in the WPS on the simulator, I experience on any/all of the 2 iPod 1st and 2nd Gen's I have...(4 in total)
I have even tried to deliberately bloat the code of cabbiev2 to reproduce the error in the Simulator with success, if the max token limit is hit...random aspects of the WPS code just plain stop working.
Despit the code itself being sound and free of syntax or conditional errors....

It's got Me pretty annoyed that I've "hit a wall" persay as to the limits of what I can do personally with this WPS, but I can live with it, it should be finished relatively soon barring any huge setbacks (fingers crossed)

If a workaround could be found for that, or a solution rather, I'd be capable of building WAY cooler WPS's in future bacause as I said, this error has forced Me to cut back the visuals on My current project dramatically :'(


Sincerely,
[St.]

[Llorean]

You can't try different builds on a simulator - the simulator binary is the build. You don't install builds to it. This is why it doesn't require you to download a build, and this is why it always reports the same version number until you download a new simulator.

The current Rockbox revision is in the approximate range of r23820 or so right now and is reported on the front page of the site, over a thousand revisions later than r22799.

While this may still be a problem, you should always try to make sure you're reporting with actually current builds to speed things along - the current problem may be completely unrelated to the token limit (for example, there are simply limits on RAM available to the WPS that you may have hit).

[[Saint]]

What I should of said is that I use that Simulator http://rasher.dk/rockbox/simulator-3.3/ , but I always replace the .rockbox DIR with the current build from the "Daily Builds" page.

Works for Me...if it's wrong, say so, but I haven't found a better way to do it.

In saying that it was r22799 I was in error, and I'll freely admit that, but I was trying to remember a six digit number entirely off the top of My head....please excuse My fallability 

[Llorean]

That's a 3.3 simulator. Changing the .rockbox folder doesn't update the build for simulators, since the .exe file is the build. Changing the .rockbox folder just breaks things. You can't use a player .rockbox folder with a Rockbox simulator - they're completely different files.

Please, take the few seconds (or few minutes, or whatever) to look up the number before citing it - readers WILL assume you're telling the truth and can thus spend time trying to track down a bug or problem that no longer exists (or send you in circles down paths you've already done, or whatever) because they thought you were being accurate.

So, the simulator is entirely useless since it's not even the latest release, let alone a remotely current build. It's more than 5 months old.