Sujet Questions à propos des spécificités et des évolutions futures.
- 52 réponses
- 10 participants
- 5 435 vues
- 12 followers
Acher
Bonjour j'aurais juste trois questions sur les specs de la machine et les évolutions futures :
-- Est ce que le filtre Moog dispose des caractéristiques de saturation sur re-injection comme sur un vrai Model D ?
-- Cette question concerne d'avantage les concepteurs Arturia qui passent de temps en temps sur ce forum : est il envisagé à terme, de proposer un upgrade permettant d'avoir des enveloppes super rapides (genre Minimoog justement ou Prophet 5) ?
-- Est il envisagé à terme un correctif logiciel sur le problème parfois évoqué d'aliasing sur les modulations hautes fréquences ?
Voilà, c'est tout.
Acher.
[ Dernière édition du message le 08/01/2011 à 12:42:59 ]
LDVC@
GROOVEBOX MC-909 (ROLAND) + synthétiseur Origin (ARTURIA) + carte sonore AudioFire 12 (ECHO)
[ Dernière édition du message le 11/11/2011 à 14:56:53 ]
Funkix
Oui ventilo silencieux pour le mien
Acher
This being said we are also facing challenging technical issues and this is the second reason for the delay. Origin is a very complex product and each time we undertake the work for a new important update we may have to consider in-depth re-writing of some parts in the firmware. This was the case for this update. Some parts in this work have been rewritten already and this is taking much time as you can imagine.
En réalité, le retard du produit est pas super grave, ce qui l'est davantage (et m'a un peu surpris) est la remarque ci dessus. Je suis moi même ingénieur logiciel et je connais bien tout ce qui est génie logiciel et conception logicielle, architecture ... (je ne vais pas rentrer dans les détails c'est pas l'objet) et je déduis de ce qui est écrit plus haut (avec la grille de lecture que j'ai et au vu de ce que je connais bien):
- J'ose espérer qu'il s'agit seulement du fait qu'on re-écrit l'intégration de l'Origin avec le monde logiciel externe (Intégration VST, évolution du logiciel tiers bref la première partie de l'update initialement prévu) etc etc ... qui fait qu'on touche au moteur technique de la machine et que des re-écritures sont nécessaires. Effectivement typiquement ce genre de modifications sont très coûteuses en développements et surtout en test (plus particulièrement en test de non-régression).
- D'une manière générale, cette remarque montre une faible modularité (au sens logiciel) du synthé et un couplage fort à peu près partout : à terme un enfer à maintenir et faire évoluer sans risque de lourdes régressions.
- Si c'est bien conçu, normalement l'ajout de modules doit être un simple "plug" logiciel à l'existant. Est ce le cas ? Les tests doivent du coup être simplifiés. Ce qui veut dire que effectivement la première partie du patch 1.40 (de ce que je m'en souviens qui avait été annoncé) est lourd, les ajouts de modules (donc filtres/OSC etc etc) peanuts (simple portage de code des modules logiciel existants et adaptation des interfaces).
Acher.
Funkix
moi j'ai l'impression qu'a chaque fois qu'un nouveau produit est annoncé il va pomper plus ou moins les ressources updates des autres produits, d'ailleurs ca parait un peu logique vue qu'ils ont pas l'air nombreux ce qui ne les empechent pas d'etre doués, mais je crois que spark (malgrés ce qui avaient etait dit) a tout de meme pomper la disponibilité d'un nouvel update, et le plug sem a fini la couche pour que le prochain update sera peut etre vers mars ou avril 2012 ceci dit et je rejoins l'avis de quelques personnes le firmware actuel de l'origin est deja excellent, disont que certains ont du mal avec des promesses qui n'auraient pas etait tenue, mais je crois que beaucoup de marque on du mal a suivre leur planning, en tout cas a chaque fois qu'il y'aura un nouvel update ce sera que du bonus vue le travail deja acompli.
philwick
Acher:
En réalité, le retard du produit est pas super grave, ce qui l'est davantage (et m'a un peu surpris) est la remarque ci dessus.
- J'ose espérer qu'il s'agit seulement du fait qu'on re-écrit l'intégration de l'Origin avec le monde logiciel externe (Intégration VST, évolution du logiciel tiers bref la première partie de l'update initialement prévu) etc etc ... qui fait qu'on touche au moteur technique de la machine et que des re-écritures sont nécessaires.
Non, il ne s'agit pas de çà. La solution d'intégration - en attendant mieux - que nous avons fourni est basée sur l'automation via des messages midi. L'intégration style "Total Integration" au moyen d'un plugin nous demanderait certes une refonte d'une partie du firmware "bas niveau" (essentiellement augmenter notablement la bande passante du chemin de communication via USB entre la machine et le host + sans doute synchronisation des horloges audio host-origin), mais surtout un très gros investissement sur le host lui-même (écrire ou acheter un driver USB, écrire les couches intermédiaires entre le plugin et le driver pour garantir faible latence + faible jitter...). Le genre de travail qui a demandé 2 années à Access pour finaliser sa TI.
Acher:
- D'une manière générale, cette remarque montre une faible modularité (au sens logiciel) du synthé et un couplage fort à peu près partout : à terme un enfer à maintenir et faire évoluer sans risque de lourdes régressions.
- Si c'est bien conçu, normalement l'ajout de modules doit être un simple "plug" logiciel à l'existant. Est ce le cas ? Les tests doivent du coup être simplifiés. Ce qui veut dire que effectivement la première partie du patch 1.40 (de ce que je m'en souviens qui avait été annoncé) est lourd, les ajouts de modules (donc filtres/OSC etc etc)
Je suis d'accord sur la description des conséquences d'une faible modularité. Le firmware d'Origin est construit autour de 2 grands blocs: un bloc UI (pour simplifier) qui tourne sur un ARM, un bloc DSP qui tourne sur 2 DSPs TigerSHARK. Origin étant un synthé modulaire pratiquement sans limite on a développé un kernel audio (l'OS des DSPs) qui gèrent les modules de synthèses comme des mini plugins interconnectés dans un graphe. Chaque preset est un cas particulier en terme de besoins en cpu et mémoire. Comme on doit être capable de charger jusqu'à 4 presets en mode multi, et qu'il est par définition impossible de prédire quelles notes vont être jouées sur tel ou tel des presets le kernel audio doit gérer "dynamiquement" et en temps réel l'allocation des resources - mémoire et cpu - entre les DSPs. Cette partie du kernel est vraiment complexe. D'un point de vue "archi" rajouter un module de synthèse c'est "seulement" écrire ce plugin. Ca n'est pas forcément une tache triviale mais elle est en général assez facile à borner. L'autre aspect de l'ajout de modules c'est les resources DSPs qui sont nécessaires (cpu mais surtout mémoire). C'est sur ce plan là qu'on est de temps en temps amenés à retoucher des éléments de la structure du kernel. Par exemple pour l'update à venir j'ai du intervenir bas dans les API des "plugins" pour libérer la mémoire nécessaire pour les nouveaux modules. Ce travail concerne la partie la plus complexe du kernel audio et est donc assez long.
Concernant la partie "UI", une difficulté - je simplifie fortement ici - a été de faire évoluer un code qui était conçue pour associer 1 paramètre à 1 contrôle vers une structure capable d'associer N paramètres à 1 contrôle (ceci pour permettre l'utilisation des contrôles en multi sur les 4 slots). C'est le genre de situation que tu as probablement déja rencontré toi-même. On ne sait pas prédire exactement vers quoi les specs du produit vont évoluer dans le futur, on peut tenter d'anticiper et décider d'intégrer dans la conception ce qu'il faut pour prendre en compte ces évolutions au moindre coût, ou on peut aussi - surtout quand la pression sur les délais est importantes - décider de parer à l'immédiat.
Wasserstoff
Je pense comme Tronix, ce n'est pas tant le manque de compétences (code difficile à maintenir) que le manque de ressources humaines réaffectées à de nouveaux produits pour faire tourner la marmite
Wasserstoff
philwick, je n'y connais rien en électronique mais n'est-il pas possible d'ajouter de la mémoire (via retour usine), chose qui n'était peut-être pas possible techniquement lors de la conception de l'Origin ?
philwick
philwick, je n'y connais rien en électronique mais n'est-il pas possible d'ajouter de la mémoire (via retour usine), chose qui n'était peut-être pas possible techniquement lors de la conception de l'Origin ?
Non hélas, c'est de la mémoire interne à la puce des DSP dont je parle. Pour les autres catégories de mémoire on n'a pas de problème.
LDVC@
Avez-vous remarqué des bogues lors de la mise hors tension alors que des messages MIDI sont envoyés à l'Origin qui est en train de rejouer ?
Félicitations et encouragements pour l'Origin en rack, et la version clavier que je ne connais pas en vrai.
PS : je précise par rapport à mon message plus haut que mon synthétiseur Origin ne fait pas plus de bruit que le PC, mais le PC n'a pas besoin d'être allumé pour me servir de la boite à rythmes MC909 (totalement silencieuse) pilotant l'Origin ...
GROOVEBOX MC-909 (ROLAND) + synthétiseur Origin (ARTURIA) + carte sonore AudioFire 12 (ECHO)
Acher
Nous avons pas ce genre de problématiques au boulot, nous n'avons pas de programmation DSP (et toute les contraintes mémoire et "temps réel" liées). Nous avons d'avantages de problématique d'informatique métier lourde (avec fort changement fréquent liés à de la règlementation) et de traitement de très gros volumes de données (bases de donnée gros volume), nous avons donc surtout des problématiques d'architecture fonctionnelle et d'urbanisation ainsi que de volumétrie.
Pour en revenir à l'Origin, je comprends bien les contraintes et c'est sur que si les modifications liées à l'upgrade touchent comme tu le décris, les couches bas niveau, c'est complexe et couteux en développements. Je me doute aussi qu'avec ces contraintes mémoire c'est pas simple de faire de grosses couches d'abstraction (qui serait trop couteuses en mémoire/ressources sur des DSP), du coup c'est effectivement délicat de découpler et donc rendre modulaire. Je comprends mieux le retard ...
Est ce que les modules émulés (VCO / Filtres etc etc ...) sont du portage de code issu des Jupiter8-V, MiniMoog V etc etc sur l'Origin (avec adaptation aux interfaces logicielles) ou une re-écriture complète ?
Acher.
- < Liste des sujets
- Charte