AllTalk is based on the Coqui TTS engine, similar to the Coqui_tts extension for Text generation webUI, however supports a variety of advanced features, such as a settings page, low VRAM support, DeepSpeed, narrator, model finetuning, custom models, wav file maintenance. It can also be used with 3rd Party software via JSON calls.
EDIT Although the below statements will still be true, I have managed to introduce a legacy API setting into the new code:
So this will allow for a easier migration path for those who need it.
4th April 2024 (Dating this so you know when I wrote it)
Sometime in the near future I will be making a change to the AllTalk API, which WILL NOT affect you unless:
You have built your own software that uses the API.
You are using SillyTavern
You are using Kobold
When this change happens in AllTalk, I will put a message in the start up banner warning people of this breaking change. This change will ONLY impact the 3x following things.
API change
In short, the API will no longer return the full URL path when sending a JSON response for your wav file. e.g.
As you can see, the http://127.0.0.1:7851 will be removed from the reply. Which means you will have to alter your code to prepend the IP & port to the incoming response e.g. if within your software, you set the IP and port that you communicate with AllTalk, you will have to change your code to response = http:// + locallystoredIPaddress + locallystoredPort + output_file_url rather than just response = output_file_url
I do not know anyone's code base, however, I assume anyone whom is using AllTalk in this way and has written their own code will understand what I mean from the above.
SillyTavern
I have already updated code to meet this change, however, until I supply that code to SillyTavern for them to include in the SillyTavern download, there will be a simple manual process that I will explain on here for updating your SillyTavern. I am not sending them that code yet as AllTalk isn't ready.
Kobold
I will update code and send that over to Kobold for them to publish an update in their code. I am unable to provide a simple drop in file, like with SillyTavern.
Why am I doing this?
Its complicated and technical, however, between users having problems with changing/managing IP addresses correctly (so support requests) and also various complications with tunnelling within Docker and Google Colab environments, it seems the best solution. I have tried to code around the issue, but it just becomes more and more problematic and complex.
The net result will be that AllTalk will now just bind on your systems 0.0.0.0 address (all IP addresses on your machine) and that will be fixed. You will still be able to change the port and you will be able to use your firewall to lock down incoming traffic if necessary.
I am putting this information out there now, so that people can at least be aware of an upcoming change.
Obviously, you can stick on an earlier version of AllTalk until you are ready to move over.
š§ Breaking changes list
EDIT Although the below statements will still be true, I have managed to introduce a legacy API setting into the new code:
So this will allow for a easier migration path for those who need it.
4th April 2024 (Dating this so you know when I wrote it)
Sometime in the near future I will be making a change to the AllTalk API, which WILL NOT affect you unless:
When this change happens in AllTalk, I will put a message in the start up banner warning people of this breaking change. This change will ONLY impact the 3x following things.
API change
In short, the API will no longer return the full URL path when sending a JSON response for your wav file. e.g.
This is what would currently be sent:
"output_file_url":"http://127.0.0.1:7851/audio/myoutputfile_1704141936.wav","output_cache_url":"http://127.0.0.1:7851/audiocache/myoutputfile_1704141936.wav"and in future, this is what will be sent:
"output_file_url":"/audio/myoutputfile_1704141936.wav","output_cache_url":"/audiocache/myoutputfile_1704141936.wav"As you can see, the
http://127.0.0.1:7851will be removed from the reply. Which means you will have to alter your code to prepend the IP & port to the incoming response e.g. if within your software, you set the IP and port that you communicate with AllTalk, you will have to change your code toresponse = http:// + locallystoredIPaddress + locallystoredPort + output_file_urlrather than justresponse = output_file_urlI do not know anyone's code base, however, I assume anyone whom is using AllTalk in this way and has written their own code will understand what I mean from the above.
SillyTavern
I have already updated code to meet this change, however, until I supply that code to SillyTavern for them to include in the SillyTavern download, there will be a simple manual process that I will explain on here for updating your SillyTavern. I am not sending them that code yet as AllTalk isn't ready.
Kobold
I will update code and send that over to Kobold for them to publish an update in their code. I am unable to provide a simple drop in file, like with SillyTavern.
Why am I doing this?
Its complicated and technical, however, between users having problems with changing/managing IP addresses correctly (so support requests) and also various complications with tunnelling within Docker and Google Colab environments, it seems the best solution. I have tried to code around the issue, but it just becomes more and more problematic and complex.
The net result will be that AllTalk will now just bind on your systems 0.0.0.0 address (all IP addresses on your machine) and that will be fixed. You will still be able to change the port and you will be able to use your firewall to lock down incoming traffic if necessary.
I am putting this information out there now, so that people can at least be aware of an upcoming change.
Obviously, you can stick on an earlier version of AllTalk until you are ready to move over.
I apologise for any disruption this may cause.
Thanks