[Discussion] Ideas for better model config management

[erogol]

(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

[thorstenMueller]

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]

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]

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]

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]

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]

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

[erogol]

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

[erogol]

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

[erogol]

here we go #476

[stale]

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.

[erogol]

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

Thx everyone for your discussion.

[erogol]

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