@fastfinge The openevv project now has a PR to take care of the sample rate issues. Could you please incorporate it into Eloquence 64's openevv section for testing? Add a wideband voice, and do everything above 11,025 in whole numbers: github.com/Mudb0y/openevv/actions/runs/37492982819
@amir Is there any reason this has a checkbox? I'm struggling to understand why anyone would set a sample rate above 11025 kHz and want wideband off? I don't even understand why openEVV made this a setting. Is there any reason to not just have it always on?
@fastfinge There is one, I repeat, one, edge case where you might do this - You have a DAC that has terrible resampling and you want the 11 KHZ sound to not alias. Some integrated systems qualify. @amir
@amir@nick My worry is that too many checkboxes will confuse 99 percent of users, and then we get to spend the rest of our lives answering questions about why resampling doesn't work, or what that checkbox is for.
@fastfinge Which is why if I were you, I wouldn't implement it in the Eloquence addon. What lives in EVV upstream doesn't have to live in the addon. @amir
@fastfinge@nick Oh yeah! Damned got it! But compared with what we already have in other Eloquence 64 variants, or even in the older IBMTTS driver with ViaVoice, it's terrible.
@fastfinge@nick Honestly - and as I see it now and even as someone who sort of likes higher sample rates, the major issue holding openevv back is related to maddeningly troublesome ViaVoice quirks. Oddly enough, some appear to prefer ViaVoice to Eloquence. But I'm not one of them.
@amir@nick Same. I was sort of hoping that the ViaVoice quirks would either be fixed or made configurable, before any sample rate stuff happened. I think mudb0y just has so many people asking for so many different things right now, but hasn't quite developed the skill to say "no" or "later" to anyone. If I were him, I'd work with someone (even a non-programmer) to help him prioritize all the different things, develop a roadmap, and be the one to say "we're not doing this now, see the roadmap" for him, so he can focus on the actual work.
@fastfinge That requires discipline. I am not convinced he has it. Remember, in the midst of all of this, he decided to reverse engineer BestSpeech for...some reason. @amir
@nick@amir I can see that actually being a useful thing to do. Bestspeech is a much simpler engine than eloquence, so someone could probably learn and practice a lot of useful techniques on it. And I think it's more about...thoughtfulness than disciplin. Something it takes every good programmer (or every good person) years to learn. He does seem to stick with things and keep grinding away on them. But like, if you're not spending more time thinking about your changes than actually making your changes, well, you'll add that extra sample rate setting that nobody needs.
@fastfinge I really want to be wrong. Amir, you might actually be the most discipline out of the lot of us in documenting Eloquence behaviors, as it's part of your roll re: community dictionary. Can you write up all the differences you can find? It might be a good idea to create these in an issue and call them as regressions - given what Sam's Dad has to say about working at IBM, I'm comfortable with that designation. @amir
@nick@amir Honestly someone just needs to find a way to get Amir access to Claude Code or Codex. He could quickly fix so many things; he knows exactly what needs to happen and why in most cases.
@fastfinge That's an idea we should keep in our hats for now. Weirdly, I'm a touch hesitant that we should be digging in just yet because Stanislaw's agents already have processes and I'm not convinced they're documented in a way we can yet follow. At least, the docs intimidate me a bit anyway. If Stanislaw becomes unmoved for a time after the docs, then we'll talk about figuring out how to give Amir computing power to take a run at this. @amir
@nick@amir Yeah, that makes sense. Once I can get employed again I'm happy to throw a bit in the hat. Just...not until then, sadly. Though I do have prospects, so we shall see.
@fastfinge Yeah, I myself would feel more comfortable committing to someone's Claude Max for a month come Q1 27. Sam, you and i can discuss beforehand how to get around any possible geoblocking, E.G. putting a VM somewhere. @amir
@nick@amir Yeah, we could do that as well. I actually have used nano-gpt.com in the past, though, and they're reliable. In that case it was because OpenAI wanted my ID for age verification and I wasn't interested in giving them my passport.
@fastfinge Also, let's be on the lookout for someone who might do something similar for Finnish. ...God, I wonder what Ol' Stan's plan for that is, because that's gonna have to be reverse engineered all by itself. #headnova@amir
@nick@amir I know he's already done some work on adding Polish as a language, in order to learn what adding languages not already in viavoice will require.
@fastfinge The issue is that Eloquence already had the Finnish spec that somehow didn't end up in the IBM codebase he hammered. That means Finns are used to Eloquence behavior that already exists that someone is going to have to recreate whole cloth. Good luck, bro. @amir
@nick@amir Now that we know what a ruleset looks like, what fields it has, and how it's stored, it may well be possible to pull it out of the eloquence files.
@fastfinge ...Hope so. Really hope so. To me, the two thresholds are getting EVV to do Eloquence things, and getting Finnish. Once both of those things happen, I'm done with 64RS. This conversation makes me more hopeful that both things will happen though, because perhaps the three of us could come up witha solution if Mudboy does not. @amir
@nick@amir Another thing you could do, if you wanted to be done with RS sooner: using serde_pickle you should be able to create a rust host that communicates with eloquence_64 exactly the way the 32-bit Python host does. Then change your extension into something that just replaces the 32-bit Python host with a rust host when it's installed. That way we share literally all other code. I literally have a hook that can call a different executable as the host process. So it requires either a one-line change or no change on the eloquence_64 end of things. I don't know where or how you do resampling, so I have no idea the effects there.
@fastfinge Curves are currently happening at the host. Resampling is not, it's actually replacing Klat files - though the host is managing this. In truth, I am still willing to continue for another year, the addon still has more to teach me. Can we DLL-ize the Rust host without causing some of the weirdness that the IBM TTS addon had? that's my next project. @amir
@nick@amir The thing I've always wanted to do is just create ECI64.dll. It would have exactly the same functions as the 32-bit ECI, and would just use IPC to pass on the calls between the two different dll files. So an app can just call ECI64.dll if it's 64 bit, or ECI.dll if it's not. Either way the code would be identical, as ECI64.dll would handle all the bridging.
@nick@amir Could be. The primary reason I didn't do that, and created eloquence_64 at all, was because I couldn't figure out how to get it working. But if I had, it would have just been literally a one-line change to all existing eloquence addons to load a different DLL file. It still! feels like that should work, and is the way it should be done. I'm just not smart enough.
@fastfinge Neither am I man. We'd be relying on AI a little more than i think you're comfortable with. But at the same time...long game. Perhaps this time next year we'll be comfortable enough with a stable Rust host that we can just merge our efforts on the model you described. @amir
@nick@amir If you can get that model working in rust, as just another ECI dll, I'll add it as a back-end and turn that from a checkbox into a combobox. Because it would literally mean almost no extra code for me. Just load the host, or openevv.dll, or eci64.dll. My addon even already asks a dll what sample rates it will provide when I load it. So at that point you could offer whatever sample rates you wanted with no aditional code in eloquence_64.
@nick@fastfinge@amir if y'all would be open to this I would be very happy to add you as colaborators to OpenEVV. This project is massive, even with AI it's not optimal for me to work on it alone
@amir@Mudb0y@nick Best thing would be that list of ViaVoice regressions. Once that exists one of us can set Claude to work. A description of each plus a simple test case would help. We can then only mark each item as fixed when the provided test matches ECI.
@fastfinge@amir@nick yeah this would be very helpful. I might also tell my agents to automate some of this by comparing to Eloquence 6.1 by using the real libs and modifying our code to match the behaviour
@nick@amir Also, falling back to ECI for a single language isn't an issue. That's already what eloquence_64 does. It asks at startup what languages OpenEVV supports, then falls back to ECI for a language not included. I see a world where English gets better and better, and people slowly step by step switch over to OpenEVV. Then Spanish improves, and another group switches, etc. That's why I put it in the way I did. I don't think there'll be a single day where "Everyone uses OpenEVV now!" It'll probably happen over months and years, until we suddenly say "Hey, is anyone using ECI anymore? No? Okay, let's think about removing it."
@nick@amir Also, someone did create a tool to convert all espeak rules into openevv rules. But he wouldn't accept it, both because of licensing issues, and more because the project just isn't ready to have like 150 semi-working languages at this stage.
@fastfinge@nick Thanks. I'm trying to get either of those, but the sanctions are making it more difficult to pay for them. I know that Claud is almost out of the question as a few months ago it suddenly decided to ban Iranians who made an attempt to pay for it. But ChatGPT seems to be more lenient, at least for now.
@amir@nick Can you access nano-gpt.com? They offer the claude and gpt models, and they take payment via cryptocurrency. It's quite possible to configure either claude code or codex to use nano-gpt.com, so no problem there.
@nick@fastfinge LOL - let me take it as a compliment! But seriously, sure. I'll put my best foot forward to do that to document every difference I know.
@amir@nick Nick, how are you fixed for tokens? If Amir puts together the list, I'm tempted to just have Claude grind away at it and just submit a bunch of PR's to openevv. Unfortunately I'm between jobs, so three quarters of my tokens go to formatting resumes and stuff.
@nick@fastfinge@amir Excuse me for butting into this conversation, and I have no idea if this is worth anything in this context, but don't forget about the Eloquence Research Findings posts by @MutedTrampet
@jaybird110127 I didn't forget it and it's interesting fact, but I think Amir should still develop his own cross reference comparison. That post is a bit more general knowledge, there is a reason I didn't actively refer to it in this conversation. What we want is a lot colder, a lot more clinical. @fastfinge@amir@MutedTrampet
@nick@fastfinge Update: my first draft documenting 7 issues is ready. Of course, the first glitch sort of affects both of them in different ways. I'm sure there are other ViaVoice glitches, but I wanted to get the ball rolling. It would be great to also have others contribute to this. If you also give me hints here, I'll expand them for the document. Let me know if this format is suitable. Behavioral Differences Between Original ETI Eloquence and IBM ViaVoice wormhole.app/mMaK60#FC46fwVcmoKoTImQM-5Tew
@nick@fastfinge Also worth mentioning that the Community Dictionary hasn't targeted ViaVoice. If we're to adopt openevv one day, I'll make adjustments to ENURoot to also cover those ViaVoice quirks like composed, unread, and chased.
@amir@nick@fastfinge So adding any of the dictionaries to the android version of EVV will not fix those pronunciations? I installed it on the orbit player.
@jpellis2008@nick@fastfinge No. The Community Dictionary targets Eloquence. But ALTIBM dictionary, which is a really small project compared with the Community Dictionary, also targets ViaVoice. As mentioned, it's not as comprehensive as Community Dictionary, though.
@amir@nick Can eloquence dictionary files have comments? If so, I would suggest adding some way to have a dictionary entry that OpenEVV would process, but eloquence would ignore.
@fastfinge@nick Well, commenting hasn't been documented in the original Eloquence HLP file covering the dictionary. But this is something I should take a stab at.
@amir@nick@fastfinge my aim is to actually fix mispronunciations in openevv it self, so we can stop relying on dictionaries. If you're ok with me using the comunity dicts as a source I'll get on to doing that once the pressing issues are delt with, or along side other work
@Mudb0y You can fix the g2p rules to be better if you want but never remove support for dictionaries. There will always be foreign lonewords, names, internet slang, jargon, or other things that simply must be supplied in a dictionary, and taking that away from users is a net loss. @amir@nick@fastfinge
@Mudb0y@nick@amir I think we'll always need dictionaries though. We already have two sets, because people can't always agree on what's correct. I think there are certainly some issues that should get fixed in OpenEVV. But some should remain for dictionaries. I'm just not sure how that line should be expressed. Amir, do you have thoughts about this? Is there a way to make a systematic decisions about what rules are so general and useful they should get fixed in OpenEVV, and what should be left as a dictionary?
@fastfinge@nick@Mudb0y Honestly, I think it would be best not to touch the pronunciation rules. They’re so murky and problematic that if we try to fix something like the neuro- prefix rule, we might end up breaking something that was already working properly.
@amir@fastfinge@nick I don't know about that, I think there's room for experimentation here now that we actually have the power to do it. We obviously don't want to take crack like IBM did and go yolo on the rules, but stock dictionary entries and rule changes which make sense I think are fair game.
@Mudb0y@fastfinge@nick Well, experimentation isn't bad at all. But I suggest taking care of other issues first before tackling pronunciations. Stuff like long pauses upon navigation, sub-par quality of the sample rates, the nagging phrase prediction (SAPI 4 style) which can't be disabled and I haven't added to my file BTW, etc. These are more urgent than mispronunciations which have the dictionary work-around.
@amir@fastfinge@nick@Mudb0y What I'd probably say on this is that if there's a word where the default pronunciation is definitely incorrect in all cases, and adding an exception will fix this particular word without messing up other things, it should probably be added.
@nick@jaybird110127@amir@fastfinge I just started work on replacing all differing rules with their ETI equivalents. I'll update y'all on the progress soon tm
@Mudb0y@nick@jaybird110127@fastfinge Thanks a lot! Looking forward to whatever you come up with. Hopefully we can get the equivalent NVDA add-on to test the changes.
@Mudb0y@nick@fastfinge The problem is that at this stage at least, the Community Dictionary doesn't target ViaVoice. It just covers ETI Eloquence. ALTIBM does, but it's quite small by comparison. I can prepare a variant of the Community Dictionary for you. But I still suggest keeping pronunciation fixes out of the project PRs as people might want to add their own pronunciation flavors to the mix.
@amir What you could maybe fix is the entire clusterfuck that created St. Louis, though. That caused a huge debate in one of the community dictionary issues and the French Louis actually lost! If you can make it better distinguish when it should be each form that one can become part of OpenEVV. @Mudb0y@nick@fastfinge
@x0@Mudb0y@nick@fastfinge LOL - I remember that! I removed Louis mostly to keep St. Louis in tact. And since we have a space here, it can't be fixed by Eloquence/ ViaVoice dictionaries. Unless, of course, we cover St. Louis in openevv to make room for other Louis corrections in the dictionary.
@amir Yep. The fact is, many of eloquence/viavoice's contemporaries actually had handling for St., Dr., etc. This is common in synthesizer demos from the time, showing off their lingual skills by reading text containing those abbreviations and homographs. Eloquence, at least, completely skips handling them at all, except maybe if abbreviations are on? It has no handling for Mr., Mrs., or Ms. either, I had to add that on my NVDA side. Which causes absolute havoc with 2026.1's default sentence chunking actually, because it chunk breaks on the period there. I should probably make a case that the default chunking mode should be paragraph for that reason. St. is either Saint, as a prefix, or Street, as a suffix. Dr. is either Doctor, as a prefix, or Drive, as a suffix. @Mudb0y@nick@fastfinge
@x0@Mudb0y@nick@fastfinge All valid issues. If you enable abbreviations, you'll have proper reading of Mr., Mrs., or Ms., with a pause at least. But St. and Dr. or many others may have bad misinterpretations even when the context sounds clear and valid.
@amir But so many other things are outright borked by the stock abbreviations that I don't know a sane person who actually uses them if they have a choice. @Mudb0y@nick@fastfinge
@nick@amir This is exactly what's needed. Should be easy for whomever has the tokens first to get this into AI, have it create test plans for all the issues, then start working on fixes. Test plans should probably involve generating samples for humans to listen to and compare, as well as its own testing. I'm out of Claude tokens until Monday, sadly. So it won't be me yet.
