TTS: Provide option to disable auto re-generation of audio upon post content update.

[joshuaabenazer]

Is your enhancement related to a problem? Please describe.

Currently when the content of a post is updated even though it may be correcting punctuations ( or spelling corrections or anything other minor corrections for that matter ), if an audio version of the post already exists, it will re-generate the audio based on the updated content.

Trying to be cost effective with the service being used here, it would be great if there was a setting to disable this auto regeneration of the audio, and if so allow the editors of the post to explicitly click a button to regenerate audio when they feel it makes sense.

Designs

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[dkotter]

I'm wondering if we need a new setting for this? I guess I'm thinking that once audio generation has happened, we automatically set the existing toggle to off. At that point, we just need to add in a Regenerate button like we have for our classification features and I think that solves things (maybe also update the message we show to make it clear that audio was already generated so that's why the toggle is now off).

They're may be some that don't like this and that's where a setting comes in handy, just worried about settings fatigue here.

[joshuaabenazer]

@dkotter I do agree that we can possibly make this workflow more intuitive and this could get a bit confusing too if just keep adding settings, but currently, the audio generation toggle you are talking about is also responsible for hiding the audio version from displaying on the frontend.

[dkotter]

@joshuaabenazer Ah, right, forgot we had made that change. What if we kept the toggle on after the audio is generated but we disable it and add a message explaining that processing won't happen again unless manually triggered?

[joshuaabenazer]

@dkotter so that means we are defaulting to hit the regenerate button incase we want the audio updated for any reason and ditching the setting? Yeah that sounds good.
And to compensate I can see if we can provide a filter to just bypass that button maybe to allow for automatic regeneration ( if possible ).

Let me know if that works and I can get started on this.

[dkotter]

so that means we are defaulting to hit the regenerate button incase we want the audio updated for any reason and ditching the setting? Yeah that sounds good.

That's how I envision it working. Once audio has been generated once, disable the toggle and show the Regenerate button. At that point, audio generation will only happen if that button is clicked, never on save. I'm open to suggestions here though, if that seems like the right approach or not.

And to compensate I can see if we can provide a filter to just bypass that button maybe to allow for automatic regeneration ( if possible ).

Yeah, if there's an easy way to provide an override here, that would be great.

[joshuaabenazer]

@dkotter the toggle is tied to the display on FE so I don't think we should touch that but otherwise, I think this works. I will work on getting some code for this to start with and then we can discuss how to change it up if needed on the PR.

[dkotter]

@joshuaabenazer In thinking about this more, wondering if we need to change slightly the toggle we have. I know we discussed having just a single toggle and having that control not only whether audio is generated but also control if the audio gets output on the front end. Apologies but I don't recall all the nuances of that discussion so maybe something I'm forgetting on why that was the best approach but wondering if we should introduce a new toggle to handle display.

At the moment, I don't think it's clear to users that if they turn that toggle off, not only will audio not be generated but the display will also not happen. It also makes this task a little trickier if we have a single toggle that is doing two different things.

So thinking we may want to introduce a new toggle to handle the audio display, along with the existing toggle that determines if audio is generated or not. I think this makes a clearer UI and helps resolve the issue documented here. Basically we could automatically disable the generation toggle once audio has been generated once but keep the display toggle on. This way audio isn't generated more than once unless someone manually clicks the Regenerate button (helping cut costs) but they can still display that audio on the front-end since those two things are no longer tied together.

That said, I know this was discussed previously so there may be something I'm forgetting from that conversation and we may want to keep these in a single toggle.

[dkotter]

As discussed over a call, providing some screenshots to better illustrate what I think a nice workflow here would be:

New post	Post with audio generated	Post with audio toggle back on

The first screenshot shows the default state when creating a new post. We have a single toggle that is turned on that determines if audio should be generated or not.

The second screenshot shows how the UI changes once audio has been generated. The first toggle goes to off (so audio won't be generated again unless this is turned on) and a new toggle is shown (with a default state of on) that controls the display of the audio controls on the front-end. And then we continue to show the preview button.

The third screenshot shows the UI if audio generation is turned back on. The only difference here is I hid the input description when the toggle was off and show it again once the toggle is turned on. I think this looks cleaner but we could just show that description in all states if we want.