On ne voit pas vraiment de modèles TTS open source prenant en charge le coréen.
J’avais entendu dire que Kokoro-82M, publié il y a quelque temps, prenait bien en charge le coréen, mais aussi que la qualité n’avait pas l’air très bonne,
et en cherchant rapidement, j’ai vu qu’on pouvait aussi en créer et utiliser avec GPT-Sovits, ou obtenir des résultats plutôt corrects avec quelque chose comme Edge-TTS.
Ces temps-ci, avec le vibe coding, je me dis qu’en le combinant avec Whisper il y aurait sûrement moyen de faire quelque chose d’intéressant, mais je n’ai pas d’idée haha
Dans l’embarqué, on code en tenant compte jusqu’à la taille des lignes de cache du matériel. La question, c’est jusqu’où un programmeur peut pousser l’optimisation extrême au niveau du langage, ainsi que les performances de la bibliothèque standard et du compilateur. De toute façon, comme les deux prennent en charge le bas niveau, la légère différence d’overhead sera probablement négligeable. Donc je ne pense pas que ce soit un débat très pertinent… Si une optimisation extrême est nécessaire, une intervention humaine finit de toute façon par s’imposer. Les compilateurs ne sont pas aussi parfaits qu’on pourrait le croire.
Évidemment, le niveau est différent quand c’est utilisé par quelqu’un qui a des connaissances en composition et de la créativité, plutôt que par le grand public qui clique juste sur un bouton, non ?
Les GitHub Actions ne devraient servir qu’à configurer l’environnement (OS, toolchain de build, …) et à exécuter des scripts (shell, Python, bat, ps1…). Même si GitHub tombe, on devrait pouvoir builder n’importe où du moment que l’environnement est prêt. Quand je vois les workflows GitHub Actions en ce moment, je me dis qu’est-ce que ça vaut vraiment la peine d’aller chercher et d’utiliser jusque-là. Il y a très longtemps (?), Ansible a fait pareil et s’est planté.
Je pense que Rust sera plutôt un remplaçant de C++ que de C. Le C est pratiquement le seul langage (peut-être même le dernier) dans lequel on peut deviner le code que le compilateur va produire…
On dirait que ce n’est pas une traduction littérale, sans reformulation, comme on l’attend généralement d’un traducteur.
J’y ai collé le texte de présentation de Claude Cowork. Comme ci-dessous, des emojis et des puces de liste sont apparus.
(Texte original)
How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.
(Traduire avec ChatGPT)
🧠 Différences entre Cowork et une conversation classique
Dans Cowork, vous donnez à Claude l’autorisation d’accéder à un dossier précis de votre ordinateur, choisi par vous. Claude peut alors lire, modifier et même créer de nouveaux fichiers dans ce dossier.
Par exemple, Claude peut
organiser les fichiers du dossier Téléchargements et les renommer,
extraire des dépenses à partir de plusieurs captures d’écran pour créer une nouvelle feuille de calcul,
ou rédiger une première ébauche de rapport à partir de notes éparses.
On ne voit pas vraiment de modèles TTS open source prenant en charge le coréen. J’avais entendu dire que Kokoro-82M, publié il y a quelque temps, prenait bien en charge le coréen, mais aussi que la qualité n’avait pas l’air très bonne, et en cherchant rapidement, j’ai vu qu’on pouvait aussi en créer et utiliser avec GPT-Sovits, ou obtenir des résultats plutôt corrects avec quelque chose comme Edge-TTS.
Ces temps-ci, avec le vibe coding, je me dis qu’en le combinant avec Whisper il y aurait sûrement moyen de faire quelque chose d’intéressant, mais je n’ai pas d’idée haha
Dans l’embarqué, on code en tenant compte jusqu’à la taille des lignes de cache du matériel. La question, c’est jusqu’où un programmeur peut pousser l’optimisation extrême au niveau du langage, ainsi que les performances de la bibliothèque standard et du compilateur. De toute façon, comme les deux prennent en charge le bas niveau, la légère différence d’overhead sera probablement négligeable. Donc je ne pense pas que ce soit un débat très pertinent… Si une optimisation extrême est nécessaire, une intervention humaine finit de toute façon par s’imposer. Les compilateurs ne sont pas aussi parfaits qu’on pourrait le croire.
Je me demande si le coréen est bien pris en charge.
En moyenne, je ne sais pas quelle langue est la plus rapide, mais j’ai l’impression que c’est le C++ qui présente la plus grande dispersion.
Et la première photo ressemble vraiment à une scène d’un film de genre post-apocalyptique.
(Le niveau en code = le strict minimum pour être à table) T_T
Vous ne l’avez pas fait exprès, n’est-ce pas ? Hé hé.
Zig n’est pas mauvais non plus... TT
Évidemment, le niveau est différent quand c’est utilisé par quelqu’un qui a des connaissances en composition et de la créativité, plutôt que par le grand public qui clique juste sur un bouton, non ?
Le site original lui-même est déjà excellent, mais il n'existe toujours pas encore de traduction en coréen.
task_plan.mdest identique à la méthode que j’utilisais jusqu’à présent. Ce serait très pratique si cela se faisait automatiquement.Les GitHub Actions ne devraient servir qu’à configurer l’environnement (OS, toolchain de build, …) et à exécuter des scripts (shell, Python, bat, ps1…). Même si GitHub tombe, on devrait pouvoir builder n’importe où du moment que l’environnement est prêt. Quand je vois les workflows GitHub Actions en ce moment, je me dis qu’est-ce que ça vaut vraiment la peine d’aller chercher et d’utiliser jusque-là. Il y a très longtemps (?), Ansible a fait pareil et s’est planté.
À force d’écrire, c’est devenu un résumé façon IA, snif snif
Je pense que Rust sera plutôt un remplaçant de C++ que de C. Le C est pratiquement le seul langage (peut-être même le dernier) dans lequel on peut deviner le code que le compilateur va produire…
L’ère où les architectes et les QA Engineers survivront va arriver. Juger si c’est juste ou non....
On dirait que ce n’est pas une traduction littérale, sans reformulation, comme on l’attend généralement d’un traducteur.
J’y ai collé le texte de présentation de Claude Cowork. Comme ci-dessous, des emojis et des puces de liste sont apparus.
(Texte original)
How is using Cowork different from a regular conversation? In Cowork, you give Claude access to a folder of your choosing on your computer. Claude can then read, edit, or create files in that folder. It can, for example, re-organize your downloads by sorting and renaming each file, create a new spreadsheet with a list of expenses from a pile of screenshots, or produce a first draft of a report from your scattered notes.
(Traduire avec ChatGPT)
🧠 Différences entre Cowork et une conversation classique
Dans Cowork, vous donnez à Claude l’autorisation d’accéder à un dossier précis de votre ordinateur, choisi par vous. Claude peut alors lire, modifier et même créer de nouveaux fichiers dans ce dossier.
Par exemple, Claude peut
Dans le billet de retour d’expérience sur Claude Cowork écrit par Simon Willison, il y avait déjà des inquiétudes concernant les attaques par injection de prompt — c’est allé vite.
Je pense qu’il vaut mieux filtrer certains domaines pour empêcher complètement leur publication.
Cela dépend des capacités du compilateur.
Il suffit d’assembler le même code pour le voir.
On dirait que les gars de
ffmpegpensent que Rust n’est pas plus rapide que C, haha : https://www.memorysafety.org/blog/rav1d-perf-bounty/