--- Log for 14.02.106 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 month and 0 days ago 00.00.09 Join ashridah [0] (i=ashridah@220-253-120-130.VIC.netspace.net.au) 00.00.10 # nad teel us if it fixed the battery issue 00.00.30 # wow you are the 100th guest here ashridah! 00.00.55 # 101 actually 00.01.01 # we r busy today :) 00.01.15 # hmm it is 100 fo me. 00.01.30 # ah 101 with the OP? 00.01.39 Mode "#rockbox -o Bagder " by Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) 00.01.45 # 101..nice concert.. 00.01.50 # you got me. 00.02.09 # then elinenbe was 100th... 00.02.17 # LinusN: is the min and max db value #defined sopmehwer for each target? 00.02.36 # * XavierGr wonders how elinenbe's name is spelled.... 00.02.59 Quit Henrico ("[BX] Bender uses gtkBitchX. Bite my shiny metal ass!") 00.03.12 # now we are 100 00.03.30 # close the #..we are full :o 00.03.35 # XavierGr: huh? 00.03.54 # e-l-i-n-e-n-b-e 00.03.56 Quit Rondom ("I'm leaving on a jetplane, don't know when I'll be back again...") 00.04.00 # JdGordon: firmware/sound.c 00.04.08 # ok 00.04.08 # first initial and then the first seven letters of my last name 00.04.30 # http://www.rockbox.org/twiki/bin/view/Main/IrcNicks 00.04.48 # I've been around here forever.... 00.04.49 # elinenbe: with all those "e" I am not sure which one is like the "e" in BED or like the "e" in ME 00.04.54 # so which is which? 00.05.21 # E Linenberg 00.05.25 # Eric 00.05.38 # ah that makes sense 00.05.40 # however you want to pronounce it is fine with me... 00.06.14 # febs name is nice ;-) 00.06.29 # michael? 00.06.42 # defebbo 00.06.46 # difebbo 00.06.47 # ;) 00.06.59 # Hi, does anyone now how I can scan and add replaygain tags to my mp3s on linux? 00.08.06 # I tried using normalize-audio which is in the Ubuntu repos, but it doesnt seem to write the tags so that rockbox understands them... 00.10.11 # what do you know - finally got it working. g'night. 00.10.12 Part Musicmad 00.11.17 # Zoric: you can use a program called mp3gain 00.11.19 # * muesli__ utters a tiny wish and hope somebody will hear it...1-minute-instead-of-15minutes-increases in sleeping time mode would rule... 00.11.37 # Mikachu: does that work on linux? 00.11.41 # sure 00.11.52 # it's one of those few programs that work on both linux and windows :) 00.12.15 # it actually modifies the mp3 file, so it should work with anything 00.12.27 # it is lossless 00.12.38 # but I want it to not modify the file, just add tags. But I guess it does that too 00.12.44 # found it the a repo :) 00.12.54 # it's the only one i know about anyway, and use 00.13.08 # If you have Wine installed, you can try foobar (or other Windows apps) 00.13.29 # I think people have asked here for such a tool in the past, but there doesn't seem to be one. 00.13.33 Join DJDD___ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) 00.14.09 # i've run into a utility called 'crip' that claims to do replaygain on mp3 files 00.14.15 # yeah, but I havnt really gotten around to installing wine, it seems quite difficult to get to work... and Im much to lazy to boot my windowsinstall :P 00.14.31 # but i don't know if it *has* to do them while ripping, it doesn't make it overly clear, and i haven't looked 00.14.33 # it works pretty much out of the box now 00.14.43 # febs name is nice wink 00.14.52 # ^^I wasn't very creative when coming up with a nickname. 00.14.58 # :) 00.15.00 # linuxstb, congrats and thanks for audio on 5g - made my day :) 00.15.10 # Zoric: "apt-get install wine" worked fine for me... 00.15.24 # so did i..i guess i was eating muesli when i chose it ;) 00.15.24 # (I'm running Debian unstable) 00.15.34 # Zoric: does your ubuntu repo have a utility called 'crip' in it? 00.15.50 # (might only be in debian) 00.15.53 # muesli: you can edit the cfg file 00.16.23 # so go open your favorite cgf file and locate the option. 00.16.31 # then change the value to that of your preference. 00.17.16 # comes from http://bach.dynet.com/crip/ if you can't find it 00.17.23 # which config? guess viewers.cfg its not 00.17.41 # save your config first 00.17.42 # no 00.17.48 # your configuration file 00.17.52 # ah ok 00.18.07 # which is generated when you save your settings 00.18.15 # ashridah: I've just downloaded crip - according to the man page, it normalises the audio, rather than calculating replaygain tags. 00.18.35 # darn, then the explanation i read wasn't particularly accurate 00.18.56 # it'll pass replaygain-enable flags on to ripping/encoding utilities by the looks of it 00.21.12 Join perldiver [0] (n=say@cpe-66-65-89-236.nyc.res.rr.com) 00.23.16 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) 00.23.37 # midkay: Do you have a 5g? 00.23.46 # mp3gain does not seem to be able to save the replaygain info in tags as foobar2000 does... or can it? 00.24.15 # linuxstb, yep 00.25.14 # mp3gain *can* save the tags without editing the files. At least in Win32, a GUI version of it I tried once did 00.25.34 # If you chose to just "scan" the files instead of scan and write (or something like that) it would put the tags on without modifying the actual frames at all 00.25.35 # Is there any way to tell if a ripped MP3 has the correct encoding for gapless? I'm getting 'almost gapless' at the moment, and I'm wondering whether it's Rockbox or the encoder that's to blame (I use lame.dll). 00.26.35 # did you use --nogap ? 00.26.52 # You can't use --nogap with a DLL. 00.27.09 # Paul_The_Nerd: aah, found it in the man-file now. Will try it. 00.28.21 # it only writes tag by default, and if you want it to modify the file you have to specify it ;) 00.28.53 # XavierGr mmh..cant find the value 00.29.55 # Besides, aren't recent LAMEs supposed to contain internal data about the size of the last frame. --nogap is a hack to split tracks on frame boundaries IIRC, which is something different. 00.30.09 # midkay: Have you tried the latest Rockbox builds? 00.30.23 # Cassandra i would use mpc for gapless trax to get rid of gap issues 00.30.27 # Cassandra: You could always try the files in a non-rockbox player that supports LAME gapless. 00.30.42 # linuxstb, i stayed a few minutes later than i should have this morning to compile for audio support.. was a build from about 9 hours ago early enough? :) 00.31.20 # If it has audio, then yes :) Have you tested many different files? 00.31.38 # LinusN: Need more H300 testers on USB problem or are you fine? 00.31.47 # Paul_The_Nerd, problem is some of them 'cheat', so I still wouldn't know for sure. 00.31.57 # i'm fine, but please try the latest bleeding edge 00.32.12 Quit DJDD___ (Read error: 104 (Connection reset by peer)) 00.32.52 # linuxstb, just MP3s.. i tried a 320kbit one and a 192k one.. both skipped once in a while, i checked the audio thread and it kept trying to refill but emptied too quickly. is everything working though? wav/ogg/flac? 00.33.00 # Hmm, the strange thing is, my H340 is clicking and my H360 not... *trytofigurewhy* 00.33.39 # muesli__, if I were going to re-encode, I'd probably go wavpack. 00.33.40 Quit t0mas ("see you all tomorrow") 00.34.00 # how large are those files? 00.34.30 # It's just I'm sure someone promised me that swcodec Rockbox would do 'proper gapless' at some point. 00.35.06 # Oddly to my ear it doesn't sound like there's any actual silence between tracks. 00.35.18 # Just that the transition is somehow 'jerky'. 00.35.45 # I'd just like to get to the bottom of whether its my encoding technque or Rockbox that's to blame. 00.36.31 # How "jerky" do you mean? 00.36.48 # Just like there's a tiny jolt in track transitions. 00.36.54 # It's *almost* not there. 00.37.05 # But you know how it is with *almost*. 00.37.46 # Is this on an iPod? 00.37.51 Join ts-x [0] (n=0cad6dbb@labb.contactor.se) 00.37.59 # midkay: Yes, every audio format works in theory - I've had no problems with FLAC, 224kbps Ogg, 128kbps and 192kbps (CBR) mp3. But some codecs do struggle at higher bitrates. 00.38.01 # Nope, this is H120. 00.38.02 # i had good gapless on my ipod with a flac album 00.38.13 # Not sure if I've got the same on iPod. 00.38.26 # at afaict 00.38.31 # at least* 00.38.31 # linuxstb, i should try again.. the 4-letter filenaming pisses me off though :) (side note: is there a way to build an id3 database on the 5g?) 00.38.43 # Cassandra: Another question: Are they replaygained? 00.38.48 # Mikachu, getting gapless right is strictly an MP3 problem. They didn't think that people might want gapless when designing the format. F***wits. 00.38.51 # linuxstb, please tell me next up is faster lcd driver ;) 00.39.02 # typical of germans 00.39.09 # Paul_The_Nerd, yes. But I use "album, track if shuffled". 00.39.26 # I figured, but y'know, doesn't hurt to ask. :) 00.39.35 Quit perl|bbq (Read error: 110 (Connection timed out)) 00.40.07 # You can't blame mp3 - it is simply an mpeg elementary stream. It was designed to be used inside a container - but no-one ever did... 00.41.18 # too technical for me, I'm afraid. But it seems to me assuming that music will be exactly a set number of 'frames' is a bad thing. 00.41.21 # Cassandra: Apparently lame 3.90 or later *should* add the gapless info to the LAME tag by default. 00.41.50 # Paul_The_Nerd, That's what I thought. 00.42.42 # Though I read that one person had problems with a "very slight hiccup" being added to the audio itself at the beginning of tracks 00.43.02 Join aegray_ [0] (n=aegray@vpn82-7e-92-4.near.uiuc.edu) 00.43.53 # I'm using LAME 3.96 DLL 1.32 apparently. 00.44.08 # using x-fade kills excellent gaps either 00.44.31 # It was a program called ALL2LAME using 3.97b2 that did it for this person, but that doesn't mean the glitch couldn't happen elsewhere. 00.44.35 # there's crossfade on shuffle only 00.44.39 # muesli__, but I don't want my tracks run into one another. 00.44.56 # right, i misread that sentence 00.45.06 # nah, it sounds gapless. u wont notice it 00.45.25 # set all delays to 0 and fade in/out to 1-2secs 00.45.27 # try it 00.45.49 # I might do if there's no better way to solve it. 00.46.03 # But I'd rather get it working right than work around it, if possible. 00.46.29 # just give it a try..doesnt cost a cent. but in general ur right ;) 00.46.37 # Cassandra: You may want to try the songs in an external program or two anyway, just to see if it's something the cheating can solve or not. 00.47.26 # Winamp ought to work, right? (I'm using the Japanese MP3 codec that supports ReplayGain.) 00.48.38 # I have no clue, honestly. 00.48.39 # emupiisurii 00.49.23 # Cassandra: foobar should give you perfect gapless - that's the reference preglow used. 00.49.45 Quit Moos ("Glory to Rockbox!") 00.49.55 # OK - will try foobar. 00.49.57 Join Moos [0] (i=DrMoos@m53.net81-66-159.noos.fr) 00.52.18 # Right. It's not Rockboxes fault, I can hear it in foobar too. 00.52.28 # Very slight though. 00.55.27 Part LinusN 00.57.03 # radio is MHz or KHz? 00.57.09 # very strange... 4g grayscale is back to having the inverted Apple firmware display! 00.57.13 Quit xmixahlx ("blah blah blah") 00.57.23 # JdGordon: depends, is it fm or am? 00.57.30 # fm 00.57.36 # Cassandra: there is no such thing as perfect gapless with mp3 00.57.46 # pretty much 00.57.52 # LAME does it pretty much perfect 00.58.03 # preglow: Bah. I want my money back. 00.58.14 # you may get the same artifacts with vorbis as well 00.58.17 # but it's far less likely 00.58.33 # What about wavpack? 00.58.35 # it _is_ gapless, but there are phase discontinuities in the transition 00.58.38 # wavpack is losless 00.58.40 # lossless 00.58.46 # so that has perfect gapless support 00.58.56 # Erm, it's either, isn't it? 00.59.05 # well, yeah 00.59.13 # but the lossy mode is pure quantisation based, i think 00.59.29 # so it'll still be very nicely gapless 00.59.50 # * Cassandra looks like I need to re-rip then. 00.59.52 # You can get perfect gapless mp3 if you simply encode as a long file and split on frame boundaries. 01.00.02 # * Cassandra stares at her 300 odd CDs. 01.00.02 # Eww. 01.00.17 # That's always seemed a more sensible approach than hacks like lame headers. 01.00.23 # linuxstb, yeah, I did that for The Wall and Tubular Bells. 01.00.27 # Kind of fiddly though. 01.00.28 # if ogg works better, why not use that? 01.00.38 # linuxstb: well, as long as you're willing to give up on exact rips 01.00.45 # linuxstb: the track transitions will be all over the place 01.00.56 # i just fuck it and use a proper format instead 01.00.56 # Mikachu, because wavpack has some neat features and, it appears, works better than ogg. 01.01.00 # mp3 should be allowed to die 01.01.19 # * Cassandra uses MP3 for hysterical raisins. 01.01.39 # preglow: Can you notice if a transition is a few hundred samples out? It's already been moved artificially to a CD sector boundary. 01.01.39 Quit Zoide777 ("CGI:IRC (EOF)") 01.01.48 # When I can fit 500 albums on a jukebox losslessly, then I'll happily use lossless. 01.02.01 # But I think that requries a 160GB disk. 01.02.04 # ogg isn't lossless... 01.02.14 # linuxstb: not usually, no, but i'd still not like to work around a formats shortcomings like that 01.02.34 # How many samples in a 44.1KHz mp3 frame? 01.02.38 # 1152 01.02.39 # linuxstb, you can definitely hear the oddness when playing tracks that have been encoded like that on random. 01.02.46 # on random, yes 01.02.47 # indeed 01.03.31 # I'm mainly thinking of live albums - where even a second won't make much difference to the transition. 01.03.40 Quit ender` (" Who is General Error, and why is he reading my hard drive?") 01.03.45 # Gods my PCs speakers suck. I must replace them but it's not worth doing before I move. 01.03.47 # But if you have tracks like that, then I agree with preglow, use a better format. 01.03.53 # if it's a transition anyway, does the exact cut point really matter? 01.04.08 # not much 01.04.20 # Mikachu, sometimes, yeah. 01.04.22 # it's more for the tracks without transitions as such 01.04.44 # Two tracks may segue and still have a distinct join. 01.04.46 # getting the first 500 samples of the start of the next track is nice when that track is not the next one 01.04.55 # A lot of Mike Oldfield stuff, for example. 01.04.59 # sweet jesus, i'm tired 01.05.29 # beh 01.05.32 # bed time, then 01.05.41 # preglow or linuxstb you still here? 01.05.44 # barely 01.05.46 # Take care preglow, and thanks for the info on gapless. 01.05.51 # you happen to have that pcf spec? 01.05.58 # which? 01.05.59 # It's in our wiki. 01.06.02 # it's in the wiki 01.06.03 # ah k 01.06.03 # thanks 01.06.06 # It's the same as the pcf50606 01.06.08 # * aegray_ lost everything 01.06.10 # yep 01.06.37 # http://www.rockbox.org/twiki/pub/Main/DataSheets/pcf50606.pdf 01.06.46 Join webguest17 [0] (n=800c5ab5@labb.contactor.se) 01.06.51 # Dammit, I wonder how long Logitech are going to take to come out with a wireless version of the Z-5500. 01.07.34 Part Zoric 01.07.38 # thanks :) 01.08.32 # wireless piece of shit 01.08.34 # i hates hit 01.08.35 # it 01.08.38 # did anyone else try the latest 4g grayscale build? the original Apple firmware shows up upside down again 01.09.05 # cool 01.09.23 # webguest17: Do you like that feature? 01.09.25 # I think we'll call that a 'feature'. ;) 01.09.28 # :) 01.10.37 # * Cassandra is getting increasingly tempted by an iPod Video. Does the battery life really blow? 01.10.38 # hehe 01.10.38 # webguest17: If you would prefer to keep the apple firmware the right way up, try this bootloader: http://www.davechapman.f2s.com/rockbox/bootloader-4gtest1.bin 01.10.58 Nick webguest17 is now known as Zoide777 (n=800c5ab5@labb.contactor.se) 01.11.07 # just turn your ipod over when you boot 01.11.17 # haha 01.11.21 # thanks linuxstb 01.11.22 # http://www.clubic.com/article-30765-1-z-5450-et-logitech-perd-le-fil.html 01.11.23 # Cass 01.11.25 *** Saving seen data "./dancer.seen" 01.11.28 # there is 01.11.37 # Cassandra: compared to the nano it seems to blow, yea 01.11.41 # except you replace the wires by electricity 01.11.44 # so.. 01.11.46 # uselee 01.11.47 # ss 01.12.02 # The subwoofer on that isn't as good, apparently, 01.12.03 # what really impresses me right now is how much *faster* rockbox boots 01.12.05 # Cassandra: They are extremely nice (especially the slimline 30GB in black). But I've never done any tests for battery life. 01.12.09 # compared to one or 2 days ago 01.12.18 # i'd say 3x faster at least 01.12.22 # And if I'm going to pay that much for speakers, I'd like to have them as good as possible. 01.12.35 # linuxstb, I'd be getting a 60gb one. 01.12.35 # i have a z-680 01.12.40 # i'm fine so far 01.12.41 # Zoide777: Nothing has changed - did you switch to a different WPS? 01.12.42 # linuxstb: can you see any way out of the ui sluggishness issue, or are we just going to have to go two cores soon? 01.12.47 # Already over 40gb on the iRiver. 01.12.57 # Cassandra: Nice - you can write the code to handle the fact that it has 64MB of RAM.... 01.13.08 # (using runtime detection...) 01.13.21 # can't do that 01.13.24 Join Bg3r [0] (n=Bager@87.246.10.17) 01.13.27 # preglow: Can so 01.13.29 # we'd need to move the plugins and codec load address first 01.13.50 # Yes - just put them at the start of RAM, not the end. 01.14.01 # i think amiconn said that wasn't trivial 01.14.05 # linuxstb: i *was* playing around with wps's yesterday, but i guess it's hard to pinpoint what made the difference. I think it was after compiling & uploading the latest cvs bootloader and then overwriting all the rockbox stuff in the ipod with the latest rockbox.zip build 01.14.13 # So the 60gb has more RAM than the 30. Weird. 01.14.18 # And unhelpful of Apple. 01.14.28 # They aren't making our lives easy, are they? 01.14.58 # swine 01.15.09 # It's not too bad - the worse that will happen is we will need separate builds. 01.15.15 # Although might be best just to cut the Gordian not and have an ipodvideo30 and ipodvideo60 builds. 01.15.15 Quit Febs ("CGI:IRC (EOF)") 01.15.24 # knot even. 01.15.25 # what file controls the scrollwheel? I'd like to see if I can change it so that it accelerates after a while in the song list 01.15.27 # nah 01.15.33 # the runtime detection thing should be fairly simple 01.15.36 # it takes too long right now w/ linear speed 01.15.40 # better one build than two 01.15.50 # preglow, in theory I agree with you. 01.15.53 # Zoide777: firmware/drivers/button.c 01.16.00 # In practice, I'm not sure I want to write it. 01.16.00 # I wonder if the pcm code could simply have a "hole" in the ringbuffer. 01.16.03 # Zoide777: firmware/drivers/button.c 01.16.08 Quit aegray_ (Connection reset by peer) 01.16.09 # thanks 01.16.17 # linuxstb, I love it when you talk dirty. 01.16.29 # Zoide777: but i'm not convinced that's the way to go 01.16.36 # preglow: why? 01.16.41 # Zoide777: the acceleration part should be in the list viewer, not the button driver 01.16.43 # linuxstb: I had thought of that in order to be able to resize it 01.16.47 # ah, ok 01.16.49 # Apple claim up to 20hrs battery life on the 60gb model, 01.16.49 # that makes sense 01.16.51 # linuxstb: would introduce a ton of extra logic 01.16.54 # Zoide777: because for every menu item you'd want to move, one event would have to be dispatched 01.16.54 # Which I assume means about 15. 01.16.57 # well not a ton, but a lot 01.17.01 # lostlogic: so a bad plan? 01.17.02 # Zoide777: and the list viewer redraws for each event 01.17.09 Quit andy_ () 01.17.32 # linuxstb: I'm sure it could be done... might have to go back to statically sized buffer chunks to make it really feasible though 01.17.36 # i changed that delta to 10, it's impossible to control things with 4 01.17.36 # hole in the ringbuffer = bad plan 01.17.40 # don't even consider it 01.17.42 # hah 01.17.48 # preglow: the whole screen? wouldn't it be cheaper to just redraw the items that are changing? 01.18.13 # Zoide777: well, that's probably what it's doing, but that alone is more than slow enough that you can't make it scroll as fast as you want just because each keypress will take too long to handle 01.18.28 # Zoide777: so for acceleration to work properly, you'll have to hack the list viewer to skip several entires at once 01.19.03 # or if you use the two 150mhz cores, you can make it scroll smoothly the whole way with motion blur 01.19.04 # Zoide777: and god knows how that is to happen with the current clickwheel interface. the list viewer doesn't know how fast it's scrolled, it just takes scroll events and treats them pretty much like if it was a button pres 01.19.16 Join aegray_ [0] (n=aegray@vpn82-7e-93-2e.near.uiuc.edu) 01.19.17 # Mikachu: and phong shading 01.19.20 # preglow: i guess that wouldn't be too bad in terms of functionality... if it waits for a certain time, then starts skipping entries so you can get, say, to the letter P. then it stops skipping lines after you stop moving the wheel 01.19.27 Quit imphasing (Remote closed the connection) 01.19.29 # haha, yes, definitely phong shading 01.19.34 # preglow: hmm... i guess its not that simple then 01.19.58 # Zoide777: no it's not, i've thought about it myself, and it basically boils down to that everything that requires acceleration needs some kind of special interface for the clickwheel 01.20.08 # Zoide777: we can't just pretend it's a set of buttons anymore 01.20.34 # if can imagine clickwheel handling is already very slow on video ipods thanks to this 01.20.48 # s/if/i/ 01.20.52 # hey, is it better to reuse tags in the wps for radio specific items? or make new tags? 01.21.40 # preglow: could there just be some timer that waits, say 3 seconds and then makes the scroll events translate into 3 line skips? and then another timer that waits for inactivity for about half a second to restore it to normal 01.22.46 # preglow: it wouldn't really measure how fast you're sliding your finger on the wheel, but it could help 01.23.10 # JdGordon: It seems to me, at least, that the radio should use its own entirely separate WPS anyway since the data's pretty drastically different from Track/Artist/Album info. 01.23.28 # Zoide777: any solution that doesn't involve the event torrent the click wheel generates now is acceptable 01.23.41 # ye, but its working now with unmodified wps files.. so if i reuse tags it makes life easier... 01.23.54 # Zoide777: it's just a matter of making it as non-intrusive to the rest of rockbox as possible 01.24.11 # although, i have added a new tag to check if its the radios creen or not... so adding new tags wouldnt be _much_ hassle.. 01.24.20 # if we port to h10, we're going to have this problem all over again, so might as well start prepare for some other control mechanisms than buttons 01.24.20 # preglow: i guess it would have to be yet another menu option, hehe.. 01.25.28 # JdGordon: Does it use the existing WPS though, or does it have a separate WPS for the radio screen? 01.25.36 # exisintg 1 01.25.37 # but yeah, i believe the best thing to do is probably to add another button event which just indicates clickwheel movement 01.25.46 # then have another function where you can interact more closely with the clickwheel 01.26.07 Join imphasing [0] (n=imphasin@c-69-250-93-218.hsd1.dc.comcast.net) 01.26.34 # so that every screen can decide how to handle the clickwheel: either like it is two buttons, like now, or like it is the continuous surface it is 01.26.35 # Ick. I personally don't like that idea, but that's just me. Since a lot of the images for a normal WPS won't be used at all in a Radio WPS. Neither will the backdrop image fit the information as well in a lot of cases. Just my thoughts though. 01.26.53 # linuxstb: comment? 01.26.56 # preglow: that sounds reasonable. I honestly don't know much at all right now about how rockbox is working under the hood, but it seems pretty crazy to try to make it homogeneous now that there are so many different targets 01.27.03 # Could the scroll event have a value - i.e. how many clicks it has moved since the last event? 01.27.24 # it would be a hack 01.27.27 # But there are two variable - time and distance we need to take care of... 01.27.28 Join Thus0_ [0] (n=Thus0@154.111.102-84.rev.gaoland.net) 01.27.33 # the button event is a 32 bit bit field 01.27.39 Join tvelocity [0] (n=tony@ipa175.2.tellas.gr) 01.28.11 # there's also another issue 01.28.22 # in order to not just have the same old problem again where we fire away zillions of events 01.28.32 # the button driver would need to start skipping some of those events 01.28.45 # My original thoughts were to have different scroll events - something like SCROLL_FWD, SCROLL_FWD_FAST and SCROLL_FWD_FASTER 01.28.49 # and send them more seldom, so that the clickwheel position delta can grow a bit before the events are sent 01.28.52 Quit Thus0_ (Client Quit) 01.29.00 # linuxstb: that might work 01.29.09 # Paul_The_Nerd: i disagree... besides. it was easier this way :D 01.29.11 # we would not need many degrees 01.29.14 # So for example, SCROLL_FWD_FASTER would page-down in the list viewer 01.29.21 # you guys know about i2c interrupts? 01.29.27 # aegray_: a little 01.29.41 # how do you tell which device the interrupt came from? 01.29.49 # do you just poll interrupt status flags on all devices? 01.29.59 # hmm 01.30.02 # or maybe the wheel sends an initial signal to a listener on the driver, and then the driver polls the wheel every so often until it somehow decides it's stopped? 01.30.12 # * aegray_ wants the pcf to interrupt on low bat 01.30.36 # Zoide777: that is what happens now, problem is still that the button driver needs to decide how often to send events 01.30.44 # JdGordon: Well, at the *very* least it'll need its own tags. That way, at least, all the conditional images for normal use won't show up, and if someone doesn't show anything but say Track Name, they can still have a functioning Radio 01.30.48 # Zoide777: the clickwheel is very sensitive, tons of events are sent just at a stroke of the clickwheel 01.31.09 # erm i'lll ask agai later 01.31.10 # g2g 01.31.25 # it makes no sense for the list viewer to decide how often to poll, in the case of buttons, it wants to poll as often as it can 01.31.30 # the clickwheel is a special case 01.31.39 Quit aegray_ ("leaving") 01.32.52 Quit Moos ("Glory to Rockbox!") 01.32.59 # but it's hard to stay awake 01.33.00 Quit Zoide777 ("CGI:IRC (EOF)") 01.33.01 Join webguest17 [0] (n=800c5ab5@labb.contactor.se) 01.33.01 # i need to sleep 01.33.16 # see you in a couple of days 01.33.18 # *poof* 01.33.19 # preglow: k, get some rest. thanks for the help 01.33.35 Nick webguest17 is now known as Zoide777 (n=800c5ab5@labb.contactor.se) 01.43.56 Quit Thus0 (Read error: 110 (Connection timed out)) 01.45.08 Join Cassandra- [0] (i=Cassandr@elmyra.coraline.org) 01.45.27 Quit actionshrimp (Read error: 104 (Connection reset by peer)) 01.46.38 # h300 users... http://forums.rockbox.org/index.php?topic=2643.0 01.47.06 # for the song list display, is that just within list.c or is list.c called by something else like filetree.c, etc? I'm trying to find the code that deals with the scrollwheel like we were talking about a while ago 01.47.58 # JdGordon any try to merge the 2 patches? 01.53.33 Join aegray_ [0] (n=aegray@vpn82-7e-92-80.near.uiuc.edu) 01.53.53 # linuxstb: weird -thesame code is working for me and not for others on 5g :( 01.57.41 Quit matsl ("Leaving") 02.00.25 Join CrookedRain [0] (i=crookdra@SY-16-147.resnet.ucsb.edu) 02.05.23 # aegray: That's because everyone else is incompetent 02.05.46 # haha 02.07.40 Quit TCK (Read error: 110 (Connection timed out)) 02.11.07 # linuxstb: Hey! 02.11.24 # aegray_: pop, SEEKED!, dma not active, illegal instruction 02.11.31 # damnit 02.11.36 # why does it work for mine 02.11.42 # AGHHHHHHH 02.12.59 Quit midkay ("Leaving") 02.14.57 Quit Cassandra (Read error: 110 (Connection timed out)) 02.14.57 Nick Cassandra- is now known as Cassandra (i=Cassandr@elmyra.coraline.org) 02.21.06 Quit JdGordon (Read error: 104 (Connection reset by peer)) 02.21.20 Join JdGordon [0] (n=Miranda@c220-239-137-122.smelb1.vic.optusnet.com.au) 02.26.06 Quit elinenbe (Read error: 104 (Connection reset by peer)) 02.26.13 # linuxstb: what is this about upsidedown 4g gray? 02.27.01 # It means that Satan pwns your iPod. 02.28.07 # jaebird: Some people are still having problems with the apple firmware's display being wrong. 02.28.33 # hmm...i'll do a cvs latest again and see... 02.31.01 # how often should we update the bootloader...i mean it is the rockbox that is changing right? what differences does the bootloader make if it boots? 02.32.08 # jaebird: No difference - there is no reason to upgrade until something significant changes. The h1x0 has only had about 5 bootloader releases in the last year. 02.32.35 # that is what i figured... 02.33.25 # linuxstb: what are page up and page down in list.c? in the 4g, is that how moving the wheel a lot is translated right now? 02.35.10 # also, what does #ifdef HAVE_LCD_BITMAP stand for? don't all the targets have LCDs that use bitmaps? 02.35.54 # Not the Archos Player 02.36.06 # ah, ok 02.37.33 Join TCK [0] (n=tckocr@81-178-240-68.dsl.pipex.com) 02.38.50 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 02.38.58 Quit aegray_ ("Lost terminal") 02.39.16 Quit muesli__ (Read error: 110 (Connection timed out)) 02.40.12 # linuxstb: what are page up and page down in list.c? in the 4g, is that how larger wheel movements are interpreted right now? 02.40.16 Quit linuxstb (Nick collision from services.) 02.40.29 Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 02.40.58 # Zoide777: Look in list.h for the button mappings. 02.41.26 # I did most of the button mappings about 3 months ago without giving them much thought - so feel free to suggest better. 02.41.52 # Looks like PGUP and PGDN are not defined for the ipods. 02.42.04 # oh, no wonder! i hadn't thought of looking at the .h, silly me. of course i was never going to understand what was going one 02.42.38 # There are about 4 or 5 different .h files under apps/ that define how the various parts of Rockbox handle buttons. 02.42.58 # ok, thanks for the info 02.43.32 Join aegray_ [0] (n=aegray@vpn82-7e-93-34.near.uiuc.edu) 02.43.32 # wow, and there's even comments in the .h! looking at the .c by itself was kind of depressing :D 02.44.28 Quit Nilisco ("changing servers") 02.44.37 Join Nilisco [0] (i=nilisco@wrath.shellfx.net) 02.53.06 Join damaki__ [0] (n=Chocolat@ALille-153-1-66-77.w86-196.abo.wanadoo.fr) 02.57.18 # linuxstb: ahhhh... i have an idea. it turns out page up/down makes the selection move by pages as opposed to item by item. for the ipod, I'm going to try to have a counter keep track of how many items have been scrolled in the current screen. so when the number goes above, say, 50, it clearly means you're trying to scroll down a big list, so we will treat the wheel as pg up/down instead of the ordinary up/down. then when the user clicks on Play 02.57.44 # (it's more a patch than a fix, of course, but it might be useful in the meantime) 02.57.54 # gotta shower though, brb 02.57.59 # Zoide777: So, what happens if they start paging down, get to the 407th entry, and need #408? 02.58.12 # oh shit 02.58.13 # hehe 02.58.25 # i forgot, i had thought of a timer for stopping 02.58.30 # but that's not easy, right.. 02.58.37 # at least not as easy as the simple counter 02.58.56 # oh, now i remember 03.00.23 # so when you get to #407, you simply scroll *up*, which disables the pg up/down scrolling. the idea is that it would would do the fast scrolling to get down to some region of the playlist, and from there you can just nudge it up and have low sensitivity up & down until you scroll a large number of lines again 03.00.28 # Zoide777: The button driver in firmware/drivers/button.c receives an interrupt for every click the wheel is turned. It then sends a scroll event every 4 (I think) clicks - but only if the button queue is empty. 03.00.30 # (downward, say) 03.01.04 # linuxstb: so what does that mean? 03.01.18 # linuxstb: there's a current bug with Hold 03.01.19 # What you could do is keep track of the number of clicks since the last button event was sent, and if this is more than a certain number, send a new event, e.g. BUTTON_SCROLL_FWD_PAGE 03.01.38 # And then map that to page down in list.h 03.01.41 # linuxstb: If you turn hold on then off, until it scrolls (volume changes + or - 1) button presses don't do anything 03.02.16 Quit dpassen1 (Read error: 110 (Connection timed out)) 03.02.31 # linuxstb: that sounds great. would i do that in gui_synclist_do_button? 03.02.51 # That was introduced, as far as I can tell, when the code not to queue scroll events when busy was added. 03.03.36 # Paul_The_Nerd: so does that mean that the click counting would not always be reliable? 03.04.46 #