Bien le salut, la compagnie mytilicultrice !
Je me lance dans un side-project, libre et gratuit, d'une envergure encore inédite pour moi.
Je vais vous esspliquer un peu ce que je compte faire, et comment. Si certains d'entre vous, en passant par là, avait envie de donner un avis constructif, voire des conseils, des idées, bienvenue à eux.
L'idée est de programmer un synthétiseur FM virtuel, dans la lignée de FM8 de Native Instruments, par exemple. Il en existe déjà quelques uns dans le monde du libre, mais pour les avoir à peu près tous essayés, aucuns ne me satisfont vraiment, que ça soit dans l'ergonomie, les possibilités, ou la qualité de rendu du son. J'ai donc envie de produire une "killer app" qui fasse concurence aux plus grands du domaine (ça semble peut-être un peu prétentieux dit comme ça, mais j'aime pas trop partir en me disant que je vais faire de la merde, voyez-vous ?).
Voilà pour le résumé du projet. J'ai déjà pas mal bossé en amont. En programmant déjà quelques synthés plus simple pour voir si j'étais à la hauteur de la tâche, en réunissant un peu toutes les maths nécessaire à la simulation de cette synthèse particulière, en réfléchissant à comment faire "discuter" toutes ces équations pour obtenir le résultat voulu, en étudiant de près ce que devrait-être l'ergonomie d'un tel soft pour garder un minimum d'intuitivité sans rien sacrifier aux fonctionnalités et à la modularité, et d'autres choses. Bref, je pars pas les mains vides.
Non, si je viens vous parler de ça aujourd'hui, c'est parce qu'il est temps de me lancer à tapoter du code, et si j'ai déjà une idée assez précise de comment je vais articuler le tout, j'ai besoin de savoir si mon approche est déjà techniquement possible, et si oui, à quel point vais-je m'arracher les cheveux/me casser les dents, ou si mes compétences hétéroclites ne m'ont pas permis de voir qu'il y à beaucoup mieux à faire.
Alors d'avance merci pour vos avis éclairés.
D'abord, c'est quoi un synthé FM ?
(si vous le savez déjà, vous pouvez sauter à la partie suivante)
C'est un ensemble d'opérateurs (entre deux et huit en général, pourquoi ne pas en imaginer plus) qui intéragissent entre eux via une matrice de modulation.
Un opérateur est constitué d'un oscillateur, d'une ou plusieurs enveloppes ADSR pour contrôler ses parametres (niveaux de sortie, d'entrée, fréquence, etc.), éventuellement de filtres passe-haut/bas/bande/notch pour modeler ses harmoniques, d'une entrée de modulation, et d'une sortie.
Ces opérateurs entrent et sortent joyeusement les uns dans les autres pour se moduler réciproquement suivant des algorithmes (le plus souvent programmés dans une matrice) pour nous procurer du (parfois bon) son.
Ok, comment j'ai prévu de faire ça ?
Alors moi, je sais faire des interfaces en python avec Pyside, et je sais faire des synthés en C. Fort de cette constatation, j'ai envie d'utiliser Pyside pour la partie UI, et le C pour la partie synthèse (ou C++ peut-être, mais j'avoue être un peu frileux à cette idée). Jusque là, tout va bien =D
Mais comment articuler tout ça ? Petit schéma, avec essplications en dessous :
Légende :
Chaque rectangle est un thread,
En bleu, c'est du python,
En rose, c'est du C,
Les flèches grasses signifient "crée ce thread",
Les flèches maigres (rouges) -> échange de données,
L'entrée d'exécution est indiquée par "Entrée d'exécution"
Résumé :
On appelle un programme en C, qui crée un thread Python pour nous présenter une zoulie interface utilisateur. De là on demande au thread principal de nous créer une matrice de modulation et des opérateurs à mettre dedans (chacun dans des thread séparés), et on fait boucler le tout pour faire du bruit.
Le truc qui me chiffonne, c'est que je ne suis pas vraiment très à l'aise avec la création/gestion de threads (mais ça me fera une bonne occasion d'apprendre), surtout dans les langages différents. Alors déjà, est-ce seulement possible de faire ça d'après vous ?
Ça à l'air complexe, mais quand pensez-vous ? Vous croivez que je vais y arriver comme même ?
Merci en tout cas d'avoir lu jusqu'au bout, et d'avance merci encore pour les idées, conseils, pistes, et encouragements (ou découragements aussi).
# Qt ?
Posté par ash . Évalué à 6.
A mon avis tu te ferais moins ch** à tout faire en Qt.
[^] # Re: Qt ?
Posté par WrathOfThePixel . Évalué à 2.
Merci pour cet avis.
Justement, dans la balance "se faire chier", il y a d'un côté "me contenter de mes compétences actuelles" vs. "en acquérir de nouvelles".
Et Qt (le vrai, en C++), je n'y ai à peu près jamais touché, et j'ai aucune idée du temps que ça va me prendre pour m'y former, vs. donc, le temps que ça va me prendre pour faire ça comme je l'ai prévu. J'avais pas prévu de me mettre serieusement au C++ en tout cas… Mais ça peut être envisageable, je ne sais pas.
[^] # Re: Qt ?
Posté par ash . Évalué à 3.
De ma petite expérience, si tu cantonne au framework Qt ca reste du C++ assez simplifié. Tu peux te faire une idée en lançant Qt Creator et en ouvrant les exemples fournis.
[^] # Re: Qt ?
Posté par WrathOfThePixel . Évalué à 2.
Je vais étudier la question oui.
L'autre bonne raison (dont je n'ai pas parlé, j'aurais dû) de ne pas vouloir tout faire en Qt, mais le cantonner vraimement à l'UI, c'est qu'un utilisateur pourrait avoir envie de lancer le soft en mode headless, pour juste lire son patch sur une machine pas forcément très performante, sans s'encombrer du poids de l'interface. Pour une session live par exemple. Du coup l'approche synthèse en C au plus bas niveau possible semble plus pertinente. Après je ne sais pas trop ce qui est possible de faire en pur Qt à ce niveau. Faut que je me renseigne serieusement.
[^] # Re: Qt ?
Posté par ash . Évalué à 3.
Dans ce cas tu peux utiliser QtCore qui propose des modules Qt sans les modules IHM: https://doc.qt.io/qt-5/qtcore-module.html
Mais si tu es plus à l'aise avec tes connaissances actuelles, fonce :)
[^] # Re: Qt ?
Posté par Pinaraf . Évalué à 4.
Ça dépend, est-ce un problème que les libQtGui.so et autres soient installés ? Si c'est pas un problème, tu peux faire tourner une appli Qt sans lancer les composants d'interface graphique (voire avoir la flemme et utiliser un petit QT_QPA_PLATFORM=offscreen pour ne pas dépendre de X11/Wayland/eglfs)
[^] # Re: Qt ?
Posté par WrathOfThePixel . Évalué à 2.
J'avoue que ces questions font encore partie de la réflexion actuelle.
Dans l'idéal, il faudrait pouvoir utiliser Qt et X/Wayland quand ils sont là et si désiré par l'utilisateur, ou pouvoir être en mode headless pur, pour tourner sur un Pi sans serveur graphique par exemple. Dans ce cas une ligne de commande spécifierais le patch à charger et les parametres de connexion au serveur son éventuellement pour écouter des message midi et évidement sortir l'audio.
[^] # Re: Qt ?
Posté par WrathOfThePixel . Évalué à 2.
Je peux plus éditer alors je m'auto-réponds.
J'ajouterais que si un jour quelqu'un veut refaire une UI en rust/gtk, javascript/web ou brainfuck/motif, il n'y aurait pas de raison de se trimbaler une dépendance à Qt.
[^] # Re: Qt ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si tu peux, utilises un autre mode d'intégration qu'une bibliothèque dynamique, car c'est très pénible de fournir une ABI stable, les distribs ne proposent jamais la bonne version…
Ton synthé pourrait par exemple être un programme qui peut recevoir des ordres via une socket avec un protocole bien documenté.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qt ?
Posté par Pinaraf . Évalué à 3.
Un pi sans serveur graphique ne veut pas dire sans GUI. Par exemple eglfs marche très bien…
# Thread et Python
Posté par Pinaraf . Évalué à 6.
Je lis «thread» et «Python» dans la même phrase, je m'inquiète.
Que vont faire les threads en question ?
Il ne faut jamais perdre de vue qu'en Python, il n'y a qu'un seul thread qui exécute du code Python par interpréteur. C'est le fameux GIL.
Mais donc, si on est sur des threads qui ne feront pas de tâche intensive en CPU… quel devient leur intérêt par rapport à un modèle plus événementiel ? Et si c'est des tâches intensives en CPU, alors ça part dans du multi-processus Python…
[^] # Re: Thread et Python
Posté par WrathOfThePixel . Évalué à 1.
Non, Python ne serait chargé que de l'UI dans son propre thread, tout le reste serait en C.
# HS
Posté par gUI (Mastodon) . Évalué à 5.
Il est tout joli ton schéma, tu l'as fait comment ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: HS
Posté par WrathOfThePixel . Évalué à 5.
Merci, avec Inkscape tout bêtement.
# Plugin ?
Posté par Elfir3 . Évalué à 4.
Tu n'en parle pas, mais je suppose que tu risques sans doute tôt ou tard de vouloir l'intégrer dans une DAW. Commencer par une version plugin (ou du moins échafauder une version plugin dès le début), aidera a avoir la bonne archi pour que ce soit facilement pluggable par la suite.
Il y a 2 types de plugins que je te conseillerais à l'heure actuelle :
- lv2, qui est compatible avec la plupart des softs sous linux.
- clap, nouveau, mieux techniquement et poussé par BitWig. Mais nouveau… donc encore peu supporté.
Je me trompe peut être, mais j'ai pas souvenir d'y avoir déjà vu du python, même si c'est juste pour la partie GUI. En général, c'est du C ou C++ de ce côté là, avec Juce, Gtk, Qt ou des framework graphiques un peu plus exotiques. Encore une fois, je regarderais le code d'autre plugins pour me faire une idée.
Je sais que Juce est très utilisé à ce sujet avec pas mal d'outils pour la partie synthétiseur (oscillateurs, filtres…). Mais jamais testé.
Note que Lv2 et Clap viennent avec des "facilités" pour te donner des points de contrôle sur les paramètres du synthé, et que tu peux potentiellement reporter la développement de l'interface à plus tard.
--
Note, il me semble que python n'est pas vraiment fait pour être utilisé depuis un autre langage. Ca a déjà été fait, mais on préconise plus souvent d'appeler du C depuis python.
Surtout que, dans le cas d'un logiciel de traitement audio, j'éviterais de mettre du python dans la boucle pour des questions de perfs.
Autre idée si tu t'attaches au python, utiliser le midi pour contrôler les paramètres et faire de ton GUI un contrôleur midi.
[^] # Re: Plugin ?
Posté par WrathOfThePixel . Évalué à 1.
Oui j'ai pensé aux plugins ;)
Dans ma reflexion, c'est pour le moment résumé à juste un bouton pour charger un patch, et laisser le travail d'automation se faire via le DAW, par Midi. La création du patch se faisant à part.
Côté perf, justement le moteur de synthèse sera completement décorélé de l'UI, dans son thread à lui, dans un langage bas niveau. Rien dans la synthèse elle-même ne dépendrait du thread UI. Avec possibilité encore une fois de le lancer en mode headless et ne jamais executer une ligne de Python.
Pas con l'histoire du controleur Midi… Faut voir si des messages Midi seraient suffisant à le création d'un patch (sans trop de bricolage non plus). Je suis pas encore assez documenté pour ça, merci pour l'idée.
[^] # Re: Plugin ?
Posté par Elfir3 . Évalué à 3.
Normalement avec les sysex tu peux faire un peu ce que tu veux. Par exemple juste envoyer un patch que tu désérialise côté synthé. Ou lancer une sauvegarde des paramètres en cours sur un emplacement mémoire.
J'ai trouvé la doc sysex du Korg Kronos pas mal faite si tu cherches des exemples de ce que tu peux faire avec.
# synthés virtuels et compagnie
Posté par zurvan . Évalué à 7.
c'est une belle idée de projet, même si je trouve qu'il y a déjà pas mal de bons synthés FM en libre, je pense à Dexed avant tout, et il y a également OXE FM Synth (avec 8 opérateurs) mais quantité d'autres permettent également de rajouter de la synthèse FM, comme zynaddsubfx, Surge…
En tout cas c'est toujours bien d'avoir de nouveaux synthés, et ça fait une belle idée de projet.
Tu peux peut-être contacter ce développeur, il a une bonne expertise sur le sujet et est très sympa, il pourra peut-être te passer quelques tuyaux : http://jpcima.sdf1.org/
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: synthés virtuels et compagnie
Posté par WrathOfThePixel . Évalué à 2.
Merci je garde le lien sous le coude =D
[^] # Re: synthés virtuels et compagnie
Posté par Tonton Th (Mastodon) . Évalué à 5.
Les amateurs de ligne de code apprécieront Chuck, qui sait lui aussi faire de la synthèse FM. Mais pas que…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.