| 00:42:04 | | Quit othello7 (Ping timeout: 252 seconds) |
| 00:43:47 | | Join spork [0] (topic@126-232-20-31.ftth.glasoperator.nl) |
| 00:51:55 | | Quit dconrad (Remote host closed the connection) |
| 01:00 |
| 01:13:35 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 01:14:16 | | Join braewoods [0] (~braewoods@user/braewoods) |
| 01:17:11 | | Quit pixelma (Quit: .) |
| 01:17:12 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:18:00 | | Quit dconrad (Ping timeout: 252 seconds) |
| 01:18:12 | | Join amiconn [0] (jens@p4fd7f6f5.dip0.t-ipconnect.de) |
| 01:18:12 | | Join pixelma [0] (marianne@p4fd7f6f5.dip0.t-ipconnect.de) |
| 01:34:15 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:05:30 | edhelas_ | I think I might have a clue regarding my battery level issue. In powermgmt.c the faulty function is battery_level(void) that is returning percent_now that is actually a cached percentage. This value is updated in battery_status_update() that seems to relate to this case !storage_disk_is_active() || usb_inserted(), in my case I have a SD card adapter in my iPod. |
| 02:06:25 | edhelas_ | So I suspect that the storage_disk_is_active() is kind of always returning true which in the end never update the battery_level status. |
| 02:09:58 | edhelas_ | So this might be related to how the SD adapter ATA interface report its activity. |
| 02:13:53 | edhelas_ | I think that this case was there because the Voltage is dropping when the disk is spinning, but it's not an issue with SD adapters, maybe a simple "if(SD) return true" might solve it ? Is there a way to know if Rockbox is running on a SD based iPod ? |
| 02:14:12 | edhelas_ | *return false |
| 02:19:51 | | Quit jacobk (Ping timeout: 276 seconds) |
| 03:00 |
| 03:15:19 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 03:19:43 | | Quit dconrad (Ping timeout: 252 seconds) |
| 03:34:17 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:02:56 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 05:06:19 | | Quit advcomp2019_ (Ping timeout: 260 seconds) |
| 05:34:18 | *** | Saving seen data "./dancer.seen" |
| 05:46:26 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 05:49:41 | | Quit advcomp2019__ (Ping timeout: 248 seconds) |
| 06:00 |
| 06:16:39 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 06:21:34 | | Quit dconrad (Ping timeout: 260 seconds) |
| 07:00 |
| 07:06:28 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 07:13:44 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 07:34:20 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:13:38 | | Quit dconrad (Remote host closed the connection) |
| 08:16:39 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 08:21:06 | | Quit dconrad (Ping timeout: 248 seconds) |
| 08:29:12 | | Quit Bobathan_ (Ping timeout: 265 seconds) |
| 09:00 |
| 09:17:02 | edhelas_ | speachy thanks for the fix, can't wait to try it ! |
| 09:34:21 | *** | Saving seen data "./dancer.seen" |
| 09:47:17 | | Quit Galois (Remote host closed the connection) |
| 09:47:36 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 09:52:44 | | Quit jj5 (Remote host closed the connection) |
| 09:53:09 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 09:57:13 | speachy | edhelas_: Unfortunately I don't have any way of testing it (my ipod5g's zif connector broke) |
| 10:00 |
| 10:02:02 | _bilgus | edhelas_, nice sleuthing.. |
| 10:04:10 | speachy | if that translatable-database thing works out as I hope, then extending it to full voicing of the DB is only a smidge more work. |
| 10:04:26 | _bilgus | speachy pushing the virtual ptr through name should work nicely without carrying around langid and checking P2ID |
| 10:05:11 | speachy | yeah, I was fairly confident that was the case, but I needed to double check before I weighed in. |
| 10:08:38 | speachy | overlaying the db browser onto the database tree viewer gives us a lot of stuff for free but it also suffers a bit from a square-peg-round-hole at times. |
| 10:11:40 | _bilgus | voicing the db is one of those long time TODOs |
| 10:13:47 | speachy | there are some fundamental non-i18n-able aspects of the current design, unfortunately. |
| 10:14:17 | speachy | (due to how the entire menu structure is defined in a user-modifiable configuration file) |
| 10:15:39 | speachy | Hmm, one thing that would help is to have the DB itself generate the list of "first letters" instead of relying on the static menu list. That way we can pull that aspect out of the config file and into the core. |
| 10:16:03 | speachy | (And I don't use the DB at all, heh..) |
| 10:17:11 | _bilgus | TBH i don't use it a lot either I usually just generate huge playlists but I think the random selection makes that a better way now |
| 10:19:26 | speachy | sweet, the mini2g came back to life. I can now test my patch |
| 10:19:54 | _bilgus | find a good ribbon cable I assume? |
| 10:20:57 | speachy | no, the battery had apparently died on itand it wuoldn't power up |
| 10:21:31 | speachy | the 5.5g I have with no audio out (and now, a broken drive zif connector) remains a basket case. |
| 10:21:44 | speachy | will probably take another change on ebay for a replacement motherboard... |
| 10:24:30 | rb-bluebot | Build Server message: New build round started. Revision e0df9952fd, 345 builds, 10 clients. |
| 10:24:30 | rb-bluebot | ata: Alter ata_is_active() when drive doesn't support power management by Solomon Peachy |
| 10:24:56 | speachy | smoke test passed, granted that doesn't test the ipod6g code path but eh.. |
| 10:29:55 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 10:34:44 | | Quit dconrad (Ping timeout: 260 seconds) |
| 10:35:01 | rb-bluebot | Build Server message: Build round completed after 632 seconds. |
| 10:35:03 | rb-bluebot | Build Server message: Revision e0df9952fd result: All green |
| 10:37:03 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 10:39:48 | speachy | meanwhile. I think perhaps we should flag all punctuation/symbols in voice strings other than ' , . |
| 10:40:13 | speachy | still finding stuff (eg '|' plus paranthesis and other stuff that really doesn't voice properly) |
| 10:43:40 | rb-bluebot | Build Server message: New build round started. Revision a056150d52, 345 builds, 10 clients. |
| 10:43:41 | rb-bluebot | updatelang: Flag '|' in voice strings too by Solomon Peachy |
| 10:45:06 | speachy | I'm not a fan of the large number of additional strings added in that db i18n stuff, but it's pretty much a 1:1 map of what's already in tagnavi.config and I don't think it's reasonable/feasible to attempt to concjucat in a way that will work for everything |
| 10:49:40 | _bilgus | add in multiple languages and that becomes an even harder task, I think our eventual path will probably be to separate out the lang files for plugins |
| 10:50:55 | _bilgus | basically load second voice file when plugins load problem being that you still have stuff in core so thatd need duplication or a way to have both at the ready |
| 10:52:01 | _bilgus | so probably a script to parse them (plugin lang strings) to go with it |
| 10:52:59 | speachy | them there's the matter of a sane way to present all of that to translate.rockbox.org or whatnot |
| 10:53:22 | speachy | it's not the "in core" aspect, it's the "sheer total number" |
| 10:53:57 | _bilgus | I think you'd just keep the whole scheme as is they are pretty well delineated and do the separation on the build side |
| 10:54:16 | speachy | after this i18n-the-db eventually lands, I want to get rid of the static A-Z alphabetic entries and make that dynamically generated from the DB contents. |
| 10:54:26 | rb-bluebot | Build Server message: Build round completed after 647 seconds. |
| 10:54:27 | rb-bluebot | Build Server message: Revision a056150d52 result: All green |
| 10:55:09 | _bilgus | I think thats a good idea anyway but need to make it backwards compatible in that a lot of people have custom ones and you don't want to break them |
| 10:56:20 | speachy | the only customization I can conceive in the A-Z stuff is "adding $language's alphabet" |
| 10:56:25 | _bilgus | probably just searching for the current headers and ignoring the ones that you'll be generating |
| 10:57:30 | _bilgus | I wasn't really concerned with their customization in that menu just that if you loaded an older tagnav you'd get both maybe thats not too bad versus the work of checking |
| 10:57:31 | speachy | if you'v ecustomized it, I don't expect anything to _break_ as we have to support the existing syntax anway. This would be some sort of unspecified extension. |
| 10:57:51 | speachy | (and a chagne to the default tagnavi.config) |
| 10:58:46 | _bilgus | so in that case make it optin and have a placeholder tag?? (#ALPHABETICAL_LIST_HERE) |
| 10:59:15 | _bilgus | pretty close to free then |
| 10:59:25 | speachy | it would have to be some new token for the engine to parse/handle, yeah. |
| 11:00 |
| 11:00:16 | speachy | the way it works now is that the user is not supposed to modify tagnavi.config in-place; they're supposed to copy it to a different name −− and if that different file exists, it will be used exclusively. |
| 11:01:04 | speachy | my goal is that if the user is using the defuault tagnavi.config they'd see no difference, except for a potentially expanded list of "first letter" entries. |
| 11:01:17 | edhelas_ | Why is the percent_to_volt_discharge and percent_to_volt_charge different with the 6g and similar with the nano2g ? With the 1200mah battery that I have it gives weird behaviours (30% battery remaining => plug charger => charging from 6%) |
| 11:01:39 | | Quit jj5 (Remote host closed the connection) |
| 11:02:01 | edhelas_ | speachy your patch fixes the issue :) But the percentage is far from stable, it seems that the curves doesn't fit with the battery I have |
| 11:02:04 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 11:03:07 | speachy | it's probably because nobody analyzed the nano2g's battery curves carefully, or it was "close enough" as to not matter. |
| 11:03:10 | _bilgus | edhelas there should be a menu to change you capacity if the devices differ between models but otherwise its a compiled change if you have something odd |
| 11:03:59 | speachy | if the new battery has the same chemistry as the original, the percentage tables will be accurate. |
| 11:04:08 | _bilgus | if you have a stock battery (or if you don't) you can do a battery bench to update the curves |
| 11:04:47 | _bilgus | basically do 3 runs from full to empth average them and choose some points to be your new levels |
| 11:05:04 | speachy | but that's a big _if_. putting aside the questionable quality of "replacement" batteries, there have been plenty of legitimate changes in battery chemistry over the past couple of decades. |
| 11:05:22 | edhelas_ | I changed the capacity in the menu already, its more about the voltage. From what I see the 6G is the only one to have different values between percent_to_volt_discharge and percent_to_volt_charge tables. For IPOD_NANO, IPOD_VIDEO... and all the others the two tables are the same. |
| 11:06:03 | edhelas_ | You can check powermgmt-ipod-pcf.c and powermgmt-6g.c |
| 11:11:33 | speachy | only thing to realyl do is to run the battery benchmark with what's in there, and genrate a new set of tables. |
| 11:11:50 | _bilgus | well basically the bettery bench will help correlate that but likely its not going to be perfectly linear being that you are extrapolating that whole range in only 10 steps but it should be good enough |
| 11:13:05 | | Quit jj5 (Read error: Connection reset by peer) |
| 11:13:37 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 11:14:49 | _bilgus | and its likely to be different between users with even the same battery as that will change between manufacture runs it'll change depending on the battery remaining lifetime and might change if you have a heavier load (sd versus spinning disk) |
| 11:16:19 | speachy | all that really matters is our upper and lower thresholds. and even then uppper doesn't matter if SW isn't in control of battery management. |
| 11:16:46 | _bilgus | but the idea is to get it close enough to give an indication (hopefully accurate) |
| 11:17:47 | _bilgus | the real danger is for devices that use SW powermanagement for the lower bound but the battery will still cut you off |
| 11:18:10 | _bilgus | so then its atleast just a unexpected powerdowm |
| 11:18:52 | _bilgus | suppose same with the upperbound but again the battery should save you |
| 11:20:55 | _bilgus | I don't know if we still have any devices where we have to do all the charging stuff (we used to not sure if it went away with hwcodec players) |
| 11:21:49 | speachy | I don't think any of our targets require SW management of charging. beyond plugging parameters into a PMIC/BMIC anyway. |
| 11:22:26 | _bilgus | hopefully they went away :) |
| 11:34:25 | *** | Saving seen data "./dancer.seen" |
| 11:34:42 | | Join Trzyzet_ [0] (~Trzyzet@live-34-b2-v4wan-169259-cust832.vm29.cable.virginm.net) |
| 11:35:05 | | Join gevaerts_ [0] (~fg@user/gevaerts) |
| 11:39:31 | speachy | ugh, the LiIon archos devices required SW to manage charging? |
| 11:41:25 | | Quit Trzyzet (*.net *.split) |
| 11:41:25 | | Quit baltazar (*.net *.split) |
| 11:41:26 | | Quit gevaerts (*.net *.split) |
| 11:41:26 | | Quit toruvinn (*.net *.split) |
| 11:41:26 | | Quit q3k (*.net *.split) |
| 11:41:30 | | Nick Trzyzet_ is now known as Trzyzet (~Trzyzet@live-34-b2-v4wan-169259-cust832.vm29.cable.virginm.net) |
| 11:43:06 | | Join baltazar [0] (~baltazar@user/baltazar) |
| 11:43:06 | | Join q3k [0] (q3k@hswaw/infra/q3k) |
| 11:47:09 | | Join toruvinn [0] (~toruvinn@KD119106027116.ppp-bb.dion.ne.jp) |
| 11:58:40 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 12:00 |
| 12:00:13 | | Quit jj5 (Remote host closed the connection) |
| 12:01:31 | OlsroFR | hello all; I add to read a lot of messages today in IRC haha. I just finished processing all reviews on my merge request and pushing patches. |
| 12:01:46 | OlsroFR | But I don't know how to use "name" as a pointer to also store the integer in it |
| 12:02:09 | OlsroFR | feel free to amend my merge request with your own solution for this |
| 12:02:22 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 12:04:30 | _bilgus | do your check english to id then convert to P2STR and place in name on the other end you use P2ID to see if its a lang entry |
| 12:05:10 | _bilgus | speachy might get to it if not i'll try to look tonight |
| 12:05:42 | speachy | won't be able to have another look at it until tonight |
| 12:44:22 | | Quit TheEater1 (Quit: WeeChat 3.8) |
| 13:00 |
| 13:24:46 | OlsroFR | Ah you want me to directly put the correct name in the "name" field. The issue by doing so is that we need to retrieve the ID again later for voice speech... |
| 13:25:11 | speachy | name = ID2P(LANG_WHATEVER) |
| 13:25:39 | speachy | later when you need the string you'll do whatever = P2STR(name) |
| 13:26:32 | OlsroFR | P2STR will tell if it is a localized string and will fail otherwise ? But what is an entry (like an album name) has a name that is localized ? |
| 13:26:40 | speachy | (and we'll use P2ID(...) to retrieve the ID for voice purposes) |
| 13:26:41 | OlsroFR | We don't want to localize real album names |
| 13:26:56 | OlsroFR | or dynamic things like that |
| 13:26:57 | speachy | look up the definition of that |
| 13:27:11 | speachy | if it's a non-localized string it just returns the parameter. |
| 13:27:19 | OlsroFR | OK |
| 13:27:42 | OlsroFR | I am going to work on a patch to try to do this |
| 13:28:25 | | Quit OlsroFR (Quit: Client closed) |
| 13:34:26 | *** | Saving seen data "./dancer.seen" |
| 13:36:43 | | Quit cnx (Remote host closed the connection) |
| 13:37:33 | | Join cnx [0] (~cnx@tem.loang.net) |
| 14:00 |
| 14:26:00 | | Join Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 15:00 |
| 15:22:26 | | Quit jacobk (Ping timeout: 248 seconds) |
| 15:23:03 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 15:34:30 | *** | Saving seen data "./dancer.seen" |
| 15:35:35 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 15:35:38 | OlsroFR | Patch pushed ! :) |
| 15:35:43 | OlsroFR | I now use the name pointer |
| 15:36:15 | OlsroFR | Adding voice control in top of that should still be trivial after this patch |
| 15:56:55 | | Quit OlsroFR (Ping timeout: 256 seconds) |
| 15:58:48 | _bilgus | OlsroFR I've got a different patch for you to look at |
| 16:00 |
| 16:06:21 | _bilgus | g#5934 |
| 16:06:24 | rb-bluebot | Gerrit review #5934 at https://gerrit.rockbox.org/r/c/rockbox/+/5934 : Database Voicing by William Wilgus |
| 16:07:46 | _bilgus | that still needs work but it does work I hadn't gotten to the actual voicing part but I think you see the idea |
| 16:07:53 | speachy | _bilgus: that patch won't compile...? |
| 16:08:10 | speachy | since it requires a variable that you nuked |
| 16:08:20 | speachy | oh wait nvm |
| 16:08:32 | _bilgus | I was like it compiles for me?? |
| 16:11:28 | _bilgus | what might be better is to carry the translation through a pointer rather than doing the translation in that buffer copy |
| 16:12:22 | | Quit Bobathan (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 16:12:41 | | Join Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com) |
| 16:12:51 | _bilgus | ln 1808 |
| 16:13:42 | _bilgus | sorry ln 809 |
| 16:16:45 | _bilgus | no it is 1808, 809 OTOH needs some guards to limit its scope |
| 16:23:37 | _bilgus | well I guess parse_search() is already limited to the loaded tagnav file so no issue there |
| 16:25:32 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 16:30:13 | OlsroFR | look like your patch was based on a former version of mine _bilgus. Since then, I now use fully name pointers, I do not even store lang_id anymore :) I put placeholders to add easily voice speech in my last patch |
| 16:32:04 | OlsroFR | your solution probably works too though |
| 16:33:05 | _bilgus | you still store them static char* current_title_refs[MAX_TAGS]; |
| 16:34:04 | OlsroFR | Yes it seems like it is needed for retrieval to store refs in this case |
| 16:34:05 | _bilgus | the other thing is the overhead yours has to do that logic every refresh i believe |
| 16:34:26 | _bilgus | where as what I pushed does it once at load |
| 16:34:32 | OlsroFR | yes. That's why my very first proposal was to cache everything at boot and refresh it only on language change |
| 16:34:43 | _bilgus | mine needs no caching |
| 16:35:30 | OlsroFR | I guess we should use your solution, it is less confusing that my last patch |
| 16:35:35 | OlsroFR | than* |
| 16:35:47 | OlsroFR | I am going to compile it to test it |
| 16:38:31 | _bilgus | the idea is for you to take it from there and finish it up should be enough to get you going but hold off a bit speachy might have some ideas |
| 16:38:50 | _bilgus | better implementation in mind |
| 16:40:29 | | Quit jacobk (Ping timeout: 260 seconds) |
| 16:40:52 | OlsroFR | OK. I will wait. I tested your implementation. Entries are fine. All titles are not translated (all root titles), like "Database". |
| 16:41:58 | speachy | I want to see what the latest rev looks like. I expect I'll want to incorporate some of #5934 but some of it feels like a step backwards (in part because it carried over some things I wanted to see changed) |
| 16:42:29 | speachy | and yes, we want titles translated too. :D |
| 16:43:14 | _bilgus | I'm not sure I follow everything looks translated to me |
| 16:43:57 | OlsroFR | Feel free to look what I pushed to use 1 hour ago to use the name pointer speachy |
| 16:44:40 | OlsroFR | _bilgus Set your player in french, enter the db, then you will see that the title will be "Database" with your patch. It should be "Base de données tags" when things are properly translated |
| 16:44:59 | _bilgus | oh the top level item |
| 16:45:57 | _bilgus | just didn't make it that far |
| 16:46:39 | speachy | turns out that the top level item has historically been not translated |
| 16:46:56 | speachy | (overlooked, not intentionally) |
| 16:46:58 | OlsroFR | Aside of dev things, today I received the Bose sounddock II I was waiting for. It's sounding damn good and I could get one for very cheap (just around 30 dollars). Now that I use docking features, I can understand why certain options exists like enabling auto backlight on each track change ;) . |
| 16:47:34 | speachy | every feature is there because _someone_ found it useful and convinced at least one other person. :) |
| 16:48:20 | OlsroFR | speachy The whole database entries were not translated, including titles. I had to fill up the static files with all the texts to allow translation. Top titles are translated in all other context (if I enter the "Settings", it's correctly translated) |
| 16:49:29 | OlsroFR | It seems like the whole database context was coded without any kind of translation in mind at all |
| 16:49:31 | speachy | Over the past year I've fixed a bunch of titles in other contexts. |
| 16:50:05 | OlsroFR | Ah OK. The rest of the Rockbox experience feels translated everywhere (especially in french thanks to the recent work of edhelas) |
| 16:50:53 | OlsroFR | Also, increasing the contrast is another useful option to better see the screen when the iPod is docket. It is helping a lot to read the text especially when it is scrolling |
| 16:50:57 | speachy | the FR translation could still use attention; the voice strings with flagged problems and the large pile of "same as english" stuff that needs to be audited and either translated or annotated as intentional. |
| 16:52:04 | speachy | speaking of FR, if you or edhelas wants to volunteer to maintain the FR translation, let me know and I'll add you to the notify-on-updates list. |
| 16:52:35 | | Join COMPL_EXE [0] (~compl.exe@aosc/dev/origincode) |
| 16:53:11 | speachy | (all of the languages that are at 100% have mainatiners that similarly volunteered) |
| 16:54:10 | | Quit sam_d (Quit: Bye) |
| 16:54:22 | speachy | but yeah, the DB stuff stood out quite dramatically, not just a lack of translation but also the lack of voicing. very surprising given how much attention has been paid to this in the rest of rockbox. |
| 16:54:47 | | Join sam_d [0] (~sam@user/sam-d/x-8933526) |
| 16:57:34 | speachy | putting aside my "maintainer of last resort" on everything else, improving the localization and voicing stuff has been my main interest in rockbox. which is hilarous given how uni-lingual I am. |
| 17:00 |
| 17:02:13 | COMPL_EXE | Hi, I sometimes get usb_dw_gonak_effective failed panic on my FiiO M3K with the latest nightly build when unplugging my usb cable, is there any solution or is that a known issue? |
| 17:05:09 | _bilgus | I get a similar panic sometimes haven't seen it in quite a while |
| 17:05:20 | speachy | _bilgus: where I want to go wrt the voicing of the db stuff is to create a hierarchy of talkclips, one per indexed field, for each file in teh database. ".rockbox/talkclips/artists/GeriatricRockers.talk" or "genre/AngryWhiteChickMusic.talk" or whatever. |
| 17:05:33 | _bilgus | COMPL_EXE, are you using the latest dev versions? |
| 17:05:59 | speachy | yeah there were some USB fixes merged within the last month-ish IIRC? |
| 17:07:14 | | Quit OlsroFR (Quit: Client closed) |
| 17:08:17 | _bilgus | believe it was g#5825 _lists_uiviewport_update_callback() was getting called with bad data |
| 17:08:21 | rb-bluebot | Gerrit review #5825 at https://gerrit.rockbox.org/r/c/rockbox/+/5825 : [Bugfix] crashes on usb unplug, extra text on USB screen, viewportmgr ovfl on sim by William Wilgus |
| 17:09:02 | _bilgus | might be something newer too but I haven't seen it crash since then |
| 17:14:37 | _bilgus | speachy so you want to just call the talk files for each header then what switch them out per language isn't that going to be a ton of files to carry around? |
| 17:15:23 | speachy | it is, but.. there's no other way to voice the tags. one clip per unique string |
| 17:15:50 | _bilgus | well they are indexed so could you do db_engilish.talk |
| 17:15:59 | speachy | the headers etc will prefer the master lang file if possible |
| 17:16:00 | _bilgus | db_francisis.talk |
| 17:16:24 | speachy | but if the user customizes them they can provide .talk files for those headers. |
| 17:16:32 | _bilgus | ah |
| 17:16:57 | speachy | eg .rockbox/talkclips/database/headers/SomeCustomizedHeader.talk |
| 17:16:57 | _bilgus | but you could also just give them a plugin to smush and index them into a single file |
| 17:17:28 | speachy | I see that as a future optmization that may not make sense |
| 17:17:35 | speachy | consider that files (and db entries) come and go. |
| 17:17:41 | _bilgus | idk I guess its not terrible till you go adding more languages |
| 17:17:55 | _bilgus | good directory structure would help |
| 17:18:05 | speachy | eh, there's no need for multiple languages in this context |
| 17:18:08 | _bilgus | the calling side is simpler here |
| 17:18:44 | speachy | the user customizes their stuff? they generate the talk clips in their preferred language and that's that. as far as we're concerend, it's just a UTF-8 sequence to look up. |
| 17:19:25 | _bilgus | OH ok so you want to add a way for them to do talk clips like we do for folders |
| 17:19:38 | speachy | yep. |
| 17:19:47 | _bilgus | I was reading that as you wanted us to do that always |
| 17:19:53 | _bilgus | gotcha |
| 17:20:33 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 17:21:04 | speachy | so we'll need a tool that parses the dbfile on disk and generates a list of all the necessary strings, which it can then pass into the voice generation tooling. |
| 17:21:37 | speachy | heck this could even be done entirely in a plugin if we manage to integrate espeak, but I really want to support offline systems due to vastly higher quality options. |
| 17:22:50 | _bilgus | I think as long as it will fit I can get that espeak with static allocation running I have the make file about half way there after that I'll see if I can get it closer to upstream |
| 17:22:51 | speachy | what I expect to do is build out the code tha tlooks for these talkclips and get that tested, commit that then phase 2 will be the enhanced dbtool/voice.pl generation stuff. |
| 17:23:24 | speachy | once I have an end-to-end working implementation, rbutil can probably be extended to do this as well. |
| 17:23:59 | speachy | (or maybe the string extraction will be done in a plugin unconditionally, and that file can be passed into whatever. that's all TBD) |
| 17:24:04 | _bilgus | my fear after looking at their (espeak) commits the addition of malloc adds a lot of 'features' that just serve to make it slower for us |
| 17:26:36 | _bilgus | I'd assume a perl script should suffice to pull the names out of tagnav but a plugin/native command line driven version might work out better |
| 17:27:55 | _bilgus | then you could have the same-ish code in the same module for the plugin and the build side |
| 17:29:32 | speachy | we have a per-device dbtool build; I need to investigate if that's still necessary or we can get away with a universal binary. |
| 17:32:03 | speachy | it _looks_ like the actual on-disk metadata is the same regardless? |
| 17:34:32 | *** | Saving seen data "./dancer.seen" |
| 17:35:20 | speachy | it does appear that in the swcodec-only world, all builds should work with the same dbtool binary. |
| 17:37:35 | _bilgus | it has handling for endianess in our bin I think and do we have any devices with opposing endian ???? |
| 17:39:33 | speachy | I think m68k and the native ARM targets are all BE, mips is LE? |
| 17:40:02 | speachy | hosted ARMs could go either way I think |
| 17:40:28 | speachy | ugh, forgot about the endianness. |
| 17:40:34 | COMPL_EXE | _bilgus: I was using 20240915 I believe |
| 17:41:09 | _bilgus | COMPL_EXE, then thats new enough then |
| 17:41:17 | speachy | so creation of the dbfile probably has to remain at least somewhat target-aware but the data extraction can be universal since the DB files have a header with a magic value that will tell us the endianness. |
| 17:42:25 | speachy | I can't imagine the overhead of making the on-disk format to be a fixed endianness would be all that bad. |
| 17:43:41 | _bilgus | unless you are on the wrong side of it lol |
| 17:44:19 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 17:50:55 | speachy | I mean there's not that much numeric data. we don't use the on-disk structures in RAM. |
| 18:00 |
| 18:20:04 | | Nick Bubblegumdrop_ is now known as Bubblegumdrop (~znc@user/Bubblegumdrop) |
| 18:59:10 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 19:00 |
| 19:00:52 | | Quit davisr (Quit: yeehaw) |
| 19:04:48 | | Join davisr [0] (~davisr@fsf/emeritus/davisr) |
| 19:28:54 | | Quit Bubblegumdrop (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
| 19:29:25 | | Join Bubblegumdrop [0] (~znc@user/Bubblegumdrop) |
| 19:31:33 | | Quit Bubblegumdrop (Client Quit) |
| 19:32:33 | | Join Bubblegumdrop [0] (~znc@user/Bubblegumdrop) |
| 19:34:36 | *** | Saving seen data "./dancer.seen" |
| 19:34:42 | | Quit Bubblegumdrop (Client Quit) |
| 19:35:28 | | Join Bubblegumdrop [0] (~znc@user/Bubblegumdrop) |
| 19:39:30 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:6510:df5c:44b6:6738) |
| 19:49:58 | | Quit davisr (Quit: yeehaw) |
| 19:50:04 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02:77cb:6304:f9db:dda1) |
| 20:00 |
| 20:06:24 | | Quit jacobk (Ping timeout: 260 seconds) |
| 21:00 |
| 21:05:43 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 21:09:41 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 21:34:39 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:16:51 | | Quit Moriar (Ping timeout: 246 seconds) |
| 22:57:23 | | Quit dconrad () |
| 23:00 |
| 23:06:40 | | Quit othello7 (Ping timeout: 272 seconds) |
| 23:08:28 | | Quit massiveH (Quit: Leaving) |
| 23:34:42 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).