--- Log for 16.04.105 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 24 days and 8 hours ago 00.01.02 # can you freeze the core externally? 00.01.20 # yes and no 00.01.24 # by external means, more like 00.01.30 # Right.. I'll try and sleep some more.. goodnight 00.01.36 # rasher: more? 00.01.36 Quit rasher ("CGI:IRC 0.5.4 (2004/01/29)") 00.01.39 # haha 00.01.42 # i don't think you can freeze the iriver 00.01.45 # externally 00.02.07 # well, what ways of freezing the core is there? does halting it count? 00.03.14 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 00.03.19 # the key is the TA signal 00.03.28 # Transfer Acknowledge 00.04.11 # if you set up the Chip Select controller to terminate accesses with TA, the CPU will wait for TA forever 00.05.33 # Hey guys, I grabbed cvs again, and it suddenly refuses building midi2wav.c. It's in SOURCES but it's as if it ignores the source file completely 00.06.32 # stevenm: you had a compiler error 00.06.35 # привет, stevenm 00.06.36 # LinusN: like that is the problem here, or that's the way to hang it externally? 00.06.39 # hi all :) 00.06.46 # preglow: a way to hang it 00.06.56 # Bagder, yes, someone fixed that, now I went back to fix it and saw it was already fixed. Tried rebuilding, and it just ignores it 00.07.47 # stevenm: the dependencies of single rocks aren't the best 00.08.05 # Bagder, what do you mean? 00.08.15 # midi2wav.c builds fine here 00.08.22 # stevenm: you haven't set up the deps well yet, i'd wager 00.08.23 # stevenm: make clean 00.08.28 # stevenm: midi2wav.rock doesn't get rebuilt when you modify code in midi/ 00.08.34 # stevenm: you need to have all plugins depend on the midi codec 00.08.56 # Ah, that would explain SOME of the weirdness 00.08.58 # that's the way it's done for the rest of the xxx2wav guys 00.09.21 # midi2wav.c has all the stuff in /midi #included so it is as if it is one huge c file. 00.09.29 # preglow, how do I make it depend ? 00.09.53 # Hiya LinusN 00.09.53 # I tried removing everything, then checking out everything again, then making a new build directory and building. It just skips right over that file 00.10.24 # ahaha, included 00.10.27 # elegant :) 00.10.34 # well, i have no idea 00.10.54 # Rick: hi 00.11.18 # stevenm: you simply do not include C files 00.11.22 # stevenm: you should probably move the midi stuff into a midi codec directory? 00.11.28 # that is badness 00.11.48 # preglow: can i link libdumb with -m to make floats work? 00.11.58 # if so, i'll be able to work on mod2wav 00.12.53 # first one guy #includes .c files, and now you want floats 00.12.57 # am i in hell? 00.13.00 # HCl: try 00.13.01 # preglow, how do you set up deps, other than putting it in the MASNONE section of SOURCES ? 00.13.17 # stevenm: there is no deps in SOURCES 00.13.22 # deps are in the makefiles 00.13.41 # Bagder, ah.... so what would I do? 00.13.44 # if you mean build dependencies 00.13.47 # LinusN: don't worry, it's temporary, just so i can verify that stuff works when i int-ify it 00.13.57 # stevenm: to make what happen? 00.14.18 # Bagder, I want it to build midi2wav.c with the rest of the iriver plugins 00.14.25 # it does for me 00.14.30 # or when HCl int-ifyes it :) 00.14.30 # floating point should work without -m 00.14.37 # Bagder, really? This is strange 00.14.38 # LinusN: yeah, but it uses log, floor, etc 00.14.43 # bleh 00.14.59 # we don't have a math library 00.15.01 # i don't even know if it'll work 00.15.40 # stevenm: all files in the plugins dir build exactly the same 00.15.45 # i don't even know of libm supports emulated floating point 00.15.52 # of=if 00.15.53 # stevenm: there's nothing special with midi2wav.c 00.16.10 # Bagder, that's what I figured.. I mean, putting it in SOURCES worked before.. 00.16.31 # stevenm: it still does, it seems you have something odd in your end 00.16.43 # Bagder, but now it just suddenly glosses over that one file. It is probably something on my end then 00.17.51 Quit stevenm ("Leaving") 00.18.30 # preglow: we don't have libm 00.18.46 # i thought that was a gcc thing 00.18.50 # no 00.18.55 # aight 00.19.05 # then we'll need some other plan 00.19.38 # HCl: how about learning yourself fixed point math? :) 00.20.28 Join stevenm [0] (~steve@stevenm-router.student.umd.edu) 00.22.36 Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) 00.22.59 # no thanks :) 00.23.02 # * t0mas points HCl at this one: http://members.aol.com/form1/fixed.htm 00.23.16 # Oookay there it goes 00.23.51 # that was some starnge PC voodoo 00.24.03 # um 00.24.04 # right. 00.24.10 # okay, that doesn't look too hard 00.24.15 # it really is quite simple and useful, and frees me from having to do it :) 00.24.16 # can't say i understand it though. 00.24.48 # maybe I can try to help you? 00.24.49 # lower 8 bits are behind the point? 00.24.55 # yes 00.24.59 # and they're simply stored in normal int format? 00.25.05 # long 00.25.09 # well, i mean. 00.25.15 # the lower 8 bits go from 1-255 00.25.23 # 255 being .FF 00.25.28 # ? 00.25.43 # yes 00.25.46 # 0-255 00.25.48 # so? 00.25.51 # preglow: yea, sorry. 00.25.55 # okay, just wondering 00.26.06 # i was taught a different fixed point format in class, i think, but that was a while ago 00.26.30 # you use as many fractional bits as you need 00.26.38 # in the case of the emac unit, you use all bits as fractional bits 00.26.40 # i don't quite understand how shifting is gonna trash them compared to *256 00.26.48 Quit thegeek (Read error: 54 (Connection reset by peer)) 00.26.55 # ohh. right. 00.26.59 # they were talking about floats. 00.27.03 # ok nm 00.27.11 # easy as 3.141... 00.27.12 # afaik you just can't shift a float? 00.27.21 # sure, i can do that. 00.27.28 # but not today 00.27.30 # and not tomorrow. 00.27.33 # ghehe 00.27.45 # cause i need sleep, and i have a mini anime convention tomorrow 00.28.35 # fixed point itself is rather trivial, the harder part will likely be the implementation of functions like pow() etc 00.28.57 # * t0mas is going to sleep too :) 00.29.04 # In fact, fixed point math is already used in quite a number of places in rockbox 00.29.06 # amiconn: indeed 00.29.10 # nite t0mas 00.29.13 # tnx 00.29.14 # lookup tables... 00.29.14 # heh 00.29.21 Quit t0mas ("bye") 00.29.47 # amiconn, isn't there some sort of taylor series for pow ? 00.30.32 # not for the general case, i think 00.30.45 # you can make taylor series for well nigh everything, though 00.30.55 # Examples for fixed point in rockbox: mandelbrot.rock, cube.rock, the stereo width stuff for the mas... 00.31.31 # but yeah, taylor series will of course be used wherever they can 00.31.53 # Stereo width for mas uses the internal mas format which just happens to be a fixed point format as well 00.32.03 # not very surprising 00.32.11 # really 00.32.23 # very few float dsps around 00.32.26 # 1 bit sign, 19 bit fraction 00.32.45 # one of the two formats of the coldfire is 1 bit sign, 31 bits fraction 00.33.16 # of course, you can use whatever you like, but that's what it'll be treated like 00.33.55 # cube.rock uses a somewhat more cpu intensive way as it does not bit-shift, but divide by a power of 10 (10000 iirc) 00.34.53 # ahh, non power of two fixed point? 00.35.02 # I'll most likely change that if I ever get around implementing my idea of a double buffered greyscale library and backport greyscale cube from ipodlinux 00.35.08 # can't see the point of doing that 00.35.46 # Me neither, but that is how it is implemented 00.35.51 # you can make a grayscale cube for iriver already :) 00.35.51 Join DjMnG [0] (~Hot@pcp745416pcs.reston01.va.comcast.net) 00.36.09 # that is, after your h140 wins the prize for slowest shipping of the century and actually arrives 00.36.15 # * HCl tries to remember the matrix multiplication implementation of the pow() function 00.36.16 # bleh :( 00.37.05 # could anyone send me a compiled bootloader/firmware? 00.38.54 # there's one on my ftp.. 00.38.59 # * HCl goes to sleep, night. 00.39.12 # wheres your ftp located? 00.39.54 # preglow: I'm already waiting longer for my iriver than it took us ([IDC]Dragon and me, that is) to get the initial rockbox port on Ondio up & running :( 00.41.11 # amiconn: yes, indeed, and this is shipped within germany? 00.41.17 # yup. 00.41.44 # The shop promised to ship in less than 14 days and send a message when it will take longer 00.41.59 # i bet you won't get it at all 00.42.02 # indeed 00.42.10 # since they were out of stock 00.42.12 # I neither received a message nor the iriver up to now 00.42.29 # iriver won't send them any, since they aren't produced anymore 00.42.43 Join starmanager [0] (~534ebde1@labb.contactor.se) 00.43.07 # Hi 00.43.21 # helo 00.43.30 # hey 00.43.37 Join ashridah [0] (ashridah@220-253-123-181.VIC.netspace.net.au) 00.43.54 # I am looking for some help with my JBR 00.44.07 # with your what? 00.44.14 # jukebox recorder 00.44.25 # I got the rockbox on it and it works really nice 00.44.26 # * preglow lets the big boys handle it 00.44.46 # you seem to have come to the right place 00.44.52 # bah, sr.se is flaky atm :( 00.45.18 # Now I am using it in my car with talking menus and remote from my VW radio 00.45.37 Nick stevenm is now known as stevenm|food (~steve@stevenm-router.student.umd.edu) 00.45.45 # does anybody know a community for the gimini 400 except gmini400.com 00.45.46 # ? 00.46.06 # I got the talking menus running, but only with the 8bit languages 00.46.45 # how can I change it to my 16bit languages? I got ATT languages with nice voices 00.47.36 # starmanager: you don't do that easily 00.47.48 # rockbox uses 8bit chars internally 00.48.04 # Bagder: I think he's talking about sample width 00.48.09 # oh 00.48.18 # * Bagder shuts up 00.48.22 # No I mean the language file on my PC with the script for making the file names 00.48.57 # Amiconn: Yes you are right 00.49.02 # Any Ideas? 00.49.05 # starmanager: There are voice files built from AT&T voices in the wiki. 00.49.17 # These are built with the 16 bit versions 00.49.49 # There's a howto as well, in case you want to build voice files yourself 00.50.35 # It shouldn't matter whether you use the 8 or 16 bit voices for them, they should work with any SAPI compatible voice 00.50.57 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 00.51.02 # Right. But what do I need to change in the script? 00.51.23 # It is made for 8 bit and english 00.51.34 # Pre-built voice files http://www.rockbox.org/twiki/bin/view/Main/VoiceFiles 00.51.47 # thank you 00.51.51 # Howto: http://www.rockbox.org/twiki/bin/view/Main/VoiceBuilding 00.52.15 # Maybe you want to choose the voice for the file/dirname clips as well 00.52.38 # Iirc, the script for generating these does not select the voice from within the script 00.52.55 # You have 2 options: 00.53.01 # who does it? 00.53.48 # (1) Change the script to select the voice as well. You could use the MakeVoices.vbs script as a reference how to do that 00.54.26 # (2) Simple way: select the desired voice in the control panel prior to running the script 00.54.50 # Ok but how? I am a little confused with the options for the script 00.57.15 Part LinusN 01.00.01 Join thegeek [0] (~thegeek@ti521110a080-1991.bb.online.no) 01.04.08 # just right-clicked on a midi file, now it's frozen (first wrote something like "can't be played", then "loading patches" and now frozen 01.04.38 Part starmanager 01.06.14 # (just thought this could interest someone^^) 01.06.48 # right-clicked? 01.07.04 # you mean like in rockbox? 01.07.48 # sry, what i've done: copied some midis on the H, then browsed the files and moved the joystick of the H on the rigt side (as "playing") when a .mid file was marked 01.07.56 # midi2wav is not done 01.08.05 # it not working is hardly surprising at all 01.08.29 # okay 01.08.45 # that also happens when opening a midi file with midi2wave (think it's the same^^) 01.08.54 # indeed 01.09.11 # midi support is being worked on right now 01.09.24 # probably wont be working for a couple of days 01.10.07 # ok :) 01.11.33 # and: you would need a patchset 01.11.45 # instrument samples, that does not come bundled with rockbox 01.14.00 # where can i get such a set? 01.14.56 # i have no idea, you'd have to ask stevenm 01.15.09 # which seems to be enjoying some food at the moment 01.15.47 # hehe yes 01.15.52 # i'll wait :D 01.16.05 Join muesli- [0] (muesli_tv@dialin-145-254-146-146.arcor-ip.net) 01.16.22 # high 01.16.43 # Shagnar: http://wam.umd.edu/~stevenm/patchset.tbz2 (if he didn't it take down since yesterday). Beware, it's some 23 MB... 01.16.54 # * amiconn thanks the good logbot ;-) 01.17.49 # thanks! 01.18.19 # hello muesli- :) 01.18.42 # druschba Shagnar ;) 01.22.29 # 50% down 01.23.50 Part MoosCamaro 01.27.39 # preglow where do I have to put the content of the patchet archieve? 01.28.15 Join moi_eric11 [0] (moi_eric11@ACD28FF0.ipt.aol.com) 01.28.36 # hi all 01.28.45 # hi 01.29.44 # Shagnar: why, there again you have a question for stevenm 01.31.59 # anything has info about rockbox on gmini series 100 and SP ? 01.32.14 # moi_eric11: not much to say, the effort is somewhat stalled 01.32.51 # try #gmemu 01.33.05 # ok 01.33.10 # thx 01.33.42 # preglow: kk :)^^ 01.36.33 *** Saving seen data "./dancer.seen" 01.44.21 # looks like stevenm eats a whole cow 01.44.33 # haha 01.45.13 # probably just decided to have ten courses 01.54.52 Quit Tulkar[] () 01.59.36 # n8 ladiez 02.00.44 Part DjMnG 02.09.15 Quit muesli- (Read error: 60 (Operation timed out)) 02.23.01 # hmm, stevenm|food is eating very long... strange, perhaps fallen asleep.... 02.23.40 # well, gn8 i'll go then :) cya! 02.26.34 Quit preglow ("n") 02.27.57 Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) 02.29.10 Quit Shagnar ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 02.31.28 Quit _Lucretia_ (Read error: 110 (Connection timed out)) 02.49.08 Join BBub [0] (belzebub16@dsl-082-082-060-007.arcor-ip.net) 02.49.18 Quit Sucka ("a bird in the bush is worth two in your house") 02.53.13 # Hello people 02.53.15 Nick stevenm|food is now known as stevenm (~steve@stevenm-router.student.umd.edu) 02.54.14 # hey where'd everyone go? 02.58.18 # In outerspace. 02.58.50 # heh at least I aint alone here 02.59.27 # thinking about making the patch loader pre-convert everything to 16bit signed, so the synth loop doesnt have to worry about that 03.03.07 # but oh what a pain that will be 03.05.30 # patch loader? 03.05.32 # patches for what? 03.06.44 # midi still 03.07.01 # soundsets can be 16 bit or 8 bit, signed and unsigned 03.07.32 # and instead of just loading it all at once, I want to write something that will do a conversion 03.07.56 # problem is, 8 bit stuff will have to scale up to 16 bit.. doubling the size 03.08.29 # i guess the sign conversion wont matter.. use one read call to read it all in, then convert it while it's in ram. just add a number to it 03.08.42 # 8bit -> 16bit, i may have to read it one byte at a time, which is SLOW 03.09.20 Quit edx (Read error: 54 (Connection reset by peer)) 03.10.52 Quit asdsd__ (Read error: 110 (Connection timed out)) 03.14.33 # when coldfire is not powered, are its ports in high impendance mode? 03.19.18 # so what kind of ballpark figure would we probably be looking at for sound playback? 03.20.01 # 3 months? 6? 03.26.12 Quit moi_eric11 () 03.28.23 # anyone played ravenshield? 03.34.18 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") 03.36.34 *** Saving seen data "./dancer.seen" 04.04.05 Quit cYmen_ ("zZz") 04.05.20 Join QT_ [0] (as@area51.users.madwifi) 04.05.42 Quit DMJC (Remote closed the connection) 04.06.44 Join DMJC [0] (~James@220-245-171-89.tpgi.com.au) 04.09.18 Quit QT (Read error: 60 (Operation timed out)) 04.28.00 Quit thegeek (Read error: 54 (Connection reset by peer)) 04.29.29 Join thegeek [0] (~thegeek@ti521110a080-1991.bb.online.no) 04.38.25 # Hey guys, if I commit some code with some IOCTLs in it, what will happen? It compiles here, but will it build on the servers ? 05.00.46 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- The future of IRC") 05.11.01 # How the HECK do you use xxx2wav ? keeps segfaulting on close 05.31.16 # Okay.. here goes nothing 05.36.38 *** Saving seen data "./dancer.seen" 05.49.21 # wow I committed it and it compiled 05.50.08 # I give you people.. actual working midi2wav that outputs a .wav. Just add a patchset- there's a link on the wiki 05.52.13 # nice 05.52.35 # * ashridah digs out some original doom midis 05.53.11 # cool 05.53.29 # it needs to be tried on target.. we never actually saw if it generated a valid file 05.53.47 # although, i do have properly synthesized and reencoded versions using proper instruments from a decent midi keyboard and bits 05.54.02 # you feel like testing this thing anyway ? 05.54.29 # darn, i don't have anything i can use to extract the midis 05.54.39 # http://www.vgmusic.com ? 05.58.25 # here's a bunch? http://www.theparticle.com/midi/doommidi.html 05.59.50 # said something about couldn't open file, then seemed to keep going anyway. didn't say what file it couldn't open 06.00.02 # sitting on 'loading patches' atm 06.00.03 # ashridah, did you grab the patchset ? 06.00.48 # and i can't kill it :) 06.00.56 # it's a 22 meg download.. http://wam.umd.edu/~stevenm/patchset.tbz2 06.01.10 # extract that into /.rockbox/ 06.01.37 # hmm 06.01.41 # darn birds 06.01.50 # HCl, birds ? 06.02.02 # ahaha. 22megs. yeah. that'd only take me an hour or so :( 06.02.03 # yup, singing outside at 6 am 06.02.07 # they make a lot of noise :/ 06.02.09 # i'll let someone else do the honours 06.02.13 # * HCl tries to go back to sleep 06.02.45 # ashridah, ah, all right.. 06.03.04 # ashridah, wait a second.. did it die, or did you not have the patchset ? 06.03.57 # i didn't have the patch set 06.04.04 # that's probably what it was complaining about 06.04.16 # ashridah, ah, all right. that explains it 06.04.37 # 22 megs, compressed :) but dang good soundset too 06.24.53 # HCl, wait a sec... 6AM? Where are you? 06.30.55 # * [HCl] (hcl@titania.student.utwente.nl): 06.30.58 # heh. nl. 06.45.09 Join Lost-ash [0] (ashridah@220-253-121-112.VIC.netspace.net.au) 06.50.20 Quit ashridah (Nick collision from services.) 06.50.25 Nick Lost-ash is now known as ashridah (ashridah@220-253-121-112.VIC.netspace.net.au) 07.04.23 # So is everyone asleep ? 07.08.49 # probably, if it's 7am in europe :) 07.36.40 *** Saving seen data "./dancer.seen" 07.45.38 Join rasher [0] (~3e4f4094@labb.contactor.se) 07.53.39 # morning 07.53.53 # stevenm: The midi was decoded correctly 07.57.05 # listening to it now :) 08.16.12 # rasher, sweet! 08.16.16 # thanks for the info 08.16.44 # rasher, I put a new version into CVS which actually outputs a .wav.. and lets you click on .mid files instead of always using test.mid 08.17.11 # I wrote it in the log, but I guess it's only me that checks the log for my name :- 08.17.14 # :-/ 08.17.27 # The Log ? 08.18.20 # http://www.rockbox.org/irc/ 08.18.54 # Oooh I see 08.19.08 # Has created some interesting moments :) 08.19.20 # with people dropping in to answer questions asked before they logged on 08.20.08 # aaah 08.20.12 # haha 08.20.30 # trying the new midi2wav now 08.20.35 # well as for midi, cvs has a new version, but a few things got changed. there's a new patchset file 08.20.43 # oh ah 08.20.46 # only difference is, the config files are in the same dir 08.20.56 # patches are the same but the .cfgs are in the patch dir 08.21.02 # which is now in .rockbox 08.21.12 # and i think iriver2.cfg got renamed 08.21.27 # so I just move /patchset to /.rockbox/patchset and /*cfg /.rockbox/patchset/ 08.22.27 # yea 08.22.47 # and rename iriver2.cfg to patchset.cfg 08.23.09 # alright 08.23.13 # let's try it now then. 08.23.22 # you'll also want to put midi2wav.rock into /.rockbox/viewers and get the new viewers.config 08.26.05 # there's also an 'option' now in the main file that you can have it playing sound directly thru the speakers if you have a Sim build 08.27.03 # erp, a piece of plastic has come lose off my iRiver :-O 08.27.12 # that's no good 08.27.23 # only a tiny bit, though 08.27.26 # but I'd rather it hadn't 08.27.28 # ah 08.29.06 # wonder how that happened 08.29.26 # bumped ? 08.30.13 # I guess 08.30.22 # it's just been in my coat pocket.. :-\ 08.30.25 # oh well 08.30.37 # PLUS the backplate of my watch keeps falling off 08.30.47 # * rasher gets annoyed 08.30.52 # maybe you can get Linus or someone to send you some parts? I am sure those guys must have tons of stripped parts 08.31.10 # it's no biggie.. just a small chip 08.31.16 # ah 08.31.38 # and it hadn't come entirely loose, so I might be able to glue it back on 08.33.42 # hot glue maybe ? 08.35.28 # *shrug* I'll look into that later.. right now I just stuck a bit of tape over it 08.35.40 # ah, that works 08.35.48 # midi codec doing anything ? 08.36.08 # it's decoding 08.36.18 # Forgot to go 120mhz 08.36.21 # ah 08.36.36 # I still don't believe it is possible to make it realtime 08.36.45 # could be 08.37.01 # it would have to be A LOT of ASM optimization 08.37.38 # oh well, we can cut sampling rate if anything.. 08.42.08 # What the FUCK... Danish police wants access to travel agencies booking lists >< 08.42.21 # what ?? 08.42.27 # Just reading news 08.42.36 # booking lists ? 08.42.48 # Like, who goes where, on which hotels etc 08.42.57 # oh 08.44.05 # that thing still decoding ? 08.44.09 # * rasher is annoyed 08.44.10 # yup 08.44.14 # wow 08.44.18 # which file is this ? 08.44.23 # test.mid 08.44.27 # ah 08.44.27 # wow 08.44.31 # heh 08.44.41 # could it be all the hard drive access slowing it down ? 08.44.56 # Hrm, I doubt it 08.44.58 # it writes every 2000 bytes 08.45.12 # I don't know.. could be 08.45.15 # it should run maybe half realtime 08.45.25 # that file isn't too intense, so it may not even be that 08.45.35 # try making a version that writes less? 08.45.51 # I could increase the output buffer 08.46.02 # sounds like an idea 08.46.05 # and write, say, every meg or so 08.46.14 # it'd have to be made to be dynamically allocated 08.46.29 # but the whole point is to have it decode fast, not save it fast.. 08.46.50 # heh, well for testing.. 08.47.16 # i guess 08.47.35 # maybe tomorrow I try to do that 08.49.40 # Think I've had enough monkey island (it is, isn't it?) for now 08.50.50 # * rasher plays a real-instruments rendition of it 08.50.56 # ah, it sure is 08.51.00 # thought so 08.58.32 # yep 08.59.23 # sounds fine 08.59.31 # using audio test :) 08.59.37 # haha 09.05.11 # yea I been using monkey island for a lot of testing 09.15.43 # it's started to get on my nerves lately... love the game though 09.15.50 # how fast can iriver run, anyway 09.15.59 # 120mhz 09.16.06 # Ah.. 09.16.20 # well theoretically 140mhz, but it gets too hot then 09.16.39 # you can call rb->cpu_boost(true); to make it go to 120mhz 09.16.47 # (and then cpu_boost(false) when you're done) 09.16.49 # It runs realtime ish when my PC is at, effectively 230 Mhz 09.17.10 # it runs fully realtime when my PC is at 300 Mhz no problem 09.17.36 # and that is with an operating system in the background, and all the sim stuff.. and I guess waiting for the sound buffer to empty before writing more data 09.18.09 # * rasher times a run at 120mhz 09.18.15 # ooh 09.19.27 # file running time is 1 min 35 sec 09.19.36 # but it is not a difficult file. 09.23.52 # not done yet... 09.25.06 # still not. 09.25.49 # wow 09.26.03 # you wanna try commenting out the disk write possibly ? 09.26.09 # IF it even at all matters 09.26.14 Join Harpy [0] (QNpt89tEMV@dsl-hkigw7wbb.dial.inet.fi) 09.26.22 # Sure, I'll try that 09.26.28 # midi2wav.c line 196 09.28.12 # still running.. 09.28.30 # done 09.28.40 # 10:49 09.29.15 # 10% 09.29.18 # wooow 09.29.36 # i doubt disk write overhead is the cause of THAT :) 09.29.49 # Probably not 09.29.51 # well let's see 09.29.55 # ok 09.30.20 # starting now 09.30.30 # oops, forgot 120mhz 09.30.39 Quit ashridah ("Leaving") 09.31.06 # now, then 09.31.20 # ok 09.36.42 *** Saving seen data "./dancer.seen" 09.37.13 # it's not showing any hd activity, is it? 09.37.21 # nope 09.37.24 # ok 09.38.15 # passing 7 minutes now 09.38.51 # yeah... 09.39.01 # I can think of maybe one or two things to do to the synth code 09.39.09 # 8.. still not done 09.39.12 # but it's stuff that gets executed 4 MILLION times per second, on a tough file 09.39.37 # not having much luck getting midi to work? 09.39.45 # it's working fine 09.39.47 # just rather slow 09.39.49 # I really hope the ASM gurus have reason to be confident that they can optimize it to run realtime 09.40.04 # HCl: now get working on mod2wav :) 09.40.13 # it's not optimized at all but it is bloody slow 09.40.45 # preglow said it was definitely possible to make midi synth work fast enough. we'll see I guess 09.41.06 # how similar is it playing a mod file to playing a mid file? 09.42.04 # now 09.43.12 # well that didn't make much of a difference :) 09.43.24 # not sure of the exact time, got a phone-call 09.43.34 # (and was using my phone to time it) 09.43.40 # well, still 10% ish 09.43.46 # still not good. 09.43.48 # aaat all 09.44.14 # I guess one shift and one multiply can be eliminated if the decay stuff gets called conditionally 09.44.36 # cutting out the ADSR crap would help, but I dont know if we should go taht far 09.44.43 # possibly function call overhead 09.44.52 # convert 8bit to 16 bit to save an if statement 09.45.07 # merge synthsample, synthvoice, getsample, and the main loop ? 09.45.27 # no idea 09.45.33 # better ask someone else 09.45.33 # and theres that whole hand optimized assembly thing.. converting stuff to MAC instructions which are supposedly very fast 09.45.51 # put stuff in iram 09.45.51 # if they can get a 386 to do this stuff, there's got to be a way 09.45.55 # iram ? 09.46.04 # fast chunk of ram 09.46.07 # Oh 09.46.14 # 96kb or so iirc 09.46.17 # hcl knows 09.46.22 # Don't know how, but that is possible 09.46.33 # put the voice array in there at least 09.47.01 # I dont know where stuff ends up by default, but it checks all 100 voices even if one is active.. it still has to check to see if they are active or not 09.47.19 # but yea that would probably help 09.47.31 # I guess everything's put in ram 09.47.50 # I guess optimization, etc will be up to the people who know how to do it.. I just got the basic thing working 09.48.19 # in all my life I maybe wrote 100 lines of asm. none of which were for coldfire 09.51.24 # what? 09.51.39 # iram 09.51.57 # I just wasn't sure about the details of the iram 09.51.59 # i don't think iram will provide a 1000% speedboost.. 09.52.07 # :) 09.52.39 # * HCl yawns 09.52.51 # you can look at rockboy for an example, i guess. 09.52.59 # i'm not here 09.53.03 # anime con, yay. 09.53.11 # i'll take my old laptop with me though. 09.53.13 # o.O 09.54.00 # well not even everything in iram.. 09.54.05 # just some things 09.54.14 # plus that magical all-solving MAC instruction 09.57.00 # wow it is LATE 09.57.16 # and i'm sick as a dog 09.58.20 # No, it's EARLY 10.03.40 # rasher, what time is it? 10.03.49 # 10am here 10.03.53 # wow 10.03.56 # 4AM here 10.04.13 # heh 10.04.29 # think I'll go create some breakfast 10.10.09 Quit Nibbler ("blubber") 10.27.13 # okay, it's 4:30 AM. I am going to sleep 10.27.16 # good night people 10.27.22 Quit stevenm ("Leaving") 10.51.35 Quit rasher ("CGI:IRC") 10.52.43 Join webguest57 [0] (~3e4f4094@labb.contactor.se) 10.55.14 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 10.59.59 # Good news boys! Yesterday had the most talk in the history of this irc channel! 11.00.07 # hm 11.00.08 Nick webguest57 is now known as rasher (~3e4f4094@labb.contactor.se) 11.00.29 # oh no, I lie 11.00.40 # I don't.. 11.00.45 # It just didn't have the most lines 11.07.58 Join amiconn_ [0] (~jens@pD9E7F0FD.dip.t-dialin.net) 11.09.34 Quit amiconn (Nick collision from services.) 11.09.35 Nick amiconn_ is now known as amiconn (~jens@pD9E7F0FD.dip.t-dialin.net) 11.18.57 # morning amicon 11.19.07 # amiconn 11.29.36 Quit mico (Read error: 131 (Connection reset by peer)) 11.30.02 Join t0mas [0] (~Tomas@ip503c08d1.speed.planet.nl) 11.30.18 # hi 11.35.49 # morning 11.36.46 *** Saving seen data "./dancer.seen" 11.37.09 Join austriancoder [0] (~austrianc@80.120.117.30) 11.37.16 # good morning 11.37.40 # morning 11.37.52 # morning 11.38.00 # g'night 11.38.12 Nick Strath is now known as StrathAFK (~mike@dgvlwinas01pool0-a221.wi.tds.net) 11.38.21 # heh 11.39.10 # (shift change i guess :) ) 11.39.16 Quit StrathAFK ("Client closed") 11.40.53 # amiconn: are you here? 11.45.39 # what do you all think about: no backlight if the player is in hold-mode? 11.53.25 # nice idea 11.53.34 # but hold mode isn't working at the moment? 11.53.49 Join edx [0] (edx@pD9EAB180.dip.t-dialin.net) 11.55.45 # hi 12.11.51 Join mozarius [0] (~morath@p549FE4F8.dip.t-dialin.net) 12.12.02 Part mozarius 12.13.08 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.17.21 # t0mas: sure, but i will do some work in that direction after finishing remote lcd support 12.17.24 Join preglow [0] (thomj@s183a.studby.ntnu.no) 12.17.32 # hi preglow 12.17.36 # hello 12.20.55 # hi preglow 12.26.37 # saw you got a 1.1.1 release going? ;) 12.27.14 # * rasher creates irc stats 12.27.39 # i thought bagder already did that 12.28.08 # I'm not sure.. sounded like he just grepped or something 12.28.13 # 1.1.1... extremely minor update 12.28.42 # no one of the musepack people has a h1x0 and wants to start optimizing the code, i take it? :P 12.29.36 # austriancoder: nice progress on remote ;) 12.29.37 # this model is hard to get 12.29.48 # looks like i'll be a bit short of time in the coming weeks/months 12.30.02 # hi Rick 12.30.24 # yeah.. next thing is to make wsp working for the remote 12.30.30 # wsp? 12.31.12 # wps sorry 12.31.24 # look: http://www.rockbox.org/twiki/bin/view/Main/WpsGallery 12.31.30 # ah 12.32.17 # I think your best bet if you want a h100 now is ebay or similar 12.35.29 Join MoosCamaro [0] (MoosCamaro@m214.net81-66-158.noos.fr) 12.35.36 # Hi all 12.37.37 # hi 12.38.11 # hi austriancoder 12.38.34 # you've got news for remote? 12.40.54 # text wirting should work later the day 12.41.18 # then wps sutff and the remote is finished 12.41.41 # good news 12.42.05 # are they in cvs? 12.42.31 # current cvs shows rockbox logo on startup on remote lcd 12.42.41 # backlight handling is also working 12.43.22 # http://www.rockbox.org/twiki/pub/Main/IriverPort/remote_lcd.jpg 12.43.46 # ok, thanks 12.44.07 # ;) 12.44.14 # must go noe 12.44.15 # now 12.44.22 Quit austriancoder ("using sirc version 2.211+KSIRC/1.3.11") 12.44.22 # on startup? more like all the time :) 12.53.39 # lol 12.53.41 # well 12.53.44 # technically only on startup 12.53.49 # because it only paints it to the remote lcd once 12.53.49 # ;p 12.57.02 # ah ok 12.57.56 Join FunkyMonk [0] (~FunkyMonk@dsl-082-083-189-047.arcor-ip.net) 12.58.06 # have you seen the new 30gb from toshiba? it fits well into the h110/120 12.58.47 # 60 go 12.58.52 # how does the h120 handle a new drive, power wise? 12.59.15 # MoosCamaro: the 60gb will only fit into the h140 ;) 12.59.45 # Rick: from what i heared it works fine 13.02.07 # 30 gig is also supposed to eat less power than the 20 gig 13.02.32 # a lot of bother for 10 gb though :-\ 13.02.50 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 13.03.00 # more money than bother 13.03.05 # inserting a new disk is shit easy 13.03.32 # money is bother :) 13.06.23 Quit preglow ("off") 13.08.17 Quit FunkyMonk (Read error: 60 (Operation timed out)) 13.11.46 Join BBub_ [0] (belzebub16@dsl-082-082-060-009.arcor-ip.net) 13.20.18 Quit BBub (Read error: 60 (Operation timed out)) 13.20.18 Nick BBub_ is now known as BBub (belzebub16@dsl-082-082-060-009.arcor-ip.net) 13.30.10 Join Tulkar[] [0] (~hfdshd@log68-1-82-227-88-10.fbx.proxad.net) 13.32.18 Quit Zagor ("Client exiting") 13.33.13 Join Naked [0] (naked@naked.iki.fi) 13.33.49 Quit Hadaka (Read error: 60 (Operation timed out)) 13.34.31 Nick Naked is now known as Hadaka (naked@naked.iki.fi) 13.36.50 *** Saving seen data "./dancer.seen" 13.40.06 Join Shagnar [0] (~tester@p54A0F887.dip.t-dialin.net) 13.43.22 # xxx2wav <= what does that mean? any format to wave?! 13.44.27 # It's common functions for converting stuff to wave 13.44.32 # so in a way, yes 13.45.20 # hmm 13.48.19 Join Sucka [0] (~NNSCRIPT@host81-157-72-191.range81-157.btcentralplus.com) 13.55.10 # amiconn? 13.55.19 # you where thinking of a universal image loading thing? 13.55.23 # -h 14.08.49 Join mico [0] (mico@80.178.183.78.adsl.012.net.il) 14.09.20 Nick mico is now known as micoo (mico@80.178.183.78.adsl.012.net.il) 14.09.42 Nick micoo is now known as mico (mico@80.178.183.78.adsl.012.net.il) 14.09.56 Nick mico is now known as micoo (mico@80.178.183.78.adsl.012.net.il) 14.11.31 # rasher? 14.11.42 # you know something about mem allocation on rockbox? 14.15.05 # t0mas: Now I am here (sort of) 14.15.28 # ok, what was you idea? 14.16.04 # (and I'm trying to fix the old loading stuff... as a quick fix... but there is no malloc() function, any idea's on how to do it?) 14.18.10 # Yes, there is no malloc(). malloc() is evil on architectures with no mmu because of memory fragmentation 14.18.46 # t0mas: absolutely nothing 14.19.31 # who of you was the one i should ask for the midi2wav support? 14.19.38 # For image loading, the caller should provide a buffer, and tell the loader how large it is 14.20.13 # ok, and how should the caller create that buffer? 14.20.48 # Core or plugin? 14.20.54 # core 14.20.59 # and plugin... 14.21.08 # but plugin isn't really needed 14.22.03 # In the core, you have 2 options. (1) reserve the buffer statically (2) one-time allocate at rockbox init. There is buffer_alloc() which allows to allocate from the free memory area as long as the main playback buffer is not yet initialised 14.23.05 # Plugins could also use a static buffer, or use a private malloc()-alike, allocating from either the plugin buffer, or the audio buffer. The latter of course stops playback 14.23.59 # for a wps the last isn't an option... 14.24.09 # yup ;-) 14.24.35 # Smaller buffers can also reside on the stack, but keep an eye on the stack usage 14.24.55 # http://rasher.dk/rockbox/ircstats/ :) 14.24.58 # Stack size is rather limited (and has to be) on embedded devices 14.26.25 # rasher: Does the script handle multiple nicks/ nick changes for the same person? 14.26.42 # eh.. don't know :) 14.27.19 # amiconn: how would you allocate a buffer for a wps image? 14.27.20 # 2 examples: midknight2k3 and midk are identical, as are diddystar5, dstar5 and bagawk 14.27.28 # it should be done in wps-display.c I guess? 14.27.51 # amiconn: guess not then :) 14.28.30 # hm... another problem... how would the code know what size buffer is needed? 14.28.50 # "During this 1000-day reporting period" 1000 days of #rockbox logs! 14.28.53 # t0mas: Personally, I wouldn't do that at all, because I don't want/ need images in the wps, but yes, I think it should go into wps-display.c 14.29.59 # Just reserve a large enough buffer for all reasonable images. Images that won't fit would then be only loaded partial, or not at all 14.30.27 # (possibly showing an error message, "Image xyz too large") 14.30.36 # ok, so allocate a buffer of the maximum lcd size for that device? 14.31.12 # Imho that would be overkill. Surely you always want some text info in the wps? ;-) 14.31.37 # yeah, but a background would be maxsize... 14.32.03 # I doubt a background image makes sense on a 4-greylevel display... 14.32.26 # yeah, but it's not only for wps anyway... 14.32.38 # maybe a plugin want's to show fullscreen bmp 14.32.51 # Other places - other buffer, I'd think 14.33.20 # Then the plugin would have its own buffer, imho 14.33.37 # ok, and how do I release a "unsigned char bmp[size]" 14.33.58 # You can't 14.34.31 # That is, if it's in a function it would be on stack, which is probably a bad idea 14.34.58 # yeah, stack isn't very large is it? 14.35.04 # If you declare it toplevel, or use static unsigned char bmp[size] within the function, it is reserved at compile time 14.35.48 # hmz... can't I allocate it in function space? 14.35.49 # Stack size (on archos) is 8 KB for the main thread, 4 KB for the other threads. Iirc on iriver it's a bit more 14.35.56 # so at the end of my function it's released again? 14.36.26 # Then it would end up on the stack, as I already said 14.37.17 # yeah, but would it be removed from stack when my function ends? 14.37.51 # Yes, but depending on the size you would overflow the stack 14.38.01 # Image buffers tend to be large 14.38.36 # yeah... 14.38.45 # So the best would be to put it above the function? 14.38.47 # toplevel? 14.38.52 Join preglow [0] (thomj@s183a.studby.ntnu.no) 14.39.03 # hi preglow 14.39.25 # hello 14.39.46 # t0mas: I think so 14.43.08 # My approach for (multiple small) images in the wps would be to have one buffer, a pointer array, and a 'next free byte' pointer. 14.43.44 # At wps init, the 'next free' pointer is reset to the buffer start address 14.44.23 # Then the first image is loaded into the buffer, the first pointer of the array set to the image start, and the 'next free' pointer advanced to point behind the image data 14.44.36 # Next image then loads there, and so on 14.45.19 # ...until either (1) there are no more images to load (2) the buffer is full or (3) the pointer array is full 14.46.28 # Images would be loaded only at wps init, then referenced (as often as wanted) within the wps layout 14.46.32 # yeah... 14.46.43 # I'm just fixing the load_bmp() function 14.47.20 # eh 14.47.24 # read_bmp_file() 14.48.13 # Ah, I forgot: Of course I'd use a struct array instead of a pointer array, containing width, height and pointer_to_data for each image 14.50.16 # yeah, but the function isn't wps only 14.51.22 # what did I forgot to include when I get this: 14.51.22 # recorder/bmp.c:50: error: `LCD_WIDTH' undeclared here (not in a function) 14.51.23 # ? 14.52.01 # lcd.h? 14.53.04 # I'd be going to implement this buffer management within wps-display.c. The bmp loader itself would only be handed the load address and the available size. Then it would load the image data into the buffer, and return either succes or an error 14.53.28 # If the load is succesful, it should of course also return the image dimensions 14.53.54 # it already does that... 14.54.02 # int read_bmp_file(char* filename, 14.54.02 # int *get_width, /* in pixels */ 14.54.02 # int *get_height, /* in pixels */ 14.54.02 DBUG Enqueued KICK t0mas 14.54.02 # char *bitmap) 14.54.11 # yup 14.54.15 # the last one is a pointer to a buffer to load the image into 14.54.23 # Only that it doesn't do it correctly 14.54.28 # ? 14.54.38 # It is written to produce the old internal bitmap format 14.54.52 # that's what I'm changing... 14.55.21 # Yes, then it would do exactly what I would expect it to do 14.55.49 # o 14.55.49 # k 14.56.16 # recorder/bmp.c: In function `read_bmp_file': 14.56.16 # recorder/bmp.c:122: warning: assignment from incompatible pointer type 14.56.18 # hmz... 14.56.53 # unsigned char bmpbuf[((LCD_WIDTH+3)&(~0x3)) * LCD_HEIGHT]; 14.56.54 # unsigned char *bmp; 14.56.58 # bmp = &bmpbuf; 14.57.04 # it doesn't like that? :) 14.58.37 # Yes, because the correct statement is bmp = bmpbuf; 14.59.12 # bmpbuf is already the start address of the array, equal to &bmpbuf[0], but *not* equal to &bmpbuf 15.00.11 # Btw, the buffer management I described is already used in some places within rockbox, so you don't need to rewrite that from scratch 15.01.12 # ok 15.01.34 # hmz... my compiler doesn't like wavpack.h 15.01.36 # filetypes.c uses it for managing string_buffer[], and iirc font.c does similar 15.01.46 # ok, I'll read that 15.02.01 # is there a way to simply skip wavpack compiling? 15.02.37 # yes 15.02.42 # in tools/configure 15.02.45 # ok 15.02.47 # you can disable the codecs you don't want 15.02.54 Join ashridah [0] (ashridah@220-253-123-189.VIC.netspace.net.au) 15.02.56 # done 15.03.40 # what's mpc_decoder.c ? 15.03.43 # midi stuff? 15.03.56 # musepack 15.04.00 # ah... 15.04.07 # lot of warnings about that... 15.04.11 # Gotta leave now, cu 15.04.17 # bye 15.04.20 # tnx for the help 15.04.21 # warnings, yes 15.04.22 Part amiconn 15.04.29 # i didn't bother to fixthose yet 15.04.35 # what compiler do you use anyway? 15.04.41 # streaminfo.c:224: warning: implicit declaration of function `memcmp' 15.04.45 # looks rather concerning? 15.04.47 # i know of them 15.04.48 # no, it's not 15.04.58 # ok 15.05.19 # but what compiler do you use? 15.06.13 Join DJ_Dooms_Day [0] (DJ_Dooms_D@dialup-106.43.220.203.acc07-dryb-mel.comindico.com.au) 15.06.32 # Heya 15.07.36 # Using m68k-elf-gcc 3.4.3 (304) 15.07.40 # @ preglow 15.07.48 # well, that's what i use... 15.07.53 # i have no problems at all with wavpack 15.07.54 # ghehe 15.07.58 # weird 15.08.07 # have you done a fresh checkout and compile? 15.08.17 # (I did, my laptop is at my work...) 15.10.15 # pretty recently 15.10.23 # no one has changed wavpack for yonks anyway 15.10.31 # then it's my setup or something... 15.10.42 # it's complaining about line 497 15.10.46 # the (bs)-> part 15.10.58 # (((bs)->bc) ? \ 15.10.59 # that 15.11.24 # parser error left of "->" 15.23.43 # ARG 15.23.44 # preglow? 15.24.23 # LD /home/tomas/dev/rockbox-devel/build/battery_test.elf 15.24.23 # /opt/m68k/bin/../lib/gcc/m68k-elf/3.4.3/../../../../m68k-elf/bin/ld: cannot find -lwavpack 15.24.32 # when I remove wavpack from that codec list... 15.24.37 # little mistake in the configure script? 15.25.20 # t0mas: i really haven't got time to look at this now 15.25.33 # no, that's not a mistake 15.25.35 # it's hard coded 15.25.44 # ah 15.25.57 # you need to fix the makefile for plugins 15.27.04 # done :) 15.28.53 # GRRR 15.29.08 # In file included from wv2wav.c:26: 15.29.10 # again :X 15.29.27 # /home/tomas/dev/rockbox-devel/apps/codecs/libwavpack/wavpack.h:497: error: parse error before '->' token 15.29.35 # what the.. 15.30.12 # remove wv2wav from sOURCES in plugins 15.30.23 # i really would rather have fixed the compiler, but... 15.30.38 # if that doesn't work, god knows what other stuff isn't right either 15.30.41 Quit DJ_Dooms_Day () 15.31.02 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 15.31.02 # * t0mas wonders why it doesn't work here... and does work for you 15.31.42 # works for everyone else as well 15.31.43 # ARG 15.31.45 # no-one has complained 15.31.50 # * t0mas is in a compiler hell 15.32.03 # midi2wav isn't working either 15.32.23 # wouldn't know about that, haven't compiled rockbox in some times 15.32.24 # -s 15.32.49 # yeah, found it... a little error in cvs around that time :) 15.33.01 # 2005-04-15 20:27 had an error for midi 15.35.42 # when loading some patches on the iriver 15.35.51 # the midi2wav seems working (harddisk works) 15.36.30 # dunno if result, after 5mins i pressed the reset button 15.36.53 *** Saving seen data "./dancer.seen" 15.38.36 # damn... 15.38.39 # I really have a bad day... 15.39.06 # In file included from /lib/gcc-lib/i686-pc-cygwin/3.3.1/include/syslimits.h:7, 15.39.06 # from /lib/gcc-lib/i686-pc-cygwin/3.3.1/include/limits.h:11, 15.39.06 # from common/strchr.c:37: 15.39.06 # /lib/gcc-lib/i686-pc-cygwin/3.3.1/include/limits.h:122:75: limits.h: No such file or directory 15.39.33 # Shagnar: why reset button? 15.39.45 # Shagnar: midi2wav is supposed to exit if you just push any button 15.47.28 # midi2wav runs at about 10% real time 15.47.38 # (at 120mhz) 15.48.06 # ouchouchouch 15.49.57 # Quite 15.50.10 # in non-related news: http://rasher.dk/rockbox/ircstats/ 15.54.50 # 15.54.50 # Bagder always lets us know what he/she's doing: 1138 actions! 15.54.50 # For example, like this: 15.54.50 DBUG Enqueued KICK ashridah 15.54.50 # * Bagder ignores such IRC crap 15.54.52 # hahaha 15.55.03 # excellent 15.55.23 # also very fitting is preglow's quote on the 2005-page 15.58.09 # Also, HCl tells us what's up with 659 actions. 15.58.18 # Yeah, he always yawns :P 15.58.59 # hahah 16.02.08 # damn... 16.02.25 # it still doesn't compile... 16.02.41 # I HATE windows 16.03.52 # there's a good cure for that 16.04.20 # yeah 16.04.27 # break into the office and get my laptop :P 16.17.43 # yeah :D 16.18.04 # build finished... simulator isn't working... but the real thing is :D 16.19.03 # sounds like you're having all sorts of fun 16.19.10 # ghehe yeah 16.19.13 # I really like windows + cygwin 16.20.24 Nick Tulkar[] is now known as Tulkar[AFK] (~hfdshd@log68-1-82-227-88-10.fbx.proxad.net) 16.21.46 Join muesli- [0] (muesli_tv@Bc1ec.b.pppool.de) 16.22.04 # high 16.22.29 Join austriancoder [0] (~c1aa0259@labb.contactor.se) 16.22.31 # hi all 16.22.41 Part gromit` ("Client exiting") 16.23.00 # can somebody tell me, where the bottons get processed? 16.24.16 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 16.24.16 # * rasher bites his tongue 16.25.15 # i want to code the holde-button stuff 16.26.31 # don't the other devices have hold buttons? 16.26.45 # i dont know 16.26.51 # but on iriver it doesn't work 16.27.37 # firmware/drivers/button.c ? 16.28.15 # flipped-screen appears to have been (almost) fixed? 16.28.24 # thats the driver, but i must look where it get used 16.28.32 # ah 16.29.22 Quit muesli- (Read error: 131 (Connection reset by peer)) 16.29.30 Join muesli- [0] (muesli_tv@Bc1ec.b.pppool.de) 16.29.34 # think i found it 16.32.55 Quit ashridah ("Leaving") 16.37.03 Join bagawk [0] (~Lee@bagawk.user) 16.37.15 # weird... flip screen was not giving me the garbage last night 16.37.49 # only 4 lines of blankpixels 16.38.04 # now it's back at 4 lines of garbled pixels 16.38.09 # ghehe 16.38.18 # oh oh... not booting orignal firmware again :) 16.38.21 # very probably depends on memory contents 16.38.23 # battery loading time 16.38.36 # preglow: good point 16.39.08 # would be a fun way to reverse engineer something 16.39.16 # if it had a bug that spilled memory unto the display 16.39.34 # bit like that hack they used for ipodlinux at some point 16.40.28 # Hrm.. "LCD Mode" .. doesn't "Inverse mode" make more sense? 16.41.25 Join kergoth [0] (~kergoth@covenant.kergoth.com) 16.41.51 # for the flipped screen? 16.43.05 # no, for inverse mode :) 16.43.11 # just looking at the display menu 16.43.13 # if then, yes 16.43.18 # then = so 16.43.23 # and thought it was a silly name for that entry 16.43.38 # you'd really have to know, or look to guess what it means 16.51.14 # Then there's the menu structure... 16.51.50 # Root->General->Playback, but Root->Recording ?! 16.52.52 # recorinf menu will be show, if hte target support it 16.52.55 # but I guess that's a whole can of worms to open 16.53.36 # What I mean is.. why are two so similar entries not placed at the same level? 16.53.46 # And so on 16.54.58 # they're programers - not designers ;) 16.55.19 # I guess that's the "problem" 16.55.45 # well, if everything is working well, they will probably fix those things 16.55.49 # Not that I'm claiming to be.. it was just a single thing.. and the structure as a whole just .. "feels" wrong 16.56.10 # I doubt it.. I think it'd need to be someone from the outside.. with good knowledge of such things 16.57.21 # everyone can join the project afaik :) 16.58.13 # I know this 17.02.10 Quit bagawk ("Leaving") 17.06.00 Join oooops [0] (~51e70717@labb.contactor.se) 17.06.07 # hi 17.06.56 # what are the risks in flashing rockbox? 17.07.14 # your player might not boot anymore 17.08.51 # well, i've just downloaded grayrockbox and ihp_120.hex from HCL's server and checked the md5sum 17.09.01 # do you think I should flash it or not 17.09.03 # ? 17.09.36 # yepp, theres nothing to worry about 17.10.13 # so if I succesfully flashes it... nothing can go wrong that i can't fix with a reset? 17.10.24 # yup 17.10.37 # but rockbox won't do anything for you now 17.10.48 # so you could just view the screenshots and get the same result 17.11.04 # but I can make playlists and play gameboy games 17.11.41 # from what i read rockboy (the gameboy emu) doesnt work in realtime yet 17.11.59 # and the playlists are of no use as you cant playback any music ;) 17.12.30 # but i can easily boot the original firmware to listen 17.12.35 # right? 17.12.41 # yes 17.13.12 # I thought it was only the sound in rockboy that wasn't realtime 17.14.00 # i only read about, so i'm not sure 17.14.51 # k, but theres no harm in testing it... 17.15.05 # the games are slightly less than realtime I think 17.15.11 # been a while since I last tried one 17.16.07 # ok... anyone know how the sound API's going, I've seen alot of commits the three latests days 17.19.57 # the sound api is chugging along 17.20.50 # I think I've read that the bootloader isn't completely ready, but it's working so what is it that needs to be improved? 17.21.03 # arg... 17.21.16 # preglow? do you know how I allocate a buffer from core? 17.21.28 # (in wps-display to be precise) 17.21.37 # i quote"WARNING! The boot loader is still in development." 17.21.43 # I want something like this: unsigned char wpsbg[20480]; 17.22.04 # but the size should be variable... as this is a waste of ram for small images.. 17.23.19 # oooops: it is *mostly* a disclaimer-type warning.. I don't think much work will go into it from now on.. bug fixes (if bugs are found) mostly 17.24.17 # t0mas: rockbox has no malloc 17.24.21 # I know 17.24.31 # that's why i asked how to do it :) 17.24.34 # then why are you asking when you know the answer? 17.24.40 # you can't 17.24.45 # t0mas: why don't you use amiconn's suggestion? 17.24.50 # but those "unknown bugs" can't brick my player, right? 17.24.52 # I do.. 17.24.55 # you'll have to use the mp3 buffer 17.24.59 # oooops: of course they can 17.25.00 # I have the function the way he told me 17.25.16 Quit muesli- (Read error: 104 (Connection reset by peer)) 17.25.16 # but amiconn wanted the caller to create a buffer 17.25.24 # why do you need to allocate then? 17.25.36 # * rasher shuts up 17.25.40 # ghehe 17.25.46 # and the caller doesn't know the image size... 17.25.58 # that's another problem... 17.26.10 # can't the caller get access to the entire image-buffer then? 17.26.27 # what image buffer? 17.26.40 # the caller has to give a pointer to a buffer where the image is stored 17.26.49 # a single image? 17.27.02 # atm: yes 17.27.20 # hm.. then maybe I didn't understand amiconn's idea, or you didn't :-\ 17.27.25 # either way, gtg 17.29.39 Quit rasher ("CGI:IRC (EOF)") 17.34.01 Join DangerousDan [0] (~Miranda@newtpulsifer.campus.luth.se) 17.34.49 # hi 17.36.57 *** Saving seen data "./dancer.seen" 17.39.24 Quit austriancoder ("CGI:IRC 0.5.4 (2004/01/29)") 17.52.41 Join Nibbler [0] (~sven@84-245-186-173.muc.bpool.celox.de) 17.58.24 Join _ferenczy [0] (ferenczy@a3brn-108.dialup.vol.cz) 18.00.24 Join booper [0] (~boop@nat01-silvers-ext.Rutgers.EDU) 18.00.32 # good afternoon all 18.00.34 # anyone around? 18.01.42 Quit Sucka ("a bird in the bush is worth two in your house") 18.01.52 Join Sucka [0] (~NNSCRIPT@host81-157-72-191.range81-157.btcentralplus.com) 18.01.54 # <_ferenczy> hi there 18.02.31 # hello 18.02.41 # i have a question about the rockbox firmware that i can't find anywhere...perhaps you could help? 18.03.49 # <_ferenczy> I'll attempt ;) 18.03.53 # great :) 18.04.35 # in short, i have a JBR V2 and want to take it in my car...but I have no line-out port. I don't see a setting anywhere in the software to limit the output to <=1V 18.05.02 # surely this has been an issue before...any way to attain a pseudo line-out without a line out port? 18.05.35 # or do i need to find the magic volume level (don't want to do this if possible so I don't damage the head unit in the car) 18.06.56 # <_ferenczy> do you want to connect line-in to the players speaker output? 18.08.03 # yes. archos output -> stereo line-in 18.08.44 # <_ferenczy> It' 18.08.57 # <_ferenczy> It's not designed to do that, I think 18.09.54 # aww 18.09.59 # well, that's a disappointment : 18.10.22 # :) 18.17.49 # hmz... 18.18.09 # anybody know's why ms paint doesn't save a black and white image as 8bit bitmap? 18.18.59 # because it's ms 18.19.00 # ;) 18.19.07 # Duuh! 18.20.25 # sup? 18.23.26 # fuck... 18.23.38 # I've done the impossible :P 18.23.42 # crashed the simulator :) 18.26.38 # HCl: hows the rockboy sound going? 18.26.54 # working 18.27.11 # only rockboy isn't at 100% speed afaik? 18.27.42 # well i know i's working.. but it's rather choppy, right? 18.27.52 # yes 18.27.59 # that's because rockboy isn't at 100% 18.28.15 # k 18.28.29 # and what % is it at? 18.29.56 # don't know 18.30.04 # 80? maybe 90? ask HCl 18.31.26 # depends on the game 18.31.31 # I would say 18.31.51 # generally around 80? 18.32.04 # yeah, think so 18.32.05 # (this is where hcl comes in and corrects me) 18.32.06 # ;) 18.32.08 # mhm 18.32.13 # k... i haven't flashed my player yet... I don't dare :( 18.32.20 # you pussy! 18.32.24 # got out. 18.32.27 # *get 18.32.28 # ;) 18.32.51 # (im in that grumpy mood again) 18.33.02 # and apparently I can't type today either 18.33.07 # lol 18.33.22 # ghehe 18.33.54 # * t0mas didn't flash it until needed for development 18.37.19 # * oooops is going to eat 18.37.41 # * t0mas too 18.38.03 # * t0mas is ff eten 18.38.24 # woops.. 18.38.26 # wrong channel 18.39.07 Join muesli- [0] (muesli_tv@Bc1e8.b.pppool.de) 18.39.13 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) 18.49.41 Join F1^Aison [0] (~hans@zux166-181.adsl.green.ch) 18.53.29 Quit F1^Aison (Client Quit) 18.56.51 Quit Aison (Read error: 145 (Connection timed out)) 19.09.23 # * t0mas is still fighting bmp's :x 19.15.43 # <_ferenczy> I have got a question> is this channel same as #rockbox channel on irc.openproject.net? 19.17.51 # I don't know that channel... 19.18.01 # and irc.openproject.net is refusing connections on port 6667 19.25.07 # <_ferenczy> t0mas> it's noticed in rockbox FAQ (#11), #rockbox at irc.openproject.net is the official channel... 19.26.05 # I think it's moved then... 19.26.24 # ow lol 19.26.25 # http://www.rockbox.org/irc/ 19.26.34 # "We often hang out on #rockbox over at irc.freenode.net (freenode was once known as openprojects.net, see their web site for more information)." 19.26.42 # so that's it :) 19.26.52 # <_ferenczy> so, this is the one channel 19.26.55 # <_ferenczy> ah so ;) 19.26.58 # <_ferenczy> thanks 19.29.37 # hm... getting the actual fileposition was lseek(fd, 0, SEEK_CUR); right? 19.31.47 Quit muesli- (Read error: 110 (Connection timed out)) 19.36.58 *** Saving seen data "./dancer.seen" 20.02.51 Join muesli- [0] (muesli_tv@hmln-d9b8e258.pool.mediaWays.net) 20.03.45 # hm.. 20.03.54 # is there any information on the rockbox image format? 20.04.48 Quit Nibbler ("blubber") 20.11.31 Quit oooops ("CGI:IRC") 20.22.46 Quit _ferenczy (Read error: 113 (No route to host)) 20.32.20 Join zezayer [0] (~5198da45@labb.contactor.se) 20.34.31 # Does anyone know when grayscale will be enabled in the iriver version of rockbox, i know u can download an old version with it but when will it be found on the daily builds? Thnaks. 20.35.02 Quit zezayer (Client Quit) 20.35.03 Join zezayer [0] (~5198da45@labb.contactor.se) 20.35.27 Quit zezayer (Client Quit) 20.35.34 Join zezayer_ [0] (~chatzilla@host81-152-218-69.range81-152.btcentralplus.com) 20.35.36 Nick zezayer_ is now known as zezayer (~chatzilla@host81-152-218-69.range81-152.btcentralplus.com) 20.38.40 # zezayer: as soon as the guy who made the grayscale version updates it to work as it should 20.38.54 # the current grayscale support is very half-baked 20.38.58 # ok cool thanks 20.43.23 Join stevenm [0] (~steve@stevenm-router.student.umd.edu) 20.43.30 # hello people 20.43.49 Quit zezayer ("Chatzilla 0.9.67 [Firefox 1.0.1/20050311]") 20.44.45 # hey preglow, are you good at optimizing things in ASM ? 20.45.03 # hi stevenm 20.46.21 # How much 'optimization' can one expect? 20.46.41 # Unoptimized this thing runs 10% realtime on a good day with an easy file 20.47.24 Join zezayer [0] (~chatzilla@host81-152-218-69.range81-152.btcentralplus.com) 20.51.48 # hmz... 20.52.03 # 10% isn't much.. 20.52.11 # is that in boost mode? 20.52.25 # yep 20.52.36 # I just hope this code is just THAT inefficient 20.52.51 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 20.53.16 # I know I can still make a few optimizations, in C, but that's not many.. 20.53.26 # it's a midi codec right? 20.53.28 # yes 20.53.37 # and midi isn't a really difficult format? 20.54.01 # or have you implemented a full synth or something? 20.54.04 # no but synthesizing 50ish voices at 48000Hz is kind of intensive 20.54.13 # (just thinking, I don't know anything about midi( 20.54.14 # ) 20.54.28 # the sequencer is not a problem. it is the synth part that runs slowly 20.55.00 # it's a bunch of shifts, adds, multiplies, and memory access 20.55.10 # what memory? 20.55.12 # iram? 20.55.18 # no, the MP3 buffer 20.55.32 # the soundset it like 30 megs decompressed 20.55.41 # ah 20.55.51 # maybe that's a little too much? 20.55.55 # I guess the voice objects themselves can go in iram.. there's 100 of them and they're structs 20.56.04 # well only 8 megs or so are loaded for each file 20.56.17 # preglow know's more of the iram thing... 20.56.24 # yea 20.56.26 # I guess he can do something with it 20.56.35 # hmm? 20.56.37 # he said he could get this type of thing running fast easily 20.56.38 # hi 20.56.44 # easily? :P 20.56.50 # i don't know.. 20.56.57 Quit Tulkar[AFK] (Read error: 110 (Connection timed out)) 20.56.58 # the procedure is straightforward, yes, but it'll take time 20.57.05 # ah 20.57.10 # but yes 20.57.18 # how much do you think can get squeezed out of it? 20.57.21 # what you need to do is collect the data that is accessed frequently in one place 20.57.23 # and stuff that in iram 20.57.39 # yea, the voice objects. there's 100 and they're structs of a bunch of ints 20.57.46 # yup 20.57.54 # but right now you only have 32kb of iram 20.58.01 # that _might_ be increased to 64kb 20.58.01 # how much improvement do you think that would be > 20.58.14 # the improvements will be large if the data is critical 20.58.34 # do you still #include the .c files? 20.59.00 # yes :( 20.59.03 # then you need to make a proper build system before you do anything else, imho 20.59.05 # it's not hard 20.59.12 # preglow? 64k of iram? how? 20.59.15 # i estimate the voice array takes up about 5kb of space 20.59.16 # t0mas: how what? 20.59.26 # t0mas: there are 96kb iram available on the cpu 20.59.27 # wasn't 32 a hardware limit? 20.59.31 # ooooh 20.59.39 # t0mas: rockbox itself will probably require some of it as well 20.59.48 # yeah.. 20.59.50 # preglow, well the voice objects should fit 21.00.08 # unless I am missing something, each one takes 50-60 bytes or so. and there's 100 of them 21.00.38 # plus a few bytes for the current output sample, buffer position, any varaibles used to cycle thru them.. 21.00.55 # stevenm? how big are the numbers? 21.01.05 # maybe you could fit them in something smaller than int? 21.01.15 # the ones that can be, are 21.01.19 # ah ok 21.01.28 # I may be able to get rid of some deprecated ones 21.01.29 # well... 6000 < 6kb 21.01.30 # ouch 21.01.33 # zo it should be possible 21.01.41 # why did you commit the midi codec in plugins/ ? 21.01.48 # i told you that has to go in apps/codecs 21.01.51 # Linus said this was a good idea 21.02.00 # well, it will have to be moved 21.02.03 # Linus said to keep it a plugin for now and we can make it a codec later if needed 21.02.07 # hmm 21.02.07 # ok 21.02.28 # hm... 21.02.30 # but then you need to look at rockboy on how to make a proper build system out of it 21.02.39 # my bmp code from scratch starts to work :P 21.02.42 # but gimme a sec, and i'll have a quick look at the source 21.02.45 # it display's some lines now :) 21.02.54 # Maybe the whole synthvoice / getsample / etc chain can be made into a single function 21.03.04 # still don't understand the thing Bagder wrote... 21.03.25 # and I can prolly save a little time if I auto-convert all 8bit waveforms into 16bit in the loader so the synth doesnt have to worry about checking and shifting 21.03.39 # hmm 21.03.40 # that saves, like 2 operations 21.03.43 # i guess voices should be in iram 21.03.49 # yes 21.03.50 # do that 21.03.53 # ifs are evil 21.03.54 # midiutil.c is where the struct is defined 21.03.58 # yeah, i know 21.03.59 # oh god 21.04.14 # ifs are evil ? 21.04.32 # I guess if I do that, we can get rid of getsample() entirely and just shove the remains of it into synthsample 21.04.55 # I already made it auto-convert unsigned into signed 21.05.51 # getsample? 21.05.54 # i can find no getsample 21.06.55 # it's in synth.c 21.07.30 # give it a waveform pointer and a sample and it will return the sample in 16bit form based on wave size, etc 21.09.04 # ouch 21.09.07 # that sounds slow 21.09.12 # you should convert to one format internally 21.09.13 # yeah 21.09.36 # Yea I did half of that. Convert the sign in the loader, but it doesn't scale 8 bit samples to 16 bit ones yet 21.10.02 # couldn't think of how do to that last night without wasting memory, was too asleep. Now I have an idea 21.10.30 # without wasting memory? it should be fairly easy 21.10.34 # ie, if it's 8bit, allocate 2x the memory, fast read in the 8bit data into the first half of it, then work backwards 21.10.57 # I wanted to try to avoid reading it one byte at a time.. that seemed slower 21.11.27 # ahh, like that 21.11.42 # but, why do you have 8 bit samples anyway? :V 21.11.44 # they're evil 21.11.56 # Honestly, I don't even know if I do or not 21.12.12 # I have to check that out. This was supposed to be a very high quality patchset 21.12.29 # I put in 8bit support 'just in case' but I guess I can go thru and see if 8 bit ones exist at all 21.13.24 # but ok 21.13.38 # if you see 8 bit stuff, just use a small temp buffer to read data chunk by chunk 21.13.42 # that should be more than fast enough 21.13.52 # all right... 21.14.13 # maybe even I could just convert the 8bit files into 16bit and distribute those 21.14.32 # there's a batch converter on my roommate's box I think 21.14.43 # w000t :D 21.14.49 # my bitmap loading is working on pc... 21.14.59 # and the conversion to rbx format is half working.. 21.15.02 # so almost there :D 21.15.05 # no, if there are 8 bit samples around, make an 8 bit loader 21.15.11 # you might not have the copyright of the sample sets 21.15.11 # all right 21.15.23 # ah... 21.15.41 # preglow, do you think it would even be possible to make this realtime ? 21.16.40 # yes 21.16.54 # even if it runs 10% now, on an easy file ? 21.17.02 # i'm not certain, however, sample based formats need a lot of random accesses to slow ram 21.17.16 # as i said, i'm not certain 21.17.22 # i think it should be able to run realtime 21.17.22 # wow 21.17.29 # well, I have faith in you 21.17.37 # and that magical MAC instruction 21.18.31 # haha 21.18.40 # i won't have to work on it 21.18.40 # in the meantime, how do I declare a variable so that it ends up in iram ? 21.18.49 # ah 21.18.54 # there is a macro in plugin.h, i think 21.18.57 # and in codec.h 21.19.01 # IDATA_ATTR 21.19.01 # ah ok 21.19.10 # how do you use that ? 21.19.15 # char myarray[80] IDATA_ATTR; 21.19.52 # aah all right 21.20.27 # well, I am going to go eat my 3PM breakfast. 21.20.32 # I will talk to you guys later 21.20.49 Quit stevenm ("Leaving") 21.37.02 *** Saving seen data "./dancer.seen" 21.39.40 Quit edx () 21.57.24 Quit booper (Read error: 110 (Connection timed out)) 21.57.58 Join muesli_ [0] (muesli_tv@brsg-d9b8e19a.pool.mediaWays.net) 21.58.13 Quit muesli- (Read error: 113 (No route to host)) 22.26.50 Join stevenm [0] (~steve@stevenm-router.student.umd.edu) 22.40.42 # HCl: here? 22.41.03 # yes, but by sheer chance 22.41.04 # whats up 22.41.18 # I read through the runtimedb wiki page 22.41.23 # mmm? 22.41.35 # we need to take into account that the songdb gets updated 22.41.44 # i'm already aware of that 22.41.53 # but zogar and rasher insisted on changing my original design 22.41.58 # which didn't have a problem with it 22.42.04 # hello people 22.42.21 # i think they said that they would write the perl script that would read the songdb back in and keep track of everything and not mess everything up 22.42.32 # HCl: well, I didn't like the original one either 22.42.45 # How to declare an array in iram? putting IDATA_ATTR after a single variable works, but complains w/ syntax error if I do it after an array declaration 22.42.46 # feel free to suggest something better, heh. 22.42.57 # I like this suggestion 22.43.06 # mm? 22.43.06 # but it needs additional stuff to deal with songdb updates 22.43.13 # like what? 22.43.56 # well, preferably something smaller than the full path name 22.44.13 # hey preglow, it doesn't seem to like this: struct SynthObject voices[MAX_VOICES] IDATA_ATTR; 22.44.20 # i'm confused 22.44.30 # my original suggestion with something smaller than the full path name? 22.44.36 # no 22.44.39 # this suggestions 22.44.40 # then what? 22.44.41 # this suggestion 22.44.47 # the full path name is already part of the tagdatabase 22.44.47 # fixed to deal with updates 22.45.03 # its mostly just the problem of the updater program 22.45.09 # not necessairly the format 22.45.14 # I disagree 22.45.18 # mm? 22.45.21 # explain? 22.45.34 # it would require that the songdb.pl script has the *previous* db when you run it 22.45.39 # yup. 22.45.40 # and I don't like that 22.45.54 # can't help it much, heh. 22.45.59 # ? 22.46.05 # you're planning to store filenames in the rundb or what? 22.46.17 # even then, with the current approach, it would still need to be updated. 22.46.24 # I said it needs "a way" I didn't say how 22.46.31 # okay 22.46.36 # i hope you'll be getting to that, sorry 22.46.41 # sure it would need to get updated 22.46.55 # but only using the new songdb 22.47.02 # it would need the former one 22.47.07 # would NOT 22.47.37 # well, i don't understand how you plan to do this, aside from moving part of what the update script would normally do to the rockbox firmware itself. 22.47.43 Join Biptoria [0] (~d92ba1c6@labb.contactor.se) 22.48.00 # the current format is simply linked too harshly to the tagdatabase. 22.48.08 # I disagree 22.48.20 # how so? we use record ids to match song record ids 22.48.28 # it only lacks this little thing I'm talkign about 22.48.30 # its almost the same as including the runtime data into the tag database 22.48.32 # okay 22.48.34 # explain? :x 22.48.44 Quit muesli_ (Read error: 113 (No route to host)) 22.48.59 # well, you don't seem to want this format anyway 22.49.08 # * HCl shrugs hesitantly. 22.49.18 # i can live with it, as long as i don't have to write the updater. 22.49.31 # I want to be able to generate my songdb and copy it to my player 22.49.32 # calm down ladies 22.49.38 # without ruining my runtimedb 22.49.41 # * HCl is perfectly calm o.o; 22.49.48 # well... 22.49.52 # go ahead and propose something... 22.49.58 # I will 22.50.01 # personally, i wouldn't see how with the current format, but only with my old format... 22.50.05 # on the wiki? 22.50.13 # no, I'll post to the list 22.50.17 # have any ideas so far? or are you just not mentioning it :X 22.50.21 # mailing list? O.o. 22.50.22 # I have ideas 22.50.43 # but I think the problem here is that we all have different goals 22.50.50 # mailing list, yes 22.50.51 # i have no idea 22.51.03 # my goal is stated at the top of the runtime db wiki.. 22.51.21 # yes, but for example you don't say how you want to deal with updates 22.51.31 # or if you want to work without a tagdb 22.51.32 # etc 22.51.45 # we agreed a while ago that we wouldn't work without a tag database 22.51.51 # my old design could do pretty much all of it.... 22.51.52 # yes 22.51.57 # sigh 22.52.00 # when it was rejected i just mostly went "okay, how would you like it" 22.52.06 # its not really my brainchild 22.52.12 # but it shows we have different goals 22.52.13 # i suggest you talk to rasher or zagor :/ 22.52.19 # I will 22.52.21 # on the list 22.52.43 # i don't suppose you could easily subscribe me to the list or tell me where/what? 22.52.54 # http://cool.haxx.se/mailman/listinfo/rockbox 22.53.00 # i'm hardly fond of mailinglists, but i want to know progress on runtime database.. 22.53.14 # hmz... 22.53.18 # well, this list is where rockbox dev stuff is happening 22.53.26 # Bagder? do you know a way to "reverse" a unsingned char? 22.53.28 # not being there means missing lots of rockbox 22.53.33 # mhm, i'm generally not fond of email at all. 22.53.38 # t0mas: reverse? 22.53.43 # i prefer chat to discuss stuff.. 22.53.46 # yeah, bit to little endian 22.53.57 # is there a simple way for that? 22.54.06 # a char is only 8 bits, how can that be different endian? 22.54.25 # * HCl subscribes 22.54.25 # wait... 22.54.30 # ah, you mean the bits in the other order? 22.54.30 # I'm stupid... 22.54.34 # yes 22.54.41 # nothing to do with big/little endian 22.54.46 # just guessed it was that... 22.55.15 # t0mas: there's no shortcut or easy fix to switch order, you need to do it by ANDing bits and ORing them 22.55.33 # :( 22.56.06 # or EATing them 22.56.25 # do you see what i did there...? clever huh 22.57.16 # ? 23.00.00 Join muesli- [0] (muesli_tv@hmln-d9b8ef53.pool.mediaWays.net) 23.08.49 Quit Biptoria ("CGI:IRC") 23.17.21 Quit muesli- (Read error: 60 (Operation timed out)) 23.18.55 Join rasher [0] (~3e4f4094@labb.contactor.se) 23.20.24 Quit zezayer ("Chatzilla 0.9.67 [Firefox 1.0.1/20050311]") 23.20.46 # HCl: mailed 23.21.10 # hola 23.21.21 # evening rasher 23.24.53 # hm... 23.24.59 # lseek(fd, 62, SEEK_SET); 23.25.01 # I'll have a look.. but I'm really not that clever.. I'm more comfortable standing on the sideline, waiting for someone to say something I can comment on :) 23.25.09 # that would jump to byte 62 in my file right? 23.25.35 # t0mas: yes 23.25.46 # and when it returns -1 ? 23.25.50 Join muesli- [0] (muesli_tv@brsg-d9b8e198.pool.mediaWays.net) 23.25.53 # it failed 23.25.55 # this is strange 23.26.00 # ghehe 23.26.01 # i can actually remember registering for the mailing list 23.26.06 # but then again, i've never received any mail 23.26.14 # ok, and what are causes for it to fail Bagder? 23.26.24 # t0mas: errno has the answer 23.26.32 # hey preglow, the thing is complaining about IDATA_ADDR being used with an array of structs 23.26.38 # where do I find -1 ? 23.26.41 # for lseek? 23.26.45 # stevenm: what's the error? 23.27.16 # In file included from midi2wav.c:40: 23.27.17 # midi/midiutil.c:92: error: syntax error before "IDATA_ATTR" 23.27.32 # stevenm: do you include a file that actually has the IDATA_ATTR define? 23.27.38 # t0mas: is this rockbox ? 23.27.43 # yes 23.27.55 # preglow, yes, in midi2wav.c. It works fine there.. with ints and arrays of chars, anyway 23.27.58 # (I'm reading bmp files) 23.28.09 # stevenm: i can't imagine why it shouldn't work with structs 23.28.19 # oh wait... no.. this lseek isn't the rockbox one.. it's gnu libc 23.28.31 # preglow, it doesn't work in ANYTHING not declared in midi2wav.c 23.28.32 # I think... as I'm testing outside rockbox 23.28.34 # sorry :) 23.28.55 # heh 23.29.03 # preglow, like, it won't work on an int in synth.c... funny thing it, IDATA_ATTR is not defined in plugin.h... it's defined in xxx2wav.h of all things 23.29.05 # *then* you can check errno's value after the failure 23.29.06 # t0mas: did you work out the memory thing? 23.29.19 # rasher: yeah, most of it 23.29.25 # stevenm: well, i have no idea, i've always had it work, but then again i never used it on arrays 23.29.26 # Bagder: I'll check errno 23.29.49 # anyways, I work on that later. bye people 23.29.50 Quit stevenm ("Leaving") 23.30.18 # * t0mas includes errno.h and starts bughunting :) 23.36.05 Quit XShocK (" Want to be different? HydraIRC -> http://www.hydrairc.com <-") 23.37.04 *** Saving seen data "./dancer.seen" 23.41.14 # hm 23.41.20 # i think it'll take a while before i get your mail Bagder 23.41.30 # I got it 23.41.35 # prolly cause i told it to summarize every day 23.41.37 # yes, there are some >600 subscribers 23.41.38 # not 5 minutes ago 23.41.46 # HCl: ah, yes then most likely 23.41.54 # is it on the web with a link to it? 23.42.07 # http://www.rockbox.org/mail/archive/rockbox-archive-2005-04/0135.shtml 23.42.13 # thanks 23.43.36 # i don't understand your first bit, and the second bit is just moving stuff from the songdb script into the rockbox firmware.. 23.43.45 # no 23.43.53 # if you have offsets into the songdb and update the songdb then your offsets would be dead 23.43.59 # yes 23.44.13 # but please read 23.44.22 # what isn't clear? 23.44.28 # i don't understand what you mean with "a second way" either.. 23.44.35 # how offsets would help at all.. 23.44.46 # offsets work when they are in synch 23.44.52 # That's what Zagor and I were saying - let the tag-update script keep the runtimedb in synch 23.44.54 # the "other way" is for when they are not 23.45.08 # ah. 23.45.08 # rasher: and I disagree, as I wrote 23.45.29 # so pretty much, you suggest moving part of the tag-update into the rockbox firmware. 23.45.44 # the offsets are automatically calculated, you can store them to check whether they start to differ. 23.45.49 # Bagder: yeah, but it's the same idea sortof, just applied in a different scenario 23.46.10 # I don't want the songdb to require the FORMER db nor the runtimedb when updaing a songdb 23.46.16 # personally, i don't see the benefits of moving the load of a tag-update (the runtime db part of it) into the firmware. 23.46.28 # why not? 23.46.29 # "optional" is the key there 23.46.30 # It's just *potentially* doing that 23.46.37 # it doesn't require it 23.46.43 # it just happens when the previous already exists. 23.46.44 # yes it does 23.46.45 # no. 23.46.52 # only when there's an existing one. 23.46.54 # otherwise it'll break the runtimedb completely 23.47.12 # let me explain 23.47.23 # in the current format, to update a songdb and runtimedb 23.47.26 Join asdsd_ [0] (~asdsd@h-67-100-30-151.miatflad.dynamic.covad.net) 23.47.26 Quit muesli- (Read error: 113 (No route to host)) 23.47.29 # you need to run a program on the host pc... 23.47.50 # that program needs the current songdb and the runtimedb to generate a new songdb and runtimedb 23.48.06 # and if you then add some more songs 23.48.16 # ... 23.48.26 # then you rewrite the old songdb 23.48.31 # or if you forget, and don't use the current one... 23.48.32 # and then suddenly rockbox itself has to do all the work 23.48.36 # then you blow away the old runtimedb 23.48.39 # and fix the runtimedb 23.48.46 # it doesn't have to 23.48.46 # i don't see why you would move load to a player 23.48.51 # when you can just do it on the host pc. 23.48.53 # a smart user will do it while updating the tagdb 23.49.06 # but if something doesn't match, it *can* be done in rockbox 23.49.07 # if you forget, you do 23.49.21 # how can you forget? 23.49.21 # rasher: only with my (or similar) changes 23.49.29 # presuming we'll have a script that'll autodetect an existing db? 23.49.31 # Yes.. 23.49.43 # HCl: with a bit of luck, you can't :) 23.49.44 # HCl: the existing is on the player, I generate my on my host PC 23.49.47 # it cannot autodetect 23.49.56 # oh right 23.49.59 # at the moment it can't, no. 23.50.01 # aside 23.50.01 # see my mail (in a minute) 23.50.04 # it can't, ever 23.50.08 # from noticing the amount of rundb records 23.50.12 # not being the same as the amount of songs 23.50.18 # in which case it should start to scream. 23.50.39 # also the runtimedb is on the player too, which I don't want to be forced to have mounted just to update my songdb. even if it is wiser 23.50.55 # Mail sent. 23.50.57 # enlighten me on how you update the db on the player 23.50.58 # ? 23.51.07 # I copy it there 23.51.16 # but not necessarily at the same time I run the script 23.51.36 # HCl: assuming you have a local mirror of your player, or similarly.. run the tagdb-update using that 23.51.53 # o.o;; 23.51.59 # a local mirror of my player? 23.52.07 # sure.. I have 23.52.07 # of course I have a local mirror 23.52.18 # i definately don't have that o.O 23.52.22 # well some do :) 23.52.29 # * HCl sighs. 23.52.30 # okay, well. 23.52.32 # and since we have a say in designing the thing.. well :) 23.52.37 # i think i'll leave the database entirely to your hands 23.52.58 # i'm not really agreeing with it, but i'll go along as long as it will still be able to do the searches i want to make possible 23.52.58 # :-/ 23.53.26 # a local copy mirror of mp3 player contents? 23.53.29 # HCl: my additions as mailed here doesn't change anything major from the existing suggestion 23.53.29 # someone has that? 23.53.30 # i'll start to complain the minute it can't anymore though. 23.53.31 # :P 23.53.48 # Bagder: i'll just wait for the end result, to be honest, i'm starting to get slightly tired of it 23.53.49 # preglow: well I have symlinks that makes up a local mirror :) 23.54.09 # HCl: that's how developing things in a larger group is: compromises 23.54.16 # i know that 23.54.23 # i'm not rejecting it :P 23.54.41 # * Bagder remembers the language file format debate 23.54.44 # i'm just, not gonna try anymore to design the database, since we *clearly* have different mindsets 23.54.45 # oh that was good ;-) 23.54.47 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 23.55.00 # i'll only complain if the eventual format is not gonna be able to do what i need 23.55.08 # Bagder: and now... noone cares :) 23.55.09 # HCl: that works too 23.55.13 # rasher: yeps 23.55.13 # which is pretty much: 23.55.15 # smaller chanches of that happening if you don't participate 23.55.25 # rasher: everyone stopped caring the day it was introduced 23.55.28 Quit Harpy (Read error: 60 (Operation timed out)) 23.55.38 # well, it's not like we disagree on the goal 23.55.51 # so there should be few, if any, problems 23.55.52 # "being able to create an on the fly playlist that adheres the conditions the user throws at it, at a reasonable speed, example: "give me all the rocksongs of the 90 and 80's, that are longer than 3 minutes and have been played at least 5 times" 23.55.52 # in the end 23.56.15 # now the ui for creating such searches, I'm not so sure about 23.56.25 # that'll be tricky 23.56.34 # possibly we can use something from ipod? 23.56.55 # I'm guessing a "add condition" "type?" "value?" loop? 23.56.59 # the ui isn't too hard 23.56.59 # yes 23.57.04 # its the algorhythm that is. 23.57.05 # rasher: yup. 23.57.19 # "year" "above or equal" "1980" 23.57.27 # "year" "lower or equal" "1999" 23.57.33 # "genre" "contains" "rock" 23.57.34 # well the ui isn't *hard* as such.. it's just making it friendly that'll be fun 23.57.56 # "runtime" "above or equal" "300 seconds" 23.58.03 # length :) 23.58.07 # "playcount" "above or equal" "5" 23.58.12 Join zezayer [0] (~chatzilla@host81-152-218-69.range81-152.btcentralplus.com) 23.58.24 # and allowing to add (in theory) an infinite number of those conditions. 23.58.32 # doing the algo for that will be interesting 23.58.37 # 20 should be enough for everyone 23.58.37 # yes, its gonna be hard. 23.58.41 # ;) 23.58.45 # pretty much. 23.58.54 # hmm