I decided to jump early. Eloquence64RS 19.5 Beta 5 is out. In 11 KHZ mode, we've cherry picked @fastfinge's buffer improvements. We've also replaced the Presence contour checkbox with a Sound contour dropdown, so you can choose the sound you prefer without losing your previous selection. Those who liked the 16 KHZ Presence contour from Beta 2 get it back, the current one is renamed Smooth. 11 KHZ Presence Contour remains unchanged.
Whoops! Eloquence64RS 19.5 Beta 5.1 has just been released, Fixing Eloquence failing to load at NVDA startup when restoring a saved sound contour. Settings restoration could try to refresh the contour dropdown before NVDA had created its GUI, causing Eloquence to fail and NVDA to fall back to another synthesizer. Thanks @amir for reporting this one!
Remember what RS stands for in Eloquence64RS? Rust! 19.5 Betas kinda forgot that. It remembers now in RC1, which I've just released. Native voice data is now patched in memory and written to its private temporary files once, avoiding the extra copy and reread during initialization. This is the type of thing compiled Rust code is good at. Loading the 16 KHZ mode should be 21X faster.
I want to thank @ground024 for an Eloquence pop report, but in reproducing it I discovered something I really don't like. We're going to have to raise that buffer in 16 KHZ mode a little bit, and responsiveness will be effected. ...This is when I remind everyone that in 16 K mode, we are asking the synth to do things it was never designed to do.
@amir No. That buffer is perfectly fine, probably Eloquence's Golden ratio when operating at normal spec. The addon can and will treat these as separate implementations. @ground024
@amir I should say that I'll only raise the buffer commensurate with what it takes to stop it from clicking and popping. The hope is that you will experience something more like the keypress delay you'd get in beta 4, rather than something significantly worse. However, we do have to make it so that an average sentence won't make the thing pop more than its 11 KHZ version, otherwise it's irresponsible for me to call it stable. @ground024
@nick@ground024 BTW I also suggest raising NVDA's compatibility to something like NVDA 2099 to match what @fastfinge has done. This will cover NVDA 2027 and beyond without that nagging compatibility issue.
@amir Will take under advisement. I didn't because I'd planned to manually make absolutely certain this worked once 2027's addon standard went final, so honestly, it's immaterial to me. @ground024@fastfinge
@nick@ground024@amir The primary reason I did it, actually, is because I didn't want someone submitting it to the store. While it's...probably legal, I don't want it in the store. Having an invalid NVDA version means it will fail the automated tests if anyone tries to submit it to them."
By the way dude, thanks for being so cool about this entire thing since I started. This entire damn project was born out of my being impatient and a miscommunication, but you've been great even so. @ground024@amir
@nick@ground024@amir I mean honestly, forks are the entire point of open source. I frequently fork things if I don't like the direction they're going or want something the maintainer won't/can't/doesn't have the time to do. Usually I'm the only one who cares, because I was the only one who needed my changes. But I'm not going to be annoyed if someone else forks my stuff. The point of releasing anything at all is for it to be useful. If you fork and it's useful to a different group of users that I can't, or don't want, to serve, that's a good thing. And I feel like your fork gave you and your users a lot of experience about what you want, how you want it, and why you want it. If you later send a PR to me, I get to benifit from all that learning, while not having to moderate all the discussion or approve all the code myself. As far as I'm concerned this has been open source working as intended. And for something like eloquence...I couldn't exactly list it on my resume. Although you credited me anyway, if that was important to me for some reason.
@nick@ground024@amir You got all the users who really really wanted resampling. I get it. But as a non-audio guy it's just work I can't do, or test, or make smart decisions about, written in code I couldn't read. So I'd been refusing them for months. Now you know what the smart decisions are, and everyone knows you don't release code until you're sure it works. So if you decide to bring it to main everyone can be sure you have the expertise and experience needed to make smart decisions about it, both from your fork, and your background in radio.
@fastfinge I'm glad you said that here. Because the rest of you, that's what's happening when OpenEVV turns into a synth that doesn't have ViaVoice's regressions/Speaks Finnish - My Finish friends would roast me on a spit if I abandoned RS before it spoke their language. Once EVV becomes Golden, this addon dies, but we'll be carrying at least some of the presence features, subject to my judgment on what actually works with OpenEVV. @ground024@amir
@nick@ground024@amir Yup. Nick is ultimately in charge of the sound profiles for whatever resampling/equalization stuff needs to happen in eloquence_64. My involvement there will just be verifying that the code doesn't add bugs/security problems/complexity that could be avoided. But discussions RE: the resampling/curves or whatever go to Nick, as he's far more qualified than I am to make final decisions on what's needed, and what can reasonably be done based on the tradeoffs and different things everyone wants. I'll add you as a collaborator to the repo when I get home on Monday.
@nick@ground024@amir Makes sense. I do want to keep my host in Python. Because that way openevv and eci share literally identical code. Just one runs in NVDA directly, and one runs in the host. Otherwise I'd be more willing to consider C++ or something for the memory management. But I don't want to have to have two different versions of the same code and keep them both up to date and in sync. And my real hope is that openevv will some day be good enough we can not have a host at all.
