The basis for an xtalk engine [I/we] control

A place to discuss any and all xTalk implementations, not just LC LCC Forks, but HyperCard, SuperCard, MetaCard, Gain Momentum, Oracle MediaTalk, OpenXION, etc.
Forum rules
Please limit any bashing/harping on any commercial interests to a minimum, thanks!
Post Reply
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

tperry2x wrote: Tue Mar 11, 2025 7:12 pm Speaking of which, added a few more changes:
release notes.pdf

Notably, fixed an error with double-output and added the send in x<duration><measurement> so we can have pendingmessages.
I actually just got some time to look at this, nice!
However, Answer/Ask dialogs aren't working with 097 in latest Safari (18.3), or latest Mac Chrome, they worked with version 096 though.

I also noticed concatenating two strings together results are incorrect.
put "this string" & "that string"
result:
this string" & "that string

Have you seen the "Winkler test", the HyperTalk compatibility test included with OpenXION? It's kind of crazy. HyperTalk was extremely forgiving and/or much more flexible than OXT engine interpreter.
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

As a quick test to see if I understand the construction of the interpreter I just added 'the appearance' (or should it be the systemAppearance ? ) which results in either 'dark' or 'light' depending on the browser engines current preferred appearance mode.

Code: Select all

      	// Handle "the appearance"
        if (expr.trim().toLowerCase() === 'the appearance') {
            return this.detectAppearance();
        }
        
        
        // JS function for "the appearance"
            detectAppearance() {
          const darkkMode = window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches;;
          if (darkkMode) { return 'dark'; }
          else { return 'light';}
    }
I added that to v 096 which has a different directory layout, because v.097 seems to be broken.
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

I might have given you my experimental version of v97 - Sorry.
I can confirm that's working as intended in 98 onwards. I aim to test this on different browsers today at some point.
2025-03-12-06-12-55.png
2025-03-12-06-12-55.png (16.27 KiB) Viewed 32180 times
2025-03-12-06-13-19.png
2025-03-12-06-13-19.png (13.88 KiB) Viewed 32180 times
Thank you for the dark mode / light mode detection. I'll add that in, and include it in "testing2.html" as well.

edit:
line 129 of interpreter.js

Code: Select all

detectAppearance() {
    // Check if the browser supports the prefers-color-scheme media query
    if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) {
        return 'dark';
    } else {
        return 'light';
    }
}
Then I added the appearance handler at line 1360

Code: Select all

// Handle "the appearance"
if (expr.trim().toLowerCase() === 'the appearance') {
    return this.detectAppearance();
}
Then I added the test for it in test-suite-2.js at line 192

Code: Select all

// Test appearance function
        await this.runTest("Appearance function test", [
            'put the appearance into tResult',
            'put tResult'
        ], "Testing the appearance function to detect dark/light mode");
Much appreciated:
appearance.png
appearance.png (3.11 KiB) Viewed 32148 times
so, did a bit of testing. I thought (just for a laugh), I'd test this on an old version of MacOS (10.9 Mavericks).
testing_Mac OS Mavericks.png
testing_Mac OS Mavericks.png (355.98 KiB) Viewed 32094 times
Ended up running it in Waterfox, which is based on Firefox, but with older OS-compatible APIs. Safari chokes on the CSS styling, before I even get to the script, and then refuses to run anything as it can't understand the javascript classes. Ho-hum, I did think that might be the case.

In fact, I could probably start a related-rant on the state of Safari on earlier versions of MacOS now. Just shows how much the web (and related technologies) has moved on. Can't even get to download waterfox on MacOS 10.11 El-Capitan, before Safari crashes.
Safari-El Capitan 10.11.png
Safari-El Capitan 10.11.png (140.52 KiB) Viewed 32076 times
Working fine in Safari on MacOS 12 though:

safari-macos12.png
safari-macos12.png (248.69 KiB) Viewed 32030 times
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

Yeah, I've tried HyperCard Sim, Decker, and others in old versions of macOS with various browsers like iceWeasle, InterWeb, etc. that have tried to back-port some of more modern-web engine features to older OSes and unfortunately I had similar results. A lot of web-tech has changed for the better (IMO) in the pat 15 years or so with HTML5 APIs becoming standard. I don't want to say it wasn't possible to implement an xT interpreter with 2010 web standards, but it certainly would've been more difficult and not as capable.

