@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 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.
@fastfinge Somethign to think about. ...In fact, I think I know something else I'm going to do, I'm going to make the addon rip the Contours out of the monolythic host and DLL-ize them in preparation for the idea you just had. @amir
@amir@nick Your AI agent could honestly look at how eloquence_64 loads OpenEVV now to understand the calls and hooks it needs to provide. Once it makes something compatible all I have to do is put it in the combobox as an option, and configure my build process to pull it from your github.
@nick@amir Another thing a dll file would solve is the nonsense around using the addon on secure screens. NVDA will copy dll files just fine. Okay, sleep, now! LOL
@nick@fastfinge@amir Sorry to butt in. I'm really interested in this stuff but I'm finding it a bit difficult to locate myself, which projects exists, what they are doing, etc. How can I get a sense of what is being done, what needs to be done, and possibly get involved?
@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
