Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Ideas for better model config management #21

Closed
erogol opened this issue Mar 6, 2021 · 12 comments
Closed

[Discussion] Ideas for better model config management #21

erogol opened this issue Mar 6, 2021 · 12 comments

Comments

@erogol
Copy link
Member

erogol commented Mar 6, 2021

(I keep it in the issues to refer back to the initial discussion)

Hi All!!

I guess one of the biggest issues in TTS is the way we handle the configs for models and training. Putting example config files under the config folder is hard to maintain and looks complicated for people to start using TTS.

So I want to discuss here some better alternatives and ask for the wisdom of the crowd 🧑‍🤝‍🧑.

Couple of constraints we need to consider from the top of my head.

  • configs should not be python specific, and they should be in a generic form to be serialized and loaded by other systems and programming languages. So if someone likes to export the model and use it in an embedded system config file should not be a problem.
  • configs should allow easy experimentation, collaboration, and reproduction.
  • Each model should explain its config fields. Right now I do this in config.json by violating the JSON format with comments. It is not optimal ☹️.

If you have an idea please share it below and let's discuss it.

Edit:

I should also add one more constraint.

  • We should solve this with no dependencies if possible.

NOTE: This is a continuation of previously started conversion mozilla/TTS#660

Originally posted by @erogol in #20

@erogol erogol changed the title Hi All!! [Discussion] Ideas for better model config management Mar 6, 2021
@thorstenMueller
Copy link
Contributor

In addition to the previous conversation i'd like to add:

  • different training configs should be easy to compare (even if additional attributes in config has been added/removed)
  • maybe a finer grouping of attributes which affect each other (eg: if you change a it's recommended to change b also)

@WeberJulian
Copy link
Contributor

Maybe we could have an internal default for each model and only write default override in a YAML file (which allows for comments and is more user friendly). And since we don't have the json to explain the fields, we can have a .md per model or concept (like the audio processor) explaining the fields.

@gerazov
Copy link
Contributor

gerazov commented Mar 11, 2021

If we're leaning towards YAML maybe strict-yaml is worth considering.

On the other hand Python devs seem to be going for TOML - PEP 621

@WeberJulian
Copy link
Contributor

On the other hand Python devs seem to be going for TOML - PEP 621

I don't know the ambitions of coqui-TTS but if one day you decide to have model run on iOS or android (or something else) it seems that keeping the config in a non specific to python format might be a good idea

@erogol
Copy link
Member Author

erogol commented Mar 11, 2021

do you know what are good formats with multiple platform support?

I guess json is one and that was the reason I choose it initially.

Btw one good option could be using just Python classes as config files and export them to generic formats when necessary.

@gerazov
Copy link
Contributor

gerazov commented Mar 13, 2021

+1 for a Python class that could get exported if need be.

@erogol erogol mentioned this issue Mar 13, 2021
58 tasks
@erogol
Copy link
Member Author

erogol commented Mar 18, 2021

this looks like a good option https://pypi.org/project/dataclasses-json/ as @reuben suggested

@erogol
Copy link
Member Author

erogol commented Mar 31, 2021

I created this to use an in house solution https://github.com/erogol/coqpit

@stale stale bot added the wontfix This will not be worked on but feel free to help. label Apr 30, 2021
@coqui-ai coqui-ai deleted a comment from stale bot May 1, 2021
@stale stale bot removed the wontfix This will not be worked on but feel free to help. label May 1, 2021
@erogol
Copy link
Member Author

erogol commented May 6, 2021

here we go #476

@stale
Copy link

stale bot commented Jun 5, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You might also look our discussion channels.

@stale stale bot added the wontfix This will not be worked on but feel free to help. label Jun 5, 2021
@erogol erogol removed the wontfix This will not be worked on but feel free to help. label Jun 5, 2021
@erogol
Copy link
Member Author

erogol commented Jun 5, 2021

I think we can close this as it is solved with the new Coqpit integration.

Thx everyone for your discussion.

@erogol erogol closed this as completed Jun 5, 2021
@erogol
Copy link
Member Author

erogol commented Jul 5, 2022

@omkarade why are you spamming here and there? Please create a new topic under discussion and ask your questions there.

eginhard referenced this issue in idiap/coqui-ai-TTS Apr 2, 2024
refactor(dataset): get audio length with torchaudio
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants