I've released Eloquence64RS 19.1.2. This release works around profile issues @lerven reported. Thanks man! It came to light while I was banging away that the profile issues were in core, but this addon should work properly even so, no monkey patching. Profile switching should carry over all settings and be stable. Check for updates within Settings > Eloquence, or grab it here: github.com/Nick6489/Eloquence64RS/releases/download/v19.1.2-RS/Eloquence-19.1.2-RS.nvda-addon
I've released Eloquence64RS 19.1.3. This release fixes a tiny edge case so a cancelled Speech Sequence cannot start a new Speech Generation after Stop. Oddly, you might get a little responsiveness increase with this addon as we're not carrying around stale data anymore, but very much YMMV. Check for updates within Settings > Eloquence, or grab it here:
Urgent: Eloquence64RS 19.1.4 is released in stable channels including the updater. Please grab this one now as it is a hotfix for clean shutdown of the 32-bit Eloquence host when NVDA exits or switches synthesizers. It fixes this upstream bug (Thanks, @fastfinge!)
Well, Eloquence 64RS 19.5 Beta 3 has been released, with a drasticly different 16 KHZ presence contour. @Leowyatt88 is the star of the show here, we just prooved out that you can draw up an EQ curve in Reaper, then reimplement that in Rust. This is a starting point, he is willing to do some more if we can come to a consensus on changes that should be made.
Working on Eloquence 64RS nuts and bolts. Serious credit where it's due to @fastfinge for improving the keypress delay to the point where it bettered the RS addon, while still keeping sync with Unspoken - something my addon never did. I'm adopting that from upstream. Going to heavily test it before it goes beta, also figuring out what the fuck I'm doing about 16 KHZ presence curves. LOL.
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.
@nick RS seemed to handle this test phrase better than others. Had I been reading it with RS I wouldn't have even made the post. Went back and listened with all samplerates presents smooth and still nothing worth commenting on with RS. Maybe you can hear the library glitching out a bit but eloquence gonna be eloquence. Wish you could have RS and e64 installed at the same time but this has probably been debated plenty as well.@fastfinge@interfree.ca @amir RS
@amir test phrase with the pop around was impressed. I once had such bad piles that when one ruptured I had to use one of my wife's tampons to staunch the flow. Tbf the doc at A&E was impressed with my ingenuity. @nick@fastfinge
@fastfinge That would be halarious. Do you plan to make a version of your addon with openev only for testers? I am hoping to move full time and find a way to provide better debug info when the nvda process restarts. your code is the only one for openev that does the shortened pause. @nick@amir
@amir I have the latest version. there is checkbox but I am unsure what engine is running when, how the loading and unloading is done. Need to check openve box, restart nvda, and check taskmon to make sure the host isn't running. When does the engine change, check box, ok button, it doesn't seem to unload the host after I change so it's unclear unless you have some special speech test case queued up. @fastfinge@nick
@ground024@nick@amir You have to check the box and restart NVDA. It won't switch until you restart. It also won't switch if you're using a language openevv doesn't support.
@ground024@nick@amir The quickest way to tell: if you are in settings, and you shift tab to the apply button, you will here a long pause during alt+a if you're on openevv. You don't get that pause with eci. No, I don't know why.
