Re: [Emacspeak] TTS Server Implementation Questions

["T.V Raman" <raman@xxxxxxxxxx>]

 as a single call is that it ensures  atomicity i.e. all of the state
 gets set at one shot from the perspective of the elisp layer, so you
 hopefully never get TTS that has its state  partially set.
 note that the other primary benefit of tts_sync_state 

Robert Melton writes:
 > On threading. It is all concurrent, lots of fun protecting of the state.
 > 
 > On language and voice, I was thinking of them as a tree, language/voice, 
 > as this is how Windows and MacOS seem to provide them.
 > 
 > ----
 > 
 > Oh, one last thing. Should TTS Server implementations be returning a \n 
 > after command is complete, or is just returning nothing acceptable? 
 > 
 > 
 > > On Apr 5, 2024, at 14:01, T.V Raman <raman@xxxxxxxxxx> wrote:
 > > 
 > > And do spend some time thinking of atomicity and multithreaded systems,
 > > e.g. ask yourself the question "how many threads of execution are active
 > > at any given time"; Hint: the answer isn't as simple as "just one
 > > because my server doesn't use threads". > Raman--
 > >> 
 > >> Thanks so much, that clarifies a bunch. A few questions on the 
 > >> language / voice support.
 > >> 
 > >> Does the TTS server maintain an internal list and switch through 
 > >> it or does it send the list the lisp in a way I have missed? 
 > >> 
 > >> Would it be useful to have a similar feature for voices, being 
 > >> first you pick right language, then you pick preferred voice 
 > >> then maybe it is stored in a defcustom and sent next time as 
 > >> (set_lang lang:voice t)
 > >> 
 > >> 
 > >>> On Apr 5, 2024, at 13:10, T.V Raman <raman@xxxxxxxxxx> wrote:
 > >>> 
 > >>> If your TTS supports more than one language, the TTS API exposes these
 > >>> as a list; these calls loop through the list (dectalk,espeak, outloud)
 > >> 
 > >> --
 > >> Robert "robertmeta" Melton
 > >> lists@xxxxxxxxxxxxxxxx
 > >> 
 > > 
 > 
 > --
 > Robert "robertmeta" Melton
 > lists@xxxxxxxxxxxxxxxx

--