Some things, like for example WebAudio API, weren't supported or weren't fully supported by a plurality of browsers engines at the time. Apple in particular does seem to take a very long time to fully support newer web APIs as they become standards by default in WebKit, but you can somtimes enable such things like WebGL support from WebKit's developer menu (labeled something like "enable experimental support for"...). There's also WebKit developer preview release builds that can have all the bleeding edge things they're working on. I remember some people in the community used the source to extend the life of Safari on Snow Leopard after Apple dropped official support for 10.6.x WebKit which Safari was built on is open-source https://www.webkit.org. it was derived from KDE's KHTML browser engine (https://en.wikipedia.org/wiki/Konqueror).
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

Hmm, these do work - which is confusing, but depends on what version you are using.
hello-singular.png
hello-singular.png (15.56 KiB) Viewed 31771 times
put-singular.png
put-singular.png (11.59 KiB) Viewed 31771 times
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

tperry2x wrote: Wed Mar 12, 2025 5:15 pm Hmm, these do work - which is confusing, but depends on what version you are using.
hello-singular.png
put-singular.png
I think I was trying an earlier version when I got the idea that they didn't. I'm playing around with v100 tonight.

Here's a very very basic 'speak' command:

Code: Select all

            // Handle Speak command
            if (script.startsWith('speak ')) {
                const expr = script.substring(5);
		const voices = speechSynthesis.getVoices();                
		var msg = new SpeechSynthesisUtterance();
                msg.text = this.evaluateExpression(expr);
		msg.voice = voices[1];
		window.speechSynthesis.speak(msg);
                return '';
            }
I tested on macOS Safari: speak "Hello World"
and it spoke.

It needs several things to make it better. At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.

The JS line:
const voices = speechSynthesis.getVoices();
should retrieve a list array of available voices.

I set the msg.voice = voices[1]; so that it would use the first voice it finds
what I think we want is either:
setSpeechVoice voiceName -- as a command, derived from revSpeak's revSetSpeechVoice command
or as a global property:
set the speechVoice to voiceName
micmac
Posts: 168
Joined: Mon Sep 13, 2021 9:46 pm
Contact:

Re: The basis for an xtalk engine we control

Post by micmac »

What are the chance for graphics tools in that you are working on?

Mic
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

OpenXTalkPaul wrote: Thu Mar 13, 2025 12:09 am ...It needs several things to make it better...
Well, yes - but up until this point, it's only been myself with a text editor (and about 4 months).
OpenXTalkPaul wrote: Thu Mar 13, 2025 12:09 am .At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.
It would be good, but my entire point of doing this in a browser was to provide true cross platform features, with functions that are on a parity across Linux, Windows and MacOS. I'm cautious (actually, I'm against) adding a Mac-Only feature which has no comparable equivalent on Windows or Linux.

Don't get me wrong - I'm not being dismissive of anything you suggest. I too think it should have a good speech function, it's just a shame that speech on Linux and Windows sounds like cr4p compared to MacOS. Ideally, I'd like them all to be high quality and up to the same standard if we are going to implement that. That's all I mean.
micmac wrote: Thu Mar 13, 2025 1:30 am What are the chance for graphics tools in that you are working on?
I'm also a way off that. I am rapidly getting to the point where all the functions I want to add are to do with setting properties of objects, and of course for that you need to support objects in the first place. We have a 'card', (the white area) where things can be placed, but in the same way as I mention above, I want this to be platform-agnostic (uniform in approach) across all platforms - which of course would include the likes of Haiku now.

This is also why I've gone to great lengths to keep this a purely javascript and CSS implementation. Not using anything exotic or anything the user may have to install as optional addons. Also, because those addons (and the quality of them) vary drastically between different operating systems. I don't want to use some mac-specific library or windows dll webex extension, or some linux 'library so' file - for exactly that reason.

Yes, this makes it harder, but the end result (I hope) is clean code. That's also my second objective for doing this. Not to stuff it up with comments and things which are half-implemented, broken, or now redundant. As can be seen in our community engine source and also throughout the IDE.
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

Continuing with this, I now have the beginnings of a script editor and implemented button objects.

So, for example I can now run:

Code: Select all

create button "test"
edit script of button "test"
This will make a new button in the card, and it'll invoke the script editor.
You can also do this by right-clicking on a button object:
invoke-script-editor.png
invoke-script-editor.png (21.43 KiB) Viewed 30822 times
It'll bring up the script editor (in which I'm also trying to support script colourisation/colorization) - which can be edited easily in a css file incidentally.
editing-script.png
editing-script.png (25.18 KiB) Viewed 30822 times
Then, when I run the button script:
run-result.png
run-result.png (9.97 KiB) Viewed 30822 times
Seems to be working well.
I'm trying to implement some kind of autocomplete too, but I now have a headache, so this is all for now!
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

