Commentaires sur le test : Vous reprendrez bien un peu de clavier ?

Je crois bien d'ailleurs qu'aucune STAN ne gère pour l'heure un redimensionnement en pourcentage de son interface graphique.

Et notez que ça tombe bien, vu que je viens de mettre mon test de Django en ligne !

Vu, lu, écouté et apprécié

x

Hors sujet :

Citation :

@Los teignos
La comparaison avec le code d'Audofanzine ne tient pas : tu compare PHP, un langage interprété avec un langage compilé... il y a un monde entre les deux, les facilités d'intervention n'ont rien à voir.
Pour les OS, ou certaines applis, c'est la compatibilité ascendante qui plombe l'évolution, donc, de temps en temps tu repars de 0... euh, non même pas, mais tu vas dire que tu l'as fait, ça résonne bien en marketing

Je n'ai pas 50 ans d'expérience en développement mais je soumets quand même ces éléments à ta réflexion, issus de mon expérience personnelle (je m'occupe des specs fonctionnelles chez AF et bosse donc au quotidien avec des développeurs) et des nombreuses interviews de dévs que j'ai pu faire dans le monde de l'audio ou du jeu vidéo :

En fait, sans parler de comparer du PHP et du C++ ou de l'assembleur, rien que pour des raisons RH, un code trop vieux devient dur à maintenir : quand tu as 30 développeurs qui se sont succédés sur un projet, même en les ayant sensibilisé au fait de commenter proprement leur code, tu te retrouves avec du bordel qui rend le code produit par le premier développeur difficile à gérer par le dernier développeur, et même si les outils de documentation ont bien évolué, quand un dév s'attaque à ce qu'a fait un autre dix ans avant lui, tu peux parier que tu vas te retrouver avec des effets de bords qu'il faudra gérer à l'arrache... D'ailleurs, le secret pour avoir un développeur malheureux dans son travail, c'est de lui donner un vieux code source qu'il n'a pas produit et sur lequel il devra faire la hotline et du debug.

S'ajoutent à cela les problématiques d'optimisation. A priori, dans un monde parfait, tout le monde fait de l'objet, de sorte que le code est facile à faire évoluer sur la longueur, vu qu'on peut travailler sur des briques une par une sans que ça remettre en question l'édifice. Seulement voilà : l'objet n'est pas performant et lorsque vient le moment d'optimiser le bel édifice tout propre, il faut descendre au niveau de l'assembleur pour certains trucs et trouver des compromis sur certains autres en équilibrant le gain apporté par une modif, la propreté de cette dernière et le temps à la coder. Et là, c'est le règne de la bidouille avec la nuée de cas particuliers qui se transforment en IF machin THEN truc. Le problème, c'est qu'à force de croisements d'IF, le code devient super dur à comprendre et qu'il commence même à se comporter comme un organisme vivant qui gère des trucs auxquels tu n'aurais pas pensé (et c'est parfois une bonne surprise), mais qui t'expose à des effets de bord de dingue.

S'ajoute encore à cela le problème des specs qui arrivent après le développement parce que tu te rends compte que tu as oublié un cas particulier dans les specs fonctionnelles. Dans le cas de Spectrasonics, les specs arrivées après fabrication du moteur sont liées à la compatibilité avec les OS 64 bits par exemple, et maintenant à cette histoire de polyphonie ou de scripts. Alors ça se gère oui, mais jamais aussi bien que si tu avais eu ces contraintes dès le départ. Si Spectrasonics devait sortir son soft en chinois avec tout ce que cela implique en terme de localisation de l'interface, ou s'il fallait que le logiciel tourne sur iPad, maintenant que le format AU est trans-plateforme, je pense que leur directeur technique dirait : VOUS POUVIEZ PAS Y PENSER AVANT, BORDEL !

S'ajoute enfin à tout cela la dimension de temps et de rentabilité. Quand tu bosses pour un ministère, tu n'as pas trop la pression en terme de retour sur Investissement : de toutes façons, ce ne sont pas tes utilisateurs qui payent ton salaire. Dans le privé et à plus forte raison dans une petite boîte, c'est autre chose et à choisir entre vite et bien, on choisit le plus souvent vite. Ca veut dire dans les cas extrêmes de la bidouille pas commentée au cul du camion qui va bien pourrir ton code mais qui fera plaisir au commercial qui dira au client : oui, oui, on gère ça !

Citation :

Pour les OS, ou certaines applis, c'est la compatibilité ascendante qui plombe l'évolution, donc, de temps en temps tu repars de 0... euh, non même pas, mais tu vas dire que tu l'as fait, ça résonne bien en marketing

J'ai du mal à penser qu'OS X n'était pas une réécriture de zéro vu que le Shell même du système n'avait rien à voir et que justement, ça a foutu en l'air toute la rétrocompatibilité. Tu veux dire qu'en fait, même OS X, ce serait un MacOS 9 qu'on aurait patché ?

Si le gros de l'équipe qui développait Nuendo s'est barré de Steinberg pour aller faire Studio One, c'est justement parce que l'éditeur avait refusé leur proposition de reprendre le code de zéro et que c'était un enfer à gérer au quotidien.

