trevix wrote: ↑Wed Mar 25, 2020 10:09 am
I wasn't referring so much to the lib e OS version, as to the fact that the "LC way" should not be betrayed.
If I have 2 TTS libraries, one for OSX/Win and one that I am building for iOS/Android, why don't unify them with the same commands and functions names? How can a newbie make sense of it?
And, at least, I would not call the two libraries with the same name, as I read
...Important: The revSpeak command is part of the Speech library....
OK I see what you're saying, my thinking about it is very different from "newbie" because I'm an old-head that arrived at LC from a position of being a long-time HyperCard/SuperCard/AppleScript X-talk user... One of the great things about all of those IMO is that they were/are all very extensible via easy to use add ons (XCMD/XCMDs, AS Scripting Addition OSAXen, etc.). I actually prefer to have MORE than one option floating around for hooking into OS things, APIs, Services, etc. The more the merrier! Many of the things that you needed an Xternal add-on for back in the day is already incorporated into the LC engine now, but I used to have a choice of various add-ons just for selecting files, for example. I can't see there being a good way to control all developer's making add-ons, forcing them into some large set of arbitrary rules about function naming, or what datatypes would be allowed to be returned, just to make things consistent and simple for newbies. I don't think that would be good for devs, users, or newbs. Newbs got a bunch of stuff to understand before they should be getting too into the goodies anyway.
The Speech libs that are now available:
The very old RevSpeech, which is a pre-LiveCode Builder External (plug-in) built in Xcode probably a long time ago. It has pretty much just the basic features that were common between the big platforms at the time (built pre-Smart-Phones, so Desktop only). This still seems to work just fine (I've used it recently on both macOS & Win), and is a good choice for newbs just running in the IDE on Desktop. If they changed the functions in this to match the new speechLib it would break a lot of older stacks that use it. I believe revSpeech has been around so long that it supported MacOS 9 Classic/Carbon.
The newly released native speechLib, built in LiveCode Builder, a bit more complicated to use but supports Mac, iOS, and Android, with (As I understand from the comments) added Windows support planned for future update. They can't name the handlers in this exactly the same as revSpeech because they don't do the same things, revSpeech is much more straight forward to use. speechGetVoices (or whatever) in this lib gets an Array of Voices that includes all the Voice Attributes, which isn't close to the same as the Voice Names list returned by revSpeech's getVoice (or whatever). My only complaint here is that this doesn't seem to me like it should be a premium feature for Commercial Editions only, since it's also accessibility thing for like the visually impaired, but I do understand LC people got bills to pay, and there is still revSpeech available for Community edition.
Then there's my recent NSspeech Lib, that's free / open source, built with LiveCode builder, it's macOS only but it should work on every OS version from 10.6 on and it has at least one feature that LC's new speechLib doesn't have (probably because it's a speech API feature that's specific to macOS/MacOS X), the ability to synthesize speech to an AIFF sound-file.
If you only need to support iOS, but also need to support older iOS devices, you could use the AVSpeech lib that youse guys were putting together in the other thread. Change the handlers so they're closer to the one's in LC's speechLib if you like, if you search speech in the dictionary they should all show up (as soon as I finish adding docs to my lib anyway).
If anyone would like to do the work, one could take my NSspeechLib and combine it with the AVspeech lib in the other thread to make a single lib that supports speech on old versions of macOS & old versions of iOS in one library available to the community. Don't look to me to do it as I intend to concentrate on other things right now.
Then someone might come along and support some alternative open source TTS engine, like MaryTTS or eSpeak for example, that aren't a built-in part of an operating system. I imagine someone making an LCB lib that uses one of those would want to name their handlers something like eSpeakGetVoices() for example.
Too much fun!