ROAD MAP the Future!

All flavors welcome.
Forum rules
Be kind.
Post Reply
User avatar
Posts: 1835
Joined: Sat Sep 11, 2021 4:19 pm

ROAD MAP the Future!

Post by OpenXTalkPaul »

So getting to a point where I feel like it's close to a 1.963.1 release-release, more cleaning up and testing work to do. I really could use a script to the delete System files that the IDE creates on first run so I can test in 'new' environments more easily. I'm also testing on various Linux distributions that I'm partial to such as Ubuntu Studio (low-latency kernel) and Elementary OS.
I just recently watched an hour long video someone sent me that was about moving to things like single-window UIs and catering to tech-savvy business guys that don't want to pay much or anything for someone else to do dev work when they can just sign up for a no-code or low-code service to do most, if not all, in 'the cloud' from anywhere, and like do the web things, which is fine if you like that sort of thing I guess. Personally I'm not a 'The Cloud' fan, it's not a cloud it's someone else's storage device that enables consumers to forget about ideas of content ownership in exchange for convenience, and if I really wanted to do the web things then I'd probably be mostly using standard HTML/JS/CSS/PHP instead. Sure I suppose you could build wrappers for those things in another language adding additional time to execution, or perhaps have an interpreter that honors multiple languages (Polyglot) but I suppose that's risky to mix directly with 'the competition' (specially when that competition price-point is 'completely free').

But that's got me thinking which ways would I like to see an FOSS xTalk go, on the desktop and elsewhere, post-de-branding and how to get from here and now to there, so I want to make up a 'Road Map' and then try to follow it.

Of course this too could become a continuous 'work-in-progress'

0) Recompiling the engine binaries from source code, this can and will be done, and when it is it should launch faster because the first thing to do is remove that annoying filesystem checking for the licensing file (which can be a empty dummy file) and that obnoxious account sign-up first-run stack. I'd like to create a stripped down, basic version of the interpreter / engine that's easy to compile on most any platform with minimal dependencies (the Emscripten engine is probably a good starting point for this) preferably retaining Builder lang code loading with FFI functionality so dynamic libraries and operating system APIs can be used. But the goal will be to separate the xTalk language interpreter from as much of everything else as possible. More portability means more possibilities, additional run-time engines or transpilers could become additional deploy options. For example if my stack is a simple info model-view-controller, perhaps an mp3 album art pict and a few player-transport buttons (model), then I imagine translating that into a PythonQT (view) layout that is controlled by OpenXION (controller) script wouldn't be all that difficult, and it frees your xTalk scripts, free as in freedom.

1) Wrapper libraries!
I think this is THE way to go for OXT. Common syntax for common functionality, but with diverse underlying execution mechanisms. Your stack scripts would no longer use proprietary names for things like text to speech, instead of calling 'revSpeak' you call 'Speak' and if revSpeak is available the OXT Speech API would pass to that, if it's not available, as is the case with OXT on Linux, then the unified Speech library would look for a substitute API such as an eSpeak-ng CLI on Linux or use HTML5 TTS API via JS when running in a web browser context. This is exactly how I'm approaching OXT General Music library. The main 'PlayPMD' looks for a playback engine and checks for a default instrument soundbank to use, and then it passes the musical data to the appropriate handler variation (exam. 'PlayPMD_FluidSynth)'. Similarly to how the Ask/Answer dialog stacks do different things depending on the platform it's running on. On HTML5/Emscripten Builds does not even use the Ask/Answer stacks at all, instead it passes (most) of the the parameters to the JavaScript equivalent and you get a 'browser-native' ask/answer dialog box instead. So this is about abstracting away the implementation, which may be changed so some new implementation, from the xTalk syntax which would then stay largely consistent across decades, which it (mostly) has. You wouldn't want to have to code script for Android Native Audio Record library and then have to re-code, basically the same work but for iOS/macOS AVAudioSession API record too when we could have 'Answer Record' that checks for a default Audio Recording API (used to be QuickTime)

So these Unified xTalk APIs world be...?
-- PlayPMD -- (PMD is PlaysentenceMusicalData) API for using xTalk-style text musical notation, this is already taking shape nicely. This historically (HyperTalk) integrated in the plain-old 'Play' command, but I think it's OK that they've become operate entities.

-- Speak -- for all Text-To-Speech, we have a bunch of different implementations already, old revSpeak ( external, Mac & Win only), NSSpeech (Mac) lib, AVSpeech (iOS and macOS), HTML5/web, CLI, etc.
-- Record sound, bring back Answer Record with new underlying implementations (this was QuickTime only in the past)
Having common API libs helps to facilitate platform agnosticism, which brings me to my next point...

2) xTalk should be platform agnostic whenever possible! One of the few things that has actually really excited me about the web in the past 25 years or so is WebAssembly, and VMs running inside a webpages, the idea of HTML5 browsers as App engines. That's what Electron and its kind are. I've imagined welding that together with xTalk engine(s), it could really be made into multi-threading monster with access to TONS of JS libraries and even native APIs! I've become very interested this new-fangled polyglot programming stuff.
I think that command line engines like OpenXION (Java) or LC CE Server engines could be really great general purpose scripting if they were expanded with a libs like GUI Widget libraries (Qt for one example, Lazarus has a similar lib for Pascal). Python+Qt is quite popular for building simple apps with this method, and I'm convinced xTalk could do anything Python can. I already created a basic AppleScript based GUI lib for OpenXION as a quick experiment. Like HyperTalk OpenXION allows you to redefine / override some syntax, so just write your own 'Ask [param1] [param2]...etc' handler and load it into the interpreter and from then on that handler gets used instead of the built-in 'ask' (which is a plain text based dialog by default).


Stickying this to add to it later
User avatar
Posts: 3091
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria

Re: ROAD MAP the Future!

Post by richmond62 »

Let's hope that this roadmap does not end up like another road map "somewhere else" that consisted
largely of broken promises from a couple of fund-raising exercises and, also, a way of peering back into the past
at a string of 'possible futures', almost all of which never came to pass.
SShot 2022-12-26 at 10.50.24.png
SShot 2022-12-26 at 10.50.24.png (47.24 KiB) Viewed 11733 times
Posts: 126
Joined: Mon Sep 13, 2021 9:46 pm

Re: ROAD MAP the Future!

Post by micmac »

Richmond... let's be happy here that Paul have come so far.

Good work Paul!

Happy New Year to all.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests