| 00:00:26 | dfkt | http://www.telechips.com/product/p_02_1.asp |
| 00:03:04 | | Quit wodz (Quit: Leaving) |
| 00:03:13 | | Join skx` [0] (~skx@d51A4AF07.access.telenet.be) |
| 00:03:53 | linuxstb | Watermark: Are you testing? I need to go to bed soon... |
| 00:04:17 | | Quit anewuser (Ping timeout: 248 seconds) |
| 00:04:18 | Watermark | how do i test it? sorry need a refresh |
| 00:04:45 | linuxstb | Do you have a firmware file to upload? |
| 00:04:47 | dfkt | linuxstb, i'm trying it too... having issues installing the tcctool driver |
| 00:05:05 | Watermark | o sure sec |
| 00:05:23 | linuxstb | Watermark: And you'll need to install the tcctool driver for Windows (I'm assuming you're on Windows...) |
| 00:05:29 | dfkt | linuxstb, here's the latest firmware - http://www.cowonglobal.com/download/Firmware/COWONS9/COWON_S9_2.52.zip |
| 00:07:44 | Watermark | how do i install it if no Device can be detected? |
| 00:07:58 | Watermark | well, can't be detected by Tcctool |
| 00:08:03 | | Quit ender` (Ping timeout: 276 seconds) |
| 00:08:13 | Watermark | when i try to install nothing happens |
| 00:09:04 | dfkt | linuxstb, just got the driver to install... i had to add the pid&vid.. d'oh |
| 00:09:22 | Watermark | dfkt how do i do it? |
| 00:09:55 | dfkt | you open tcc.inf and add this line under "devices": |
| 00:09:55 | dfkt | "TCC7901 usb-boot mode"=LIBUSB_DEV, USB\VID_140E&PID_B057 |
| 00:09:55 | linuxstb | dfkt: Ah yes... I forgot about that. |
| 00:10:12 | dfkt | add it 3 times, for each subsection |
| 00:11:15 | linuxstb | dfkt: The COWON_S9_FW.BIN looks like the right file to try to upload. |
| 00:11:18 | dfkt | Watermark - or just copy that whole thing over: http://pastie.org/914725 |
| 00:11:29 | Watermark | yes omg |
| 00:11:32 | Watermark | !!!!1 |
| 00:12:00 | Watermark | omg i love you guys Crys... |
| 00:12:04 | CIA-5 | New commit by Buschel (r25600): Tweaking iPod Video battery configuration. Dangerous battery level is latest reached below 3500 mV, discharge curve is optimized for stable runtime ... |
| 00:12:43 | dfkt | linuxstb, you mean after the *fw.bin is uploaded, the other two firmware parts should already be uploaded in normal connect mode? |
| 00:13:24 | dfkt | i let Watermark test that, his s9 can't be more broken than it already is... and i don't want to brick my s9 ;) |
| 00:13:34 | Watermark | i rthink all you need to the FW file to upload then all should be good |
| 00:13:55 | linuxstb | Watermark: So Windows is now recognising your S9? |
| 00:14:02 | linuxstb | (in recovery mode) |
| 00:14:15 | dfkt | the *rs.bin file is obviously resources, like fonts and such - no idea what the *ft2.bin is |
| 00:14:31 | Watermark | yep, brb ok. going to upload the FW via tcctool. refreashing myself here |
| 00:15:33 | Ctcp | Version from Chazz!dabomb69@unaffiliated/dabomb69 |
| 00:20:22 | | Quit Buschel () |
| 00:24:59 | Watermark | hm... nothing seems to be happening |
| 00:25:56 | dfkt | are you in recovery mode? is the s9 recognized in windows device manager? |
| 00:26:28 | Watermark | yes, i was able to use tcctool but the device shuts off after patching the FW File |
| 00:26:48 | dfkt | did your battery run dry when you bricked it? ;) |
| 00:27:08 | linuxstb | Have you found any instructions for recovering a Cowon D2 with tcctool? This could be similar (and I don't know that process). |
| 00:27:19 | Watermark | hmmm... maybe |
| 00:27:41 | Watermark | o i'm an expert on that teehee |
| 00:27:48 | linuxstb | Also, maybe you need to hold the "on" button when you upload the firmware - so it detects it as being pressed when it runs. |
| 00:27:56 | Watermark | i was actually using one of my guides as a refresh |
| 00:28:40 | linuxstb | Or it could mean the "sdcfg" value I guessed was wrong. But there's no more I can do now - time for sleep... I'll read the IRC logs tomorrow. |
| 00:29:05 | | Join halmi [0] (~Miranda@188.20.253.186) |
| 00:29:07 | dfkt | thanks, linuxstb |
| 00:29:10 | Watermark | ok thanks linuxstb |
| 00:30:17 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 00:31:01 | dfkt | Watermark, so did oyu see an "updating" screen after you got the firmware on the s9? |
| 00:31:10 | Watermark | no |
| 00:31:13 | Watermark | nothing |
| 00:31:18 | dfkt | i assume you have to push the rest hole for the update to initialize, iirc |
| 00:31:25 | dfkt | to get the player out of recovery |
| 00:31:35 | Watermark | as before the S9 shuts off when patching is done |
| 00:32:33 | dfkt | shuts off? you mean, it isn't visible anymore in the device manager? |
| 00:32:49 | dfkt | since there is no other clue of activity when it's in recovery mode |
| 00:33:04 | Watermark | hold on |
| 00:35:16 | Watermark | yeah, the device isn't listed after patching. like it disconnect |
| 00:36:25 | dfkt | and you pushed the reset hole? |
| 00:37:50 | Watermark | the only thing that does is lets me reconnect the S9 in Boot Mode. when i try to turn the S9 on in Boot or regular nothing happens |
| 00:42:41 | | Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) |
| 00:43:42 | | Quit linuxstb (Ping timeout: 258 seconds) |
| 00:44:01 | dfkt | then it's probably best waiting for linuxstb to come back... i'm off to bed as well - good luck! |
| 00:44:04 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 00:44:33 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 00:44:58 | | Quit BHSPitLappy (Ping timeout: 276 seconds) |
| 00:46:32 | | Quit petur (Remote host closed the connection) |
| 00:46:57 | | Quit EKulabuhov (Ping timeout: 248 seconds) |
| 00:47:40 | | Join Strife1989 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) |
| 00:49:17 | Watermark | alright thanks |
| 00:50:14 | | Join nima [0] (~nima@adsl-75-45-240-173.dsl.sfldmi.sbcglobal.net) |
| 00:51:17 | | Quit Strife1989 (Read error: Connection reset by peer) |
| 00:51:38 | | Quit Strife89 (Read error: Connection reset by peer) |
| 00:51:40 | | Join Strife1989 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) |
| 00:53:42 | | Quit nimak (Ping timeout: 276 seconds) |
| 00:54:32 | | Quit Watermark (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 00:58:12 | | Join kramer3d [0] (~kramer@unaffiliated/kramer3d) |
| 01:00 |
| 01:06:03 | *** | Saving seen data "./dancer.seen" |
| 01:09:21 | | Join Watermark [0] (~chatzilla@adsl-220-183-243.mob.bellsouth.net) |
| 01:12:55 | | Quit Watermark (Client Quit) |
| 01:15:33 | | Quit piotrekm (Quit: piotrekm) |
| 01:17:03 | | Quit Tuplis (Ping timeout: 245 seconds) |
| 01:17:20 | | Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) |
| 01:20:22 | | Join guymann [0] (~charlie@adsl-69-177-38-82.adsl.snet.net) |
| 01:28:04 | | Quit efyx (Quit: Quitte) |
| 01:32:00 | | Quit halmi (Quit: halmi) |
| 01:35:23 | | Quit xiainx (Ping timeout: 245 seconds) |
| 01:37:31 | | Join Watermark [0] (~chatzilla@adsl-220-183-243.mob.bellsouth.net) |
| 01:38:02 | Watermark | linuxstb you still here? |
| 01:39:57 | Watermark | nvm, we will see what you can do to further fix the issue (Issue: after patching the Device disconnects from PC) |
| 01:41:09 | | Quit Blue_Dude (Read error: Connection reset by peer) |
| 01:41:10 | S_a_i_n_t | He went to bed, he'll read the logs. |
| 01:41:21 | Watermark | roger that |
| 01:41:47 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
| 01:42:49 | Watermark | btw linuxstb, i will be on close to 3PM CDT |
| 01:43:07 | Watermark | see you then and again Thanks! |
| 01:43:16 | | Quit Watermark (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 01:45:07 | | Join Spaceghost [0] (libertad@unaffiliated/spaceghost) |
| 01:45:09 | Spaceghost | hi |
| 01:45:39 | Spaceghost | with a ipod rockboxed, is possible use the screen for show anything that I want when the ipod is connect to the PC? |
| 01:46:02 | Spaceghost | show what music I am playing on the computer, for example |
| 01:46:50 | Spaceghost | the CPU temp, CPU use, RAM use, etc |
| 01:47:14 | Spaceghost | with a good dock, that is very interesting |
| 01:48:50 | | Quit DataGhost (Ping timeout: 264 seconds) |
| 01:57:26 | | Quit krabador (Read error: Connection reset by peer) |
| 02:00 |
| 02:08:36 | S_a_i_n_t | What's with the .sbs flashing when the database inits? |
| 02:09:01 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 02:09:06 | | Join halmi [0] (~halmi@188.20.253.186) |
| 02:09:41 | | Quit toffe82 (Read error: Connection reset by peer) |
| 02:10:04 | | Join halmi_ [0] (~halmi@188.20.253.186) |
| 02:10:37 | | Quit halmi_ (Client Quit) |
| 02:10:49 | | Join halmi_ [0] (~halmi@188.20.253.186) |
| 02:11:05 | | Quit Spaceghost (Ping timeout: 258 seconds) |
| 02:11:18 | | Quit halmi_ (Client Quit) |
| 02:13:51 | | Quit halmi (Ping timeout: 268 seconds) |
| 02:14:59 | | Join IiLuminated [0] (iiluminate@89.34.252.169) |
| 02:15:08 | | Join halmi [0] (~halmi@188.20.253.186) |
| 02:15:32 | | Part IiLuminated |
| 02:15:38 | | Quit halmi (Client Quit) |
| 02:28:33 | | Quit adnyxo (Remote host closed the connection) |
| 02:42:03 | | Quit kugel (Remote host closed the connection) |
| 02:48:02 | | Join hearit [0] (~asdd@201.255.83.135) |
| 02:55:11 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 03:00 |
| 03:06:04 | *** | Saving seen data "./dancer.seen" |
| 03:07:09 | | Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) |
| 03:17:22 | | Join [1]Lynx_ [0] (~Lynx@86.51.114.197) |
| 03:19:13 | | Quit Lynx_ (Ping timeout: 268 seconds) |
| 03:19:13 | | Nick [1]Lynx_ is now known as Lynx_ (~Lynx@86.51.114.197) |
| 03:29:32 | | Join [1]Lynx_ [0] (~Lynx@86.51.114.197) |
| 03:32:41 | | Quit Lynx_ (Ping timeout: 260 seconds) |
| 03:32:41 | | Nick [1]Lynx_ is now known as Lynx_ (~Lynx@86.51.114.197) |
| 03:37:56 | | Nick Strife1989 is now known as Strife89 (~michael@adsl-154-2-63.mcn.bellsouth.net) |
| 03:39:47 | | Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 03:41:26 | | Join hebz0rl_ [0] (~hebz0rl@dslb-088-065-048-228.pools.arcor-ip.net) |
| 03:44:54 | | Quit katyl (Quit: Ex-Chat) |
| 03:45:09 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 03:45:13 | | Quit hebz0rl (Ping timeout: 264 seconds) |
| 03:49:50 | | Quit mikroflops (Ping timeout: 276 seconds) |
| 03:50:49 | Strife89 | A minor but perhaps-difficult(?)-to-impliment suggestion: |
| 03:51:08 | Strife89 | Two SBSes: one for the Main Menu, on for everywhere else. |
| 03:51:12 | Strife89 | s/on/one/ |
| 03:51:21 | JdGordon_ | why? |
| 03:51:25 | JdGordon_ | you can do that anyway |
| 03:51:37 | S_a_i_n_t | you can? |
| 03:51:40 | Strife89 | ... You can? |
| 03:51:58 | JdGordon_ | as long as the ui viewport doesnt move you can |
| 03:52:09 | JdGordon_ | ^ is on my todo list |
| 03:52:21 | Strife89 | As for why: If you start digging into menus, having a lot of other info on the screen can become frustrating. |
| 03:53:11 | S_a_i_n_t | JdGordon_: How do you inplement these two .sbs? I mean "use" rather than implement. |
| 03:53:21 | S_a_i_n_t | I've thought about it, but couldn;t work out how. |
| 03:53:29 | JdGordon_ | with the %cs and %mp tags |
| 03:54:25 | S_a_i_n_t | Oh...right, I gotcha. One .sbs, but conditional to screens. |
| 03:55:19 | S_a_i_n_t | <pedantic>well, that's not *really* two .SBS's.</pedantic> |
| 03:55:26 | * | Strife89 can only imagine how complicated such an SBS will look. |
| 03:55:36 | Strife89 | In the source, I mean. |
| 03:55:52 | S_a_i_n_t | Strife89: not very. |
| 03:57:11 | JdGordon_ | it is the only way |
| 03:57:11 | S_a_i_n_t | The .sbs file itself wouldn't be too much more complicated actually. |
| 03:57:20 | S_a_i_n_t | It's given me ideas lol. |
| 03:58:35 | * | S_a_i_n_t still can't believe how much skin buffer he can get back by using %pv|bitmap.bmp| |
| 03:59:17 | S_a_i_n_t | it's truly awesome, some of my themes still need to have bitmap strip volume, but that doesn't mean I can't make new ones! |
| 04:00 |
| 04:00:22 | | Quit linuxstb (Ping timeout: 264 seconds) |
| 04:03:22 | JdGordon_ | S_a_i_n_t: can you please do a patch for all the cabbies? |
| 04:05:16 | S_a_i_n_t | yep. I guess so. |
| 04:05:19 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:05:37 | S_a_i_n_t | may take me a while, but I can get it done soon-*ish* |
| 04:05:41 | JdGordon_ | hmm, I think i need to pix it so it doesnt eat the rest of the line, so it can go in conditionals |
| 04:06:12 | S_a_i_n_t | it doesn't need to be a conditional, does it? |
| 04:06:13 | JdGordon_ | s/pix/fix |
| 04:06:26 | S_a_i_n_t | it can use %?mv to call it |
| 04:06:36 | S_a_i_n_t | (in a viewport) |
| 04:06:43 | JdGordon_ | mv? |
| 04:06:46 | S_a_i_n_t | that's what I'm doing now...works fine. |
| 04:07:00 | S_a_i_n_t | mv (is volume changing yes/no |
| 04:07:29 | JdGordon_ | na, I still want to add the tag for "is volume above 0?" |
| 04:07:55 | S_a_i_n_t | I can't think of many other reasons you'd want volume to be conditional. |
| 04:08:02 | S_a_i_n_t | Oh, right. |
| 04:09:09 | S_a_i_n_t | Jd, wait. How can I patch the cabbies with this? remove the volume .bmp that exists already? |
| 04:09:39 | S_a_i_n_t | just use a small "volumebar" in its place? |
| 04:09:43 | | Quit TheSeven (Disconnected by services) |
| 04:09:45 | JdGordon_ | yes |
| 04:09:56 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
| 04:10:06 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
| 04:10:07 | Strife89 | Y'know, why does the Reversi plugin start you off against a human opponent? |
| 04:10:10 | S_a_i_n_t | Gotcha..but some people may not like that. |
| 04:10:21 | Strife89 | Wouldn't one rather play against the CPU? |
| 04:10:35 | JdGordon_ | once the "clipping" tag is added, noone should be able to tell the differebnce |
| 04:11:31 | S_a_i_n_t | It doesn't need it, I can just colour the end of the .bmp where it (approximately) clips |
| 04:12:02 | S_a_i_n_t | go, yellow, orange (just about clipping), red (definitely clipping) |
| 04:12:12 | JdGordon_ | or that |
| 04:12:17 | S_a_i_n_t | Same effect, no additional tag |
| 04:12:24 | JdGordon_ | although the area changes based on the target |
| 04:12:29 | S_a_i_n_t | I'll get to work. |
| 04:12:53 | S_a_i_n_t | Yeah, it'll be approximate...but it was anyway really, |
| 04:13:02 | S_a_i_n_t | the only value that wasn;t was 0db |
| 04:13:47 | JdGordon_ | yeah but old style is <mute|......range....|0dB|>0> |
| 04:14:12 | S_a_i_n_t | Hmmm, yeah. this won't have mute. |
| 04:14:35 | S_a_i_n_t | well, mute will be "there is no volume icon" |
| 04:16:15 | | Quit mirak_ (Quit: Ex-Chat) |
| 04:17:09 | | Quit linuxstb (Read error: Operation timed out) |
| 04:17:34 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:19:47 | JdGordon_ | mute is done with a silhouette of the bar on the mackground |
| 04:19:56 | JdGordon_ | hehe mackground |
| 04:20:36 | S_a_i_n_t | my theory of showing clipping with the very end of the .bmp won't work for volume-112x64x1 for instance |
| 04:20:48 | S_a_i_n_t | as the "clip" indicator is at the front of the .bmp |
| 04:21:08 | S_a_i_n_t | I'll do the targets I can, and we'll go from there. |
| 04:25:31 | | Join Barahir_ [0] (~jonathan@gssn-5f75612e.pool.mediaWays.net) |
| 04:26:19 | | Join Rob2223 [0] (~Miranda@p4FDCA149.dip.t-dialin.net) |
| 04:28:48 | | Quit linuxstb (Ping timeout: 264 seconds) |
| 04:29:16 | S_a_i_n_t | Hmmmmm.I think we need a better way to represent clipping. |
| 04:29:31 | S_a_i_n_t | I could only ever get it *vaguely* approximate. |
| 04:29:38 | | Quit Barahir (Ping timeout: 276 seconds) |
| 04:29:56 | | Quit Rob2222 (Ping timeout: 265 seconds) |
| 04:30:14 | S_a_i_n_t | For the target I'm looking at now, when clipping starts would *technically* be 3dB too "early" |
| 04:30:17 | S_a_i_n_t | thoughts? |
| 04:30:37 | JdGordon_ | a new tag ad fix it so it doesnt eat the line |
| 04:31:00 | S_a_i_n_t | So, I have to wait untill then? |
| 04:31:19 | S_a_i_n_t | well, I guess so, so I know how it works, so I know what .bmps to make |
| 04:31:57 | S_a_i_n_t | or will it just be 2 bmps? 1 for x~0, the other for 0+? |
| 04:32:15 | S_a_i_n_t | if the latter, I can still start working on it now. |
| 04:32:26 | S_a_i_n_t | and, it'd be a LOT easier. |
| 04:32:49 | | Quit Strife89 (Quit: Sleep.) |
| 04:33:02 | JdGordon_ | yeah, just 2 bmps |
| 04:33:26 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:33:45 | S_a_i_n_t | Sweet, means I can just use the last two cells from the original volume strips, and noone will notice anything ;D |
| 04:33:54 | JdGordon_ | how bad does %?pv<|%pv|bmp|...||0dB|%xdf> look? |
| 04:34:12 | S_a_i_n_t | fine, it's how I imagined it in my head. |
| 04:34:32 | S_a_i_n_t | but, does that mean the other way of doing it won't work anymore? :'( |
| 04:34:43 | JdGordon_ | no |
| 04:34:48 | S_a_i_n_t | (%pv|blah|-|-| |
| 04:35:02 | JdGordon_ | it would still work, the midde bit is only 1 so it is always used |
| 04:35:32 | S_a_i_n_t | so, they'll both work, min to max *and* min to 0db to greater than 0dB? |
| 04:35:55 | S_a_i_n_t | *cool* |
| 04:39:49 | | Quit linuxstb (Ping timeout: 246 seconds) |
| 04:42:30 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:50:24 | | Join Rondom_ [0] (~quassel@dslb-084-057-166-146.pools.arcor-ip.net) |
| 04:53:29 | | Quit linuxstb (Read error: Operation timed out) |
| 04:53:57 | | Join linuxstb [0] (~linuxstb@94-193-103-239.zone7.bethere.co.uk) |
| 04:53:58 | | Quit linuxstb (Changing host) |
| 04:53:58 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 04:54:01 | | Quit Rondom (Ping timeout: 248 seconds) |
| 04:59:27 | | Quit linuxstb (Ping timeout: 252 seconds) |
| 04:59:45 | S_a_i_n_t | Ok, sweet, bitmaps for all the colour targets are done. |
| 05:00 |
| 05:00:06 | S_a_i_n_t | Just need to wait and find out the final syntax, then I can start on the WPS files. |
| 05:00:49 | S_a_i_n_t | I've gone with "volume-240x320x16" and "volume-clipping-240x320x16" etc. |
| 05:01:30 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 05:01:42 | Llorean | Do we need new bitmaps if the old syntax isn't discontinued? |
| 05:01:54 | S_a_i_n_t | yes. |
| 05:01:58 | Llorean | Why? |
| 05:02:22 | S_a_i_n_t | because it uses one bitmap like the playbar does. |
| 05:02:30 | Llorean | That's not a reason. |
| 05:02:30 | S_a_i_n_t | not a cell from a bitmap strip. |
| 05:02:34 | Llorean | That's an explanation of what it does. |
| 05:02:49 | S_a_i_n_t | Its a reason if you understand it. |
| 05:02:54 | Llorean | No, it's not. |
| 05:03:44 | S_a_i_n_t | does a playbar use bitmap strips? |
| 05:03:45 | S_a_i_n_t | no. |
| 05:03:48 | S_a_i_n_t | same thing. |
| 05:03:56 | | Join markun_ [0] (~markun@bastards.student.ipv6.utwente.nl) |
| 05:03:58 | | Quit markun_ (Changing host) |
| 05:03:58 | | Join markun_ [0] (~markun@rockbox/developer/markun) |
| 05:04:09 | Llorean | Why does it need to be like the progress bar (learn your terms) |
| 05:04:28 | Llorean | I'm asking for reasons, not just "what it does" |
| 05:04:31 | Llorean | I understand what it does. |
| 05:04:34 | | Quit markun (Ping timeout: 276 seconds) |
| 05:04:47 | S_a_i_n_t | because that's an option just committed, jd asked me to do something, I'm doing it. |
| 05:05:07 | Llorean | Again, "it's a new option, so we should use it" isn't a reason. |
| 05:05:09 | Llorean | What's the benefit? |
| 05:05:26 | Llorean | What do we gain by replacing the existing tag in WPSes with the new version? |
| 05:05:35 | S_a_i_n_t | less skin buffer realty |
| 05:05:49 | S_a_i_n_t | a LOT less in some cases. |
| 05:06:08 | *** | Saving seen data "./dancer.seen" |
| 05:06:35 | Llorean | Really? |
| 05:06:41 | S_a_i_n_t | yes. |
| 05:06:43 | Llorean | Does the amount of RAM allocated decrease? |
| 05:06:53 | Llorean | Or does it simply decrease the total amount used within the allocation we already give it? |
| 05:07:04 | | Quit CaptainKewl (Remote host closed the connection) |
| 05:07:04 | S_a_i_n_t | does it really matter? |
| 05:07:08 | Llorean | Yes, actually |
| 05:07:24 | Llorean | You can't use allocated WPS RAM for other things even if the WPS isn't using all of it |
| 05:07:32 | S_a_i_n_t | Ok...then argue it with the author, not I. |
| 05:07:33 | Llorean | So if the amount of RAM allocated doesn't decrease, it doesn't actually save anything |
| 05:07:38 | S_a_i_n_t | actually *discuss* it. |
| 05:08:10 | Llorean | You mean, like asking for reasons to do it and expecting people to actually be able to give me information such as "benefits" rather than reiterating what it does, or making things up that they don't even know about? That sort of discussion? |
| 05:08:44 | S_a_i_n_t | Some people may not think aesthetics matter, others do, those that don't aren't losing anything. |
| 05:09:19 | Llorean | Well, if people are to be able to learn from cabbieV2 too, having an example of both multiple images (the volume indicator) and a single image that is progressively drawn (progress bar) provides the wides benefit to people looking for examples. |
| 05:09:55 | S_a_i_n_t | You just like to shake up things you dislike right? its totally uncool. |
| 05:10:09 | Llorean | What's the aesthetic gain, exactly? JdGordon_ said people wouldn't be able to tell the difference. If you're making an exact replacement, surely you can't argue that it's also an aesthetic gain, so either there's a visible difference (which you can then call a "reason") or it can't be told apart. |
| 05:11:01 | Llorean | S_a_i_n_t: I notice that you're making personal attacks against me already, rather than discussing the idea of whether or not it decreases the usefulness of it as a learning tool. |
| 05:11:15 | Llorean | Score one point for the person who suggested *I* should actually try discussion. |
| 05:11:36 | S_a_i_n_t | Not an attack, merely an observation, based on conduct past and present. |
| 05:11:56 | Llorean | Yes, one that doesn't belong in this discussion. |
| 05:12:01 | Llorean | Unless it's somehow a part of the feature. |
| 05:12:32 | Llorean | So, do you have answers for *any* of the questions I've presented? If you want to complain about my behaviour rather than actually discussing the idea, I suggest it be taken to -community. |
| 05:12:38 | Llorean | As it stands, I'd like to know what we're gaining from this. |
| 05:12:44 | S_a_i_n_t | Did I or did I not ask you to refer you "questions" to the author? |
| 05:12:50 | S_a_i_n_t | yet you still continue. |
| 05:13:10 | Llorean | You claimed something about aesthetics *after* that |
| 05:13:13 | Llorean | Which I then asked about |
| 05:13:41 | Llorean | I assumed you were offering more information on that aspect - why otherwise even say it? |
| 05:21:45 | | Quit linuxstb (Ping timeout: 245 seconds) |
| 05:25:23 | | Join Adubbb [0] (~Aldubuc@67.201.160.144) |
| 05:25:36 | Adubbb | suuup |
| 05:27:03 | | Part Adubbb |
| 05:27:30 | | Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-jruphgujmmcmtzst) |
| 05:27:38 | JdGordon | you are both idiots! |
| 05:27:49 | Llorean | JdGordon: I'm just asking what we gain. |
| 05:28:17 | Llorean | If it's exactly the same, I don't think we need to change cabbiev2, but if we gain something, we certainly could. |
| 05:28:26 | | Join Adubb [0] (~Aldubuc@67.201.160.144) |
| 05:28:37 | | Part Adubb |
| 05:28:40 | JdGordon | 1) much simpler wps code, 2) skin buffer back so it can be used for other things, 3) smoother bar drawing |
| 05:29:13 | Llorean | JdGordon: I don't agree with 1) as long as the old syntax still exists. 2) I already asked my question about (if we really get it back from the allocation, I'm all for it). 3) wasn't told to me. |
| 05:29:32 | Llorean | Is the current bar on many targets inaccurate? I imagined it was small enough on most targets that we'd have enough bitmaps to be precise. |
| 05:30:00 | Llorean | I know that currently I have several hundred K allocated for my WPS that is unused according to rockbox info |
| 05:30:28 | JdGordon | %?pv<%xdCa|%xdCb|%xdCc|%xdCd|%xdCe|%xdCf|%xdCg|%xdCh|%xdCi|%xdCj> is nicer than %pv|volume.bmp|-|-|-|-| is it? |
| 05:30:35 | Llorean | No, it's not nicer. |
| 05:30:39 | Llorean | I didn't say it was. |
| 05:30:53 | JdGordon | s/nicer/simpler |
| 05:31:06 | Llorean | My point was that as long as we allow the old syntax, it's better to have it in cabbiev2 is there's not an aesthetic difference on the actual screen, because it's the one people will have a harder time understanding. |
| 05:31:37 | Llorean | But if there's a precision problem with the old code, then an upgrade might make more sense. |
| 05:31:51 | Llorean | Also, of course, if we got rid of the old syntax. |
| 05:32:16 | Llorean | But I'm not sure that's feasible since it servers for nonlinear volume bars too |
| 05:32:33 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 05:33:10 | JdGordon | frankly I dont care, I think cabbie should show good WPS code, I asked S_a_i_n_t if he would do it, he said maybe, thats it |
| 05:33:57 | Llorean | I think that, where it doesn't harm other things, it should be a decent learning tool. |
| 05:34:02 | JdGordon | and on that, I would also really like to force cabbie on all targets to use viewports |
| 05:34:26 | Llorean | Is there some reason it doesn't need to on some targets? |
| 05:34:49 | Llorean | I guess on Portrait targets it can get away without it... |
| 05:35:03 | Llorean | What about the newer cabbie versions from the theme site that take advantage of SBS features and such? |
| 05:35:10 | Llorean | Maybe it's time for an official cabbie version 3. |
| 05:35:16 | JdGordon | ok, any target which cabbie is filled with %?C<>'s NEED to be converted |
| 05:35:49 | Llorean | Sounds like a good idea. |
| 05:39:02 | saratoga | http://arstechnica.com/open-source/news/2010/04/google-boosts-open-video-by-funding-arm-theora-codec.ars |
| 05:39:09 | saratoga | google has kicked some money to the Tremorlo guy |
| 05:41:16 | | Quit Horscht (Quit: Verlassend) |
| 05:41:21 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 05:41:47 | S_a_i_n_t | JdGordon: I'm all set when we have a definitive syntax to work with. Just post an example line somewhere for me. |
| 05:42:04 | | Join Spaceghost [0] (irrsi@unaffiliated/spaceghost) |
| 05:42:34 | JdGordon | any ideas for the letters to use for "is above 0?" |
| 05:42:59 | JdGordon | I think a new token is much more readable than putting a %pv|...| insdie a %?pv<> |
| 05:43:05 | Llorean | Is $vd taken? |
| 05:43:09 | Llorean | Er % |
| 05:43:30 | Llorean | Ah, the V stuff seems to all be viewports |
| 05:43:36 | JdGordon | don't think so |
| 05:43:42 | JdGordon | yeah V is viewport stuff |
| 05:43:45 | Llorean | I'd say "vd" for "volume danger" or something |
| 05:43:48 | JdGordon | but we only have so many letters |
| 05:44:20 | JdGordon | I can do %vpd or something |
| 05:44:26 | JdGordon | umm %pvd |
| 05:44:41 | S_a_i_n_t | JdGordon: Just go with %xda|%xdB|etc.? |
| 05:44:49 | S_a_i_n_t | *for "above 0dB" |
| 05:45:01 | JdGordon | no, a single image for above 0 |
| 05:45:05 | S_a_i_n_t | oh, shit...wait. |
| 05:45:20 | Llorean | JdGordon: Would it be possible to concatenate two images? |
| 05:45:35 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 05:45:38 | JdGordon | you mean overlay? |
| 05:45:40 | Llorean | So you could have %pv|muteimg|mute+1 through 0db| danger.bmp| |
| 05:45:52 | Llorean | No, basically, take two images and draw one until it's wholly there, then start drawing the other |
| 05:45:58 | Llorean | From the end of the first |
| 05:46:03 | S_a_i_n_t | jd, we only need one letter for "is volume above 0dB" right? |
| 05:46:15 | JdGordon | that is a seperate feature which we've talked about |
| 05:46:41 | JdGordon | there is a patch for it, but I dont tihnk it is needed because doing the volume bar with a single image looks better |
| 05:46:54 | JdGordon | S_a_i_n_t: tags are 2 letters |
| 05:47:04 | JdGordon | generally* |
| 05:47:07 | S_a_i_n_t | but, doesn't allow for accurate "am I clipping" unfortunately. |
| 05:47:27 | S_a_i_n_t | *using only one bitmap. |
| 05:47:33 | S_a_i_n_t | this is why we need to. |
| 05:47:54 | S_a_i_n_t | *two |
| 05:47:55 | Llorean | JdGordon: Could it be |mute|scaling image|danger.bmp ? |
| 05:48:15 | S_a_i_n_t | there is no mute IIUC |
| 05:48:22 | Llorean | There is mute. |
| 05:48:28 | JdGordon | with the current tags it is mute|scaling|0|danger but that means %pv inside %?pv |
| 05:48:29 | Llorean | After the lowest volume level it mutes the DAC |
| 05:48:59 | S_a_i_n_t | not with this implementation there isn't |
| 05:49:04 | S_a_i_n_t | (yet) |
| 05:49:05 | JdGordon | %?pv<mute|%pv|volume.bmp|-|-|-|-||0db|dander> |
| 05:49:19 | Llorean | S_a_i_n_t: There's a difference between "there is no mute" and "we don't display mute with the current implementation" |
| 05:49:23 | Llorean | Please, say what you mean. I can't read minds. |
| 05:49:49 | Llorean | JdGordon: Maybe we should just go with the nested tag for the moment until someone has a better idea, just so it can get in use? |
| 05:49:56 | Llorean | It does offer some flexibility that way, at least |
| 05:50:28 | JdGordon | that snippet wont work right now because the long type %pv eats the rest of the line (simple fix) |
| 05:50:42 | | Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
| 05:50:44 | JdGordon | and I wouldnt remove that option if another tag was added |
| 05:50:55 | JdGordon | but I think it is a bit awkward |
| 05:51:13 | Llorean | Well, it would be nice if there was an actual mute image as well |
| 05:51:44 | | Quit kramer3d (Quit: This computer has gone to sleep) |
| 05:51:52 | S_a_i_n_t | I assume mute will be the empty recess in the volume area, well need to add it to some backdrops |
| 05:52:00 | S_a_i_n_t | *we'll |
| 05:52:13 | Llorean | You could have %sa or %sv with a basic |mute|!mute|danger condition set. |
| 05:52:46 | Llorean | S_a_i_n_t: Often there's a grayed out volume behind the volume bar showing where it will fill in. |
| 05:52:55 | Llorean | So I don't think you could add mute to the background without removing that. |
| 05:53:02 | JdGordon | I don't think any extra tags should do more than just be a bool for if the volume is above 0 or not |
| 05:53:11 | S_a_i_n_t | I know, but I don;t think all the targets have this. |
| 05:53:16 | Llorean | JdGordon: What about mute, then? |
| 05:53:17 | S_a_i_n_t | But I could be wrong. |
| 05:53:27 | JdGordon | is mute such a big deal? |
| 05:53:36 | S_a_i_n_t | IMO, no. |
| 05:53:44 | JdGordon | you also dont tihnk >0 is :D |
| 05:53:53 | S_a_i_n_t | :P |
| 05:53:54 | Llorean | I think >0 is a lot more important than mute |
| 05:54:00 | Llorean | But a mute indicator has revealed a bug from time to time |
| 05:54:10 | Llorean | When you see that it's supposed to be muted, and you still hear audio, you know something's up. |
| 05:54:31 | Llorean | Generally speaking, you're going to pause rather than mute anyway. |
| 05:54:38 | JdGordon | exactly |
| 05:55:03 | S_a_i_n_t | If we had a "mute" button, I'd say it was important. |
| 05:55:09 | S_a_i_n_t | but, seeing as we don't. |
| 05:55:35 | * | JdGordon wonders about allowing a different seperator style for when we are inside a conditional |
| 05:56:02 | Llorean | JdGordon: Why not %bv as a new tag with |mute|scaling bar|danger ? |
| 05:56:06 | JdGordon | %?pv<mute|%pv,volume.bmp,-,-,-,-,|0db|dander> |
| 05:56:13 | Llorean | Rather than trying to make it coexist with %pv etc? |
| 05:56:55 | S_a_i_n_t | personally, I think %pv still makes sense. The systax that follows is enough to tell the two %pv's apart. |
| 05:57:16 | JdGordon | because unless the scaling bar part of your suggestion is another tag, it is to restricted |
| 05:57:32 | Llorean | Why? |
| 05:58:43 | Llorean | Couldn't you make it so if the first/third parts were empty it works like your %pv does, but if they were filled in, it shows the respective images at mute / >0, without having to dance around the fact that %pv could *theoretically* have a single bitmap in the middle? |
| 05:59:30 | JdGordon | I dont like forcing anything, what you suggest forces the bitmap, but the themer might want something compeltly different |
| 05:59:39 | JdGordon | so it really just duplicates the existing pv tag |
| 06:00 |
| 06:00:04 | Llorean | I don't understand |
| 06:00:06 | Llorean | Forces which bitmap? |
| 06:00:31 | Llorean | I was just suggesting instead of the new tag being another limited variant of %pv, give it more flexibility by making it its own tag. |
| 06:00:33 | JdGordon | maybe i dont understand you |
| 06:00:35 | Llorean | Then leave the old %pv alone. |
| 06:01:02 | Llorean | Basically, instead of two different %pvs, have the old %pv, and a new %bv which takes the form %bv<mute| scaling bar image | danger> |
| 06:01:11 | Llorean | Where if mute and danger are left empty, it just uses the scaling bar. |
| 06:01:34 | JdGordon | and the image is what? any wps code? or a bmp filename? |
| 06:02:14 | Llorean | I'm confused. |
| 06:02:25 | Llorean | Doesn't %pv<volume.bmp> require an image too? |
| 06:02:41 | S_a_i_n_t | of course. |
| 06:02:41 | Llorean | Er <volume.bmp|-|-|-|-> or whatever |
| 06:02:56 | Llorean | I'm basically proposing use that .bmp in a new tag, rather than a variant of the old tag. |
| 06:03:00 | Llorean | So that it's more explicit for users. |
| 06:03:07 | Llorean | And so the theme code can still be rather clean |
| 06:04:27 | S_a_i_n_t | I still think it makes more sense to have just the one tage for "draw volume" and let the syntax that follows it determine how its drawn. |
| 06:04:42 | S_a_i_n_t | rather than having two tags with *similar* outcomes.' |
| 06:05:15 | Llorean | We've got lots of different tags for very similar things |
| 06:05:35 | Llorean | %ff / %fk, %fm / %fn, etc. |
| 06:05:40 | JdGordon | Llorean: the problem is those extra params to say where to draw the bmp |
| 06:05:54 | JdGordon | anything we do is going to be messy |
| 06:05:58 | Llorean | Ah, true |
| 06:06:15 | Llorean | I was just thinking it might be less messy if the progress bar-like version had its own tag, so someone could tell at a glance what they're trying to decipher |
| 06:06:35 | S_a_i_n_t | the syntax should indicate that. |
| 06:06:41 | JdGordon | it is obvious which volume display is being used by the code |
| 06:07:31 | Llorean | I'm confused. |
| 06:07:31 | JdGordon | and I'm liking %?pv<xdaA|%pv,volume.bmp,-,-,-,-,|%xdaB|%xdaC> if you want full control |
| 06:07:41 | Llorean | What does the new tag look like exactly? |
| 06:08:05 | S_a_i_n_t | JdGordon: btw, I think using "," instead of "|" makes it cleaner, better than the mess that %Sx can look like |
| 06:08:08 | Llorean | I mean the old tag is %?pv<Mute|N entries|0 dB|Above 0 dB> |
| 06:08:16 | Llorean | How do you distinguish the new tag, exactly? |
| 06:08:21 | Llorean | The presence of a filename as the first entry? |
| 06:08:22 | S_a_i_n_t | these tags systaxes are vaguely similar. |
| 06:08:46 | JdGordon | Llorean: %?pv<> is a conditional, %pv is a number, %pv|||||| is a bar |
| 06:08:51 | Llorean | Ah |
| 06:09:39 | Llorean | Will it draw without a .bmp as our old progress bar code? |
| 06:09:45 | JdGordon | yep |
| 06:09:59 | JdGordon | it is all the same code, just wired to different values :) |
| 06:10:28 | Llorean | I guess it makes sense then. |
| 06:10:34 | Llorean | Do we *need* a >0 conditional then? |
| 06:10:44 | Llorean | The basic %?pv<|||> conditional seems to do it. |
| 06:10:49 | Llorean | If someone _must_ have that functionality. |
| 06:10:53 | JdGordon | this is the question |
| 06:10:54 | Llorean | And it offers mute as well. |
| 06:11:04 | Llorean | I don't think we need to add yet another tag for something that's already done. |
| 06:11:46 | Llorean | It's going to look almost equally ugly with the two-case as with the four-case conditional |
| 06:11:49 | Llorean | Only very slightly better. |
| 06:13:14 | * | JdGordon is going to fix it so the param delimiter *inside* conditionals can be user defined |
| 06:13:30 | JdGordon | or would that be too flexible? |
| 06:13:38 | JdGordon | maybe just allow ,./ ? |
| 06:13:51 | JdGordon | or ' " : |
| 06:13:51 | Llorean | I'm not following. |
| 06:13:53 | S_a_i_n_t | wait, noob that up for me. |
| 06:14:02 | S_a_i_n_t | Me neither lol |
| 06:14:16 | Llorean | Oh, wait |
| 06:14:23 | Llorean | You mean allowing the use of something other than | in conditionals |
| 06:14:27 | * | Llorean somehow didn't see the /me line |
| 06:14:28 | JdGordon | %?pv<xdaA|%pv,volume.bmp,-,-,-,-,|%xdaB|%xdaC> <- readable %?pv<mute|%pv|volume.bmp|-|-|-|-||0db|dander> <- de fuck? |
| 06:15:00 | Llorean | Maybe allow conditionals to "eat" line breaks, so you can nest them across multiple lines for readability? |
| 06:15:22 | JdGordon | that would probably be a nice addition also, but not really related |
| 06:15:23 | Llorean | Allowing multiple delimiter choices just seems like a recipe for extra confusion as different WPS authors use different styles. |
| 06:15:33 | JdGordon | yeah |
| 06:15:33 | Llorean | Well, they both help readability in a situation like that. |
| 06:16:10 | S_a_i_n_t | IMO %?pv<xdaA|%pv,volume.bmp,-,-,-,-,|%xdaB|%xdaC> is the winner of the two. |
| 06:17:07 | S_a_i_n_t | but, having a bitmap for 0dB is slightly hard to do. |
| 06:17:44 | Llorean | %?pv<mute| |
| 06:17:44 | Llorean | %pv|volumte.bmp|-|-|-|-|| |
| 06:17:44 | Llorean | 0db| |
| 06:17:44 | DBUG | Enqueued KICK Llorean |
| 06:17:44 | Llorean | etc |
| 06:17:46 | Llorean | isn't too bad, though |
| 06:18:06 | | Quit linuxstb (Ping timeout: 252 seconds) |
| 06:18:13 | Llorean | S_a_i_n_t: I'd imagine for 0db you'd just re-use the full volume bar image. |
| 06:18:13 | S_a_i_n_t | still, if the rest is progressbar style, how is 0 and >o represented? |
| 06:18:27 | Llorean | The volume bar shouldn't appear "full" at -1db |
| 06:18:30 | S_a_i_n_t | >0rather |
| 06:18:31 | JdGordon | different colour |
| 06:18:31 | Llorean | So that'd be the only way to see it. |
| 06:18:43 | JdGordon | and the ! |
| 06:18:47 | Llorean | For >0 a different color, or even just something displaying to the side. |
| 06:19:00 | Llorean | Like you could show the full volume bar, but put a warning triangle to the right of it. |
| 06:19:04 | Llorean | It's up to the user. |
| 06:19:15 | Llorean | Current targets in cabbiev2 just turn the volume indicator red (on color targets, obviously) |
| 06:20:32 | S_a_i_n_t | the way I was thinking it was going to work (which is easiest when it comes to reducing .bmp's which is the goal here is it not?) is, two bmps drawn playbar style, image one is drawn from mute to 0dB, image two takes over from >0dB to max. |
| 06:20:35 | S_a_i_n_t | you dig me? |
| 06:21:27 | S_a_i_n_t | I was planning on using the last two images from the current .bmp strips for this. |
| 06:21:46 | S_a_i_n_t | I think this works best (in theory), but how to implement it. |
| 06:21:47 | JdGordon | 0 should be full or almost full |
| 06:21:55 | JdGordon | for cabbie, 0 SHOULD be full |
| 06:22:08 | JdGordon | full yellow |
| 06:22:10 | Llorean | For cabbie currently, 0d is the only time the "full" image is shown |
| 06:22:20 | Llorean | -1 gets a nearly full, and +1 gets red. |
| 06:22:31 | S_a_i_n_t | +1 to +6 |
| 06:22:40 | Llorean | +1 to +whatever |
| 06:22:56 | Llorean | Some targets stop at 0, others go up to +12 I think |
| 06:23:26 | | Quit JdGordon (Quit: Page closed) |
| 06:23:51 | S_a_i_n_t | I'd still like to (as its moddelled from the progress bar) be able to display incremental change past 0dB |
| 06:24:17 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 06:24:23 | Llorean | When implementing the old way (mute|increments|0|danger) we decided that wasn't too important. |
| 06:24:25 | S_a_i_n_t | the way it is in current SVN is fine, but the question/difficultty with that is where/how to start drawing "clipping" |
| 06:24:39 | S_a_i_n_t | as, some targets are plaing with one 11px across. |
| 06:24:54 | S_a_i_n_t | s/one/only |
| 06:24:55 | Llorean | Basically, the volume indicator isn't too useful past 0db other than letting you know in advance that if you unpause it's going to be very loud. |
| 06:25:15 | Llorean | S_a_i_n_t: Look at how it's done currently... |
| 06:25:21 | S_a_i_n_t | still, if its PB styled, it *should* still advance past 0db |
| 06:25:21 | Llorean | The whole image is overwritten with a different one |
| 06:25:46 | Llorean | It just needs to be indicated, there are ways to do this besides advancing. |
| 06:26:14 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 06:26:14 | * | jhMikeS has an idea for all audio settings: all settings range 0..n-1, with n being the number of levels. All can be translated easily to dB or other units and back again. Only one value is required in the driver. Any increment or number of decimal places can be represented anywhere, or rounded to nearest int if so desired. |
| 06:26:23 | S_a_i_n_t | but its nice to know "how far am I above 0db" instead of "I'm just past 0db" |
| 06:26:24 | S_a_i_n_t | IMO |
| 06:26:49 | jhMikeS | * of course this is internal, not user-visible, unless it increases accuracy of display. |
| 06:27:41 | S_a_i_n_t | I dont like the idea that you'd hear an audible increase in volume, yet stop seeing any visual reference of this past 0dB |
| 06:27:47 | S_a_i_n_t | that's my quark with it. |
| 06:28:11 | Llorean | S_a_i_n_t: In a lot of cases you won't hear an audible increase in volume so much as "more and more distortion at a similar loudness" |
| 06:28:13 | | Quit n17ikh (Ping timeout: 240 seconds) |
| 06:28:32 | jhMikeS | "quark? you mean qualm? |
| 06:29:05 | S_a_i_n_t | It just seems to break with the idea of drawing it as a progressbar, if we just stop doing incremental change at 0dB, we may as well not bother with it at all. |
| 06:29:06 | jhMikeS | perhaps it was a "strange quark". :P |
| 06:29:39 | S_a_i_n_t | the point of progressbar it to show min to max value IMO |
| 06:29:58 | S_a_i_n_t | regardless if that happens to exceed 0dB |
| 06:30:16 | Llorean | We had someone saying that last time. |
| 06:30:33 | Llorean | Basically, 0db is *a* upper bound |
| 06:30:46 | S_a_i_n_t | we need to note where it is exceeded visually of cource, but the idea that we stop drawing increments past 0dB seems pointless to me. |
| 06:30:52 | Llorean | You're fixating on the numerical maximum, rather than the realistic upper bound. |
| 06:30:56 | S_a_i_n_t | we may as well use bitmapstrips for that. |
| 06:31:09 | * | jhMikeS agress: bar full when no further increment is possible, bar empty when no further decrement is possible. (if he properly understands what's being discussed). |
| 06:31:11 | Llorean | What does how we draw it have to do with what we limit it at? |
| 06:31:18 | S_a_i_n_t | that "someone" was me ;) |
| 06:31:35 | S_a_i_n_t | and as per current SVN, I won that battle (sarcasm) |
| 06:31:57 | | Quit hearit (Read error: Connection reset by peer) |
| 06:31:58 | Llorean | Why would bitmap strips be better for the 89 steps below 0db, but we need a progress bar if we're gonna to 95 steps? |
| 06:32:31 | Llorean | Basically, "100% volume" is 0db, and above that would best be represented but >100% |
| 06:32:35 | Llorean | So a "full bar" is 0db. |
| 06:32:47 | S_a_i_n_t | well, IMO a progressbar should show ever increment it can, not just stop at a value it is capable of exceeding. |
| 06:32:52 | S_a_i_n_t | even if you shouldn;t |
| 06:32:57 | | Quit linuxstb (Ping timeout: 276 seconds) |
| 06:33:04 | S_a_i_n_t | users know that "full" volume is a bad idea. |
| 06:33:17 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 06:33:21 | Llorean | Many of them don't know of the dB scale or what exceeding it can mean at all |
| 06:33:46 | S_a_i_n_t | exactly, but *everyone* knows that max volume is bad. |
| 06:33:56 | jhMikeS | you can exceed the dB scale? |
| 06:34:06 | S_a_i_n_t | so, I don;t see why increments beyond 0dB pose a problem |
| 06:34:10 | Llorean | Sorry, what exceeding 0db can mean |
| 06:34:37 | Llorean | S_a_i_n_t: But they're hardly necessary, obviously. |
| 06:34:57 | Llorean | And you keep talking about "a progressbar" that goes the whole range. |
| 06:35:08 | Llorean | There should be a clear visual indicator when 0db is reached. |
| 06:35:27 | Llorean | Which either means a progress bar image that already indicates where the transition is (difficult to make cross-target compatible) or two progress bars rather than one. |
| 06:35:51 | S_a_i_n_t | In terms of a "progressbar" I think they are, the reason to have this (initially I thought it was going to be an option, but it seems it's taking over, it's optional *now* and I think it should stay that way) is so people can choose to display the "full" range if they wanted to. |
| 06:36:04 | S_a_i_n_t | actually, I think current svn is fine. |
| 06:36:18 | Llorean | People can see the full range by displaying a numeric volume. |
| 06:36:22 | S_a_i_n_t | commenting out a line for one way or the other in a theme may be an option to consider. |
| 06:36:33 | Llorean | A visual volume is always going to be approximation unless you have as many pixels in width as you have steps. |
| 06:37:50 | S_a_i_n_t | At the moment, they way I have done it in my theme is this. the last 10% of the volumebar is coloured orange, the final 7% is red. |
| 06:37:55 | S_a_i_n_t | works fine for me. |
| 06:38:11 | Llorean | That doesn't tell explicitly where 0db is, does it? |
| 06:38:13 | S_a_i_n_t | but for smaller .bmp's that is how this whole discussion came about. |
| 06:38:18 | Llorean | Not every 320x240 target has the same range. |
| 06:38:33 | S_a_i_n_t | it can't be represented that way, so we need a seperate image for >0dB |
| 06:39:03 | S_a_i_n_t | Llorean: no, but it gives an idea at least of loud, kinda bad, very bad. |
| 06:39:09 | S_a_i_n_t | which is all we really need. |
| 06:39:12 | Llorean | S_a_i_n_t: No. |
| 06:39:15 | Llorean | 0db is an important position. |
| 06:39:27 | Llorean | Knowing explicitly where 0 is is kinda the important part about all of it |
| 06:39:32 | S_a_i_n_t | sorry: kinda bad was my 0dB |
| 06:39:53 | Llorean | Another problem splitting it into two bars - if the first part is 90 pixels, and the second 10, what about targets that only go up to 0db? |
| 06:40:06 | Llorean | Or targets with a different ratio (-57 to +6 vs -89 to +6) |
| 06:40:11 | Llorean | Step sizes will vary for the two bars |
| 06:40:34 | jhMikeS | it's all sort of relative anyway. we could just make it so targets have maximum as 0dB without exception, or put 0dB elsewhere on the scale...say, all targets do +6. that's a little deeper change, however. |
| 06:40:37 | S_a_i_n_t | I assume in that case, at 0dB it would show the second "full/past 0dB" image at full. |
| 06:40:39 | Llorean | The problem is many targets have a 320x240 screen, and many of those have different volume ranges, yet the targets should in most cases share WPSes |
| 06:41:07 | Llorean | S_a_i_n_t: So you'd show a red clipping warning image at 0db where clipping is very unlikely? |
| 06:41:26 | Llorean | And that still doesn't address that the number of pixels per step at less than 0db will be different than at >0db depending on target. |
| 06:41:36 | jhMikeS | this -89 range on the S is done artificially anyway. others could be hooked up to do it though. |
| 06:42:35 | S_a_i_n_t | The way this is going, it's looking like its headed to "just show from min to max" |
| 06:42:55 | S_a_i_n_t | as it is now in SVN |
| 06:43:15 | Llorean | Max shouldn't be a positive number, though |
| 06:43:20 | S_a_i_n_t | the exceptions make it too difficult. |
| 06:43:21 | Llorean | Or rather, the maximum value on the bar. |
| 06:43:30 | S_a_i_n_t | and (at the moment) it is optional |
| 06:43:52 | S_a_i_n_t | so, I think a "comment this line and uncomment this line if you want this feature might be aplicable. |
| 06:44:53 | S_a_i_n_t | At the moment, if themers use it, they know what values it will display, and should be aware of any risks that may come with it. |
| 06:45:42 | S_a_i_n_t | But as I said earlier, eberyone knows full volume, or even near to it, is a bad idea. |
| 06:46:25 | S_a_i_n_t | The war against stop at 0dB or stop at Max Vol is never going to be won without someone just making a descision. |
| 06:46:35 | Llorean | This really has very little to do with "loud is a bad idea" |
| 06:46:50 | * | jhMikeS doubts it really is "everyone". There's always a few of them that just cannot help it. |
| 06:47:03 | Llorean | jhMikeS: There are plenty who've said +6 isn't loud enough and asked if we could make it louder |
| 06:47:09 | Llorean | It's about a visual indication that you've gone beyond 100% volume |
| 06:47:55 | S_a_i_n_t | and personally, if it were anything other than a progressbar, I'd gladly say "by a;ll means 0dB should be "max", but as it *is* a progressbar, I have to say "it should be min!max volume" |
| 06:48:15 | jhMikeS | I got that much so far. If we go to +6, I think that's all it's got. Beyond that, you need more efficient phones. |
| 06:48:55 | Llorean | S_a_i_n_t: It should go from 0-100%, that's different from "min-max" |
| 06:48:58 | | Quit hebz0rl_ (Quit: Ex-Chat) |
| 06:48:58 | jhMikeS | then again, they could just be impaired. I never listen to anything near 0db. |
| 06:50:02 | S_a_i_n_t | well, no, as you'll take 100% as 0dB right? when in my eyes "max" is +whatevr. |
| 06:50:05 | saratoga | jhMikeS: the 0dB point isn't really relative, by convention its the maximum level of the amp, with positive values corrisponding to overdriving |
| 06:50:10 | saratoga | so you risk clipping |
| 06:50:15 | Llorean | S_a_i_n_t: 0db is - 100% volume. Say a song is recorded at arbitrary loudness 50. If you add 0db to it, it's still 50 (100% of its original level). If you add 1db to it it's no >100% its original level. If you subtract from it, you're at <100%. Down to mute, which is 0%. |
| 06:50:42 | Llorean | 100% is 0db, plain and simple. Nothing added or subracted. |
| 06:50:45 | Llorean | *subtracted |
| 06:50:50 | jhMikeS | saratoga: is that always the case? I think you're right though. it sounds like it should mean something. |
| 06:50:50 | S_a_i_n_t | but we're IMO representing minimun/maximun output. |
| 06:50:57 | S_a_i_n_t | not a dB scale with this. |
| 06:50:59 | saratoga | in theory using positive gain values is no better then applying digital gain with the preamp, you will get clipping if you do it too much, but in practice the amp often handles it better then doing it digitally |
| 06:51:05 | Llorean | S_a_i_n_t: No, we're representing a percent of the volume. P V |
| 06:51:31 | saratoga | jhMikeS: well thats obviously hardware specific, but afaik we always set 0dB to be max voltage, and if its not, then that would be a bug |
| 06:52:42 | saratoga | i bet in practice some DACs have extra headroom built in just to be safe |
| 06:52:53 | jhMikeS | saratoga: most of my players allow additional gain above 0dB and I've never programmed a driver to limit it to less than the register range. |
| 06:53:16 | saratoga | in theory that extra gain is above the maximum output voltage of the DAC |
| 06:53:30 | saratoga | so its only louder if the digital output isn't peak normalized |
| 06:53:56 | saratoga | i guess you could pretty easily test this with RMAA though to see if its actually the case |
| 06:54:33 | saratoga | by that i mean only louder without distortion if the digital output isn't peak normalized |
| 06:54:37 | jhMikeS | right. but, a signal up to -6dB could go without clipping if it goes to +6. |
| 06:54:42 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 06:54:45 | saratoga | correct |
| 06:55:12 | S_a_i_n_t | OK, howabout this. We use 2 bitmaps (the third to last, and last cells from each volume bmp strip), the end of the third to last image is 0dB, and beyone that the second image "full red" starts to be displayed? |
| 06:55:41 | S_a_i_n_t | so fullred would be anything past 0dB |
| 06:56:36 | saratoga | isn't that what we do now in cabbie? |
| 06:57:01 | * | jhMikeS thinks the WPS parser and display would handle this best, by marking the "0dB point" somehow in the .wps file. That way it's always correct. |
| 06:57:15 | S_a_i_n_t | not quite. |
| 06:57:33 | S_a_i_n_t | the second to last image is 0dB, but its "full yellow" |
| 06:57:43 | saratoga | thats what it should be |
| 06:57:51 | saratoga | you're not overdriving until you get past 0dB |
| 06:57:56 | Llorean | Isn't that what cabbie does? |
| 06:58:07 | S_a_i_n_t | I suggested using the third to last, as there would still be room for increments past 0dB to be displayed. |
| 06:58:28 | S_a_i_n_t | exactly, that's what I suggested. |
| 06:58:36 | JdGordon_ | ... still going?! :p |
| 06:58:41 | S_a_i_n_t | yep. |
| 07:00 |
| 07:00:09 | | Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) |
| 07:00:22 | S_a_i_n_t | I think we have the champion...this seems to keep the masses happy, and keeps in line with it being a "progressbar" |
| 07:00:25 | S_a_i_n_t | \0/ |
| 07:00:31 | Llorean | S_a_i_n_t: I'm confused. |
| 07:00:38 | S_a_i_n_t | gah! |
| 07:00:40 | Llorean | You want to keep two extra images for "steps" or ? |
| 07:00:49 | notlistening | FlynDice you have any progress on your clip+ yet? |
| 07:00:55 | S_a_i_n_t | No, I want to only use two bitmaps |
| 07:00:57 | Llorean | Or is it two separate progress bars, one on each side of 0db? |
| 07:01:04 | S_a_i_n_t | yes |
| 07:01:06 | S_a_i_n_t | that |
| 07:01:08 | jhMikeS | is the number of images fixed (rather WPS ignorant here) |
| 07:01:09 | Llorean | If so, remember I asked about step size, and total spacing for players that stop at 0db |
| 07:01:23 | Llorean | You'll have different step size on the left and right side of 0db |
| 07:01:35 | Llorean | As well as having completely different use of space on players that stop at 0 |
| 07:01:38 | S_a_i_n_t | ahhhh.fuck! |
| 07:01:50 | S_a_i_n_t | there isn't one that works for all targets! |
| 07:02:00 | Llorean | There's just a lot of complication for trying to visualize the *amount* past 0db. |
| 07:02:12 | Llorean | Plus, if someone needs the exact amount they can use a theme with the number rather than visual bar |
| 07:02:17 | Llorean | That's kinda why the number exists. |
| 07:02:40 | JdGordon_ | jhMikeS: no, the total size of the loaded bmps are though |
| 07:02:43 | Llorean | What the visual /graphical version does is needs to indicate approximate loudness, 0db, and the potential for clipping in some manner. |
| 07:03:39 | jhMikeS | Llorean: Different step size is a problem, below vs above? is it really meant to be accurate? I admit I don't think too much of it looking at a bar. It just gives me a vague idea. |
| 07:03:45 | JdGordon_ | can everyone remembver that the number of pixels used is tiny comapred to the number of steps so any visualisation is stupidly approximate anyway |
| 07:04:07 | | Join CharlesNumber2 [0] (~476ad68f@giant.haxx.se) |
| 07:04:20 | Llorean | JdGordon_: That's kinda my point. I don't know why we need an approximation for use above 0db in the first place. On a lot of player it's going to be 1 or 2 steps at best anyway. |
| 07:04:36 | | Quit xiainx (Quit: Good Bye) |
| 07:05:15 | jhMikeS | other than this magic 0dB point, accuracy really isn't necessary |
| 07:05:23 | Llorean | jhMikeS: Well, my point is really that there needs to be a clear indicator when you're at 0, and it should be done in a way to try to take up the same amount of space on the screen independently of the volume range of the target (for those with a max of 0 and those with a max above 0) and that mostly comes out to "-X to 0, with a >0 indicator" |
| 07:05:42 | Llorean | Which is what Cabbiev2 does now anyway |
| 07:05:55 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.1.163) |
| 07:06:04 | S_a_i_n_t_ | bah...connection dropped. |
| 07:06:11 | *** | Saving seen data "./dancer.seen" |
| 07:06:38 | | Quit S_a_i_n_t (Ping timeout: 260 seconds) |
| 07:06:55 | | Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.1.163) |
| 07:07:51 | CharlesNumber2 | Hello all. I am encoding videos for my 5th generation iPod that runs the latest version of rockbox. When encoding with WinFF at a size of 320x240, the video doesn't play as fast as the audio and skips several frames every about every second. Is there a certain bitrate that the mpeg play will run best with? |
| 07:08:03 | | Quit linuxstb (Ping timeout: 276 seconds) |
| 07:08:14 | | Part The-Compiler |
| 07:08:55 | S_a_i_n_t | doesn't winFF have presets for RB targets? |
| 07:09:09 | CharlesNumber2 | yes and when using that preset it skips |
| 07:09:17 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 07:09:32 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 07:10:03 | S_a_i_n_t | Lower the framrate? |
| 07:10:04 | jhMikeS | Llorean: yes, that problem is rather sticky. it seems two things are in conflict. personally, I'd like to see some space if volume is left, while other targets wouldn't completely fill if they don't go above 0. |
| 07:10:17 | Llorean | CharlesNumber2: The iPod 5G is basically just not fast enough to do MPEG-2 well, and we can't use the hardware for MPEG-4 |
| 07:10:57 | CharlesNumber2 | Oh I see, Llorean, is there a better codec for the iPod 5G? |
| 07:11:22 | S_a_i_n_t | This whole thing is messy (volumeprogressbar), I wish to the Gods on high that one way would "just work" so I can get on and start making the patch up. |
| 07:11:58 | CharlesNumber2 | And it seemed to play fine when encoded with the size of an iPod nano screen, which led me to believe that the issue was bitrate |
| 07:12:01 | S_a_i_n_t | The whole targets the stop at 0dB seems to be the culprit |
| 07:12:07 | saratoga | you should just use the original firmware for vdieo on that player |
| 07:12:17 | S_a_i_n_t | and I'm tempted to say, "just don't use it for those targets"? |
| 07:12:59 | jhMikeS | on S, a single bar step is 12-13 dB, +6 would never register a change anyway. |
| 07:13:00 | Llorean | S_a_i_n_t: Why can't you just do it the way that's worked for cabbiev2 for so long? |
| 07:13:20 | Llorean | I thought the point was "show what we did before, but with finer steps" |
| 07:13:22 | | Quit CharlesNumber2 (Quit: CGI:IRC (EOF)) |
| 07:13:25 | * | jhMikeS spoke of cabbiev2 of course |
| 07:13:45 | S_a_i_n_t | As I've stated, I have beef with the idea that increments past 0dB aren't displayed. |
| 07:13:52 | jhMikeS | Llorean: I'd welcome at least pixel-level step for sure. It's way too coarse. |
| 07:14:09 | Llorean | S_a_i_n_t: The fact that you have beef with it doesn't change the fact that that's currently how the theme is designed. |
| 07:14:24 | Llorean | Implementing a new feature with the same design, and changing the design, are two different tasks anyway |
| 07:14:37 | Llorean | jhMikeS: This new feature does exactly that, AFAIK |
| 07:14:54 | Llorean | jhMikeS: Basically, it progressively reveals a bitmap based on volume level, just like the bitmap progress bar. |
| 07:15:08 | S_a_i_n_t | well, I didn't necessarily think we were sticking to the original design. |
| 07:15:13 | S_a_i_n_t | *strictly* |
| 07:15:19 | Llorean | S_a_i_n_t: At the very least they should be presented as two separate patches. |
| 07:15:24 | S_a_i_n_t | as much as we cold sure, but not strictly. |
| 07:15:37 | Llorean | "as much as we could" would mean not change the red display... |
| 07:16:14 | S_a_i_n_t | I want it to display red, it's only the targets that stop at 0dB messing this idea up |
| 07:16:38 | S_a_i_n_t | if it wasn;t for that my past idea of third to last and last cells from the original volume would work fine. |
| 07:16:44 | Llorean | It only messes the idea up if you insist on adding progress after red. |
| 07:16:48 | Llorean | Something that isn't there currently |
| 07:17:30 | S_a_i_n_t | progress after red makes sense, to me, if there *is* progress after red. |
| 07:17:38 | S_a_i_n_t | if there wasn't, then it wouldn't |
| 07:18:13 | jhMikeS | Llorean: ok, I thought so. the problem is the same, multi-image or progressive revealing. :) |
| 07:18:28 | S_a_i_n_t | jhMikeS: basically, yes. |
| 07:18:29 | Llorean | S_a_i_n_t: Yeah, but adding that conflicts with your own earlier statement of preserving the old behaviour "as much as we cold" (presumably, could) |
| 07:18:55 | Llorean | jhMikeS: My point is that adapting the current WPS to the new code should be a different discussion than "changing the behaviour of the default WPS" |
| 07:19:12 | Llorean | He's basically saying he can't adapt it to the new code because he's unwilling to have it work the way it's always worked. |
| 07:19:35 | S_a_i_n_t | I'm not saying that at all...don;t be an ass. |
| 07:19:36 | Llorean | And he obviously doesn't have to adapt it. |
| 07:19:44 | S_a_i_n_t | I'm stating an opinion same as you are. |
| 07:20:01 | Llorean | S_a_i_n_t: ", I wish to the Gods on high that one way would "just work" so I can get on and start making the patch up." |
| 07:20:05 | Llorean | One way *does* just work |
| 07:20:12 | Llorean | So you *can* get on and start making it up. |
| 07:20:40 | S_a_i_n_t | No, I can't, as we have no syntax. |
| 07:20:51 | Llorean | Didn't JdGordon_ give you the syntax for doing it that way? |
| 07:20:59 | S_a_i_n_t | no. |
| 07:20:59 | Llorean | Nest a pv progress bar inside a ?pv conditional |
| 07:21:18 | JdGordon_ | that doesnt work in svn |
| 07:21:20 | Llorean | He said the fix for it eating the nested tag stuff is minor. |
| 07:21:26 | S_a_i_n_t | he gave several different versions of ways to do it |
| 07:21:30 | S_a_i_n_t | *potentailly* |
| 07:21:58 | S_a_i_n_t | Nothing is set in stone, which is why this is still a debate. |
| 07:22:22 | Llorean | One requires what the JdGordon_ has said is a minor fix, then things can be made to work as they worked before only with more accuracy |
| 07:22:27 | Llorean | Seems like a pretty good starting point at least |
| 07:22:45 | Llorean | It also is screen size and volume range independent. |
| 07:23:04 | S_a_i_n_t | yes, but untill I see actual code...there's no pint. |
| 07:23:11 | S_a_i_n_t | As I may have to undo everything. |
| 07:23:16 | S_a_i_n_t | *point |
| 07:23:37 | | Quit liar (Ping timeout: 258 seconds) |
| 07:24:05 | S_a_i_n_t | He may find another way of doing it, he may change his mind...I'm not writing code for something on a whim and a prayer. |
| 07:24:16 | JdGordon_ | boring! |
| 07:24:31 | JdGordon_ | I mean not writing code on a whim and prayer is boring |
| 07:24:59 | S_a_i_n_t | but, indeed, you *may* well change it completely...even you have to admit that ;P |
| 07:25:16 | JdGordon_ | no, I think the pv inside pv is the way to go |
| 07:25:40 | Llorean | At the very least it's a good halfway point until any other decisions are made. |
| 07:25:46 | S_a_i_n_t | and we're set on two images? |
| 07:26:41 | * | jhMikeS should probably actually learn WPS-eez and could contribute more meaningfully to all this stuff, since UI is always a contentious point, thereby providing a good fill of entertainment. :P |
| 07:27:26 | JdGordon_ | and headache |
| 07:27:34 | S_a_i_n_t | Amen |
| 07:27:47 | JdGordon_ | How does allowing , and ' for internal seperators sound? |
| 07:27:59 | * | jhMikeS has lots of naproxen sodium and good kidneys and liver to process it. |
| 07:28:42 | S_a_i_n_t | *and* ' ? |
| 07:28:55 | JdGordon_ | not together of course |
| 07:28:59 | * | pixelma would rather want cabbie to display volume in decibels while changing volume like the builtin status bar does (and was started in the Clip version but never continued) |
| 07:30:02 | S_a_i_n_t | so, do we have a mute image? |
| 07:30:07 | S_a_i_n_t | that's a no right? |
| 07:30:15 | Llorean | pixelma: That is quite nice, yes. |
| 07:30:26 | jhMikeS | S_a_i_n_t: not that i know of...it's exceedingly rare if so. :) |
| 07:30:32 | Llorean | S_a_i_n_t: Status bar displays mute, but I don't know if any of the cabbiev2 variants do |
| 07:31:00 | jhMikeS | there's only one mute level anyway...mute |
| 07:31:01 | S_a_i_n_t | just checking it wasn't going to be added with this. |
| 07:31:21 | S_a_i_n_t | see? the original syntax I saw had mute. |
| 07:31:36 | pixelma | S_a_i_n_t: it could be that monochrome or greyscale targets do, not sure |
| 07:32:01 | S_a_i_n_t | That's why I'd like to see the syntax, seperators. |
| 07:32:12 | S_a_i_n_t | pixelma: IIRC, they won't anymore |
| 07:32:21 | S_a_i_n_t | but I'm only working with colour for now. |
| 07:32:21 | * | jhMikeS wishes there could be a target with lower-than-mute volume to argue about, one with imaginary volume |
| 07:32:23 | pixelma | not a "special" one, just because you can't represent "empty" in the same graphic style |
| 07:32:43 | pixelma | S_a_i_n_t: what won't work anymore? |
| 07:33:00 | S_a_i_n_t | well, it will just be "empty" for mute. |
| 07:33:06 | S_a_i_n_t | unless I'm mistaken. |
| 07:33:16 | pixelma | why that? |
| 07:33:30 | S_a_i_n_t | switch to progressbar style volume |
| 07:33:52 | pixelma | the first part of %?pv is mute |
| 07:34:06 | S_a_i_n_t | and AFAIK, we're only doing images for min to 0dB and >0dB |
| 07:34:17 | Llorean | And min db should be 1 above mute. |
| 07:34:22 | Llorean | Mute shouldn't show anything within the volume space. |
| 07:34:34 | Llorean | Since it's not really a "db value" at all anyway |
| 07:34:53 | S_a_i_n_t | pixelma: that's the *old* (yet still current) way it works. |
| 07:35:10 | jhMikeS | Llorean: a big "X" maybe? |
| 07:35:19 | pixelma | yes, so why can't the "new" way? |
| 07:35:25 | Llorean | jhMikeS: I'm happy with the current solution of "just show nothing" |
| 07:35:34 | Llorean | There's no yellow at all, just the gray shadow behind the volume triangle |
| 07:37:19 | S_a_i_n_t | JdGordon_: so, it's " %?pv<%pv,volumebar.bmp,-,-,-,-|%xda> " ? |
| 07:37:21 | jhMikeS | Llorean: I know, but somehow, I don't feel quite perfectly certain by looking at it. I think, from an ignorant stance, "maybe it could just be quite near it since it's not accurate". |
| 07:37:28 | S_a_i_n_t | is that agreeable for now? |
| 07:37:53 | JdGordon_ | pixelma: what do you tinhk about allowing the seperator for tags inside conditionals to be something other than | (like the example S_a_i_n_t just said where , is used instead of | ) |
| 07:37:55 | Llorean | jhMikeS: Well, something more explicit isn't bad. |
| 07:38:18 | Llorean | jhMikeS: Especially since I think some targets still don't mute, and seeing a mute image but hearing very faint audio can let someone know to report that it's not muting the DAC yet. |
| 07:38:51 | JdGordon_ | S_a_i_n_t: no, %pv doesnt change, so you still need the mute and 0 params, even if they are empty (which they shouldnt be or it wont work properly |
| 07:38:52 | jhMikeS | Llorean: perhaps show a little icon when it hits mute, otherwide hidden. For cabbie, it could go in that otherwise blank upper part. |
| 07:39:35 | Llorean | jhMikeS: Makes sense |
| 07:39:41 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 07:39:50 | S_a_i_n_t | so, what are the params to be for mute anu 0? I thought we were using 2 images? |
| 07:39:56 | S_a_i_n_t | *and |
| 07:40:11 | pixelma | JdGordon_: I'm usually opposed to new character that need special treatment then when you want to use them "normally" (if a %, would be needed) and I don't see why it is here yet |
| 07:40:23 | JdGordon_ | mute is either a image showing mute, or empty so the backdrop silooutte is used |
| 07:40:44 | S_a_i_n_t | and 0 needs its own image? |
| 07:41:06 | pixelma | line level might be interesting |
| 07:41:19 | Llorean | Almost definitely unless we know for sure that -1 will never show what looks like a full bar. |
| 07:41:21 | JdGordon_ | pixelma: %?pv<xdaA|%pv,volume.bmp,-,-,-,-,|%xdaB|%xdaC> <- readable %?pv<mute|%pv|volume.bmp|-|-|-|-||0db|dander> <- unreadable |
| 07:42:38 | S_a_i_n_t | so, compared to volume.bmp, what is 0db's image to be? |
| 07:42:50 | S_a_i_n_t | how do we show that as an increment? |
| 07:43:08 | pixelma | S_a_i_n_t: by the way - we have a mute button on most targets with a radio... |
| 07:43:08 | S_a_i_n_t | I'm *fucking* lost. |
| 07:43:08 | JdGordon_ | it would be a copy probably of the full image |
| 07:43:16 | JdGordon_ | :) |
| 07:43:44 | S_a_i_n_t | Hmmmm, ok. |
| 07:44:28 | | Quit linuxstb (Read error: Operation timed out) |
| 07:44:33 | S_a_i_n_t | So, I'll also need to add a mute image, of should I just leave that out (for now)? |
| 07:44:34 | JdGordon_ | I'm just testing it now |
| 07:44:40 | Llorean | JdGordon_: How would you distinguish it from -1 then? |
| 07:44:42 | JdGordon_ | doesnt look like it works without a bmp |
| 07:44:54 | S_a_i_n_t | I was just thinking that. |
| 07:44:58 | JdGordon_ | Llorean: you wouldnt, and you wouldnt be expected to |
| 07:45:03 | S_a_i_n_t | 0 and -1 will be the same image. |
| 07:45:12 | JdGordon_ | just like you cant tell the difference between -43 and -35 |
| 07:45:22 | S_a_i_n_t | Hmmm, fine with me. All i needed to know. |
| 07:45:25 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 07:45:34 | S_a_i_n_t | "do people expect it to be different." |
| 07:45:39 | Llorean | JdGordon_: So what, you can't tell when line level is hit? |
| 07:45:52 | Llorean | Right now 0db is easily distinguished from -1 |
| 07:45:58 | S_a_i_n_t | yes, back off one from "fullred" |
| 07:46:07 | Llorean | S_a_i_n_t: Which only works on targets that have that. |
| 07:46:14 | S_a_i_n_t | good point. |
| 07:46:17 | JdGordon_ | so make the "full" not quite full |
| 07:46:19 | S_a_i_n_t | AAAAARRRGH! |
| 07:46:22 | Llorean | And also makes it impossible to find without first going over, something you might not want to do. |
| 07:46:27 | Llorean | JdGordon_: Yes, that was my point actually |
| 07:46:29 | S_a_i_n_t | see whay I haven't written code yet? |
| 07:46:30 | S_a_i_n_t | ;P |
| 07:46:32 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 07:46:44 | Llorean | -1 should stop 1 pixel or whatever visible unit short of the 0db image |
| 07:46:56 | Llorean | Which just means you draw your progress bar 1 pixel shorter than the 0db image |
| 07:47:09 | S_a_i_n_t | then we need three images, and just can't reuse one. |
| 07:47:13 | Llorean | Or 1 pixel short from the edge of the frame or whatever. |
| 07:47:19 | S_a_i_n_t | And the savins start becomming less. |
| 07:47:42 | JdGordon_ | my laptop doesnt have internet making this hard.... |
| 07:47:43 | S_a_i_n_t | ipx is a LOT on some targets |
| 07:47:49 | S_a_i_n_t | and *nothing* on others |
| 07:47:55 | S_a_i_n_t | 1px |
| 07:48:05 | Llorean | S_a_i_n_t: I don't see how you can't reuse an image. |
| 07:48:18 | Llorean | You could just draw the 1px short image + a single 1px wide image for the "0db" case. |
| 07:48:19 | pixelma | JdGordon_: about your %pv explanation compared to %pb - with the progressbar you can just use %pb which will draw it in the current line, looks like this is not possible with %pv because then it is a number |
| 07:48:33 | S_a_i_n_t | well, it was sugested to reuse volume.bmp for 0dB |
| 07:48:39 | Llorean | I just said you could... |
| 07:48:46 | Llorean | You reuse it plus append a single tiny image. |
| 07:48:58 | JdGordon_ | pixelma: %pv|-|-|-|-| will do a boring line (you might need the height one filled in though |
| 07:49:01 | Llorean | As in, you append it within the WPS rather than on the file |
| 07:49:37 | S_a_i_n_t | I am officially massively confused. |
| 07:49:40 | S_a_i_n_t | I have no idea what is happening anymore. |
| 07:49:52 | S_a_i_n_t | you've all lost me. |
| 07:50:43 | S_a_i_n_t | We're going to end up with four images including mute, and on most targets the savings wont weigh out with the hassle. |
| 07:50:44 | jhMikeS | that's our real MO, to confuse and obfuscate /joke |
| 07:51:19 | pixelma | JdGordon_: yes, but you compared the two as if the case %pb wouldn't exist (and using "the same code" I just want to remind of that just in case there could be problems in the code because you didn't think of this part) |
| 07:52:09 | pixelma | and I still have my doubts about using the same tag name |
| 07:52:31 | JdGordon_ | you are very kind, but no, you are thinking about it wrongly. %pb is the standard bar display, %pv is the standard volume display (i.e a number)... if you add extra params you get the new shiy display for both |
| 07:52:33 | Llorean | S_a_i_n_t: The only difference in size between the four images and the three images (without the 0db image) would be the size of the bitmap header. |
| 07:53:02 | S_a_i_n_t | so, what's the point? |
| 07:53:16 | S_a_i_n_t | when it was one image I saw it...now I'm not so sure anymore. |
| 07:53:17 | JdGordon_ | the point is not needing 8 images for the variable bit |
| 07:53:30 | | Quit anewuser (Quit: http://xrl.us/Renoise Like renoise + like music? 3 days to submit your entry!) |
| 07:53:32 | Llorean | S_a_i_n_t: The point is that it's also much smoother in increasing/decreasing |
| 07:53:59 | S_a_i_n_t | until 0db that is. |
| 07:54:27 | Llorean | You have a mute image, a volume bar that's X pixels long, a 1px wide "0db" image that you draw alongside the full volume bard, and a "overboost" image. |
| 07:54:30 | JdGordon_ | yes, so now you only need a mute, full, 0, clipping image, instead of 8 for full |
| 07:54:49 | jhMikeS | what about just switching to an alternate image and continuing to fill the bar as normal? |
| 07:55:15 | Llorean | Instead of 8 images all 40 pixels wide, you have 1 image 39 pixels wide, one 1pixel, and one 40 (if you have a full sized overboost image) |
| 07:55:16 | JdGordon_ | or doing that so it is only 1 miage |
| 07:55:20 | Llorean | So 1/4 the image data |
| 07:55:23 | S_a_i_n_t | jhMikeS: that was my "two image idea" |
| 07:55:28 | S_a_i_n_t | it got shot down |
| 07:57:00 | | Quit Spaceghost (Read error: Connection reset by peer) |
| 07:57:04 | S_a_i_n_t | llorean, take a look at some of the smaller volumebars though |
| 07:57:18 | S_a_i_n_t | that 1px is goint to be a LOT more than 1dB |
| 07:57:35 | S_a_i_n_t | thats why it doesn't work. |
| 07:57:37 | Llorean | jhMikeS: If we could take advantage of the cover art scaling code, you could possible just give it two arbitrary bitmaps and then tell it what size space for it to fit them in, and have it handle the transition through 0db depending on space available and range of the player |
| 07:57:48 | JdGordon_ | on those I think going the multi colour single bar makes more sense and just ignore it not being exact |
| 07:57:49 | Llorean | So the strip would always be 100px long, sometimes including a red bit sometimes not. |
| 07:58:16 | JdGordon_ | and make it show the number when the volume is changing |
| 07:58:17 | S_a_i_n_t | JdGordon_: then you have no concept of line level |
| 07:58:22 | jhMikeS | S_a_i_n_t: Hmm...I've been dipping in and out. I'm not sure why it would be. |
| 07:58:24 | S_a_i_n_t | and people WILL cry about it. |
| 07:58:44 | Llorean | S_a_i_n_t: So draw an "Endcap" of some sort rather than making it appear to be "progress"... then it doesn't need to seem to be 1db and confuse people |
| 07:59:25 | jhMikeS | Llorean: Switching to an overdrive image though, allow ones without overdrive to display a full normal image, while in overdrive range, the switchover allows a full range without saturating it at 0. |
| 07:59:39 | S_a_i_n_t | This is far more complicated than it needs to be, introduces special cases for targets...I'm losing faith. |
| 07:59:45 | Llorean | jhMikeS: I'm not sure I understood that statement. |
| 07:59:49 | JdGordon_ | hmm... it looks like even with a bmp it draws one pixel at the minimum value |
| 08:00 |
| 08:00:09 | Llorean | JdGordon_: It doesn't when muted on my player at least |
| 08:00:16 | Llorean | But mute+1 it shows a pixel |
| 08:00:29 | JdGordon_ | the new code I'm talking about |
| 08:00:32 | Llorean | Oh |
| 08:00:38 | JdGordon_ | using the progressbar from cabbie to test |
| 08:00:41 | * | jhMikeS is cooking something and will return to explain shortly |
| 08:00:46 | S_a_i_n_t | JdGordon_: you're correct. |
| 08:00:46 | Llorean | S_a_i_n_t: I don't see why there's a problem with 1 pixel representing the last step to full. |
| 08:00:58 | Llorean | Arguably the bar shouldn't "round up" to a 100% full bar until you're full |
| 08:01:00 | S_a_i_n_t | I had to hide it with an overlay in my OF theme |
| 08:01:27 | S_a_i_n_t | Llorean: well, what if the volume is 30px wide? |
| 08:01:29 | JdGordon_ | or start the actual image 2 pixels into the bmp |
| 08:01:30 | S_a_i_n_t | or 11? |
| 08:01:35 | S_a_i_n_t | then its a problem |
| 08:01:41 | Llorean | S_a_i_n_t: So you're saying it should present a full bar even at -10? |
| 08:01:42 | S_a_i_n_t | its either too much or too little |
| 08:02:02 | Llorean | It's always going to have to approximate if there's not room. I'm just saying only the last step should "fill" just like it does on-target now |
| 08:02:11 | Llorean | The bar isn't full until the 0db step |
| 08:02:16 | S_a_i_n_t | We either need it to be consistent (like the current code) for targets...or, it's juat making things crazy. |
| 08:02:58 | S_a_i_n_t | And always showing 1px if its muted will be really offputting fot the "small volume=bmp" targets. |
| 08:03:05 | Llorean | the current code stops short of full, then only uses the full image for the single step of 0db. -1 is a different image, and +1 is a different image, independently of how many steps the -1 image covers. |
| 08:03:19 | JdGordon_ | ~line 1229 of apps/gui/skin_engine/skin_parser,c, can someone change that to "return ptr+1-wps_bufptr;" and test the bars inside conditionals please? |
| 08:03:25 | JdGordon_ | that will stop it eating the whole line |
| 08:03:26 | S_a_i_n_t | yes, I do know how it works currently. |
| 08:03:40 | Llorean | So why were you saying it needs to be "consistent (like the current code)"? |
| 08:03:52 | Llorean | My suggestion was to mimic the current code's behaviour by only showing a completely full bar for 0db |
| 08:03:58 | S_a_i_n_t | what I mean is, why introduce this this way and have special cases for some targets "just because it doesn't work" |
| 08:04:09 | Llorean | Since you can't draw a half pixel, you mimic this by only drawing the last pixel when the bar is full... |
| 08:04:17 | Llorean | What targets would be special cased? |
| 08:04:24 | S_a_i_n_t | If it were just one image, it would be *so* much easier |
| 08:04:31 | S_a_i_n_t | but it can't be...so? |
| 08:04:41 | Llorean | What targets would be special cased though? |
| 08:04:47 | S_a_i_n_t | the "small volume.bmp" targets. |
| 08:04:47 | jhMikeS | Llorean: For mute, switch to mute image, for normal range, display normal image clipped according to full volume scale, above 0, display overdrive image clipped according to full volume scale. |
| 08:04:54 | Llorean | S_a_i_n_t: Why would they be special cased? |
| 08:04:59 | JdGordon_ | how about.... %?mv<%pv|%pv|volume.bmp|....|> where that volume.bmp is a coloured bar |
| 08:05:00 | Llorean | Do they have less than 2 pixels for the volume image? |
| 08:05:24 | S_a_i_n_t | you'd need to just vauely colourise the bitmap, instead of this stepping, and you'd loose all concept for libe level |
| 08:05:41 | Llorean | S_a_i_n_t: Is that what we do on those targets currently? |
| 08:05:54 | Llorean | I don't see why they'd need special casing for a smooth stepping bar when they don't need it for the coarse stepping bar. |
| 08:06:07 | S_a_i_n_t | no, but the way we want to do it now won;t work right. |
| 08:06:23 | S_a_i_n_t | -1px for less than line level is far too much |
| 08:06:32 | S_a_i_n_t | and on the bigger targets, far too little |
| 08:06:34 | Llorean | But we currently do -1px for less than line level |
| 08:06:34 | | Quit linuxstb (Quit: Leaving) |
| 08:07:00 | Llorean | And, the target would need to have more pixels for the image than volume steps before it becomes "too little" let alone "far too little" |
| 08:07:27 | jhMikeS | Llorean: so, for a target with no overdive, no OD image is shown and the normal image is shown fully at 0dB, while for overdrive targets, the image is shown gradually even in overdrive levels. |
| 08:07:57 | S_a_i_n_t | if the image only is 11px across, and you take away 1px for -1line level...it's really about 3~4db-ish |
| 08:08:09 | S_a_i_n_t | probably 2~3ish, but still |
| 08:08:12 | Llorean | jhMikeS: Maybe just draw the OD image on top of the full bar, as a sort of second bar? Just re-fill the progress bar to represent that it's "over full" |
| 08:08:21 | Llorean | So you can then see when you're at 100% overdrive when the bar fills a second time |
| 08:08:45 | Llorean | S_a_i_n_t: If you have 8 steps and the image is 11 px wide, 1px = 8db. |
| 08:08:58 | Llorean | And yet we already use 1px as the change from -1 to 0 |
| 08:09:02 | Llorean | Or sometimes several px |
| 08:09:17 | Llorean | The problem you're stating we'd have is a "problem" we already have, and not really a problem |
| 08:09:22 | jhMikeS | Llorean: LOL. What? "Fills a second time"? I want to fill one time, no more than that! :) |
| 08:09:30 | S_a_i_n_t | which is why if accuracy is one of the reasons this is implemented...it's a fail. |
| 08:09:52 | Llorean | S_a_i_n_t: Displaying a 100% full bar when it's not 100% full is also inaccurate. |
| 08:10:04 | pixelma | JdGordon_: (a) I'd rather see a [] or something around those multi-parameter tags (same with %St etc.) which would make the line more readable too (b) if you have need another separator, maybe you could reuse ; which isn't allowed in conditionals anyways IIRC - but I don't like introducing another separator for conditional because it seems inconsistent |
| 08:10:05 | jhMikeS | that's sort of like puking during a binge so you can keep drinking ?? |
| 08:10:27 | Llorean | S_a_i_n_t: 1px will never = 1db, they're always going to equal a range of them. So the single px below 0db represents -9 to -1 for example |
| 08:10:30 | Llorean | What's wrong with this? |
| 08:10:37 | Llorean | Why should the last pixel have the same range as previous ones? |
| 08:10:45 | pixelma | JdGordon_: (a) for every tag it applies to would break a lot of existing themes unfortunately I think |
| 08:11:06 | S_a_i_n_t | it shouldn;t, unless its a progressbar that is supposed to represent a percentile. |
| 08:11:07 | Llorean | jhMikeS: I'm just trying to think of a way to visually represent it without changing how much space you use. |
| 08:11:20 | S_a_i_n_t | in the way it is now, its fine. |
| 08:11:26 | jhMikeS | Llorean: so was I. it would do just exactly that with some minor code support. |
| 08:11:37 | Llorean | jhMikeS: I guess I don't well understand yours, sorry. |
| 08:12:20 | S_a_i_n_t | I don't understand it at all anymore...as soon as it went past 2 images (or 3 for mute also) it kinda lost the whole point of it. |
| 08:12:31 | Llorean | S_a_i_n_t: Okay, think of it this way, "no pixels" obviously means mute. Once you've added X db, the first pixel lights up. Add X more the second one does. Keep adding X and eventually the last one lights up, and you're full." |
| 08:12:49 | S_a_i_n_t | Llorean: that is one problem already |
| 08:12:52 | jhMikeS | Llorean: the over-zero bitmap would be the same size as the one used for 0db and less, but *both* clipped according to the range, say, -89 to +6 dB. |
| 08:12:53 | S_a_i_n_t | with this way |
| 08:12:55 | Llorean | Why does it need to keep going past lighting the last one up? |
| 08:13:01 | S_a_i_n_t | we don;t *have* no pixels |
| 08:13:05 | S_a_i_n_t | it's always 1 |
| 08:13:08 | Llorean | S_a_i_n_t: JdGordon_'s fixing that |
| 08:13:11 | Llorean | Or did you miss that? |
| 08:13:25 | Llorean | Or at least, I think he is |
| 08:13:29 | Llorean | He made it sound like it's unintentional |
| 08:13:35 | S_a_i_n_t | Apparently I did...this is so fucking hard to follow. |
| 08:13:52 | S_a_i_n_t | Someone needs to make up their mind, and even if I don;t like it, I'll do it. |
| 08:14:05 | S_a_i_n_t | but we need to have our minds made up. |
| 08:14:19 | Llorean | jhMikeS: So on targets that go to 0db it'd fill the whole thing because the overboost bitmap would always be hidden, or? |
| 08:14:26 | jhMikeS | Llorean: yes |
| 08:15:19 | jhMikeS | there, loading it could be avoided entirely with a quick check |
| 08:15:35 | pixelma | jhMikeS: not sure where you wanted to go there but not all audio settings are 0...n - bass and treble isn't |
| 08:16:20 | S_a_i_n_t | Basically, I'm at a point where I couldnlt give a rats ass how its done, as long as I know how it will be done, and that noone will change their mind. |
| 08:17:12 | S_a_i_n_t | But then, someone will come along that wasn't in this discussion and say, why have you done this (for some reason I'm thinking kugel might not like it so much) and demand it be changed. |
| 08:18:32 | S_a_i_n_t | the point it is now in SVN is fine if we just arbitrarily colour the bitmap for line-level |
| 08:18:39 | S_a_i_n_t | and it only usus 1 bitmap |
| 08:19:03 | Llorean | And you need target-specific bitmaps. |
| 08:19:10 | Llorean | Rather than screen-specific |
| 08:20:00 | S_a_i_n_t | that is less hassle than it is at the moment though |
| 08:20:08 | S_a_i_n_t | and more saving in buffer |
| 08:20:26 | jhMikeS | pixelma: are you referring to my earlier comment? The PP e200 has odd steps that the number doesn't reflect accurately, but it would be accurate and could just show whole numbers. |
| 08:21:19 | S_a_i_n_t | I'm honestly scared for the lefe of this project if it goes much past SVN now. |
| 08:21:24 | S_a_i_n_t | *life |
| 08:21:48 | S_a_i_n_t | The initial idea was to use 1 bitmap. |
| 08:22:17 | jhMikeS | Llorean: btw, you'd only need 3 bitmaps, mute, normal and, if supported "overboost". if we cut mute out, then 2 of course. |
| 08:22:31 | S_a_i_n_t | And in that sense, just arbitrarily colouring the bitmap to represent line-level (as we'll have to do for some targets anyway) seems to be the way to go. |
| 08:23:22 | S_a_i_n_t | not entirely arbitrary of course, but it'd be just as accurate as we can get it if we *do *implement the curent way of thinking. |
| 08:23:44 | Llorean | jhMikeS: If the last step in the first bitmap was always the 1 step to line level, that should be fine. |
| 08:25:33 | S_a_i_n_t | Does anyone have a nano1g (current SVN) sim? |
| 08:25:46 | S_a_i_n_t | I can show you how my idea looks, I'm already using it. |
| 08:26:05 | jhMikeS | Llorean: at least that could allow a completely accurate (if shown with enough pixels width) progress-style, working for any range |
| 08:26:20 | S_a_i_n_t | Using only 1 bitmap really isn't as bad as it *seems* to be. |
| 08:27:04 | Llorean | jhMikeS: I'm really only concerned with "completely accurate" if "width in pixels" == "number of volume steps" |
| 08:27:25 | Llorean | In any other width, I don't mind if there's a little inaccuracy introduced by being explicit where 0db is. |
| 08:27:57 | Llorean | The first step past 0db should always present some sort of user feedback that something has changed. |
| 08:27:58 | jhMikeS | Llorean: exactly. it doesn't inhibit that if the themer wants it. |
| 08:28:33 | Llorean | jhMikeS: I guess I'm just not understanding the verbalization of what you're proposing. Somehow I can't imagine how it works in my head, sorry. I'll take your word for it though. |
| 08:29:19 | * | jhMikeS gets out the paint program real quick and tries. |
| 08:30:54 | | Quit arbingordon (Quit: `) |
| 08:31:27 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:33:06 | S_a_i_n_t | this is what I'm using in current SVN, works fine for me. |
| 08:33:08 | S_a_i_n_t | http://imgur.com/OL9pF.png |
| 08:33:42 | S_a_i_n_t | the linelevel range is a *little* bigger than it need be, but otherwise fine. |
| 08:34:33 | Llorean | You do realize line level is one *specific* value, not a range, right? |
| 08:35:18 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 08:35:35 | S_a_i_n_t | yes, I do, I mean the range on the bar, basically, if you're in orange you're close enough. |
| 08:36:01 | S_a_i_n_t | It's going to have to be this way for some targets with the *new* implementation also. |
| 08:36:09 | jhMikeS | Llorean: jhmikes.cleansoap.org/mute_normal_over.bmp">http://jhmikes.cleansoap.org/mute_normal_over.bmp |
| 08:36:11 | Llorean | No, it doesn't if things get fixed. |
| 08:36:52 | S_a_i_n_t | it was Jd's suggestion of "fixed" for "small volumebar targets" |
| 08:36:56 | Llorean | jhMikeS: So just have it transition to displaying the red bar on top at 1db? |
| 08:37:12 | Llorean | jhMikeS: I was trying to overcomplicated it in my head, I think |
| 08:37:16 | jhMikeS | Llorean: yeah, 1db transition, not 0db |
| 08:37:33 | Llorean | jhMikeS: Yeah, but it's still explicit about where 0db is, which is the most important part. |
| 08:37:41 | Llorean | And that can even let you know where 0db is inter-pixel |
| 08:37:48 | Llorean | Er intra-pixel? |
| 08:37:55 | Llorean | Man, I never know which of those prefixes to use in a case like this |
| 08:38:19 | JdGordon_ | pixelma: well, i was tihnking the seperator could be either | or , or whatever so it is up to the themer and wont break current themes |
| 08:38:27 | JdGordon_ | but yes using [] would be nice also |
| 08:38:32 | Llorean | S_a_i_n_t: If the progress bar ran from mute+1 to 0db, with the filled step being 0db, it wouldn't then be a problem on any size screen |
| 08:38:38 | jhMikeS | Llorean: Now you want it explicit ahead of time, not just when the user goes over? |
| 08:38:44 | * | JdGordon_ wouldnt be against breaking things there, or at least adding the option for them |
| 08:38:49 | Llorean | It would work exactly substituting the multiple images we have currently in the conditional between mute and 0db |
| 08:39:11 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 08:39:18 | Llorean | jhMikeS: No, no. I said earlier I'd prefer explicit ahead of time, but the bare minimum is being able to identify it explicitly either way, which is what yours does. As in, that's more or less acceptable to me. |
| 08:39:28 | * | jhMikeS thinks he misread "explicit" and "isn't explicit" :\ |
| 08:39:37 | jhMikeS | s/and/as |
| 08:40:03 | Llorean | Yours has the advantage of having the same scale left and right of the percentage, with an explicit 0db-1db changeover *even* if the progress bar is too small to see visible movement at that point. |
| 08:40:11 | Llorean | Er, left and right of the line mark |
| 08:41:01 | CIA-5 | New commit by Buschel (r25601): Add a subsection for Replaygain to the runtime optimisation section. |
| 08:41:04 | jhMikeS | Llorean: ok, ok. gotcha. of course, I didn't explore all the artistic possibilities, just the basic idea. themers might do unexpected things. |
| 08:41:11 | Llorean | Yeah, obviously |
| 08:41:15 | Llorean | They always do. |
| 08:41:27 | Llorean | But the ability to see the changeover independent of scale is an awful nice benefit to doing it that way, I think |
| 08:42:06 | | Quit pixelma (Disconnected by services) |
| 08:42:07 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 08:42:10 | | Quit amiconn (Disconnected by services) |
| 08:42:12 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 08:42:27 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 08:42:34 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 08:44:01 | saratoga | Buschel: replaygain is one multiply per sample, can that really have a measurable impact on battery life? |
| 08:46:42 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:50:46 | S_a_i_n_t | Why don't we just couple 1 bmp with %?mv<||||%pv||>? that just draws on top of the bitmap so we know when it's linelevel. |
| 08:51:03 | S_a_i_n_t | seems like a WHOLE lot of hassle out the window from my point of view. |
| 08:51:39 | S_a_i_n_t | *I think there is one too many |'s before the %pv. |
| 08:51:47 | S_a_i_n_t | but you know what my idea is. |
| 08:52:34 | S_a_i_n_t | you could even just do%?mv<%pv|> |
| 08:52:48 | S_a_i_n_t | and know what every decibel change was. |
| 08:53:04 | Llorean | S_a_i_n_t: Pixelma brought that up quite a while ago |
| 08:53:15 | S_a_i_n_t | then the .bmp doesn;t have to do any odf the work we need it to do, and complicates it by. |
| 08:53:31 | S_a_i_n_t | well, I must have missed it in the barrage of ideas. |
| 08:53:37 | S_a_i_n_t | seems the winner to me. |
| 08:54:16 | Llorean | It still seems like there needs to be a way for the new feature to present the same information visually as the old one. |
| 08:54:27 | Llorean | jhMikeS' suggestion seems to do that quite well |
| 08:55:21 | S_a_i_n_t | actually (now that I recall) I believe she said to switch to numeric whilst changing volume, I'd rather it were drawn on top of the bitmap if it had to ba anywhere, and if you didn't want it, you could just leave the %?mv case blank. |
| 08:56:30 | S_a_i_n_t | then, you'd always have a graphic/numeric volume, and always know if exceeding line level. |
| 09:00 |
| 09:03:19 | | Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:05:00 | | Join clauwn [0] (~clauwn@deliberabundus.de) |
| 09:05:13 | clauwn | hey there, how do i tell my rockbox to enter multimediamode` |
| 09:05:13 | clauwn | ? |
| 09:05:34 | clauwn | i've got an ipod mini 2nd gen and it won't connect anymore |
| 09:05:36 | S_a_i_n_t | what do you mean by multimediamode? |
| 09:05:45 | clauwn | usb-storage-mode |
| 09:05:45 | S_a_i_n_t | you actually mean the HID? |
| 09:06:06 | clauwn | probably |
| 09:06:15 | *** | Saving seen data "./dancer.seen" |
| 09:06:15 | S_a_i_n_t | well, that's not "multimediamode" |
| 09:06:27 | saratoga | i think it is now |
| 09:06:28 | clauwn | it says starting multimediamode if i connect it |
| 09:06:29 | saratoga | or was |
| 09:06:33 | S_a_i_n_t | and it should always enumerate as a USB mass storage device |
| 09:06:38 | clauwn | but it does not |
| 09:06:48 | clauwn | do you think i should restart my pc? |
| 09:06:53 | S_a_i_n_t | what is the device? |
| 09:06:56 | clauwn | i just started to copy a lot of files |
| 09:06:58 | clauwn | and aborted |
| 09:07:03 | clauwn | and now it won't reconnect |
| 09:07:23 | clauwn | device is ipod mini 2nd gen |
| 09:08:59 | S_a_i_n_t | Rebooting *may* help...I guess. In future, multimedia/mouse/browser/presentation are just different ways the player can enumerate to the host as an HID device. |
| 09:09:12 | S_a_i_n_t | All of those modes support mass storage IIRC |
| 09:09:48 | S_a_i_n_t | Multimedia mode just lets you control your PC's volume |
| 09:10:10 | S_a_i_n_t | Skip tracks/fast forward/rewind etc. |
| 09:10:19 | S_a_i_n_t | Mouse Mode is pretty obvious. |
| 09:10:35 | clauwn | ok, i just rebooted my pc |
| 09:10:39 | clauwn | now it connects again.. |
| 09:11:18 | clauwn | and as i clicked it, it disappeared... |
| 09:11:43 | clauwn | error while unmounting is : device is not a valid block device |
| 09:12:00 | clauwn | oh no, while mounting |
| 09:12:08 | S_a_i_n_t | Hmmm. that's new to me. |
| 09:12:25 | clauwn | i'll probably reinstall rockbox later :D |
| 09:12:30 | S_a_i_n_t | You may need to wait to see if anyone else has any ideas about this. |
| 09:13:06 | clauwn | might be a problem with my pc, as the entry for apple music-player won't disappear if i disconnect it |
| 09:13:30 | clauwn | thank you |
| 09:13:33 | clauwn | i'll come back later |
| 09:13:56 | pixelma | JdGordon_: I understood the either | or , but find that confusing and inconsistent |
| 09:14:22 | clauwn | so i'm off |
| 09:14:26 | * | clauwn detaches |
| 09:14:46 | | Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) |
| 09:15:38 | pixelma | clauwn: you could try turning HID off |
| 09:19:53 | JdGordon_ | pixelma: yes inconsistant, but MUCH more readable |
| 09:22:46 | | Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) |
| 09:23:00 | pixelma | you could have had a chance to introduce [] or similar for this volume bar tag if you had given it a bit more time and thought in the beginning |
| 09:23:35 | pixelma | and as I said ; might work there too and already is a special character and not allowed in conditionals otherwise |
| 09:25:35 | JdGordon_ | ; wont make things easier to read |
| 09:25:53 | JdGordon_ | and really, bitching about speed isnt going to change anything |
| 09:25:58 | amiconn | JdGordon_, Llorean: Regarding the volume bar above 0dB, couldn't the bar just use two bitmaps, each representing the full range, one in e.g. green and the other in e.g. red, and then the token switches bitmaps at 0dB, but regardless of which one is used, draws the bar as normal? |
| 09:26:13 | S_a_i_n_t | Nothing short of embedded TTS wil make this line easier to read ;) |
| 09:26:23 | S_a_i_n_t | But, it could certainly be worse ;) |
| 09:26:30 | amiconn | The only disadvantage I see with this approach is that targets which can't go above 0dB (e.g. the irivers) have a useless bitmap |
| 09:27:07 | S_a_i_n_t | but, they stilll save many a bitmap |
| 09:27:13 | S_a_i_n_t | ~7 or so. |
| 09:27:30 | S_a_i_n_t | ~bah...not 7, ~5 |
| 09:28:03 | jhMikeS | amiconn: I was thinking the loader could skip accessing it by checking first if > 0dB is not available. |
| 09:28:14 | JdGordon_ | haha /me puts %?pv<mute|%pv|volume.bmp|-|-|-|-||0db|dander> through OSX's TTS... |
| 09:28:43 | S_a_i_n_t | I bet thout sounded fuc..er, messed up. |
| 09:29:09 | * | jhMikeS supposes that WPS memory is more valuable, byte per byte than a small bit of disk space |
| 09:30:14 | JdGordon_ | amiconn: in all honesty, I dont see what the point of the whole disucssion is. We are talking about a graphical representation using maybe 1/10th of the pixels which would be needed for an accurate display |
| 09:30:24 | JdGordon_ | IMO a single one with red ends are good enough |
| 09:31:03 | S_a_i_n_t | I think so too, but everyone cares about where linelevel is too much |
| 09:31:09 | amiconn | Imo it does matter whether you're +1dB or +12dB above... |
| 09:31:38 | S_a_i_n_t | amiconn: JdGordon_: At last! Sanity! |
| 09:31:39 | amiconn | If you want line level you just load a .cfg and don't change volume in the wps |
| 09:31:43 | jhMikeS | JdGordon_: unless the user wants a fully accurate bar. then at least all appetites are satisfied. if they don't want to use it, just use the same .bmp twice? It only loads a particular image once, correct? |
| 09:31:43 | S_a_i_n_t | *hugs* |
| 09:31:53 | JdGordon_ | the only correct way to do this is showing the actual number when it is changing |
| 09:32:21 | S_a_i_n_t | JdGordon_: pixelma both had a go at suggestion that. |
| 09:32:42 | S_a_i_n_t | %pv, then %pv|playbar.bmp| |
| 09:32:44 | S_a_i_n_t | done. |
| 09:32:46 | JdGordon_ | jhMikeS: no, it isnt that smart, it will load the same bmp more han once |
| 09:33:09 | JdGordon_ | but anyway, we are talking about the default WPS, all other ones will do whatever the themer wants |
| 09:33:19 | jhMikeS | JdGordon_: you can't load some bar bitmap, give it a label, and then use it for both normal and over, and only load it once? |
| 09:33:40 | S_a_i_n_t | preferably, I'd perfer the numerical time to be drawn on top of the bitmap volumebar. |
| 09:34:06 | S_a_i_n_t | But, as long as it's there... |
| 09:34:28 | JdGordon_ | jhMikeS: that could be done, but the way the bar was done was with the smallest possible code change |
| 09:34:30 | JdGordon_ | so no |
| 09:34:38 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:35:03 | | Quit skx` (Ping timeout: 248 seconds) |
| 09:35:27 | * | JdGordon_ thinks maybe asking for cabbie to be updated wasnt such a good idea |
| 09:36:31 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 09:36:50 | S_a_i_n_t | In hindsight S_a_i_n_t agrees |
| 09:37:10 | wodz | Someone posted somewhere configuration line for vim to conform with rockbox coding style. Do You recall this line? |
| 09:37:18 | S_a_i_n_t | perhaps just leave the SVN volumebar as an option open to themers ;) |
| 09:37:23 | jhMikeS | LOL. Well, can't say it wasn't intense. :) |
| 09:37:41 | S_a_i_n_t | jhMikeS: that's one word for it. |
| 09:37:53 | S_a_i_n_t | I have a massive headache now :( |
| 09:39:12 | * | JdGordon_ wonders how hard it would be to get a script going to fix all the online themes if syntax is changed |
| 09:40:52 | | Join skx` [0] (~skx@d51A4AF07.access.telenet.be) |
| 09:45:22 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 09:47:01 | | Quit stripwax (Client Quit) |
| 09:47:36 | jhMikeS | JdGordon_: the old way with an image list won't be supported? |
| 09:47:56 | JdGordon_ | it is |
| 09:48:00 | JdGordon_ | nothing was removed |
| 09:48:31 | JdGordon_ | if you want a fluid volume bar it isnt so easy to find mute/0/>0 |
| 09:48:37 | JdGordon_ | that is the whole discussion |
| 09:50:16 | jhMikeS | it certainly was but I wondered if it wasn't supposed to replace other ways and be the "only way". :) |
| 09:50:45 | JdGordon_ | no, no :) |
| 09:54:42 | | Quit shai (Quit: Leaving) |
| 09:58:51 | pixelma | JdGordon_: bitching about speed? You mean the fact that you rushed this in? I just said that there was a chance to do things differently |
| 09:59:24 | wodz | amiconn: ping |
| 09:59:48 | pixelma | and I don't see where the difference between ; and , would be in regards to readability of that like |
| 09:59:51 | pixelma | line |
| 10:00 |
| 10:04:11 | | Quit ender` (Ping timeout: 276 seconds) |
| 10:09:03 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 10:10:50 | | Part lpereira |
| 10:11:58 | | Quit avn (Ping timeout: 276 seconds) |
| 10:12:03 | JdGordon_ | is %xd and %Vd the only tags which can have another letter on them that doesnt use |'? |
| 10:12:09 | JdGordon_ | I's? |
| 10:12:12 | JdGordon_ | |'s |
| 10:12:14 | JdGordon_ | ffs |
| 10:12:38 | JdGordon_ | %d %D also |
| 10:13:21 | | Join avn [0] (~avn@88.119.164.243) |
| 10:13:23 | S_a_i_n_t | what is &D? |
| 10:13:31 | S_a_i_n_t | I don;t remember that one... |
| 10:13:33 | JdGordon_ | next tracks dir |
| 10:13:43 | S_a_i_n_t | Aaaaaah. |
| 10:14:20 | JdGordon_ | and the timeouts |
| 10:15:49 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:16:23 | JdGordon_ | I really want to redo the parser, and dissallowing those sort of tags would make it much simpler |
| 10:19:47 | | Join ender [0] (krneki@foo.eternallybored.org) |
| 10:20:44 | | Quit ender` (Ping timeout: 264 seconds) |
| 10:21:33 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:29:59 | | Quit avn (Ping timeout: 248 seconds) |
| 10:31:56 | | Join avn [0] (~avn@88.119.164.243) |
| 10:32:58 | | Quit shai (Ping timeout: 245 seconds) |
| 10:34:55 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 10:36:55 | | Quit linuxstb (Client Quit) |
| 10:40:35 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 10:46:28 | | Join Schmogel [0] (~Miranda@p3EE21DA6.dip0.t-ipconnect.de) |
| 10:51:05 | kugel | wouldn't %?pv<%pv|green-volume.bmp|-|-|-|-||%pv|orrange-volume.bmp|-|-|-|-||%pv|red-volume.bmp|-|-|-|-|> work? |
| 10:51:16 | kugel | w.r.t to tonights discussion |
| 10:51:55 | Llorean | kugel: You missed the mute part of the conditional, but yeah, it seems like it ought to. |
| 10:52:03 | Llorean | Green being <0, orange being =0, red being >0 |
| 10:52:16 | kugel | yes, that's what I thought |
| 10:52:38 | Llorean | And that accomplishes the effect with existing code (+ the %pv inside %?pv fix) |
| 10:54:04 | kugel | it would be even better, the +6db part would be rendered smoothly |
| 10:55:30 | Llorean | And still uses less bitmaps / bitmap data than the current cabbiev2 code |
| 10:55:30 | kugel | I think someone should try if it works :) |
| 10:55:30 | | Part LinusN |
| 10:55:36 | Llorean | Well, I think it can't yet because I think you can't yet put a %pv inside of a %?pv |
| 10:56:53 | kugel | the other part of the commit was to allow multiple progress/volume bars per viewport, right? |
| 10:57:17 | kugel | so if it doesn't work it's probably only a parser problem, not an actual real problem |
| 11:00 |
| 11:00:33 | wodz | adding keypad definition to plugins drive me crazy :-/ |
| 11:02:41 | Llorean | kugel: Yeah, IIUC it's exactly a parser problem |
| 11:03:12 | | Quit kugel (Ping timeout: 276 seconds) |
| 11:03:20 | | Join bluebrother [0] (~dom@g224239114.adsl.alicedsl.de) |
| 11:03:20 | | Quit bluebrother (Changing host) |
| 11:03:20 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 11:06:19 | *** | Saving seen data "./dancer.seen" |
| 11:06:56 | | Quit bluebroth3r (Ping timeout: 260 seconds) |
| 11:07:54 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 11:08:24 | | Quit tipi^ (Ping timeout: 276 seconds) |
| 11:08:27 | | Join tipi^ [0] (pihlstro@lehtori.cc.tut.fi) |
| 11:10:32 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 11:11:53 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 11:12:42 | JdGordon_ | Llorean: kugel yes, its a one line fix, but my laptop doesnt have internet atm so cant commit it |
| 11:14:37 | | Join Kitr88 [0] (Kitr88@BSN-182-27-232.dial-up.dsl.siol.net) |
| 11:17:49 | | Quit Kitar|st (Ping timeout: 258 seconds) |
| 11:21:07 | | Join pyro_maniac [0] (foobar@p57BBA0F2.dip0.t-ipconnect.de) |
| 11:21:36 | pyro_maniac | commiters around? i got a online fix for lang.make |
| 11:23:33 | kugel | I'm around yes |
| 11:24:47 | pyro_maniac | on my up-to-date debian tail decline "tail -1" as deprecated and has to be replaced by "tail -n 1" |
| 11:28:34 | kugel | why's that deprecated :( |
| 11:29:42 | wodz | it is for quite long time |
| 11:29:57 | Bagder | my up-to-date debian tail supports it fine |
| 11:30:08 | Bagder | and yes, its has been said to be that for ages |
| 11:31:53 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 11:33:12 | pyro_maniac | i can only report what my system said: http://pastie.org/915360 |
| 11:34:31 | | Quit kugel (Ping timeout: 276 seconds) |
| 11:36:20 | | Join webguest17 [0] (~8984fa0d@giant.haxx.se) |
| 11:39:47 | pyro_maniac | this is more complete: http://pastie.org/915366 |
| 11:40:07 | | Join Lixun [0] (~8984fa0d@gateway/web/freenode/x-hwhpjiqfmwahujsv) |
| 11:40:07 | | Quit webguest17 (Client Quit) |
| 11:42:50 | Zagor | Bagder: are you on testing or unstable? |
| 11:43:01 | Bagder | both ;-) |
| 11:43:16 | Bagder | I checked two testing and one unstable |
| 11:43:24 | Zagor | tail −−version |
| 11:43:42 | Bagder | tail (GNU coreutils) 8.4 |
| 11:43:55 | Zagor | ok. pyro_maniac what does your version say? |
| 11:44:08 | Bagder | my testing says 7.4 |
| 11:44:20 | Zagor | yes. "trying to update coreutils from 7.4-2 to 8.4-2 (candidate is 36 days old)" |
| 11:45:54 | pyro_maniac | hmm, i am confused. mine said "tail (GNU coreutils) 5.3.0" |
| 11:46:18 | Zagor | ! |
| 11:46:49 | | Quit phanboyiv (Read error: Connection reset by peer) |
| 11:47:37 | pyro_maniac | but i am using debian testing too |
| 11:47:49 | Zagor | pyro_maniac: dpkg -l coreutils |
| 11:49:50 | pyro_maniac | thanx for help and sorry for this not really rockbox related thing |
| 11:51:09 | Bagder | we could still switch to -n 1 |
| 11:54:11 | | Quit avn (Ping timeout: 276 seconds) |
| 11:55:36 | | Join avn [0] (~avn@88.119.164.243) |
| 11:55:52 | | Quit Lixun (Quit: Page closed) |
| 11:56:27 | Torne | Bagder: we should, really.. |
| 11:57:03 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 12:00 |
| 12:16:40 | | Quit avn (Ping timeout: 252 seconds) |
| 12:18:16 | | Join avn [0] (~avn@88.119.164.243) |
| 12:20:17 | | Join m3dlg [0] (~m3dlg@212.183.140.51) |
| 12:25:51 | CIA-5 | New commit by funman (r25602): fix yellow |
| 12:26:15 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 12:27:19 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 12:27:57 | funman | I want to disable adjustable_cpu_freq on as3525v2, thoughts ? |
| 12:31:12 | funman | Torne: can you point me again to that file in symbian source which lists the capabilities for various ARM cpus ? |
| 12:31:24 | Torne | funman: yeah, one sec |
| 12:31:28 | Torne | we don't use the test-and-clean operation |
| 12:31:35 | Torne | i didn't know it existed until i looked it up yesterday |
| 12:31:42 | kugel | I see no reason to disable it, but I think disabling it makes us lazy about fixing it properly |
| 12:31:56 | funman | kugel: it's too buggy |
| 12:32:01 | funman | Torne: FS #11106 |
| 12:32:38 | funman | kugel: having it enabled doesn't make us fix it faster |
| 12:32:45 | Torne | funman: yeah, i had a look and it seems reasonable, but i don't know anyting about it really |
| 12:32:49 | Torne | funman: i assume it's faster? |
| 12:33:01 | funman | Torne: I don't know if it's faster, I just know it's correct |
| 12:33:20 | Torne | er, how is the current code not correct? |
| 12:33:22 | funman | arm926ej-s use a different index format for cleaning/invalidating |
| 12:34:06 | Torne | https://developer.symbian.org/sfl/MCL/sf/os/kernelhwsrv/file/fc6b53aebafa/kernel/eka/include/nkern/nk_cpu.h |
| 12:34:26 | funman | hmm it's restricted :/ |
| 12:34:32 | Torne | oh, er, sorry |
| 12:34:33 | Torne | wrong path |
| 12:34:36 | Torne | one mo |
| 12:35:04 | Torne | there are two copies of the code, one is not world readable |
| 12:35:08 | Torne | but i have access :) |
| 12:35:37 | Torne | https://developer.symbian.org/oss/FCL/sf/os/kernelhwsrv/file/d87ddb12c54a/kernel/eka/include/nkern/nk_cpu.h |
| 12:35:40 | Torne | try that? |
| 12:35:50 | funman | works, thanks! |
| 12:36:08 | Torne | the actual cache maintenance code may be interesting also |
| 12:36:23 | Torne | but again, symbian is EPL so you can't actually lift the code |
| 12:36:49 | Torne | https://developer.symbian.org/oss/FCL/sf/os/kernelhwsrv/file/d87ddb12c54a/kernel/eka/kernel/arm/cache_maintenance.cia <- that's most of the asm for cache maintenance |
| 12:37:15 | Torne | we clean by way-set index. and i assure you it works.. :) |
| 12:37:46 | funman | for arm922tdmi the index format is 31:26 = index, 6:5 = segment; for arm926ej-s it is 31:32-A = way, S+4:5 = Set (=index), 4:2 = Word |
| 12:37:57 | Torne | yes |
| 12:38:18 | funman | hm so it might just mean that set/way are variable |
| 12:38:37 | Torne | they are known, though |
| 12:38:51 | funman | but the index has another position, so the 2 formats aren't compatible afaiu |
| 12:39:05 | | Quit ender (Ping timeout: 258 seconds) |
| 12:39:10 | Torne | well, we hav ejust one implementation that works on all ARMs, afaik :) |
| 12:39:34 | Torne | though it's kinda hard to follow |
| 12:39:56 | Torne | the cache code is slightly nightmarish because it's allowing for external cache, and SMP, and so on |
| 12:40:17 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 12:40:22 | funman | I see simple asm one-liners after line 200 |
| 12:40:53 | Torne | only for ARM7 and StrongArm |
| 12:41:23 | funman | line 242: elif defined(__CPU_ARM920T__) || defined(__CPU_ARM925T__) || defined(__CPU_ARM926J__) |
| 12:41:33 | funman | no clean/invalidate by index though |
| 12:42:04 | Torne | er, it also uses weird terms for the operations |
| 12:42:13 | funman | these use MVA |
| 12:42:15 | Torne | flush is clean and invalidate |
| 12:42:23 | Torne | purge is invalidate only |
| 12:42:28 | Torne | so FLUSH_DCACHE_INDEX |
| 12:42:30 | Torne | is the one |
| 12:42:34 | Torne | (i think) |
| 12:42:40 | funman | oh right |
| 12:42:55 | funman | missed it because it hadn't the same alignement =) |
| 12:43:17 | Torne | but yeah, the code that uses these macros is in the other file i linked |
| 12:43:26 | Torne | it's parameterised by the cache line/index/etc sizes |
| 12:43:30 | Torne | which it gets from.. somewhere. |
| 12:43:37 | Torne | possibly from cp15? |
| 12:43:43 | Torne | or mabe just provided by platform headers. |
| 12:44:39 | funman | code/data at a fixed position always gets loaded in a determined cache line, right? |
| 12:44:54 | Torne | no |
| 12:45:25 | | Quit JohannesSM64 (Ping timeout: 268 seconds) |
| 12:45:39 | funman | if you can't know the cache line where some piece of code get loaded you'd use this index only in a loop to flush the whole cache then? |
| 12:45:43 | Torne | Yes |
| 12:45:51 | Torne | For remappings/etc you do it by MVA |
| 12:46:21 | Torne | A given address in memory is mapped to a particular set index, but the data can be in any way of that set index |
| 12:46:37 | funman | can you grep for (CLEAN|FLUSH)_DCACHE_INDEX and look for 2 different formats (ARM920T/ARM926J) ? |
| 12:46:51 | Torne | there aren't two. i linked the code that does it. |
| 12:46:59 | funman | hm ok |
| 12:47:35 | Torne | it is parameterised by a set mask, line length, cache size in lines, and "way increment value" |
| 12:47:46 | Torne | see InternalCache::Clean_DCache_All() in cache_maintenance.cia |
| 12:47:54 | funman | hm is that code to be used by external users? |
| 12:48:02 | Torne | define external |
| 12:48:07 | funman | 3rd party drivers |
| 12:48:07 | Torne | this is not exported from the kernel |
| 12:48:09 | Torne | No. |
| 12:48:15 | Torne | Drivers get a vastly simplified interface |
| 12:48:28 | Torne | which abstracts away all details of how many layers of cache exist, etc |
| 12:48:33 | | Join mitk [0] (~mitk@195.117.162.130) |
| 12:48:40 | Torne | InternalCache only does ARM L1 CP15-driven caches |
| 12:48:46 | Torne | but most symbian targets have L2 cache now |
| 12:49:08 | | Quit m3dlg (Ping timeout: 260 seconds) |
| 12:49:18 | Torne | https://developer.symbian.org/oss/FCL/sf/os/kernelhwsrv/file/d87ddb12c54a/kernel/eka/kernel/arm/cache.cpp has the exported interfaces for drivers |
| 12:49:25 | Torne | they look like "SyncMemoryBeforeDmaRead" and the like :) |
| 12:49:26 | funman | i download the tip.bz2 to check |
| 12:49:52 | Torne | the assumption is generally that drivers only do cache operations for DMA coherency, or possibly as IMB |
| 12:50:03 | Torne | they don't get given low level operations like clean/invalidate/etc |
| 12:50:17 | Torne | they are supposed to communicate intent only and the kernel does the right hting :) |
| 12:51:29 | funman | the code in cache_maintenance.cia depends on iCleanAndInvalidateMask and iLineLength |
| 12:53:14 | funman | in SCacheInfo (there must be static definitions of this somewhere) |
| 12:53:36 | Torne | yeah, grep for it |
| 12:53:41 | Torne | i don't remember where it gets set up |
| 12:53:46 | funman | ./kernel/eka/kernel/arm/cache_external.cpp |
| 12:54:06 | Torne | er, no |
| 12:54:12 | Torne | that's all L2 stuff |
| 12:54:46 | Torne | it's quite possibly set byt he baseport, which will be a problem since there isn't a decent published baseport there :( |
| 12:54:59 | Torne | all the baseports i use are IP-encumbered still |
| 12:56:14 | funman | cache_maintenance.cpp::InternalCache::Init1() ? |
| 12:57:04 | Torne | yeah, there you go ;) |
| 12:57:32 | Torne | so yeah, it's extracting it from cp15 cache info registers |
| 12:57:40 | Torne | via a slightly hilarious process :) |
| 12:58:45 | funman | hm so the format could be compatible after all |
| 12:58:56 | | Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) |
| 12:59:18 | funman | "For all the cache operations, the Word should be zero" |
| 12:59:43 | mitk | funman: There is no rockbox-info.txt after compiling clip+ with test plugins. Is it intentional? |
| 12:59:54 | funman | mitk: i don't think so |
| 13:00 |
| 13:00:29 | funman | what make $PWD/rockbox-info.txt gives you ? |
| 13:01:57 | mitk | Funman: gives me rockbox-info.txt \o/ |
| 13:04:25 | | Quit ender` (Ping timeout: 246 seconds) |
| 13:04:29 | funman | test plugins do not build here |
| 13:06:22 | *** | Saving seen data "./dancer.seen" |
| 13:07:10 | kugel | some need #ifdefing for certain targets, I didn't double check all |
| 13:08:28 | mitk | funman: you mead it doesn't make sense to build it yet or there are errors during compilation? I can build it and I have 2 test plugins after compilation: test_boost and test_codec. |
| 13:08:35 | mitk | mean* |
| 13:09:09 | CIA-5 | New commit by funman (r25603): some test plugins have dependencies |
| 13:09:35 | kugel | test_resize is lcd_color? |
| 13:09:37 | funman | mitk: what kugel said |
| 13:09:39 | funman | yes |
| 13:09:56 | funman | smooth_* are lcd color (in plugins/lib/SOURCES) |
| 13:09:59 | kugel | greyscale has albumart with scaling too, afaik |
| 13:10:06 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 13:10:17 | kugel | ah, I thought it tests the other scalers as well |
| 13:11:03 | funman | mitk: rockbox-info.txt was probably not built because of errors, it builds fine there (with last commit) |
| 13:16:55 | Torne | funman: the test-and-clean operaation might still be better if the cpu supports it |
| 13:17:01 | Torne | funman: if nothing else the code is way simpler |
| 13:17:09 | funman | true |
| 13:17:12 | Torne | funman: i don't know why symbian doesn't use it. |
| 13:17:22 | Torne | there may be a reason, or we may just not have noticed :) |
| 13:17:25 | funman | but i was under the assumption that this would fix some problems with the Clipv2/Clip+ |
| 13:17:39 | Torne | Well, possibly, if the current loop is not successfully cleaning all the sets |
| 13:17:59 | Torne | which it may not be, it has too many hardcoded constants to work on *all* ARMs. I don't know about the specific core in the clipv2 |
| 13:18:06 | funman | the index format in arm922t reference manual is a bit misleading |
| 13:18:13 | funman | Torne: well it's an arm926ej-s |
| 13:18:14 | Torne | The processor reference manuals suck |
| 13:18:22 | Torne | they are context-free :( |
| 13:18:39 | funman | :( |
| 13:18:54 | Torne | i am spoilt by being able to email support@arm.com and get answers, generally ;) |
| 13:19:02 | | Join archivator [0] (~archivato@77.70.28.57) |
| 13:19:33 | | Join slck [0] (Venci@Slackware.SlackPix.Com) |
| 13:20:34 | | Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 13:21:21 | funman | rockbox mmu-arm.S says: 31:26 = index, 7:5 = segment; arm922tdmi ref manual says: 31:26 = index, 6:5=segment; arm926 ref manual says: something else (no mention of segments anymore) |
| 13:21:31 | mitk | funman: I had no errors compiling with test_plugins till few commits back. But now it doesn't matter I think. Thanks. |
| 13:22:27 | | Quit archivator (Client Quit) |
| 13:24:11 | funman | 31:26 + 7:5 => 9 bits for the index, that would mean a 16kB cache with 32bits line size, or a 8kB cache with 16 bits line size |
| 13:26:57 | | Join halmi [0] (~Miranda@188.20.253.186) |
| 13:27:11 | funman | works for the gigabeatf |
| 13:27:56 | kugel | i think the caches have 32*bytes* like size, don't they? |
| 13:28:15 | funman | the PP have 16 bytes |
| 13:28:15 | | Join luistmw [0] (~luistmw@c-174-54-10-237.hsd1.pa.comcast.net) |
| 13:28:28 | kugel | that's non-standard arm cache though |
| 13:28:50 | funman | gigabeatf (arm920t) has 16kB caches, as3525 (arm922tdmi) has 8kB caches |
| 13:28:57 | kugel | f/x has 8k+8k cache IIRC |
| 13:29:03 | luistmw | hey can som1 help me |
| 13:29:12 | | Quit ender` (Ping timeout: 245 seconds) |
| 13:29:23 | luistmw | i think i bricked my nano 2g |
| 13:29:41 | luistmw | i erased the .rockbox file |
| 13:29:55 | luistmw | what can i do |
| 13:30:14 | funman | kugel: where did you see that? |
| 13:30:25 | luistmw | in its main folder |
| 13:30:33 | | Part luistmw |
| 13:30:34 | kugel | funman: 920t reference manual |
| 13:30:50 | | Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 13:30:50 | | Quit DataGhost (Changing host) |
| 13:30:50 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 13:30:52 | jhMikeS | funman: I think there's differences there. See DDI0151C_920T_TRM.pdf p.45 for index format |
| 13:30:58 | funman | kugel: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0151c/I31031.html says 16kB |
| 13:31:14 | jhMikeS | 7:5 = seg |
| 13:31:19 | kugel | yes, split into 8K data and 8K ins cache |
| 13:31:29 | funman | jhMikeS: true, 1 more bit is needed |
| 13:31:40 | funman | kugel: no 16kB dcache and 16kB icache |
| 13:31:46 | kugel | hm, looks like I'm wrong |
| 13:32:01 | funman | jhMikeS: as3525 has only 8kB cache, twice less than gigabeatf/x |
| 13:32:33 | Torne | funman: arm9 is almost guaranteed to be 32 byte lines |
| 13:33:00 | funman | still i don't see how arm926 and arm920/922 index formats are compatible |
| 13:34:04 | kugel | 8K+8K on 922t then |
| 13:35:00 | funman | DDI0198 page 52 (chapter 2-22) gives an example for 16kB 4-way set associative cache: 31:30 = way, 11:5 = index |
| 13:35:38 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 13:35:57 | funman | hm but for 64-way it's the same format |
| 13:37:12 | jhMikeS | funman: I suppose those routines just need half as many in the unrolled loop |
| 13:37:20 | funman | arm920/arm922 use 64-way caches, but arm926 use 4-way |
| 13:37:28 | funman | jhMikeS: yes, not critical though |
| 13:38:02 | | Quit Zarggg (Ping timeout: 260 seconds) |
| 13:38:03 | jhMikeS | funman: might it cause problems where it's not valid? |
| 13:38:24 | funman | don't think so, the as3525(v1) work fine |
| 13:38:50 | | Quit halmi (Quit: halmi) |
| 13:39:05 | funman | we should correct it anyway, perhaps set the cache size in cpu.h |
| 13:39:35 | funman | Torne: are you aware of weird problems occuring with arm926ej-s phones using symbian ? |
| 13:39:48 | Torne | no :) |
| 13:39:57 | Torne | I am certain that our cache code works |
| 13:40:07 | Torne | at least on <=Cortex-A8 |
| 13:40:17 | Torne | it may no longer work on ARM7, also |
| 13:40:20 | Torne | as that may have rotted ;) |
| 13:40:53 | funman | as i understand it, your code (and ours) would not flush some sets |
| 13:42:11 | funman | hum wait |
| 13:42:12 | jhMikeS | the final sub instruction before the adds can be taken out of the loop there as well, then a constant defined |
| 13:42:13 | Torne | the result of that would be catastrophic, though, no? |
| 13:42:23 | Torne | i am certain we would have noticed :) |
| 13:42:34 | funman | Torne: you're right, you read the settings from cp15 so it's ok |
| 13:42:53 | funman | jhMikeS: we could use a cache_init() function to read the cache properties |
| 13:42:55 | | Join luistmw [0] (~luistmw@c-174-54-10-237.hsd1.pa.comcast.net) |
| 13:42:55 | | Part luistmw |
| 13:43:01 | | Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 13:44:15 | funman | from c0, c0, 1 |
| 13:44:16 | jhMikeS | funman: we could, but then again, they're constant for any player and the routines can be optimized |
| 13:45:05 | jhMikeS | unless...I'm not aware of some sort of difficulty with telling at compile-time ?? |
| 13:46:00 | funman | the difficulty is figuring out the values for each player |
| 13:46:12 | funman | cowond2, mini2440, mrobe500, and creative zen vision |
| 13:47:17 | Torne | er, surely that's not a difficulty |
| 13:47:26 | jhMikeS | you just said how :) splash it up somewhere, then you've got it. |
| 13:47:26 | Torne | dump the cache id registers in the debug screens |
| 13:47:39 | Torne | then shove it in a target header |
| 13:47:56 | funman | well it's probably easier to have 2 settings for as3525 and gigabeat, and use the other method on arm926ej-s |
| 13:48:05 | | Join krabador [0] (~darkham@95.239.183.98) |
| 13:49:30 | funman | jhMikeS: FS #11106 : any thought on adding the config option in configure ? |
| 13:50:00 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 13:51:14 | funman | clipv2: cp15, 0, %0, c0, c0, 1 == 0x1d152152 |
| 13:56:16 | funman | > 16kB cache |
| 13:57:41 | CIA-5 | New commit by funman (r25604): test_codec is SWCODEC only |
| 14:00 |
| 14:00:10 | funman | same on clip+/fuzev2 |
| 14:00:17 | | Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) |
| 14:01:34 | funman | oops I was wrong, mini2440 uses the same CPU than gigabeat F/X |
| 14:02:06 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 14:02:07 | CIA-5 | New commit by uchida (r25605): viewer plugin: when the alignment is RIGHT, supports WIDE screen. |
| 14:02:12 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 14:05:47 | jhMikeS | funman: certainly interesting, using mrc with pc. why's it that way? |
| 14:06:29 | funman | that's how it's documented in arm926 ref manual (pc itself isn't modified) |
| 14:06:41 | Torne | jhMikeS: "magic" |
| 14:07:03 | Torne | jhMikeS: it's because ARM used to have the flags in PC, back when the program counter was 26-bit |
| 14:07:09 | jhMikeS | I look at a later patch and it looks completely different. |
| 14:07:30 | jhMikeS | Torne: way before my time with ARM, I can say that much |
| 14:07:47 | Torne | jhMikeS: yeah, this was ARMv3 and prior |
| 14:08:20 | Torne | the use of pc to refer to the flags in weird special case operations was left over in various odd places, and this one has survived :) |
| 14:09:14 | funman | jhMikeS: http://pastie.org/915498 |
| 14:09:42 | funman | survived, or added for some nostalgia ? :) |
| 14:10:56 | funman | oops i made too much copypasta for invalidate_dcache() |
| 14:12:00 | jhMikeS | funman: for me, it's like saying heiroglyphs are nostaligic (perhaps in pastlife regression) :) |
| 14:12:11 | funman | :)) |
| 14:12:37 | funman | http://pastie.org/915498 |
| 14:12:42 | funman | (edited) |
| 14:12:42 | | Quit avn (Ping timeout: 252 seconds) |
| 14:13:35 | jhMikeS | everythings running slow and swapping here, so my responses might be delays (too much junk open) |
| 14:13:43 | jhMikeS | *delayed |
| 14:14:25 | | Join avn [0] (~avn@88.119.164.243) |
| 14:14:59 | | Join DataGhost_ [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 14:14:59 | | Quit DataGhost (Disconnected by services) |
| 14:15:00 | | Nick DataGhost_ is now known as DataGhost (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 14:15:37 | CIA-5 | New commit by uchida (r25606): fix yellow |
| 14:17:10 | jhMikeS | funman: I think it looks good. I'd need to apply it to know for sure and will take your work for the unfamiliar stuff. |
| 14:18:59 | | Join DataGhost_ [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 14:18:59 | | Quit DataGhost (Disconnected by services) |
| 14:19:00 | | Nick DataGhost_ is now known as DataGhost (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 14:20:50 | funman | jhMikeS: last patch on FS #11106, I just added a comment compared to the last paste |
| 14:23:37 | funman | not sure why we didn't spot any problem with cowond2/mrobe500 and creative zen |
| 14:24:03 | | Join Watermark [0] (~chatzilla@adsl-220-183-243.mob.bellsouth.net) |
| 14:24:05 | funman | also as3525v2 worked "pretty fine" |
| 14:24:38 | | Quit Watermark (Client Quit) |
| 14:25:57 | | Nick markun_ is now known as markun (~markun@rockbox/developer/markun) |
| 14:29:29 | jhMikeS | funman: FWIW, a small optimization to the bulk routines which I think would conflict w/patch: http://pastie.org/915528 |
| 14:30:28 | | Quit mitk (Quit: Leaving) |
| 14:30:36 | funman | i thought about it, i'm ok with this |
| 14:31:48 | funman | is it better to use mov+sub to calculate r1, rather than a ldr ? |
| 14:34:06 | funman | btw, =(0x4000000 - 7*(0x20)) is easier to understand IMO |
| 14:35:28 | | Join nimak [0] (~nima@adsl-75-45-226-173.dsl.sfldmi.sbcglobal.net) |
| 14:36:20 | | Join halmi [0] (~halmi@ip149-148-254-211.eduroam.meduniwien.ac.at) |
| 14:36:50 | | Quit halmi (Client Quit) |
| 14:37:18 | | Quit krabador (Read error: Connection reset by peer) |
| 14:37:35 | jhMikeS | funman: I was thinking that too, about calc'ing the value with the preprocessor. |
| 14:38:06 | | Quit nima (Ping timeout: 264 seconds) |
| 14:38:33 | funman | you can use multiplications/additions/substractions/shifts (probably divisions and modulo) with the assembler |
| 14:38:37 | jhMikeS | or whatever works, less #ifdef stuff. ldr on 920T can work wile r0 is zeroed out |
| 14:39:30 | jhMikeS | less #ifdef and one less insn in the loop = cleaner + faster (slightly), no? |
| 14:40:11 | funman | hm how do you remove an #ifdef? |
| 14:41:08 | funman | ldr r1, =(0x4000000 - SOMETHING_DEFINED_IN_CPU_HEADER*0x20) ? |
| 14:43:16 | jhMikeS | yeah, something like that, for the number of segs |
| 14:44:00 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 14:44:12 | | Join froggymana [0] (~187b533e@giant.haxx.se) |
| 14:44:24 | funman | saratoga: ping |
| 14:46:41 | | Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) |
| 14:46:41 | | Quit jhMikeS (Disconnected by services) |
| 14:46:45 | | Join M3DLG [0] (~M3DLG@212.183.140.53) |
| 14:46:48 | _jhMikeS_ | ldr r1, =(0x04000000 - (SOMETHING_DEFINED_THAT_CAN_ALSO_SELECT_THE_ADDITIONAL_INSTRUCTIONS - 1) * 0x20) |
| 14:47:04 | | Quit kugel (Ping timeout: 276 seconds) |
| 14:47:10 | | Nick _jhMikeS_ is now known as jhMikeS (~jethead71@rockbox/developer/jhMikeS) |
| 14:47:14 | funman | sounds good |
| 14:51:21 | | Part LinusN |
| 14:51:59 | | Quit n17ikh (Ping timeout: 276 seconds) |
| 14:52:10 | | Join MasterFen [0] (~MasterFen@host86-185-76-205.range86-185.btcentralplus.com) |
| 14:52:34 | MasterFen | Hello there everyone! |
| 14:53:47 | MasterFen | I just installed Rockbox on my Clip+ and I'm willing to beta test if needed. |
| 14:54:06 | | Part MasterFen |
| 14:55:27 | | Join MasterFen [0] (~MasterFen@host86-185-76-205.range86-185.btcentralplus.com) |
| 14:55:41 | | Part MasterFen |
| 14:57:15 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 14:59:45 | | Quit avn (Ping timeout: 258 seconds) |
| 15:00 |
| 15:01:29 | | Join avn [0] (~avn@88.119.164.243) |
| 15:01:33 | jhMikeS | funman: I suppose now I'm going off the deep end. Maybe mov r1, #0x04000000 ; sub r1, r1, #((SOMETHING-1) * 0x20) would be faster, since it's prefetched already. lol. who knows, I've been awake all night. |
| 15:02:07 | | Quit antil33t (Read error: Connection reset by peer) |
| 15:02:13 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 15:02:49 | funman | I think it's not critical anyway, don't lose too much neurons on that :) |
| 15:04:26 | funman | saratoga: Did you edit http://forums.rockbox.org/index.php?topic=14064.msg164225#msg164225 because you thought testing wasn't needed anymore ? backlight now works but there still could exist Fuzev2 with the other LCD type, so only the backlight would work. (If it was the reason please remove your edit) |
| 15:05:15 | jhMikeS | funman: It's a zen thing, I'm allowing loss of the ego in order to be aware of infinite possibilities and the emptiness of the code, that is all. :) |
| 15:05:53 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 15:06:03 | | Quit M3DLG (Ping timeout: 252 seconds) |
| 15:06:25 | *** | Saving seen data "./dancer.seen" |
| 15:06:35 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 15:09:09 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 15:10:55 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 15:10:55 | wodz | is it possible that not having any theme at all may introduce some performance penelty? |
| 15:11:27 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 15:12:35 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 15:13:26 | | Join archivator [0] (~archivato@77.70.28.57) |
| 15:16:29 | | Quit wodz (Quit: Leaving) |
| 15:19:25 | | Quit avn (Ping timeout: 246 seconds) |
| 15:21:06 | | Join avn [0] (~avn@88.119.164.243) |
| 15:24:36 | | Part pyro_maniac ("Leaving.") |
| 15:25:09 | pamaury | gevaerts: just for information, your last commit to usb-storage put a break before a portion of code which is between #if 0 #endif. If someone changes it to #if 1 then the code is between a break and a case and is never executed |
| 15:25:53 | gevaerts | hm, right |
| 15:26:00 | * | gevaerts might fix that later |
| 15:26:56 | pamaury | gevaerts: I found out the "bug" about controls which have associated usb string |
| 15:31:30 | | Quit DataGhost (Ping timeout: 264 seconds) |
| 15:32:25 | | Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 15:32:25 | | Quit DataGhost (Changing host) |
| 15:32:25 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
| 15:33:37 | * | FlynDice has taken cover off vegetative clip+ and looks for points to short for miraculous recovery procedure. Opens mind to inspiring ideas and searches diligently |
| 15:34:42 | funman | FlynDice: did dumping the block device give you anything useful? |
| 15:35:08 | FlynDice | how do I dump it? |
| 15:35:23 | funman | dd |
| 15:35:29 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 15:35:58 | FlynDice | so switch the if=/dev/sdd? |
| 15:36:07 | | Join Luca_S [0] (~5d3fc54b@giant.haxx.se) |
| 15:37:03 | funman | hm? |
| 15:37:25 | | Join halmi [0] (~Miranda@188.20.253.186) |
| 15:38:09 | FlynDice | sorry, do I do dd if=/dev/sdd of=dump.bin for a command then? |
| 15:39:17 | funman | yep |
| 15:41:06 | FlynDice | I'll try that later, out of time now... |
| 15:44:32 | | Quit MagusG (Ping timeout: 252 seconds) |
| 15:45:19 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 15:47:59 | | Quit halmi (Quit: halmi) |
| 15:49:40 | | Quit funman (Quit: free(random());) |
| 15:51:18 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:54:50 | | Quit froggymana (Quit: CGI:IRC) |
| 15:57:54 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
| 15:59:12 | | Quit ender` (Ping timeout: 276 seconds) |
| 15:59:42 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 16:00 |
| 16:01:39 | | Quit mikroflops_ (Ping timeout: 240 seconds) |
| 16:09:03 | | Quit pamaury (Quit: Quitte) |
| 16:13:01 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 16:19:38 | | Join DataGhost_ [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 16:19:39 | | Quit DataGhost (Disconnected by services) |
| 16:19:39 | | Nick DataGhost_ is now known as DataGhost (~dataghost@192-18-ftth.onsnetstudenten.nl) |
| 16:28:10 | | Join halmi [0] (~Miranda@188.20.253.186) |
| 16:29:25 | | Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) |
| 16:29:58 | | Quit halmi (Quit: halmi) |
| 16:31:04 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
| 16:33:40 | | Join halmi [0] (~Miranda@188.20.253.186) |
| 16:35:05 | | Join ssorgatem [0] (~ssorgatem@232.Red-88-24-103.staticIP.rima-tde.net) |
| 16:35:42 | ssorgatem | hello? |
| 16:36:27 | | Join yorick [0] (~yorick@s55924da0.adsl.wanadoo.nl) |
| 16:36:47 | yorick | I think it would be nice to have the tracker in fact use flyspray priority feature |
| 16:37:01 | yorick | then I can see if there are any serious(limiting) bugs in rockbox trunk |
| 16:37:30 | Bagder | but what good what that bring? |
| 16:37:48 | yorick | prioritizing things is great |
| 16:38:14 | gevaerts | Yes, and we all prioritise bugs, just not in a shared list :) |
| 16:38:17 | Bagder | yes, I guess it can be good |
| 16:38:29 | gevaerts | *all* bugs are limiting |
| 16:38:33 | yorick | wouldn't it be better to have a shared list? |
| 16:38:34 | Bagder | if there was a way for us to do that prio |
| 16:39:06 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 16:39:23 | funman | ssorgatem: hi |
| 16:39:24 | gevaerts | yorick: the importance of a bug depends on the person looking at it |
| 16:39:37 | ssorgatem | funman: hi |
| 16:40:02 | yorick | gevaerts: but "ipod video not charging with your apple(c) charger(tm) which cost 30 euros" is a bit more limiting than "ipod video scrolling not working until key clicked" |
| 16:40:21 | funman | ssorgatem: i look at a patch I can make you try without bricking the fuzev2 |
| 16:40:23 | gevaerts | yorick: only for people who have such a charger |
| 16:40:55 | ssorgatem | funman: maybe disabling OF autoboot when a usb detection is detected? |
| 16:41:02 | yorick | gevaerts: any usb charger does it :) |
| 16:41:03 | Torne | yorick: a large number of people seem to not have even noticed the charging issues, but several of them have still been rather annoyed by the scrollwheel bug :) |
| 16:41:13 | funman | ssorgatem: that will work only if the second detection (button) is working |
| 16:41:18 | Torne | yorick: so i suspect a lot of people would disagree. |
| 16:41:22 | yorick | the scrollwheel bug is in a stable release |
| 16:41:25 | yorick | the charger thing is not |
| 16:41:36 | linuxstb | yorick: And it's only important for people who use an ipod video... |
| 16:41:45 | Torne | sure it is; if you press the button to do charging only, it doesn't charge much/at all ;) |
| 16:41:47 | gevaerts | yorick: would increasing the priority of that bug make people suddenly work on it? |
| 16:41:51 | ssorgatem | funman: mm and we have no way to see if it's working now, right? |
| 16:41:54 | Torne | This is kinda deceptive with the name, no? :) |
| 16:42:02 | Torne | (charging mode doesn't charge, the othe rmode does? :) |
| 16:42:28 | yorick | Torne: who presses that button :P |
| 16:42:29 | kugel | funman: has someone tested if the i2c detection also works on as3525v2? |
| 16:43:03 | Torne | yorick: lots of people? :) |
| 16:43:16 | funman | kugel: it doesn't work in normal build, testing in mkamsboot is looking for problems |
| 16:43:23 | gevaerts | yorick: bug priorities work if you're in an environment where you can tell people what to do and fire them if they don't. I don't think they work in an environment where people do whatever they like |
| 16:43:25 | Torne | yorick: but seriously, anyway. it was just an arbitrary example |
| 16:43:32 | kugel | ssorgatem: you should try a delay instead of disabling completely |
| 16:44:00 | Torne | yorick: priorities aren't very useful to the developers for the reason gevaerts says; priorities aren't very useful to users because different users will have vastly different ideas about what bugs are important |
| 16:44:13 | yorick | ok then |
| 16:44:18 | Torne | Ther eis one thing we could do with the tracker that might help, though |
| 16:44:26 | Torne | The affected player option should be a multiselect really |
| 16:44:28 | funman | kugel: how does http://pastie.org/915708 look ? |
| 16:44:34 | ssorgatem | kugel: it's to some of you givving me a patch which I'll hopefully compile and install |
| 16:44:43 | Torne | because there's currently no way to say "all PP5020 targets" or "all ipods" or "all CF targets" |
| 16:44:47 | Torne | or similar |
| 16:44:54 | Torne | so it's hard for people to see which bugs *might* affect their player |
| 16:45:00 | linuxstb | Torne: With the problem that the original poster can only say for sure that it's on his/her target... |
| 16:45:17 | yorick | linuxstb: you can change stuff |
| 16:45:18 | ssorgatem | kugel: my coding skills stop at perl/python |
| 16:45:19 | Torne | linuxstb: sure, but I mean from the developer's POV |
| 16:45:25 | Torne | yorick: we can, but users can't :) |
| 16:45:33 | yorick | Torne: lets change that :P |
| 16:45:43 | Torne | linuxstb: a lot of bugs are filed by people who *can* say for sure what targets are affected, also |
| 16:45:47 | Torne | linuxstb: because they know the code :) |
| 16:45:47 | linuxstb | Torne: I just mean that we don't want users (or even devs) guessing... |
| 16:45:59 | Torne | Hm |
| 16:46:01 | kugel | funman: looks ok to me, except you're wasting a cycle there :p |
| 16:46:05 | linuxstb | Torne: But they don't know for *sure*... |
| 16:46:07 | Torne | I guess the thing to do would be have a single-select for "reported on" |
| 16:46:12 | Torne | and multi for "confirmed to affect"? |
| 16:46:17 | funman | kugel: where? |
| 16:46:18 | Torne | or is that too complkicated to be useful. |
| 16:46:19 | Torne | i duno. |
| 16:46:29 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
| 16:46:33 | | Join M3DLG [0] (~M3DLG@212.183.140.37) |
| 16:46:40 | kugel | you could bne boot_of and fall through to wait |
| 16:46:50 | kugel | but it really doesn't matter |
| 16:47:04 | funman | ssorgatem: try http://pastie.org/915708 , it should always boot the OF, but with some delay inserted if you press the left key or not |
| 16:47:05 | Torne | linuxstb: *shrug8 it was just a thought |
| 16:47:55 | funman | the delay might be a bit long (10s of seconds) though, it's better than too fast to notice |
| 16:48:22 | ssorgatem | funman: ok |
| 16:49:28 | linuxstb | Torne: Are you sure flyspray allows us to make it a multi-select list? |
| 16:49:52 | Torne | linuxstb: i have no idea |
| 16:49:59 | Torne | this was entirely hypothetical :) |
| 16:50:38 | Torne | yorick: i assume what you're after is "i have an ipod mini 2g, is the current build likely to work well enough for normal use" |
| 16:50:45 | yorick | yes |
| 16:50:50 | Torne | the intention is that for the ports marked stable, this is *always true* :) |
| 16:50:50 | yorick | except I have an ipod video 5.5g |
| 16:50:55 | Torne | yes, it was arbitrary |
| 16:51:06 | Torne | My point is that the stable ports are, generally, stable. |
| 16:51:07 | yorick | but I don't want stable |
| 16:51:10 | yorick | I want relatively stable |
| 16:51:15 | Torne | No, I don't mean the releases |
| 16:51:20 | Torne | I mean, the categories on the front page |
| 16:51:40 | Torne | The stable ports are, generally, stable in svn *all the time*, with occasional exceptions because someone made a mistake |
| 16:52:06 | funman | if you don't want stable we could probably add some bugs, just open a feature request |
| 16:52:25 | Torne | ipod video 5.5g is also my primary device |
| 16:52:39 | Torne | and yes, I expect that *any* random svn version i happen to pull on any particular day works perfectly fine |
| 16:52:48 | Torne | In a couple of years this has, so far, always been true |
| 16:52:52 | Torne | at least for any feature I see or use |
| 16:52:59 | ssorgatem | funman: upgrading firmware |
| 16:53:30 | Torne | For the unusable targets, this is different, of course :0 |
| 16:53:41 | funman | ssorgatem: try first with left pressed, it should boot instantly |
| 16:53:43 | Torne | playback might work okay in only a small range of versoins, or whatever. but they're listed as unusable for that reason :) |
| 16:54:08 | ssorgatem | funman: it does |
| 16:54:14 | funman | cool at least it's not bricked |
| 16:54:27 | Torne | yorick: from that point of view, *all* the bugs that affect ipod video are probably fairly low priority. The charging issue has a trivial workaround and for most people, it does still charge, just very slowly. |
| 16:54:39 | ssorgatem | funman: and does the same without pressing anything |
| 16:54:42 | Torne | yorick: it doesn't make the player unusable, or even unreliable |
| 16:55:02 | * | kugel was about to say the usb detection is more likely to fail |
| 16:55:06 | funman | ssorgatem: ok, try increasing the value on the wait: line, add a 0 (to make it 16 times bigger) |
| 16:55:36 | funman | ssorgatem: hm wait |
| 16:55:40 | funman | did you run make in dualboot/ ? |
| 16:56:15 | ssorgatem | funman: no, make clean && make in mkamsboot/ |
| 16:56:18 | funman | you need to do: cd rbutil/mkamsboot; make -C dualboot ; make |
| 16:56:24 | ssorgatem | ok |
| 16:56:44 | Torne | yorick: is this not your experience? :) |
| 16:57:16 | funman | we have a pre-built dualboot object code in svn, so arm cross compiler isn't needed to build mkamsboot. And this code isn't automatically rebuilt if you only build mkamsboot itself |
| 16:57:16 | yorick | Torne: not yet :P |
| 16:57:20 | Torne | yorick: also, *are* there any current bugs that you would consider high priority for ipodvideo, because they actually significantly impede your ability to use it? |
| 16:57:22 | yorick | I just want to be sure :) |
| 16:57:46 | yorick | Torne: the charging bug? |
| 16:57:46 | linuxstb | There was an intention at some point that the "TargetStatus" page should list those kind of major issues for a device. |
| 16:57:49 | Torne | well, that's the idea, anyway. we are human (well, most of us), but we make every effort to not break stuff that already works |
| 16:57:57 | ssorgatem | funman: rebuilt |
| 16:58:26 | Torne | and if something important is broken in the course of doing something else, and it's not trivial to fix it, we're not going to just open a bug and leave it, we are going to revert whatever change broke it, and try again later, generally. |
| 16:58:38 | linuxstb | yorick: Have you seen this table? http://www.rockbox.org/wiki/TargetStatus#Current_status_of_supported_targ |
| 16:59:18 | ssorgatem | funman: upgrading firmware |
| 17:00 |
| 17:00:02 | ssorgatem | funman: the same |
| 17:00:09 | funman | http://forums.rockbox.org/index.php?topic=24375.0 Clipv1 poll report: 5 out of 6 people never experience crashes, 1 experience sparse crases |
| 17:00:19 | | Join {phoenix} [0] (~dirk@p57AA4682.dip.t-dialin.net) |
| 17:00:25 | funman | ssorgatem: can you upload your patched OF somewhere so I can check it ? |
| 17:00:32 | yorick | I experience crashes |
| 17:00:37 | yorick | (well once) |
| 17:00:38 | ssorgatem | funman: ok |
| 17:00:42 | funman | omloader.org for example |
| 17:00:45 | funman | yorick: on Clipv1 ? |
| 17:00:51 | ssorgatem | funman: where could I upload it? |
| 17:01:11 | funman | ssorgatem: omploader.org |
| 17:01:14 | yorick | funman: no |
| 17:01:49 | | Quit Zagor (Quit: Leaving) |
| 17:02:25 | Torne | yorick: i've done most of the usb power rework required to start fixing charging, btw ;) |
| 17:02:32 | | Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) |
| 17:02:45 | Torne | yorick: need to finish poking the code to handle when it decides the attached thing is probably a charger |
| 17:02:57 | Torne | then get various people to test tha twe reaally are flipping the right GPIOs for all the different ipod models |
| 17:03:06 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:03:12 | Torne | but i can commit the different models one at a time, if needed; I know the ipodvideo one works :) |
| 17:03:32 | Torne | the code i have on my ipod atm detects USB hosts correctly and charges from them, it just doesn't work with AC chargers still |
| 17:04:16 | yorick | :) |
| 17:04:53 | Torne | so it is being worked on, i just don't have infinite free time ;) |
| 17:04:56 | ssorgatem | funman: I'm uploading it. It will take some minutes, as it's 5,7 Mb (tar.bz2) |
| 17:06:29 | *** | Saving seen data "./dancer.seen" |
| 17:13:28 | | Quit halmi (Quit: halmi) |
| 17:14:24 | * | yorick goes looking for his Apple iPod(c) Radio Remote(tm) |
| 17:14:57 | | Join halmi [0] (~netbook@188.20.253.186) |
| 17:15:02 | | Quit Xerion (Quit: ) |
| 17:15:05 | | Quit halmi (Client Quit) |
| 17:15:29 | | Join halmi [0] (~netbook@188.20.253.186) |
| 17:18:02 | | Quit M3DLG (Ping timeout: 252 seconds) |
| 17:22:42 | yorick | hmm I can't find it |
| 17:22:51 | yorick | I have probably lost it |
| 17:28:51 | ssorgatem | funman: uploaded, but not in omgloader |
| 17:28:57 | ssorgatem | funman: https://docs.google.com/leaf?id=0B-WXiWja7YGkNmU1YTU5NDQtNjU1ZS00YWUxLThiYTgtNTliNjUwNDEwMTJj&hl=ca |
| 17:31:30 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 17:33:09 | funman | ssorgatem: strange the USB check is still there |
| 17:33:41 | ssorgatem | funman: what does that mean? |
| 17:33:53 | funman | my patch should have removed the USB detection |
| 17:35:14 | funman | did the diff apply properly ? can you paste the output of 'svn diff' ? |
| 17:36:15 | ssorgatem | funman: yes, it applied cleanly |
| 17:36:24 | ssorgatem | do i paste the output here? |
| 17:36:37 | funman | no, on pastie.org |
| 17:36:58 | funman | ah sorry, it's ok in fact |
| 17:37:06 | funman | i misread |
| 17:37:19 | funman | so the failing check is the button one |
| 17:37:40 | kugel | but then the delay should come? |
| 17:37:45 | | Quit avn (Ping timeout: 246 seconds) |
| 17:38:04 | ssorgatem | funman: here it is: http://pastie.org/915797 |
| 17:38:26 | ssorgatem | there's no delay at all |
| 17:38:31 | funman | kugel: true, perhaps the delay is too small to be noticed |
| 17:39:06 | kugel | possibly |
| 17:39:18 | kugel | it's only 10M cycles afterall |
| 17:39:32 | ssorgatem | but if the failing check were the button one, shouldn't it boot into rockbox? |
| 17:39:38 | ssorgatem | or at least try it? |
| 17:39:41 | | Join avn [0] (~avn@88.119.164.243) |
| 17:40:10 | funman | ssorgatem: svn revert . -R and then apply this : http://pastie.org/915802 |
| 17:40:34 | funman | ssorgatem: it could be that dualboot code thinks the left button is always pressed |
| 17:40:50 | funman | ssorgatem: with this other patch you should see a delay when booting normally, no delay when booting by plugging USB cable |
| 17:41:11 | kugel | the delay should be a bit higher |
| 17:41:28 | funman | i made it 16 times higher than previousy, is that enough ? |
| 17:41:31 | kugel | I assume you need at least 0x20000000 to be noticeable |
| 17:41:59 | | Quit xiainx (Ping timeout: 246 seconds) |
| 17:42:20 | kugel | my simple calculation is delay number * 2/250MHz, not sure if it makes sense |
| 17:43:34 | | Quit MuscleNerd (Ping timeout: 276 seconds) |
| 17:44:16 | | Join MuscleNerd [0] (eric@adsl-75-27-189-151.dsl.irvnca.sbcglobal.net) |
| 17:44:22 | ssorgatem | upgrading firmware |
| 17:44:48 | ssorgatem | mm |
| 17:45:45 | ssorgatem | i think there's now a little delay when powering on without usb attached |
| 17:45:51 | ssorgatem | but very little |
| 17:46:02 | funman | ssorgatem: add a 0 to the delay on the wait: line and verify |
| 17:46:53 | funman | given that the button code in rockbox driver is a bit more complex than the one in dualboot.S that makes sense |
| 17:46:59 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 17:50:12 | Bagder | rockbox bios! ;-) => http://www.bestpriceplaza.info/ipodmeetcar/ipod-car/new-ipod-nano-2g-hack-rockbox-bios-review-part-1/ |
| 17:50:14 | ssorgatem | upgrading firmware once again |
| 17:51:59 | ssorgatem | the same again |
| 17:52:13 | funman | is the delay more noticeable ? |
| 17:52:18 | ssorgatem | nope |
| 17:52:44 | Torne | Bagder: ick, ugly generated blog linkfarm thing |
| 17:52:49 | | Quit halmi (Quit: halmi) |
| 17:53:00 | | Join halmi [0] (~netbook@188.20.253.186) |
| 17:53:10 | funman | ssorgatem: try with mvn r0, #0 |
| 17:53:26 | * | Bagder didn't noticed, but I guess you're right |
| 17:53:27 | funman | instead of mov r0, #0x5... |
| 17:53:52 | ssorgatem | so, what instead of what? |
| 17:54:48 | | Quit Bagder (Quit: It is time to say moo) |
| 17:54:52 | ssorgatem | the line should be like this: "wait: mvn r0, #0"? |
| 17:54:57 | funman | yeah |
| 17:55:08 | ssorgatem | ok |
| 17:55:26 | | Quit xiainx (Ping timeout: 245 seconds) |
| 17:57:25 | ssorgatem | upgrading firmware |
| 17:58:34 | ssorgatem | nothing |
| 17:59:16 | funman | still boots fastly with or without USB plugged? |
| 17:59:22 | ssorgatem | yes |
| 17:59:49 | funman | you ran make in dualboot/ or used make -C dualboot/ right? |
| 17:59:53 | ssorgatem | i'm starting to think i'm the owner of the invincible fuze lol |
| 17:59:54 | ssorgatem | yes |
| 17:59:56 | | Quit TheSeven (Read error: Connection reset by peer) |
| 18:00 |
| 18:00:00 | | Quit petur (Quit: *plop*) |
| 18:00:18 | ssorgatem | i ran exactly : "make clean && make -C dualboot/ clean && make -C dualboot/ && make" |
| 18:00:27 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 18:01:02 | funman | hm it could be that both button & USB detection do not work |
| 18:01:11 | funman | then you're lucky it defaulted to boot OF |
| 18:02:09 | ssorgatem | ah, well, not everything i lost then |
| 18:02:11 | ssorgatem | mm |
| 18:02:20 | funman | try to comment out the "bne boot_of" before the "mvn", prefix it with a @ |
| 18:02:24 | ssorgatem | but, why is my fuze so special? |
| 18:02:46 | funman | this will run the delay unconditionally, then when it's booted you can update to unpatched OF to remove the delay. This will make sure our code is run |
| 18:02:53 | funman | ssorgatem: ask sandisk, not us! |
| 18:03:24 | ssorgatem | funman: true, it was more like a rhetorical question |
| 18:03:30 | ssorgatem | ok |
| 18:03:34 | ssorgatem | commenting... |
| 18:03:46 | funman | ssorgatem: paste your diff to dualboot.S before running mkamsboot to make sure it's correct |
| 18:04:06 | ssorgatem | ok |
| 18:04:09 | funman | ssorgatem: and a rhetorical answer :) |
| 18:05:08 | ssorgatem | http://pastie.org/915845 |
| 18:05:10 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 18:05:34 | funman | looks correct |
| 18:05:50 | funman | the delay might be quite long though (still under 1 minute i believe) |
| 18:05:59 | funman | so don't be afraid |
| 18:07:05 | ssorgatem | ok |
| 18:08:22 | ssorgatem | upgrading firmware |
| 18:09:00 | ssorgatem | ok |
| 18:09:01 | ssorgatem | now |
| 18:09:11 | ssorgatem | i'm hopefullly seeing a delay |
| 18:09:19 | ssorgatem | because i don't see anything |
| 18:09:46 | funman | sounds good so far |
| 18:10:33 | ssorgatem | i'm starting to worry |
| 18:11:34 | funman | each loop takes 4 cycles, there are 4 billions loops => 16 billions cycles, and the CPU should run at 240 millions cycles per second or less, so it will take 1 minute or more |
| 18:11:58 | kugel | 4? |
| 18:12:11 | funman | 1 cycle for sub, 3 cycles for the branch |
| 18:12:19 | kugel | a branch is 3 cylces? |
| 18:12:33 | funman | yes because pipeline must be flushed |
| 18:13:13 | ssorgatem | more than 2 minutes? |
| 18:13:30 | funman | i don't know the CPU speed at this point though, if it's 24MHz, then it would take a bit more than 10 minutes |
| 18:13:42 | ssorgatem | ow |
| 18:13:46 | ssorgatem | well |
| 18:14:00 | kugel | or maybe it's just bricked :) |
| 18:14:09 | * | funman slaps kugel |
| 18:14:11 | ssorgatem | *sigh* |
| 18:14:17 | kugel | ssorgatem: don't worry |
| 18:14:43 | ssorgatem | so, suposing it's not bricked |
| 18:14:52 | ssorgatem | what would be the next to do? |
| 18:15:58 | funman | first upgrade it with OF to remove the (annoyingly long) delay |
| 18:16:26 | funman | then reduce the delay to have a good value (some seconds so it can be noticed and not bother too much) |
| 18:16:45 | funman | and then try to read USB status or a button in a reliable way |
| 18:16:57 | funman | your only output is the delay presence or not |
| 18:17:25 | | Quit JohannesSM64 (Read error: Connection reset by peer) |
| 18:17:45 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
| 18:18:21 | ssorgatem | ah, it booted |
| 18:20:05 | funman | around 10 minutes then |
| 18:20:32 | | Quit halmi (Quit: halmi) |
| 18:20:38 | funman | 0x2000000 for the delay should be approximately 5 seconds |
| 18:21:05 | ssorgatem | and where do I put that? |
| 18:21:06 | | Join halmi [0] (~netbook@188.20.253.186) |
| 18:24:43 | funman | http://pastie.org/915872 <- this patch disables USB check for the Fuzev2, create a section specific for it |
| 18:25:06 | funman | and checks C4 pin (select button) instead of C3 (left) |
| 18:25:08 | | Quit xiainx (Ping timeout: 240 seconds) |
| 18:26:00 | funman | ideally you would read button-fuzev2.c and figure out what's missing in dualboot.S ; if C4 doesn't work I'll try to make a patch later |
| 18:30:37 | funman | i'm leaving, when i make a patch i'll post it on the forum |
| 18:30:38 | | Quit funman (Quit: free(random());) |
| 18:31:03 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 18:32:00 | ssorgatem | that last patch doesn't compile |
| 18:42:10 | | Quit xiainx (Ping timeout: 252 seconds) |
| 18:43:48 | | Join bmbl [0] (~Miranda@dsl60-198.pool.bitel.net) |
| 18:43:53 | | Quit bmbl (Changing host) |
| 18:43:53 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 18:44:05 | CIA-5 | New commit by alle (r25607): Mark const return value; correct the comment about valid menu items for the hotkey |
| 18:46:26 | Torne | JdGordon_: did you ever do anything more with the 32/64mb memory detection code for the ipod video? |
| 18:46:46 | | Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) |
| 18:48:13 | | Quit RadicalR (Ping timeout: 265 seconds) |
| 18:48:36 | CIA-5 | New commit by alle (r25608): Better dot placement |
| 18:49:18 | | Join M3DLG [0] (~M3DLG@212.183.140.6) |
| 18:50:48 | | Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) |
| 18:52:46 | Torne | JdGordon_: can you post the patch as you had it somewhere? |
| 18:54:47 | | Quit krazykit (Read error: Connection reset by peer) |
| 18:55:23 | | Join krazykit [0] (~kkit@adsl-76-251-248-223.dsl.ipltin.sbcglobal.net) |
| 18:56:21 | | Quit komputes (Ping timeout: 276 seconds) |
| 18:57:17 | | Join fml [0] (~chatzilla@port-83-236-234-85.static.qsc.de) |
| 18:59:00 | | Join petur [0] (~peter@rockbox/developer/petur) |
| 18:59:36 | fml | Re. r25607: it should be possible to extend the types of possible hotkey'able menues but the menu API is done in a way that makes it hard. The reason is that to get the text of a menu item it's necessary to know the index of the item in its parent's menu (which shouldn't be necessary IMO) |
| 19:00 |
| 19:06:32 | *** | Saving seen data "./dancer.seen" |
| 19:11:25 | | Quit flydutch (Quit: /* empty */) |
| 19:15:01 | | Quit linuxstb (Ping timeout: 258 seconds) |
| 19:16:45 | | Join GeeksHaveFeeling [0] (~meow@unaffiliated/ghf) |
| 19:17:18 | | Quit GHF (Read error: Operation timed out) |
| 19:19:47 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 19:20:08 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 19:20:31 | | Join webguest99 [0] (~55f67e4c@giant.haxx.se) |
| 19:21:23 | | Join G_H_F [0] (~meow@r73h41.res.gatech.edu) |
| 19:21:28 | | Quit webguest99 (Client Quit) |
| 19:22:08 | | Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) |
| 19:22:24 | | Quit M3DLG (Ping timeout: 260 seconds) |
| 19:22:54 | | Quit phanboy4 (Quit: Leaving) |
| 19:24:44 | | Quit GeeksHaveFeeling (Ping timeout: 260 seconds) |
| 19:25:08 | | Quit TillW (Quit: This now concludes our broatcast day.) |
| 19:25:20 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 19:25:30 | Blue_Dude | I just wanted to throw an idea out there re: the volume clipping/overboost discussion. This is an interface idea: why not have a built-in "pause" in volume control at 0db, when setting volume. That is, make the 0db point a kind of detent you have to step over in order to select something higher than 0db? If we want 0db to be a kind of soft limit, it makes sense to make it easier to stop there. |
| 19:25:47 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 19:26:32 | Blue_Dude | This could be done by making the volume range from MIN to 0, 0, 0 to MAX. Two or three chances to hit 0 on the way past to MAX. |
| 19:26:51 | Blue_Dude | And easy to reduce to exactly zero on the way down. |
| 19:26:57 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 19:30:00 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 19:33:04 | | Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net) |
| 19:34:18 | kugel | Blue_Dude: if we wanted to protect the users so badly we would have done it by now |
| 19:34:22 | | Quit saratoga (Ping timeout: 248 seconds) |
| 19:35:11 | Blue_Dude | kugel: it's not so much a protection idea as it is an ergonomic feature. It's just an idea I stole from other gear. |
| 19:35:57 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 19:36:06 | Blue_Dude | But perhaps more trouble than it's worth. I personally seldom try to hit 0dB exactly but maybe that's important to others. |
| 19:36:50 | CIA-5 | New commit by Buschel (r25609): Replaygain pre-amp can be set in 0.5 dB steps. |
| 19:37:08 | funman | ssorgatem: try http://pastie.org/915991 |
| 19:38:19 | | Join Buschel [0] (~ab@p54A3C57B.dip.t-dialin.net) |
| 19:39:37 | | Quit dfkt (Read error: Connection reset by peer) |
| 19:41:44 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 19:42:24 | | Quit Buschel (Ping timeout: 240 seconds) |
| 19:43:22 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 19:43:43 | | Join Buschel [0] (~ab@p54A3C57B.dip.t-dialin.net) |
| 19:46:28 | * | FlynDice gives up on clip+ and heads to store, wonders if ranma would like to try his JTAG voodoo magic on said unit? |
| 19:48:35 | * | funman is in remote discussion with a profesional solderer |
| 19:55:16 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 19:55:25 | | Join esperegu [0] (~quassel@145.116.11.103) |
| 19:55:31 | esperegu | Hi! |
| 19:56:01 | esperegu | I broke the screen of my iriver H120. anyone knows if that is replaceble and where I could buy that? |
| 19:57:19 | fml | Blue_Dude: hello. Have you analyzed remote keymaps during your hotkey work? |
| 19:57:56 | Blue_Dude | fml: I didn't even look at them since there were no keys I could safely steal. |
| 19:58:48 | fml | Blue_Dude: aren't there the "quick" keys to view the playlist? I haven't looked though. |
| 19:59:22 | Blue_Dude | fml: I don't think so, but I didn't look all that closely. There's no reason it wouldn't work though. |
| 19:59:44 | pixelma | the playlist viewer shortcuts were a mere guess too |
| 20:00 |
| 20:00:36 | fml | pixelma: but we could make whatever was "playlist view" to be "hotkey" |
| 20:01:29 | funman | esperegu: I don't think it's related to rockbox. Better come on #rockbox-community (or try mysticriver website?) |
| 20:01:56 | | Quit Boldfilter (Ping timeout: 246 seconds) |
| 20:02:11 | esperegu | funman: k. thx |
| 20:02:17 | | Join Boldfilter [0] (~Boldfilte@adsl-178-250-59.jax.bellsouth.net) |
| 20:03:06 | Buschel | saratoga: Even in the asm version replaygain is 1 smull, 1 mov and 1 orr per sample = 4+1+1=6 cycles per sample. Plus and 1 ldm + 1 stm per 2 samples = 3+1+4+2 = 10 cycles per 2 samples. Plus 1 sub and 1 branch per 2 cycles = 1+3 = 4 cycles per 2 samples => 13 cycles per sample = 1,1 MHz (@44.1kHz sample rate). This equals ~0.3 mA and is measurable in terms of runtime. |
| 20:03:27 | pixelma | fml: yes sure but the playlist view wasn't implemented very accurately either, I wouldn't be surprised if no-one took care of remote keymaps and I already know that the chosen combo won't work on the Iaudio M3 btw. (it just existed for a while and no-one noticed, lack of documentation is one cause and the M3 is probably an "exotic" target) |
| 20:04:18 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
| 20:04:35 | Buschel | saratoga: but of course such savings are minor comapred to other settings. |
| 20:04:40 | Buschel | *compared |
| 20:05:37 | pixelma | there probably won't be a way similar to the other Iaudios, they all have in common that the only combos electrically possible are ones with the "Power" key which also serves as a hard power-off after a rather short time |
| 20:05:42 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 20:06:12 | pixelma | fml: the playlist viewer shortcut was dropped on the M5X5 pad after I said that here |
| 20:07:18 | | Quit CGL (Quit: Saliendo) |
| 20:07:40 | fml | pixelma: OK then. But shouldn't we then remove the remote key for the playlist viewer where it's still present? It's not properly assigned and not documented. |
| 20:08:26 | pixelma | I'd rather say implement if possible and document |
| 20:09:16 | pixelma | or I misunderstood |
| 20:09:55 | pixelma | fml: which remote key did you mean, I thought you said that there wasn't one for remotes? |
| 20:12:25 | | Quit Boldfilter (Ping timeout: 260 seconds) |
| 20:12:45 | ssorgatem | funman: Now it works |
| 20:12:55 | ssorgatem | funman: wel, it waits, i mean |
| 20:14:36 | funman | regardless if you press center button or not ? |
| 20:14:37 | fml | pixelma: I mean that if a remote key is defined then it should be (temporarily) removed. And then chosen and documented properly. |
| 20:15:12 | fml | pixelma: I see that H100 has a key for ID3 |
| 20:15:26 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 20:15:28 | ssorgatem | funman: yes |
| 20:15:34 | ssorgatem | funman: well |
| 20:15:42 | ssorgatem | funman: haven't tried pressing the button |
| 20:16:25 | ssorgatem | funman: pressing the button doesn't wait |
| 20:16:38 | ssorgatem | funman: that's how it's supposed to be, right? |
| 20:16:51 | pixelma | fml: the ID3 viewer is not the playlist viewer shortcut though (and exist for a longer time) |
| 20:16:52 | funman | hm that's cool |
| 20:17:19 | funman | ssorgatem: if i give you a workaround to boot rockbox with center button as dualboot, will you still help to find how to read left button? |
| 20:17:40 | ssorgatem | funman: of course |
| 20:18:17 | fml | pixelma: then we can make it hotkey. The user can choose it to be ID3. |
| 20:19:17 | pixelma | in that case it should be the former ID3 screen thing everywhere IMO, |
| 20:20:09 | funman | ssorgatem: http://pastie.org/916065 should default boot to rockbox, boot to OF if center is pressed |
| 20:20:19 | pixelma | not like "oh, on the remote we don't need the ID3 screen button anymore" while it would be somthing else on the main unit |
| 20:21:15 | pixelma | just my first thought |
| 20:23:08 | ssorgatem | funman: upgrading firmware |
| 20:23:10 | fml | pixelma: maybe |
| 20:23:28 | pixelma | does the code even handle two different hotkeys? |
| 20:24:28 | ssorgatem | funman: it works, but the oder way around |
| 20:24:37 | notlistening | funman FlynDice's clip+ still knackered? |
| 20:24:47 | | Join Boldfilter [0] (~Boldfilte@adsl-71-216-161.jax.bellsouth.net) |
| 20:24:49 | fml | pixelma: you mean WPS and tree? |
| 20:24:50 | ssorgatem | funman: it defaults to OF, but when I press center, it tries to load rockbox |
| 20:25:02 | pixelma | fml: no, remote and main |
| 20:25:34 | ssorgatem | funman: and fails with "ATA error: -2" |
| 20:25:43 | funman | ssorgatem: hm sad |
| 20:26:01 | fml | pixelma: it doesn't handle buttons AFAIU, it handles actions which are defined in keymaps |
| 20:26:03 | pixelma | fml: which could potentially make it four different hotkeys then IIUC |
| 20:26:10 | funman | ssorgatem: bootloader might be broken in svn though |
| 20:26:28 | fml | pixelma: yes |
| 20:26:37 | pixelma | fml: but it stores some settings for them, no? |
| 20:26:51 | funman | ssorgatem: I have r25377, can you build a bootloader from this revision ? |
| 20:28:32 | ssorgatem | funman: mm how would I do it? I've never downgraded a svn tree |
| 20:29:53 | fml | pixelma: no, I think it only stores two settings (WPS and browser), but not separately for main and remote |
| 20:30:01 | funman | hm svn help revert doesn't help. I use git, not svn so I don't know but I hope someone else here does |
| 20:30:51 | linuxstb | ssorgatem: I think just "svn update -r XXXXX" |
| 20:31:06 | linuxstb | revert is for removing local changes |
| 20:31:51 | ssorgatem | linuxstb: thanks, it seems to have worked |
| 20:32:12 | ssorgatem | it says "At revision 25377", at least |
| 20:33:24 | ssorgatem | which is the preferred chainload, arm-elf or arm-elf-eabi? |
| 20:33:41 | pixelma | fml: so currently - if you would have a hotkey action on the remote which replaces the ID3 one and a hotkey action for the main keypad which replaces the playlist viewer shortcut (and assuming that the ID3 action on the main unit still exist) - if you then set your hotkey function to ID3 viewer you would have two buttons (or combos) doing the same on the main kaypad, or do I overlook something? |
| 20:33:41 | funman | arm-elf |
| 20:34:10 | pixelma | or keypad |
| 20:34:15 | funman | arm-elf-eabi should work, but we still use arm-elf as default (and it's what my bootloader uses) |
| 20:34:53 | | Join roflmao [0] (~yep@24.145.28.137) |
| 20:35:10 | fml | pixelma: I think you're right. And I also think that we should remove a special ID3 button if it exists |
| 20:35:34 | | Part roflmao |
| 20:35:59 | pixelma | it's there on (almost?) all target and been there for ages |
| 20:36:46 | | Join kugel_ [0] (~kugel@e178082195.adsl.alicedsl.de) |
| 20:37:00 | | Quit kugel (Disconnected by services) |
| 20:37:04 | | Nick kugel_ is now known as kugel (~kugel@e178082195.adsl.alicedsl.de) |
| 20:37:08 | | Quit kugel (Changing host) |
| 20:37:08 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 20:38:58 | * | kugel just saw his assessment task |
| 20:39:55 | kugel | I actually planned to do that anyway, but way later :p |
| 20:40:03 | fml | pixelma: but then we have an ideal key for the hotkey! Or is it extensively used? |
| 20:40:38 | | Quit kugel (Remote host closed the connection) |
| 20:40:42 | fml | pixelma: I mean the old ID3 key |
| 20:40:49 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 20:40:59 | ssorgatem | funman: let's see if this time it works |
| 20:41:00 | pixelma | not by me but then 2 of my 3 targets don't have it. People using both might be opposed |
| 20:41:27 | pixelma | ID3 screen and playlist viewer shortcut I mean |
| 20:41:57 | fml | pixelma: I don't think there are many people who use both since hotkey was introduced just recently |
| 20:42:06 | ssorgatem | funman: interesting |
| 20:42:22 | pixelma | fml: not hotkey but the playlist viewer shortcut |
| 20:42:32 | ssorgatem | funman: rockbox now gets further |
| 20:42:46 | ssorgatem | funman: there's a quic error i can't read and then |
| 20:42:49 | pixelma | fml: which wasn't there for too long but already a while |
| 20:43:05 | funman | ssorgatem: do you have .rockbox folder on the player ? |
| 20:43:08 | ssorgatem | funman: a screen with GPIO values and directions |
| 20:43:32 | funman | ssorgatem: hm that means an ATA error as well I think. Do you have a µSD card plugged in ? |
| 20:43:52 | ssorgatem | funman: no µSD card |
| 20:43:55 | | Join Strife89 [0] (~michael@168.16.237.214) |
| 20:44:09 | ssorgatem | funman: I think i have the .rockbox folder |
| 20:44:27 | | Join einhirn [0] (~Miranda@p5485A379.dip0.t-ipconnect.de) |
| 20:44:29 | ssorgatem | funman: *PANIC* ata -2 |
| 20:44:42 | ssorgatem | funman: and after that loads the OF |
| 20:44:43 | kugel | what compiler do you use? |
| 20:44:59 | kugel | the eabi version by chance= |
| 20:45:00 | funman | which means timeout in initialization step |
| 20:45:00 | ssorgatem | arm-elf |
| 20:45:00 | kugel | ? |
| 20:45:06 | fml | pixelma: we can still change that. Keymaps are not cemented. It's *soft*ware :-) |
| 20:45:09 | ssorgatem | ah |
| 20:45:10 | ssorgatem | wait |
| 20:45:20 | ssorgatem | rockbox may be compiled with the eabi |
| 20:45:37 | kugel | funman: the delay func in sd-as3525v2.c fails with the eabi toolchain because it's optimized away |
| 20:45:49 | pixelma | fml: ask Llorean about changing keymaps ;) Although my experience wasn't that bad |
| 20:46:04 | kugel | since it's not volatile |
| 20:47:34 | fml | Llorean: how are you about changing keymaps? (See discussion about "Show ID3" button just above) |
| 20:47:37 | ssorgatem | i'm trying now with latest build from rockbox.org |
| 20:47:52 | kugel | ssorgatem: I assume the bootloader is failing as well |
| 20:48:07 | Llorean | fml: I think pixelma was just mentioning how much flak I got when I changed a few keymaps way back. |
| 20:48:12 | funman | ssorgatem: rockbox (from .rockbox/ directory) isn't loaded afaiu |
| 20:48:12 | ssorgatem | it loads the menu for a fraction of a second, then loads the OF |
| 20:48:34 | funman | can you see the screen flicker? you would see the version number (svn revision + date) change |
| 20:48:41 | ssorgatem | yes |
| 20:48:46 | funman | ah so the bootloader works |
| 20:48:50 | pixelma | fml: you reduce the number of used buttons again though and then people complaining about an unused button and in the worst case want a second hotkey |
| 20:48:55 | ssorgatem | ah |
| 20:48:57 | ssorgatem | now |
| 20:48:58 | ssorgatem | it works |
| 20:48:59 | Llorean | I wouldn't know how may targets have a "Show ID3" button, I've never used it on any of mine or even accidentally hit it I think |
| 20:49:05 | ssorgatem | i'm ion rockbox |
| 20:49:35 | fml | BTW: how do you people feel about not displaying the splash when the hotkey is not assigned? |
| 20:50:10 | funman | ssorgatem: nice! do all buttons work ? (especially left button) |
| 20:50:24 | funman | and what happens if you plug the USB cable while in rockbox ? |
| 20:50:41 | | Join Luca_S [0] (~5711feea@giant.haxx.se) |
| 20:50:56 | linuxstb | fml: I was wondering about that feature - it serves as a way to tell users that they can assign a hotkey to it, so is useful for that purpose... But I imagine it could be annoying if you normally use that button to enable the backlight... |
| 20:51:06 | * | linuxstb adds the disclaimer that he hasn't updated Rockbox recently... |
| 20:51:40 | ssorgatem | all buttons work |
| 20:51:56 | ssorgatem | mm |
| 20:52:01 | ssorgatem | i'm trapped in solitaire |
| 20:52:03 | ssorgatem | lol |
| 20:52:23 | funman | trapped? :) |
| 20:52:31 | ssorgatem | no, it's ok |
| 20:52:35 | funman | ssorgatem: try the moving the red queen |
| 20:52:36 | funman | ah ok |
| 20:52:37 | Luca_S | use a long press of the home button |
| 20:52:41 | fml | linuxstb: yes, that's what I'm thinking. Many have resisted the rec key assignment to any function because they already see "backlight on" as a function |
| 20:52:42 | ssorgatem | i've to press the home button |
| 20:52:44 | ssorgatem | more than once |
| 20:52:58 | ssorgatem | ok |
| 20:53:00 | fml | linuxstb: ...which deserves its own key |
| 20:53:47 | ssorgatem | the fire demo looks weird |
| 20:53:49 | linuxstb | fml: Unless it can be either "unassigned" (in which case, you get the splash), or "do nothing" (in which case you don't)... |
| 20:53:53 | funman | ssorgatem: keep the bootloader you built around, i'll try to see what happens in button code (unless kugel beats me at that) |
| 20:54:05 | ssorgatem | funman: ok |
| 20:54:14 | funman | ssorgatem: hm and what happens if you plug USB ? |
| 20:54:53 | fml | linuxstb: that I didn't understand. Could you elaborate? |
| 20:54:54 | funman | if the previous tests with mkamsboot/dualboot were correct, USB should always be detected (and rockbox would reboot immediately) |
| 20:55:05 | funman | , even if there's no USB connection |
| 20:55:06 | ssorgatem | exiting froma plugin and then having a black lcd was a known issue, roght? |
| 20:55:17 | Luca_S | ssorgatem: yes |
| 20:55:40 | fml | linuxstb: ah, you mean the function "do nothing"! |
| 20:55:49 | ssorgatem | let's see what happens with usb |
| 20:56:13 | fml | linuxstb: hehe, we could add that function! |
| 20:56:20 | ssorgatem | if i can get into rockbox again |
| 20:56:31 | ssorgatem | it flickers, then loads OF |
| 20:56:54 | | Quit ender` (Ping timeout: 264 seconds) |
| 20:57:05 | funman | hum, i'm lost there |
| 20:57:31 | ssorgatem | ok |
| 20:57:42 | ssorgatem | if I hold the select button |
| 20:57:42 | funman | OF should only load if you press the center button |
| 20:57:50 | ssorgatem | until the rockbox menu |
| 20:57:56 | ssorgatem | it remains in rockbox |
| 20:58:12 | ssorgatem | OF loads if I do not press the center button |
| 20:58:28 | funman | ah sorry |
| 20:58:33 | kugel | gevaerts: quite a demanding job for a assessment task isn't it? |
| 20:58:49 | funman | so left button / USB detection works fine in rockbox, but not in dualboot, unless we messed the check for USB |
| 20:58:56 | ssorgatem | pluging it in the usb adapter does nothing |
| 20:59:05 | gevaerts | kugel: maybe :) |
| 20:59:22 | funman | ah ok, USB detection doesn't work either in rockbox |
| 21:00 |
| 21:01:18 | | Quit krazykit (Ping timeout: 252 seconds) |
| 21:03:55 | ssorgatem | mm, trying to launch doom gives an "undefined instruction" white screen, then loads OF |
| 21:04:04 | | Join krazykit [0] (~kkit@adsl-76-251-248-223.dsl.ipltin.sbcglobal.net) |
| 21:06:11 | funman | ssorgatem: did you see the status page ? |
| 21:06:23 | ssorgatem | funman: yes |
| 21:06:23 | funman | http://www.rockbox.org/wiki/SansaAMS#Specific_problems |
| 21:06:36 | *** | Saving seen data "./dancer.seen" |
| 21:06:49 | ssorgatem | funman: but should it load OF? |
| 21:07:30 | funman | when rockbox 'panics' it show a message on screen (could be the white screen instead if something bad happened), and reboot on keypress |
| 21:07:53 | funman | (not all models reboot on keypress though, but the fuze does) |
| 21:08:52 | | Quit esperegu (Read error: Connection reset by peer) |
| 21:09:37 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 21:12:08 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 21:19:21 | | Join esperegu [0] (~quassel@145.116.11.103) |
| 21:19:57 | esperegu | I get a 404 when trying to install voice. it seems that the date is not correctly formated: http://download.rockbox.org/daily/voices/iriverh120-2010-04-12-english.zip |
| 21:21:43 | esperegu | is there a way to manually fix that? |
| 21:22:49 | fml | JdGordon_: ping |
| 21:24:08 | CIA-5 | New commit by tomers (r25610): Text viewer: Remove unused max_line_len variable |
| 21:24:35 | | Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) |
| 21:24:48 | | Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) |
| 21:24:56 | linuxstb | esperegu: What do you mean? Are you using Rockbox Utility? |
| 21:25:29 | CIA-5 | New commit by tomers (r25611): Text viewer: Make calculation clearer |
| 21:26:28 | esperegu | linuxstb: yeah |
| 21:26:39 | esperegu | linuxstb: I think it has the wrong url |
| 21:26:59 | gevaerts | esperegu: which version of Rockbox Utility is that? |
| 21:27:09 | linuxstb | esperegu: I don't know about that, but to install that zip file, you simply unzip it to your device. It already contains the correct directory/folder structure. |
| 21:27:19 | | Join tomers_ [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 21:27:19 | esperegu | gevaerts: just downloaded it |
| 21:27:28 | esperegu | linuxstb: in the root. |
| 21:27:30 | gevaerts | ah, right... |
| 21:27:40 | esperegu | gevaerts: it should get it from http://download.rockbox.org/daily/voices/iriverh120-20100412-english.zip |
| 21:27:47 | linuxstb | esperegu: Yes. The zip should have ".rockbox" as the top-level directory, which is located in the root of your h120. |
| 21:27:54 | | Quit toffe82 (Read error: Connection reset by peer) |
| 21:27:57 | esperegu | but it tries http://download.rockbox.org/daily/voices/iriverh120-2010-04-12-english.zip |
| 21:28:08 | gevaerts | esperegu: 1.2.6 is ready to be released, but apparently it's not on the servers properly yet. That one should fix this issue |
| 21:28:43 | CIA-5 | New commit by tomers (r25612): Text viewer: Fix FS #11190 - Text Viewer shows no Text when skipping to last page |
| 21:29:19 | | Quit einhirn (Read error: Connection reset by peer) |
| 21:29:47 | esperegu | I really need voice since my screen is broken :-( |
| 21:29:49 | gevaerts | domonoky: can I update the RockboxUtility wiki page? It looks like 1.2.6 is on the download server |
| 21:30:04 | notlistening | funman did you see my post in the forums about the battery levels? |
| 21:30:07 | domonoky | yes |
| 21:30:42 | notlistening | on the clip+..? |
| 21:31:15 | funman | notlistening: yes, did you see my answers ? |
| 21:31:35 | notlistening | lol thats a no just take a peek |
| 21:31:41 | | Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
| 21:34:01 | notlistening | funman, the behaviour i saw was the OF shutting off when just trying to switch it on which seems weird? |
| 21:34:14 | notlistening | but i know you guys know your stuff |
| 21:35:32 | gevaerts | esperegu: the new download links are there now :) |
| 21:35:43 | | Quit Schmogel (Ping timeout: 240 seconds) |
| 21:36:27 | | Quit linuxstb (Ping timeout: 258 seconds) |
| 21:38:16 | funman | notlistening: the OF said it was discharged, and rockbox said the battery was full ? |
| 21:38:38 | funman | and no I don't know well this part, bertrik knows better than me |
| 21:38:59 | | Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) |
| 21:41:08 | notlistening | no they both reported low battery just rockbox seemed to just carry on and on and on and I got a bit worried about damaging the rechard curve of the battery by totally exhausting it |
| 21:41:33 | | Join Watermark [0] (~chatzilla@adsl-220-183-243.mob.bellsouth.net) |
| 21:42:39 | funman | did you check what % rockbox reported ? in the debug menu > battery screen |
| 21:42:40 | esperegu | hmmm.. there is already a voice file there. |
| 21:44:51 | esperegu | should I hear something after putting those files there? |
| 21:45:29 | notlistening | it was saying 0% but under rockbox info |
| 21:45:41 | notlistening | I will check next time it is running on thin air ;) |
| 21:47:11 | * | FlynDice admires new clip+4GB and waits patiently for it to charge up so he can begin the torture..... |
| 21:47:31 | esperegu | Ha! found it. was in the config file set to off |
| 21:47:37 | esperegu | manually changed the cfg file |
| 21:47:42 | notlistening | FlynDice good news bad news u had to get a new one :) :( |
| 21:48:46 | notlistening | FlynDice, did you try a full DD of the player one to the other? |
| 21:50:00 | FlynDice | I can only access a 4MB area so I don't think that's going to work... I'm open to trying something if you've got an idea though |
| 21:50:59 | wodz | amiconn: ping |
| 21:51:07 | | Quit bertrik (Read error: Connection reset by peer) |
| 21:53:31 | notlistening | do you think a full DD image of a working unit would include that 4MB space and does having the correct content in those 4MB give you a working clip? |
| 21:53:45 | notlistening | haha what do you have to loose now? |
| 21:54:05 | kugel | hrm, it doesn't seem as straight forward as I thought |
| 21:54:05 | * | gevaerts suspects not |
| 21:54:25 | esperegu | what is the best tts to use? |
| 21:55:38 | archivator | esperegu: what OS? |
| 21:55:41 | | Quit Strife89 (Quit: Clocking out.) |
| 21:55:45 | esperegu | archivator: linux |
| 21:55:51 | esperegu | archivator: kubuntu |
| 21:56:00 | | Part clauwn |
| 21:56:20 | archivator | esperegu: I usually go with festival and the cstr_us_jmk_arctic_multisyn voice |
| 21:56:27 | yorick | hmm would rockbox run on an X4-tech clipman? |
| 21:56:46 | archivator | It can be pretty slow, though. The nitech_us_* voices are all quite good, too. |
| 21:57:23 | esperegu | archivator: well. I could just let it run overnight |
| 21:57:49 | archivator | esperegu: not *that* slow (unless you have a 486) :) |
| 21:58:22 | esperegu | archivator: =) |
| 21:58:44 | esperegu | archivator: is that a config option? (cstr_us_jmk_arctic_multisyn) |
| 22:00 |
| 22:00:16 | FlynDice | notlistening: I'm trying your dd idea now I'm dumping the new clip+ to a file and I will dd that back onto the broken one. It can't make things any worse.... |
| 22:00:53 | | Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) |
| 22:01:15 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 22:02:06 | esperegu | archivator: how should I install that voice? |
| 22:02:28 | yorick | I love the thing...touching the aluminium case while it was connected to usb used to disrupt the connection and give you a shock <3 |
| 22:02:45 | yorick | display is OLED, and burns in after 15 minutes and broke down eventually :) |
| 22:03:45 | yorick | but it did hang around your neck conveniently with headphones built in to the cord |
| 22:07:12 | archivator | esperegu: well, it's not hard. You can get a bunch of extra voices here: http://www.festvox.org/packed/festival/latest/ |
| 22:07:33 | archivator | It's a matter of unpacking the folder in /usr/share/festival/lib/voices-multisyn (in Fedora) |
| 22:08:03 | archivator | However, I believe the Debian packages use a non-standard directory structure. |
| 22:08:11 | | Join linuxstb_ [0] (~linuxstb@rockbox/developer/linuxstb) |
| 22:09:02 | | Quit linuxstb (Ping timeout: 258 seconds) |
| 22:09:29 | | Nick linuxstb_ is now known as linuxstb (~linuxstb@rockbox/developer/linuxstb) |
| 22:10:27 | esperegu | archivator: what's the difference between cmu and cstr ? |
| 22:11:03 | * | gevaerts has this suspicion that festival voices aren't really on-topic here |
| 22:11:55 | archivator | gevaerts: but voice file building is! |
| 22:12:49 | | Join fml [0] (~53ecea55@giant.haxx.se) |
| 22:12:51 | esperegu | =) |
| 22:13:25 | fml | Buschel: Hello. Why is the '{}' needed in '0.5{}dB'? |
| 22:15:40 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 22:15:44 | fml | bluebrother: ah, that ^^ was originally written by you. So why? |
| 22:17:00 | Buschel | fml: I didn't want to change this as I wasn't sure about this, too. Seems to be obsolete. |
| 22:17:11 | FlynDice | notlistening: good idea but..... badabing no dice...... |
| 22:21:10 | | Quit yorick (Quit: Lost terminal) |
| 22:21:59 | | Join Schmogel [0] (~Miranda@p3EE22A45.dip0.t-ipconnect.de) |
| 22:26:44 | TheSeven | hmm |
| 22:27:00 | * | TheSeven always likes to fully understand the boot process of a device before tinkering with it |
| 22:27:20 | TheSeven | (including recovery mechanisms) |
| 22:27:52 | fml | What are all those files ending with a ~ in PD box? |
| 22:28:03 | | Quit Buschel (Ping timeout: 240 seconds) |
| 22:28:12 | fml | gevaerts: ^^? |
| 22:28:17 | | Join TillW [0] (~Till@h58-net09.simres.netcampus.ca) |
| 22:28:38 | | Quit fml (Quit: CGI:IRC) |
| 22:28:39 | gevaerts | fml: those handle waveforms. Blame the PD people |
| 22:28:45 | | Join fml [0] (~53ecea55@giant.haxx.se) |
| 22:29:04 | | Quit merbanan (Ping timeout: 265 seconds) |
| 22:29:35 | | Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) |
| 22:29:41 | | Join Xerion [0] (~xerion@84.25.7.202) |
| 22:31:28 | CIA-5 | New commit by alle (r25613): Remove confusing braces |
| 22:32:16 | | Join luistmw [0] (~luistmw@c-174-54-10-237.hsd1.pa.comcast.net) |
| 22:32:54 | | Quit fml (Client Quit) |
| 22:33:42 | luistmw | can someone help me |
| 22:33:58 | krazykit | luistmw, not if you don't ask a question |
| 22:34:07 | luistmw | sorry |
| 22:34:20 | luistmw | okay so i have an ipod nano 2g |
| 22:34:59 | luistmw | and i tried to uninstall rockbox but i only errased the .rockbox folder |
| 22:35:34 | krazykit | and so you still have the bootloader |
| 22:35:40 | luistmw | yes |
| 22:36:24 | luistmw | what can i do to put it back to normal |
| 22:36:52 | krazykit | does ipodpatcher not have an "uninstall" option? |
| 22:37:15 | luistmw | yes but my pc wont detect the ipod |
| 22:38:09 | archivator | luistmw: you'll need to enter disk mode |
| 22:38:42 | luistmw | back and select |
| 22:38:55 | luistmw | and after that? |
| 22:39:32 | archivator | connect to the PC, use ipodpatcher to delete the bootloader. |
| 22:39:39 | linuxstb | luistmw: back and select isn't disk mode... |
| 22:40:03 | archivator | There seems to be a −−delete-bootloader option but I'll let someone else confirm that it does what you need. |
| 22:40:28 | linuxstb | archivator: Yes, it does. It's also called "uninstall" if you run ipodpatcher without parameters.. |
| 22:40:53 | luistmw | ill try |
| 22:41:01 | luistmw | it |
| 22:41:11 | luistmw | be right back |
| 22:42:53 | | Quit esperegu (Remote host closed the connection) |
| 22:44:11 | Watermark | linuxstb you there? |
| 22:44:50 | | Quit merbanan (Ping timeout: 248 seconds) |
| 22:47:05 | | Quit {phoenix} (Remote host closed the connection) |
| 22:47:43 | | Quit ssorgatem (Remote host closed the connection) |
| 22:49:15 | | Quit bmbl (Quit: Bye!) |
| 22:50:17 | luistmw | how do i put it in diskmode |
| 22:50:50 | TheSeven | reset (menu+select) and then immediately select+play when it reboots |
| 22:51:12 | | Join b0hoon [0] (~quassel@xdsl-7253.bielsko.dialog.net.pl) |
| 22:51:36 | TheSeven | hm, we should add some "press any key to enter disk mode" thing in the bootloader's error handler, instead of just sitting there |
| 22:51:41 | luistmw | thank you |
| 22:52:11 | TheSeven | luistmw: another option would be just booting the apple firmware and uninstalling the bootloader from there |
| 22:52:21 | TheSeven | to do that, turn on the hold switch after resetting your ipod |
| 22:52:34 | luistmw | ok |
| 22:52:40 | b0hoon | Hi. Will it be a good proceder to commit a part of the manual without the plugin keymaps so far? For me it could ease syncing changes in SVN. |
| 22:52:52 | TheSeven | (during the apple-logo screen, before the bootloader comes up) |
| 22:53:53 | b0hoon | Or it will be better to commit the whole thing at the end? |
| 22:54:12 | Watermark | @linxuxstb, have you found a fix or other options to try to fix my COWON S9 with Tcctool? |
| 22:54:23 | gevaerts | b0hoon: I'd commit early and often |
| 22:54:40 | linuxstb | Watermark: No, I haven't looked. |
| 22:54:51 | Watermark | o ok just checking |
| 22:55:25 | Watermark | i had my S9 plugged in all night via UAB to charge the Batt. |
| 22:55:28 | b0hoon | allright, so no objections? |
| 22:55:30 | Watermark | USB* |
| 22:55:52 | | Quit archivator (Quit: Leaving) |
| 22:56:05 | linuxstb | Did you try what I suggested last night - holding the "on" button whilst uploading the fimware? |
| 22:56:34 | Watermark | yes, it still just disconnects when patching is complele |
| 22:56:53 | kugel | jhMikeS: ping |
| 22:57:31 | b0hoon | So /me backs to writing the manual... |
| 22:57:36 | b0hoon | ups. |
| 22:57:49 | b0hoon | :D |
| 23:00 |
| 23:01:18 | dfkt | Watermark, i wonder if the s9 can actually charge when its bricked, and/or when it's in recovery mode - or if that's a catch-22 |
| 23:01:43 | Watermark | idk really |
| 23:02:32 | | Quit pamaury (Quit: Page closed) |
| 23:02:55 | Watermark | i'm just why the device disconnects. could it be because of the Battery? |
| 23:02:58 | dfkt | telechips of course doesn't have the data sheet available online, just via some passworded login |
| 23:04:14 | linuxstb | Well, there's no proof (afaik) that tcctool will even work with the S9 at all - telechips may have changed things... |
| 23:04:55 | | Quit S_a_i_n_t (Ping timeout: 276 seconds) |
| 23:05:16 | luistmw | ok im back |
| 23:05:35 | luistmw | thanks to all of you who helpedme |
| 23:06:38 | * | domonoky reads the log and notes, that rbutil should also be able to uninstall a bootloader from any ipod. |
| 23:06:40 | *** | Saving seen data "./dancer.seen" |
| 23:06:43 | Watermark | true linuxstb. but what's the point of Recovery Mode then? |
| 23:07:23 | | Part luistmw |
| 23:07:36 | linuxstb | Well, it has the same purpose, it may just work differently. |
| 23:08:32 | Watermark | probably. Sighs* me stuck with a bricked S9 but not all that bad. could just get the COWON J3 when it comes out |
| 23:08:33 | linuxstb | But I would guess it's the same, and someone just needs to determing the value for SDCFG (the SDRAM configuration register) that's uploaded to the device as part of the header that tcctool adds to the firmware image. |
| 23:08:40 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:08:50 | linuxstb | s/determing/determine/ |
| 23:09:33 | Watermark | hey dfkt you think dalmane98 could help out? |
| 23:10:40 | Watermark | @linuxstb, how can we fin that Info. out? |
| 23:11:04 | linuxstb | Either guess, find it by disassembling the original firmware, or find a copy of the datasheet. |
| 23:11:37 | Watermark | how would we disassemle the FW? |
| 23:12:25 | | Part b0hoon ("GTG. Bye.") |
| 23:12:50 | linuxstb | Or in some cases, the value has been found because it's been documented somewhere. e.g. I think Cowon made the telechips "fwdn" tool available to help people unbrick some devices (maybe I6/I7), and the instructions for that included that value. |
| 23:13:09 | linuxstb | Or if the manufacture releases an official recovery tool, it can be found via a usb sniffer. |
| 23:15:13 | CIA-5 | New commit by tomers (r25614): Text viewer: Fix wrong calculation of bookmark's position (introduced by r25611) ... |
| 23:20:56 | | Quit bertrik (Ping timeout: 260 seconds) |
| 23:28:24 | | Quit tomers_ (Ping timeout: 260 seconds) |
| 23:29:44 | | Quit tvelocity (Quit: Αποχώρησε) |
| 23:31:05 | | Join yelped [0] (~62742090@giant.haxx.se) |
| 23:31:37 | yelped | Anyone have time to check this out? http://www.rockbox.org/tracker/task/11197 |
| 23:34:32 | Watermark | can it be any version of fwdn tool? |
| 23:34:42 | dfkt | Watermark, i don't think dalmane can help with that |
| 23:35:18 | Watermark | o nvm |
| 23:35:23 | Watermark | hmm... |
| 23:35:27 | dfkt | linuxstb, would it be possible finding the right value via trial & error? is it a base-2 value? |
| 23:39:57 | Watermark | what Value are we looking for again. me emailing COWON |
| 23:40:19 | | Quit notlistening (Remote host closed the connection) |
| 23:40:29 | funman | dfkt: 0x42e97010 0xa2e92010 0x62e97010 0x52e97410 0x62e92018 <- trial & error look a bit hard |
| 23:41:36 | TheSeven | funman: doesn't look too bad |
| 23:41:52 | TheSeven | i'd say around 50 tries and you're set |
| 23:42:11 | Watermark | what are those numbers? i'm a noob here Lol |
| 23:42:14 | TheSeven | those values aren't differing terribly much |
| 23:42:41 | TheSeven | from what i understood, these are values that have been seen for that SDCFG field |
| 23:42:42 | funman | common factors between 2 values: 2, 3 |
| 23:42:43 | * | linuxstb tries to find a description of that register... |
| 23:43:27 | Watermark | o |
| 23:43:38 | Watermark | well, i hope we can get this sorted out guys |
| 23:43:46 | Watermark | need all the help we can get |
| 23:44:16 | TheSeven | funman: 4 possibilities for the first digit, 2 for the fifth one, 2 for the eigth one |
| 23:44:55 | funman | oh that way there is much more common 'factors' |
| 23:45:51 | TheSeven | and if we get a basic understanding of that reg's contents, we can probably just go for some safe-slow-stupid values ;-) |
| 23:46:10 | Watermark | Lol... |
| 23:46:16 | | Join einhirn [0] (~Miranda@p5485A379.dip0.t-ipconnect.de) |
| 23:46:52 | | Quit anewuser (Quit: http://xrl.us/Renoise Like renoise + like music? 3 days to submit your entry!) |
| 23:47:06 | | Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) |
| 23:48:57 | funman | i was looking at the setting of SDRAM mode register in as3525 but it doesn't look similar (lower bits have no signification it seems) |
| 23:49:44 | Watermark | over at a Russian site i found something on the D2 for unbricking |
| 23:49:49 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:49:53 | Watermark | has some values |
| 23:49:58 | | Quit komputes (Remote host closed the connection) |
| 23:52:28 | dfkt | i have the FWDN version that is compatible with the d2, but that's probably no help for the s9... seeing as the d2 is supported by tcctool already |
| 23:52:56 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:52:59 | dfkt | fwdn for the d2 says Custom SDCFG=0xA2E92010 |
| 23:53:07 | Watermark | yeah |
| 23:53:20 | Watermark | how'd they get ahold of it? |
| 23:53:31 | dfkt | that would be good to know, indeed |
| 23:54:12 | Watermark | omg |
| 23:54:15 | Watermark | dfkt |
| 23:54:35 | dfkt | ? |
| 23:54:36 | Watermark | i have a great site. Google is your friend :) |
| 23:54:46 | Watermark | http://player.ru/showthread.php?t=50933 |
| 23:54:59 | Watermark | it's in Russian though |
| 23:55:28 | | Quit piotrekm (Quit: piotrekm) |
| 23:55:35 | Watermark | god detail for the S9 |
| 23:55:38 | Watermark | good* |
| 23:56:38 | dfkt | nothing that helps, as i see it |
| 23:56:46 | Watermark | o |
| 23:56:48 | Watermark | darn |
| 23:56:56 | Watermark | still though |
icon identifies that the person is a core developer (has commit access).