Discussion :

[thebop]

Bonjour à tous !

Je dois élaborer avec un partenaire un dossier d'avant-projet pour l'élaboration de prototype d'un logiciel musical. Le but final du prototype est d'être montré à d'éventuelles boîte d'édition de logiciel (comme Steinberg par exemple) pour débloquer des fonds et une équipe pour parfaire et vendre le logiciel.

Ma question est que j'ai beaucoup de mal à faire un choix sur l'architecture de mon programme... Et surtout quel est tout simplement celui qui est souvent retenu dans des logiciels professionnels (Cubase, Fruity Loops, and co).

D'un côté le C# est tendance et je commence à être un minimum calé dessus.
De l'autre côté le C++ est dans ma tête toujours privilégié dans ce cadre là, mais se pose alors la question MFC (qui a l'air putain de compliqué, j'ai déjà bossé dessus une fois pour un projet assez simple mais c'est un peu oldgen je trouve) et Qt ? (Jamais bossé dessus véritablement mais il a une très très bonne réputation (et se veut entièrement portable si je me rappelle bien).

Alors voilà, mon choix pour l'instant est arrêté sur Qt C++ mais je demande un avis sur la question.

Merci beaucoup


PS : Question subsidiaire : Est-ce que finalement les éditeurs en auront totalement rien à foutre et referont tout à zéro à leur sauce dès la "professionnalisation" du projet ?

[Médinoc]

Si tu n'es pas un "pro" de Win32, n'utilise pas MFC. Déjà en étant pro, il y a un temps d'apprentissage assez élevé, surtout si tu es en mode Document/Vue.

[Mac LAK]

Assez d'accord avec Médinoc, par contre je vais surtout répondre à ta question subsidiaire...

Tout dépend de la boîte : certaines ont comme principe de modifier la maquette initiale pour démarrer le projet, d'autres partent du principe que cette maquette n'est là que pour montrer un principe de base, et que l'on repart de zéro pour faire "proprement" le projet final.

Dans tous les cas, il peut être intéressant aussi de se pencher sur des systèmes RAD pour développer l'IHM, surtout si tu comptes faire une séparation propre (le cas normal, quoi...) entre IHM et traitement fonctionnel : un EXE autonome (peu importe le langage) pour l'IHM, et le traitement dans une DLL pouvant être appelée aussi bien par ton programme que par un tiers, dans sa propre application.

Surtout que si ton traitement est fait dans une DLL respectant une interface Win32 basique (en gros, des fonctions C et non pas C++ ou C#), alors ta DLL sera utilisable quel que soit le langage visé ou le compilateur choisi : C et C++ bien sûr, mais aussi VB, Delphi, C#, Python, Java, et j'en passe.

[thebop]

Et c'est un peu la réponse à laquelle je m'attendais Mac LAK mais néanmoins je te remercie de l'avoir confirmée.

Je ne connais pas du tout l'astuce du dll. En clair tout mon modèle devrait être codé en C puis compilé en .dll. Il n'y aurait "plus qu'à" l'appeler ensuite dans un programme quelconque... (même si je me demande bien du coup comment ça marcherait... Je ne sais pas si je vais faire cette solution mais je vais me renseigner dessus quand même).


La majorité des programmes du marché sont codés avec quoi alors si ce n'est pas la MFC ?

[Mac LAK]

Je ne connais pas du tout l'astuce du dll. En clair tout mon modèle devrait être codé en C puis compilé en .dll. Il n'y aurait "plus qu'à" l'appeler ensuite dans un programme quelconque... (même si je me demande bien du coup comment ça marcherait... Je ne sais pas si je vais faire cette solution mais je vais me renseigner dessus quand même).

En gros : ton code est découpé en fonction de base, comme "Ouvrir instrument", "Jouer note", "Fermer instrument", "Lire fichier de partition", "Ecrire fichier de partition", etc. Toutes ces fonctions sont mises dans une DLL au format WINAPI (= comme les DLL du système d'exploitation, donc accessibles par tous les langages).

Ensuite, ton IHM (écrite en ce que tu veux, à ce stade on s'en fout) se "contente" d'appeler les fonctions adéquates en réaction aux clicks de l'utilisateur, et d'afficher / présenter les données dans un format agréable à l'œil. Par exemple, si tu cliques sur le bouton "Save", ton IHM va afficher une boîte de dialogue standard pour demander le nom, et une fois celui-ci obtenu, elle va appeler la fonction de sauvegarde de la DLL en lui passant le nom choisi par l'utilisateur, et tous les paramètres "internes" (et cachés !!) permettant de savoir quoi sauver (ex : numéro d'identification interne de la partition en cours).

Sur le principe général de conception, cela veut dire qu'il faut en faire deux : la première, pour la librairie elle-même (la DLL, donc), pour savoir quelles sont les fonctions élémentaires à développer.
Ensuite, la conception de l'IHM, qui va permettre de créer les fonctionnalités macroscopiques, c'est à dire celles visibles par l'utilisateur final.

L'avantage d'une telle démarche, c'est qu'il y a de fortes chances que tu puisses éviter au maximum le code redondant, via l'analyse initiale des fonctions élémentaires. Le plus important étant de clairement séparer le code "IHM" du code "DLL", et de ne JAMAIS faire de mélange de l'un et de l'autre.

La majorité des programmes du marché sont codés avec quoi alors si ce n'est pas la MFC ?

T'as le choix : solution RAD (C++ Builder, Delphi, WinDev), VB, Qt, GTK, WPF, Java, et aussi les MFC bien sûr.
Cependant, les MFC sur un projet complexe, ça devient vite difficile à maintenir sans une rigueur énorme, alors que d'autres frameworks graphiques un peu plus évolués, comme il y a moins de code "manuel" à faire, il y a aussi moins de risques d'injecter des patchs / hacks / horreurs dans le code.

[thebop]

Oui c'est ce que j'avais cru comprendre, le .dll est une représentation du Modele qu'on inclut dans une IHM externe. Pas con du tout, je ne sais pas si je vais me risquer à faire ça mais je vais y réfléchir (et oui évidemment le Modele doit toujours être indépendant de l'IHM c'est très important).