FL Studio a été développé en Delphi. Pour le portage sous Mac, il a donc bien fallu tout re-développer de zéro.
https://support.image-line.com/knowledgebase/base.php?ans=114

Je le redis d'après les propos de Rapahael Dingé : si tu souhaites faire un séquenceur collaboratif en temps réel, c'est à dire quelque chose qui gère au mieux les problématiques de latence audio et latence réseau en plus des problèmes de droits que cela implique, ce n'est pas avec une surcouche sur un moteur classique que tu peux arriver à quelque chose de performant, mais en agissant au coeur même du moteur et en s'assurant que chaque cycle va bien faire ce qu'il aura à faire.

Même chose dans le jeu vidéo : ce n'est pas à après coup que tu peux transformer un jeu solo en jeu massivement multijoueur juste en faisant trois ou quatre modifs (d'ailleurs, c'est même impossible dans la conception même du gameplay), ce n'est pas après coup que tu peux gérer les dernières évolutions des cartes graphiques dans ton moteur de rendu.

D'ailleurs, soit les développeurs dans le monde de l'audio sont vraiment mauvais, soit ce n'est pas aussi facile que tu le dis de faire évoluer un logiciel quand on voit les gros problème qu'on la plupart d'entre eux pour gérer les problématiques de lisibilité en fonctions des différences de taille et de résolution d'écran. Je crois bien d'ailleurs qu'aucune STAN ne gère pour l'heure un redimensionnement en pourcentage de son interface graphique. Peut-être qu'ils s'en foutent, peut-être qu'il leur faudrait aussi réécrire tout le moteur graphique de leur soft, sachant que bon nombre d'entre eux utilisent sans doute des librairies qu'ils n'ont même pas codées...

Pour revenir à Spectrasonics, dès qu'ils ont quitté UVI pour leur propre moteur, ils ont toujours eu un soucis de performances : même sur des patches basiques, ça bouffe plus que ça ne devrait sans que fonctionnellement, ce qu'ils proposent soit d'une incroyable complexité : ça sonne la mort, c'est stable, mais ça reste un double lecteur de samples truffé de sections d'effets avec quelques modules de synthèse. Rien qui soit aussi complexe qu'un Reaktor par exemple. Et je le redis, même sur des patches simples, ça bouffe.

Du coup, qu'en penser ? Je vois trois possibilités : soit depuis 10 ans, il se contrefoutent d'optimiser leur soft, soit ils ne sont pas aussi bons en développement qu'il le sont en sampling, soit ils ne peuvent pas le faire sans tout remettre à plat. Et je penche pour un mélange des deux dernières.

x

Hors sujet :

Citation :

@Los teignos
La comparaison avec le code d'Audofanzine ne tient pas : tu compare PHP, un langage interprété avec un langage compilé... il y a un monde entre les deux, les facilités d'intervention n'ont rien à voir.
Pour les OS, ou certaines applis, c'est la compatibilité ascendante qui plombe l'évolution, donc, de temps en temps tu repars de 0... euh, non même pas, mais tu vas dire que tu l'as fait, ça résonne bien en marketing

Je n'ai pas 50 ans d'expérience en développement mais je soumets quand même ces éléments à ta réflexion, issus de mon expérience personnelle (je m'occupe des specs fonctionnelles chez AF et bosse donc au quotidien avec des développeurs) et des nombreuses interviews de dévs que j'ai pu faire dans le monde de l'audio ou du jeu vidéo :

En fait, sans parler de comparer du PHP et du C++ ou de l'assembleur, rien que pour des raisons RH, un code trop vieux devient dur à maintenir : quand tu as 30 développeurs qui se sont succédés sur un projet, même en les ayant sensibilisé au fait de commenter proprement leur code, tu te retrouves avec du bordel qui rend le code produit par le premier développeur difficile à gérer par le dernier développeur, et même si les outils de documentation ont bien évolué, quand un dév s'attaque à ce qu'a fait un autre dix ans avant lui, tu peux parier que tu vas te retrouver avec des effets de bords qu'il faudra gérer à l'arrache... D'ailleurs, le secret pour avoir un développeur malheureux dans son travail, c'est de lui donner un vieux code source qu'il n'a pas produit et sur lequel il devra faire la hotline et du debug.

S'ajoutent à cela les problématiques d'optimisation. A priori, dans un monde parfait, tout le monde fait de l'objet, de sorte que le code est facile à faire évoluer sur la longueur, vu qu'on peut travailler sur des briques une par une sans que ça remettre en question l'édifice. Seulement voilà : l'objet n'est pas performant et lorsque vient le moment d'optimiser le bel édifice tout propre, il faut descendre au niveau de l'assembleur pour certains trucs et trouver des compromis sur certains autres en équilibrant le gain apporté par une modif, la propreté de cette dernière et le temps à la coder. Et là, c'est le règne de la bidouille avec la nuée de cas particuliers qui se transforment en IF machin THEN truc. Le problème, c'est qu'à force de croisements d'IF, le code devient super dur à comprendre et qu'il commence même à se comporter comme un organisme vivant qui gère des trucs auxquels tu n'aurais pas pensé (et c'est parfois une bonne surprise), mais qui t'expose à des effets de bord de dingue.

