@draeand@nick If we want to rewrite the world, the actually correct way to do this is write ECI64.dll, that's just a shim to call the 32-bit DLL, and then have anything at all that's a 64-bit process and wants to use eloquence load ECI64.dll. The primary reason I haven't done that is lack of talent. Though in hindsight, it probably would have actually been simpler than what I did wind up doing.
@fastfinge@nick You can't load a 32-bit DLL into a 64-bit address space though, which is the fundamental issue. I mean okay, I'll be a pedant and say that theoretically you could in fact load a 32-bit DLL into a 64-bit process, but it would be very very painful and require a bunch of low level hacks and black magic (and I'm pretty sure you would need to in effect be the library loader at that point). Not worth it unless you have a really really good reason or you like over-engineering things.
@draeand@nick No, but you could have ECI64.dll handle all of the IPC stuff, using what ever method you want, behind the scenes in a way that's largely invisible to the 64-bit app. And then every single app that wants to use eloquence doesn't have to do its own IPC.
@fastfinge@nick Very true, that's probably the best route unless you really want to learn how an operating system works. Which I would encourage, if only to learn new things!
@draeand@nick Hah. I'm a guy who forgot to clean up a process on close and left it that way for, like, months. I'm far away from doing low level OS work.
@fastfinge@nick Damnit, now the nerd side of me is working through actually making that work -- loading a 32-bit DLL into a 64-bit address space... Oooof
@draeand@nick And there is a thing you can license that will do exactly that: load 32-bit libraries into 64-bit apps. But the guy wants like $3000 to license it. His target market is businesses with old codebases they can't modernize. And he doesn't offer a demo.
@draeand@nick Also remember that, for extra fun, eci.dll is just the rapper and caller. All of the .syn files for each language are dll files of there own that ECI.dll needs to load.
@draeand@nick The .obj files aren't available for the actually good versions of eloquence. That's why openevv used IBM's viavoice, with all new and improved bugs added by IBM. Because IBM left all the debug and linker stuff in their builds. Without that, patching the .syn files would, I guess, be possible in theory. But if you're going to do that you might as well just hand-rewrite eloquence in assembler.
@fastfinge@nick Fair. I hope OpenEVV is able to clean itself up eventually -- it does a lot that I don't believe is actually necessary even to get byte-identical PCM samples. The implementation internals can be different while delivering the same output after all, and I don't think the author of OpenEVV intended for Claude to do "emulate the exact semantics of this binary down to the very byte but in 64-bit mode"
@draeand@nick That may be the only way to start to reverse Engineer the delta system, the custom language the rules were actually written in. Based on the papers and time and place the founder was at when she commercialized the system, it’s probably some kind of lisp like.
@draeand@nick Why not? If it’s not, all you’re doing is writing a new tts engine. And people would like to update the existing rules. If something new is the goal, there’s TGSpeechBox. But unless the output is pcm identical to eloquence, nobody is interested.
@draeand@nick Sure, but that requires knowing the algorithm. We don’t. So getting the delta system out of the blobs we have is the only first step I can imagine. Once we know what it does, only then can we have useful conversations about what it should do differently.
@fastfinge@nick True. Although I'd argue that's what RE would be for, before you write any code at all. But Idk, time will tell what happens I suppose, I don't know if there's really a correct answer here
