Initial QTextToSpeech additions#1188
Conversation
* shortcut added for delete action
* Delete TScriptEditorManager.h * Delete TScriptEditorManager.cpp
…keyboard shortcuts
… fork
import: some Zoilder fixes from the MudletRL fork:
* in TBuffer::translateToPlainText(...): make some MXP related code execute
only if Host::mFORCE_MXP_NEGOTIATION_OFF is NOT set as well as another
condition.
* in TBuffer::wrap(...): change a for(...) {...} loop termination condition
be a "<" rather than a "<=" test - which sounds like an "off-by-one"
error fix-up.
* In TTextEdit:updateScreenView(): revise code that seems to prevent the
width of a "main" console being set too small and NOT written to the
"parent" Host::mScreenWidth variable - the original modification
removed such a restriction completely, but I have just lowered the
minimum from 100 to 40 and ensured it is always stored both in the local
"main" console and to the parent record in the Host class for that
console.
* In TTextEdit::drawForeground(...): revise the behaviour *I think* when
at the point where a console "split" becomes unnecessary...
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Fixed "reset map colors" button to work That's a 5 year old bug out of the way!
* Change travis configuration to use installed gcc-5
Thanks to Rick for his prompt response on this
* Add Communi Model & Util libs * Full refactor of IRC Client code & UI This retains the primary functions of the old IRC client but adds many more new IRC commands by default. The UI is slightly more organized and interactive now. * Adds QPointer to IRC Dialog pointer variable. * Update Lua `sendIrc()` slightly. * Added /msg command, Input History, and updated display colors. Input History stores a total of 8 previously entered commands the user can cycle through using the Up Arrow key. The previously include /msg command has been added again. Colors of some messages have been updated for (relatively) easier distinction of message lines. * Updated channel handling. * Fix CMake builds Things needed to fix CMake builds: - communi CMake builds needed `include_directories` explicitly specified - more MOC calls in communi - more explicit dependencies to MOC files in communi - ircmessageformatter must be compiled into mudlet
Changes IRC client to run with settings given per-profile, making the IRC client more visible and configurable within Lua. This adds configuration options to the settings window in the "Special Options" tab for configuring an IRC client on the host profile which opens the settings window. See the PR summary comment for details on available Lua functions and IRC Client commands.
* Create CODE_OF_CONDUCT.md
* Finished formatting all filed & added braces
* Re-enabled map load on profile load - disabling it broke scripts that relied on map data w/o the map open
* Fix bugs with Buttons & Toolbars. - Fixed change detection for location, orienation, and CSS data. - Buttons are not rendered unless they are part of a group, Toolbar/Menu. - ToolBars whos locations are changed now hide their previous TToolBar or TEasyButtonBar instance as needed. * Fix Buttons being left behind when parent toolbar is deleted. Also allows TAction to use QPointer<T>
* also pushed isFolder() and setIsFolder() to the parent Tree class
|
On:
That sounds complicated to code for both on our side and the users side. If we take example from web browsers which are the closest analogue, perhaps just allowing them to make their own jibberish would be best along with a per-profile tab option to mute them? If things get queued too far back, like combat alerts, they would become useless... |
|
From what I see, only |
src/mudlet-lua/lua/TTSValues.lua
Outdated
| mudlet = mudlet or {} | ||
|
|
||
| mudlet.ttsStates = { | ||
| "ttsSpeechReady", |
There was a problem hiding this comment.
That's close, but not quite what I meant:
mudlet.ttsStates = {
ttsSpeechReady = "ttsSpeechReady",
-- ...
}| $${PWD}/mudlet-lua/lua/GMCP.lua \ | ||
| $${PWD}/mudlet-lua/lua/GUIUtils.lua \ | ||
| $${PWD}/mudlet-lua/lua/KeyCodes.lua \ | ||
| $${PWD}/mudlet-lua/lua/TTSValues.lua \ |
There was a problem hiding this comment.
Good catch about this (I forgot it recently), but you'll also need to adapt the count of lua files in https://github.com/Mudlet/Mudlet/blob/development/CMakeLists.txt for the cmake side.
This is needed to hopefully have some TTS backend plugins in Linux
|
Okay, so I finally found some more time to look at this. And sadly there are still some issues here. It seems at least on Windows, that the speech engine does some internal queueing as well and takes some (minimal) time to start up. This is why the loop example in #1188 (comment) behaves differently than the sequential calls in there. if you change the command to I'd expect the queue to fill up at least and the On the other hand this has been lying around too long (mainly because of my fault) already, so I'd also be okay to merge this and fine-tune this behaviour in another PR. Thoughts @vadi2? |
|
Wouldn't we break code by fine-tuning it? |
|
I think the fine-tuning will result in workaround code for this being unnecessary but not harmful. I'm not even sure how many will run into the issue as I suspect the startup time has something to do with the event loop. Basically, multiple queue calls in the same loop trigger the issue (e.g. Multiple triggers queueing on the same line). |
|
Can we fix the startup time somehow by warming it up? |
|
No. The TTS engine is started asynchronously and always needs the startup time when starting to synthesize something. There's nothing to tell it "start, I'll have something for you in a moment". |
keneanung
left a comment
There was a problem hiding this comment.
Let's go through with this and fix the niggle in another PR.
This reverts commit 1c38473.
Not by any means ready. Just here for tracking (and suggestion) purposes, so I don't forget what to fix next time I get around to working on it.
Current issues:
Currently, queueing up several text to speech lines at once will append them, but if they're even slightly staggered the latter will interrupt the former. I can only imagine it has to do with the way qt synthesizes the text. ttsSpeak needs to be changed to queue these up, or perhaps added as a different function. I can see having separate functions for queueing and speaking now be quite useful, even if the function can mostly be replicated. Perhaps allow things to be put at the front of the queue as well, or even returning and editing the queue as a whole.
Currently the speechUnit uses the default locale. Changing the locale will allow access to different voices better suited to other languages. Should very rarely be an issue, as the system language should line up with the user's, but still helpful functionality.
Probably a better way to handle ttsBuild and the creation of the speechUnit. Uncertain.
Missing documentation in the core lua files.
Todo list:
#ifdefs)Uncertain:
Use separate speech units for each profile (would either cause multiple lines of speech to play at the same time, or make queueing unnecessarily complicated)
Consider pros/cons of
QQueueinstead ofQVectorfor speech queueLook into autopausing other applications (via standard play/pause/stop interface) while TTS is running
Current issues: