[Request] New features to Text To Speech

[RadiaktiveLive]

• Add an option to customize TTS message. ie: Instead of "[username] says: [message]" could change to "[username] dice: [message]" or only "[message]". Customizable via variables.
• Add an option to ignore selected accounts separated by commas. ie: bot account
• Add an option to ignore command prefix. ie: !
• Add an option to ignore selected commands separated by commas. ie: !uptime, !socials
• Add an option to allow command prefix. ie: !
• Add an option to allow selected commands separated by commas. ie: !tts [message]

*Ignore command prefix and ignore selected commands I think it shouldn't be both at same time so user must choose one or other option. The same goes to allow command prefix and allow selected commands. **Allow selected commands should have priority over ignore command prefix. ie: Allow selected commands: !tts [message] Ignore command prefix: ! Should read the !tts message instead ignore it.

[SputNikPlop]

Work is ongoing to improve the tts engine right now. Looking over the list of ideas the ideal way to do this would be to try and keep it as simple as possible which is try because we shouldn't bury the settings like Twitch does right now. I have a few questions though as I am trying to understand each feature.

1. This one may be done by muting viewer names. What is your use case for "[username] dice: [message]" instead of "[username] says: [message]"?
2. Long hold pressing a message from a user you should be able to mute them, we also have some bots muted by default. Is your use case you want a more visible list of who is muted (both app and user)?
3. If I ignore a command prefix the option to allow selected commands should be available and vice versa?
4. I am not sure I understand your last three points are they separate features or considerations for the six bulletin points you outlined?

[RadiaktiveLive]

Sorry. It was my fault. I didn't explain extensively the ideas I've posted.

What is your use case for "[username] dice: [message]" instead of "[username] says: [message]"?

"dice" means "says" in Spanish. It was just an example. What I wanted to suggest was what the TTS reads should be customizable with variables/placeholders. Maybe someone doesn't want any word to be TTS'ed between the username and the message ([username] [message]) or maybe someone wants more than a word like "has commented" between the username and the message ([username] has commented [message]) or maybe only wants the message to be TTS'ed ([message]).

Long hold pressing a message from a user you should be able to mute them

Didn't know that you could long press and do moderation tasks. With that method the only way to mute an account from a TTS is when that account already chatted. If you could write the accounts you want to be ignored by TTS you could anticipate to it.

Is your use case you want a more visible list of who is muted (both app and user)?

As there is no visual indication on chat that a user has been TTS muted maybe a list of TTS muted accounts will be great or else the same applies from previous point as you will need that account to chat to check if is TTS muted or not or to unmute it.

If I ignore a command prefix the option to allow selected commands should be available and vice versa?

Yes. You could ignore all commands starting with "!" like !youtube !instagram !uptime .... but allow !hello command. Or vice versa. You could allow all commands starting with "!" like !hello !bye .... but ignore !youtube !instagram Ignore a command prefix and allow selected commands or allow a command prefix and ignore selected commands the user will choose one or the other depending on how many commands the user want to ignore or allow. Added to the combination of ignore prefix and allow commands / allow prefix and ignore commands also the expected behavior should be with single options:

• Ignore a command prefix option only: Read on TTS everything except any message starting with that character.
• Ignore selected commands option only: Read on TTS everything except any message starting with that commands.
• Allow a command prefix option only: Only read on TTS the messages starting with that character.
• Allow selected commands option only: Only read on TTS the messages starting with that commands.

I am not sure I understand your last three points are they separate features or considerations for the six bulletin points you outlined?

Are considerations of the bulletin points. That was a brief explanation of what I wrote now on the above lines. The single asterisk: Ignore command prefix and ignore selected commands: The only use case where both should be available at the same time is when someone uses multiple command prefixes like "!" or "#" or any other character. That way you could ignore all the messages with a command prefix to be TTS'ed and ignore also selected commands with other prefixex. The same applies to allow command prefix and allow selected commands. I didn't saw anyone using multiple command prefixes on a stream but maybe someone does. The two asterisks: Allow selected commands should have priority over ignore command prefix. If you ignore a command prefix character and at the same time allow a selected command starting with the same character, the allowed command should have precedence over the ignored prefix and should TTS it. An example: If you allow a selected command like "!tts" but ignore the command prefix character "!". It should read any message starting with "!tts" command instead of ignore it.