S'ajoute encore à cela le problème des specs qui arrivent après le développement parce que tu te rends compte que tu as oublié un cas particulier dans les specs fonctionnelles. Dans le cas de Spectrasonics, les specs arrivées après fabrication du moteur sont liées à la compatibilité avec les OS 64 bits par exemple, et maintenant à cette histoire de polyphonie ou de scripts. Alors ça se gère oui, mais jamais aussi bien que si tu avais eu ces contraintes dès le départ. Si Spectrasonics devait sortir son soft en chinois avec tout ce que cela implique en terme de localisation de l'interface, ou s'il fallait que le logiciel tourne sur iPad, maintenant que le format AU est trans-plateforme, je pense que leur directeur technique dirait : VOUS POUVIEZ PAS Y PENSER AVANT, BORDEL !

S'ajoute enfin à tout cela la dimension de temps et de rentabilité. Quand tu bosses pour un ministère, tu n'as pas trop la pression en terme de retour sur Investissement : de toutes façons, ce ne sont pas tes utilisateurs qui payent ton salaire. Dans le privé et à plus forte raison dans une petite boîte, c'est autre chose et à choisir entre vite et bien, on choisit le plus souvent vite. Ca veut dire dans les cas extrêmes de la bidouille pas commentée au cul du camion qui va bien pourrir ton code mais qui fera plaisir au commercial qui dira au client : oui, oui, on gère ça !

Citation :

Pour les OS, ou certaines applis, c'est la compatibilité ascendante qui plombe l'évolution, donc, de temps en temps tu repars de 0... euh, non même pas, mais tu vas dire que tu l'as fait, ça résonne bien en marketing

J'ai du mal à penser qu'OS X n'était pas une réécriture de zéro vu que le Shell même du système n'avait rien à voir et que justement, ça a foutu en l'air toute la rétrocompatibilité. Tu veux dire qu'en fait, même OS X, ce serait un MacOS 9 qu'on aurait patché ?

Si le gros de l'équipe qui développait Nuendo s'est barré de Steinberg pour aller faire Studio One, c'est justement parce que l'éditeur avait refusé leur proposition de reprendre le code de zéro et que c'était un enfer à gérer au quotidien.

FL Studio a été développé en Delphi. Pour le portage sous Mac, il a donc bien fallu tout re-développer de zéro.
https://support.image-line.com/knowledgebase/base.php?ans=114

Je le redis d'après les propos de Rapahael Dingé : si tu souhaites faire un séquenceur collaboratif en temps réel, c'est à dire quelque chose qui gère au mieux les problématiques de latence audio et latence réseau en plus des problèmes de droits que cela implique, ce n'est pas avec une surcouche sur un moteur classique que tu peux arriver à quelque chose de performant, mais en agissant au coeur même du moteur et en s'assurant que chaque cycle va bien faire ce qu'il aura à faire.

Même chose dans le jeu vidéo : ce n'est pas à après coup que tu peux transformer un jeu solo en jeu massivement multijoueur juste en faisant trois ou quatre modifs (d'ailleurs, c'est même impossible dans la conception même du gameplay), ce n'est pas après coup que tu peux gérer les dernières évolutions des cartes graphiques dans ton moteur de rendu.

D'ailleurs, soit les développeurs dans le monde de l'audio sont vraiment mauvais, soit ce n'est pas aussi facile que tu le dis de faire évoluer un logiciel quand on voit les gros problème qu'on la plupart d'entre eux pour gérer les problématiques de lisibilité en fonctions des différences de taille et de résolution d'écran. Je crois bien d'ailleurs qu'aucune STAN ne gère pour l'heure un redimensionnement en pourcentage de son interface graphique. Peut-être qu'ils s'en foutent, peut-être qu'il leur faudrait aussi réécrire tout le moteur graphique de leur soft, sachant que bon nombre d'entre eux utilisent sans doute des librairies qu'ils n'ont même pas codées...

Pour revenir à Spectrasonics, dès qu'ils ont quitté UVI pour leur propre moteur, ils ont toujours eu un soucis de performances : même sur des patches basiques, ça bouffe plus que ça ne devrait sans que fonctionnellement, ce qu'ils proposent soit d'une incroyable complexité : ça sonne la mort, c'est stable, mais ça reste un double lecteur de samples truffé de sections d'effets avec quelques modules de synthèse. Rien qui soit aussi complexe qu'un Reaktor par exemple. Et je le redis, même sur des patches simples, ça bouffe.

Du coup, qu'en penser ? Je vois trois possibilités : soit depuis 10 ans, il se contrefoutent d'optimiser leur soft, soit ils ne sont pas aussi bons en développement qu'il le sont en sampling, soit ils ne peuvent pas le faire sans tout remettre à plat. Et je penche pour un mélange des deux dernières.

Ce test me confirme donc que ce produit est super pour ceux qui n'ont rien encore mais qu'il n'apporte pas grand chose de mieux que ceux qui ont déjà les Loung Lizard, Ivory et autres instruments d'UVI...