tperry2x wrote: Thu Mar 13, 2025 6:38 am
OpenXTalkPaul wrote: Thu Mar 13, 2025 12:09 am ...It needs several things to make it better...
Well, yes - but up until this point, it's only been myself with a text editor (and about 4 months).
Oh I don't mean to rush you into working on it. I was just sort of thinking out-loud about what other syntax would be needed to support speech. While you may have been the only one working on this interpreter, I have worked on using JS to implement missing things with the OXT Emscripten engine and HyperCard Simulator's SimScript. So I have some functionality already worked out to some degree, I just need to rearrange some lines so it fits with your code.
OpenXTalkPaul wrote: Thu Mar 13, 2025 12:09 am .At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.
It would be good, but my entire point of doing this in a browser was to provide true cross platform features, with functions that are on a parity across Linux, Windows and MacOS. I'm cautious (actually, I'm against) adding a Mac-Only feature which has no comparable equivalent on Windows or Linux.

Don't get me wrong - I'm not being dismissive of anything you suggest. I too think it should have a good speech function, it's just a shame that speech on Linux and Windows sounds like cr4p compared to MacOS. Ideally, I'd like them all to be high quality and up to the same standard if we are going to implement that. That's all I mean.
WebSpeech API ( https://developer.mozilla.org/en-US/doc ... Speech_API ) is not exclusive to macOS. Any modern browser that supports WebSpeech API should ensure there is a voice to use or provide some sort of fall back or report error if there isn't. We can't do much about poor text-to-speech quality on all browsers engines / platforms. Another option I'm a fan of would be to provide an alternative or fall-back method(s) in the implementation. One example could be that if there is an internet connection there are 'cloud' REST TTS APIs that could be used (https://cloud.google.com/text-to-speech/docs/apis https://learn.microsoft.com/en-us/azure ... =streaming .https://luvvoice.com
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

Here's another quick add

Code: Select all

	 // "the backdrop" getter
        if (expr.trim().toLowerCase() === 'the backdrop') {
            return document.body.style.background;
        }
  
        // "set the backdrop" setter
        if (property === 'backdrop') {
            document.body.style.background = this.getTextValue(value);
            return;
        }
In a web engine context I've use the web page [body] as the 'backDrop', which corresponds to the result of 'the screen' in OXT Emscripten.

pass standard web CSS color names or RGB Hex works right away.

Code: Select all

set the backDrop to darkgreen
set the backDrop to #070770
put the backdrop
Screenshot 2025-03-13 at 8.33.01 PM.png
Screenshot 2025-03-13 at 8.33.01 PM.png (73.2 KiB) Viewed 29683 times
Using xTalk-style names or RGB-CSV/Decimal values doesn't work, but that should't be very hard to implement. Using a image as a pattern-fill for 'backDrop' doesn't work either, and I don't think that's worth worrying about that at the moment.

I'm going to try to add 'Answer Color' form of 'Answer' when I get a few spare minutes.
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

Thanks for the backdrop suggestion. That's great - I'll make sure I've got that included too.

Having been experimenting more with my button script, I noticed the mouseup message wasn't being handled properly. Neither did buttons know about other things (mousedown, mouseenter, mouseleave, mousewithin) so I've just added those:

Code: Select all

on mouseDown
  put "Mouse button pressed down"
end mouseDown

Code: Select all

on mouseUp
  put "Mouse button released"
end mouseUp

Code: Select all

on mouseEnter
  put "Mouse entered the button"
end mouseEnter

Code: Select all

on mouseLeave
  put "Mouse left the button"
end mouseLeave

Code: Select all

on mouseWithin
  put "Mouse is within the button"
end mouseWithin
These would now put the corresponding messages in the "message box" as you'd expect.
mouse-events.png
mouse-events.png (78.96 KiB) Viewed 29039 times
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

I just took your code (thanks again), and added the backdrop property.
I also tweaked it slightly.
Now the interpreter also looks at "col-references.css".
You can now get the backdrop colour and store this in a variable:

Code: Select all

put the backdrop into tOriginalBackdrop
You can also set the backdrop in a variety of ways:

Code: Select all

set the backdrop to darkGreen
set the backdrop to #FF5500
set the backdrop to 200,100,50
set the backdrop to tOriginalBackdrop
backdrop.png
backdrop.png (125.92 KiB) Viewed 28868 times
Kdjanz
Posts: 40
Joined: Mon Sep 13, 2021 5:02 am
Contact:

Re: The basis for an xtalk engine we control

Post by Kdjanz »

Random interjection...

It's really nice to see both of the gurus working on a single project and pulling in the same direction. I can't help with any of what you are doing, but I really, really, really like the idea of making the browser the only platform and abandoning all this native stuff that was always pulling OXT in three directions at once. It has taken so much energy and wasted so much time to date. Everyone out there has a browser, so if you can make a new engine that works in Chrome, Safari and Firefox, then everyone can have access to OXT without caring what hardware they are running it on.

I know that recreating the engine is a mountainous task, but the upside is that it is all now in your control. You are not beholden to old code from someone or somewhere else, and you can improvise and improve on the fly. You also only have yourself to blame if things aren't working :D :lol:

I hope the new direction is decided upon and things can move ahead as you both find inspiration. OXT Lite gives us everything we had from 9.6.3, so the legacy is still there and still working. But the future is in a new direction and we can walk away from the legacy dung hill that drove that caused so much despair ! !

At least I hope this is what I am seeing and reading and that this is not just another rabbit hole and fun project that isn't going to end up going any where.

Speed on - more power to you!
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

Kdjanz wrote: Fri Mar 14, 2025 9:03 pm I really, really, really like the idea of making the browser the only platform and abandoning all this native stuff that was always pulling OXT in three directions at once. It has taken so much energy and wasted so much time to date. Everyone out there has a browser, so if you can make a new engine that works in Chrome, Safari and Firefox, then everyone can have access to OXT without caring what hardware they are running it on.
I'm not planning on abandoning 'native stuff' at all, I would say that I think it's a good move prioritizing the common capabilities that pretty much every platform has available in the form of modern browser engines. Particularly since about 2015 or so when browsers had standardized on new JS and by then most had support for HTML5 APIs like fileReader, webSpeech, webAudio, etc. Browser Engine's now support many of the things we would've needed an extension or external add on to do using native APIs, like for example 'revSpeech' which is an external that uses 'native' speech APIs (but only supports older Mac & Widows speech APIs).

We can wrap these modern Web APIs in xTalk-style syntax and have a pretty functional 'Engine' available most anywhere there's a web browser and optionally an internet connection.

But there's still 'Native' private APIs from vendors like Apple that I would still want to use (like CoreAudio, CoreMIDI, CoreImage, etc.). That's why I'm interested in webtech-as-desktop-app wrappers like Electron. Running this inside of Electron you would have DIFFERENT APIs available in its browser engine that could then be supported by the xTalk interpreter. For example, in a normal web browser you would probably use standard fileReader API to read in an entire file, which purposefully requires the end user to intitiate the file read access and browser asks for the privilege to do so before it does, but with Electron apps you would use it's fs API which could read parts of the file directly from the 'native' filesystem without the same sort of sandbox restrictions a web browser would normally impose. Running it as an Electron app you could access many of those 'Native' APIs JS wrappers and other community libraries available in the Node.JS ecosystem (there's A LOT!!!).


Speaking of WebSpeech API. I implemented the speechVoices property to (eventually) go along with that speak command:

Code: Select all

        // Handle "the speechvoices"
        if (expr.trim().toLowerCase() === 'the speechvoices') {
	    const voices = speechSynthesis.getVoices();                
	    const voccount = voices.length;
	    let vocList = '';            
        
	    for (var i = 0; i < voccount; i++) {
		vocList += ( voices[i].name + "\r\n" ) ;
		}
            return vocList;
        }
Screenshot 2025-03-14 at 8.46.32 PM.png
Screenshot 2025-03-14 at 8.46.32 PM.png (56.8 KiB) Viewed 27333 times
User avatar
OpenXTalkPaul
Posts: 2798
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for an xtalk engine we control

Post by OpenXTalkPaul »

For colorsNames it would be easy to abandon the ones used in OXT, which might be based on 'the colorNames' in SuperCard (not sure). AFAIK the OXT colorNames are NOT based on CSS1 or CSS2, although some color names may be identical to CSS, some of the names do not exist in CSS or have slightly different names.
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

OpenXTalkPaul wrote: Sat Mar 15, 2025 2:56 am For colorsNames it would be easy to abandon the ones used in OXT, which might be based on 'the colorNames' in SuperCard (not sure). AFAIK the OXT colorNames are NOT based on CSS1 or CSS2, although some color names may be identical to CSS, some of the names do not exist in CSS or have slightly different names.
Yes, I think these names seem to just be picked out of a hat. ("GoldenRod" - really? why do I think of GoldMember "I love gooooollldd") :lol: .
The way I've got it set up currently is you can define any extra / custom colours in the col-references.css
(I did have it set to load from a .txt file, but ran headlong into the CORS issue you mentioned). :D

This morning (and some of last night admittedly), I've hopefully added speech support via the WebSpeech API, and have devised this test for it:

Code: Select all

put the speechVoices into tVoices
if tVoices is empty or tVoices contains "No speech" then
   put "No voices available"
else
   put "Available voices:" & return & tVoices
   put the speechVoice into tOriginalVoice
   put "Original voice: " & tOriginalVoice
   set the speechVoice to "Default"
   speak "This is a test of the speech synthesis feature"
   set the speechVoice to tOriginalVoice
end if
I also added this to the "testing2.html" page.
However, I say "hopefully" because I can't get it to work here on Linux currently. I've tested on Firefox and Chrome in Linux - and it returns:

Code: Select all

No voices available
I did think this would be the case. I'm going to test on other platforms later if I get the chance today. (this is v104 I've shared with you Paul).
no-speech.png
no-speech.png (45.03 KiB) Viewed 23630 times
Now, hopefully this isn't down to my coding. I can't get any speech to function on this Linux system (pretty much vanilla install of Debian Mate) - no special speech library installed, because I thought it should function in-browser. Perhaps I've misunderstood there?
Anyway - this is the page I've also tested it on.
nope.png
nope.png (38.05 KiB) Viewed 23630 times
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

Kdjanz wrote: Fri Mar 14, 2025 9:03 pm It's really nice to see both of the gurus working on a single project and pulling in the same direction.
I feel flattered, but honestly - I'm a self-taught hobbyist.
Kdjanz wrote: Fri Mar 14, 2025 9:03 pm I really, really, really like the idea of making the browser the only platform and abandoning all this native stuff that was always pulling OXT in three directions at once. It has taken so much energy and wasted so much time to date. Everyone out there has a browser, so if you can make a new engine that works in Chrome, Safari and Firefox, then everyone can have access to OXT without caring what hardware they are running it on.
Don't get me wrong, there are going to be challenges too - imposed by going the browser route, and limitations - which Paul eludes to ways to overcome these. I'm just happy to be making headway on an engine that I can actually understand and make changes to.
Kdjanz wrote: Fri Mar 14, 2025 9:03 pm I know that recreating the engine is a mountainous task, but the upside is that it is all now in your control. You are not beholden to old code from someone or somewhere else, and you can improvise and improve on the fly. You also only have yourself to blame if things aren't working :D :lol:
Yes, I couldn't agree more. This is also the reason I've not released a beta or anything for someone to test yet. It's not ready for that as people would expect too much. This is pretty much why I kept the idea under wraps for a while before I worked out if it was going to be feasible.
Kdjanz wrote: Fri Mar 14, 2025 9:03 pm I hope the new direction is decided upon and things can move ahead as you both find inspiration. OXT Lite gives us everything we had from 9.6.3, so the legacy is still there and still working. But the future is in a new direction and we can walk away from the legacy dung hill that drove that caused so much despair ! !
I'm happy to fix the odd thing here and there in the OXT Lite / (inherited IDE), but my focus is now definitely this. There's just too much that's left half-done and broken - honestly adding to it is just compounding the mess.
Kdjanz wrote: Fri Mar 14, 2025 9:03 pm At least I hope this is what I am seeing and reading and that this is not just another rabbit hole and fun project that isn't going to end up going any where.
You are indeed seeing what you think you are seeing. :D
I certainly aim to keep going with it, as that's where I see real progress being able to be made.
User avatar
tperry2x
Posts: 3489
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for an xtalk engine we control

Post by tperry2x »

Well, the speech is working in Windows 10
works-in-windows-10.png
works-in-windows-10.png (20.07 KiB) Viewed 23565 times
However it does bring up the fact that there are vastly different speech voice names available. I suppose that's to be expected, but at least the code seems to work. Off to try on a mac now...

edit. Bit of a mixed bag on MacOS.
48 voices, but only 11 of them can pronounce the word "feature". The rest sound like ar$e.
test-mac.png
test-mac.png (190.38 KiB) Viewed 23538 times
Still, nothing on Linux. Will continue testing.
Edit: more testing - I get the other extreme on Ubuntu Mate.
The speech works, so I'm going to draw a line under this for now (sounds like the robotised version I produced as an appimage in OXT Lite previously).
buntu.png
buntu.png (22.69 KiB) Viewed 23501 times
The other strange thing, is when I use:

Code: Select all

put the speechVoices
I get back a list of:
buntu-voices.png
buntu-voices.png (64.78 KiB) Viewed 23501 times
13,362 voices.
User avatar
richmond62
Posts: 5234
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: The basis for an xtalk engine we control

Post by richmond62 »

"Sindarin+Jacky" sounds like some ageing male perv. and a teenage victim: what were they thinking of?
https://richmondmathewson.owlstown.net/
Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests