débutant cherche conseil pour programmation audiounit
fab
Membre
Salut, je cherche tout les tuyaux possibles et nécessaires pour la programmation d'un plugin audiounit instrument.
là je suis en plein dans les manuels de dev d'apple, mais bien pommé je dois dire.
j'aimerais, avant de m'attaquer au moteur de rendu sonore, faire le V de MVC, c'est à dire la vue.
je ne demande pas qu'on me mâche tout le boulot, juste qu'on m'explique comment on peut commencer à créer et relier une vue cocoa à un projet instrument comme on en trouve dans les templates de xcode.
après je me démerderai peut-être un peu mieux.
le but étant pour l'instant de créer de quoi programmer des tables d'onde éditables avec des courbes de bezier.
là je suis en plein dans les manuels de dev d'apple, mais bien pommé je dois dire.
j'aimerais, avant de m'attaquer au moteur de rendu sonore, faire le V de MVC, c'est à dire la vue.
je ne demande pas qu'on me mâche tout le boulot, juste qu'on m'explique comment on peut commencer à créer et relier une vue cocoa à un projet instrument comme on en trouve dans les templates de xcode.
après je me démerderai peut-être un peu mieux.
le but étant pour l'instant de créer de quoi programmer des tables d'onde éditables avec des courbes de bezier.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Sauf si tu es un crac en programmation, je te conseille la deuxième en cherchant puis suivant un ou deux tutoriels. Les tutoriels ont l'avantage d'être du type "expérimental + explication".
Je ne sais pas ce que c'est un "projet instrument", mais les plugins ont probablement une structure proche de celles des applications. Donc la première chose à connaitre est la programmation d'application sous Xcode.
Enfin pour créer une vue, on utilise généralement "Interface Builder" et les liaisons au code sont des IBOutlets ou des IBActions. Il existe également là plusieurs solutions pour créer ces liaisons.
Voila un lien sur un tutorial en français sur le siteduzero.com
Voir ici
La doc Audio Unit Programming Guide explique fort bien (pour une fois) comment créer une interface utilisateur avec Cocoa et l'interfacer avec les classes C++ de l'Audio Unit.
La difficulté dans ton projet particulier va être de passer les formes d'ondes à l'audio kernel. L'IHM devra sans doute passer les points de contrôle de la courbe de Bézier au kernel, qui devra recalculer la forme de la courbe pour générer les échantillons.
en fait je suis nouveau à la programmation sous mac tout court, mais grosso modo je connais un peu la poo, et je me suis acheté le bouquin de stroustrup sur c++ plus quelques bouquins sur cocoa et objective-C
donc désolé pour le coté lourd de l'entrée en matière, et je vais regarder tout ça.
je suis pas un crac en programmation loin s'en faut, j'ai juste quelques idées que je voudrais appliquer dans une audiounit pour apprendre. Je sais qu'il est dangereux de se la "péter" quand on commence un truc comme ça, d'autant plus quand on vient du développement web ce qui est mon cas.
Je vais regarder aussi le tuto du site du zero.
par contre j'ai fait une tentative sur mon projet d'audiounit instrument d'importer les classes de GUI du template d'effet audiounit avec vue cocoa, mais sans succès.
le compilateur me crie dessus
J'ai surement fait le bourrin et oublié plein de choses en faisant cette importation.
je pensais qu'il suffisait de créer une hierarchie comme celle-ci: NSObject <AUCocoaUIBase> -> CocoaViewFactory -> CocoaView
la dernière étant censée recevoir mon code Quartz...
Et après, tu pourras poser des questions plus en rapport avec ton projet. Normalement, tu n'as pas besoin d'utiliser Quartz directement pour ton projet, NSBezierPath doit suffire.
Par ailleurs, j'ai l'impression que tu veux mettre la charrue avant les boe“ufs! Pardon, tu es musicien, donc tu essaies de diriger l'orchestre symphonique avant d'apprendre le solfège! N'essaies pas de devenir un pro de la programmation Cocoa tout de suite, commences par quelques programmes simples voir archi-simple. Apple a des tutoriels pour cela.
Pour t'aider un peu, voici les trois marches à franchir pour programmer des choses simples:
1 Le langage Objective-C, ses principes et sa syntaxe (c'est le plus facile)
2 L'utilisation des outils d'Apple: Xcode, IB, Instruments, ...... (on s'y fait)
3 La documentation, les références ..... (ça, au début, c'est la bouteille à encre, la mer à boire, le rocher de Sisyphe ...etc)
on m'a dit sur la mailing list coreaudio-api que mon problème venait de la non-inclusion du framework cocoa dans le projet (erreur aussi évidente que mon impatience), ce que j'ai fait sans problème, mais je ne continue pas avant d'avoir bien lu des ouvrages que je n'ai pas bien intégrés...
Merci Céroce, je vais acheter ce livre d'Aaron Hillegass tout de suite.
J'ai déjà le précis et concis objective-c, tablier.
c'est pourquoi je pensais que Quartz était indispensable. Mais si vous me dites que :
.c'est une mauvaise idée, car trop gourmande en ressources ou impossible à gérer dans un plugin AU
ou
.c'est faisable et en se passant de Quartz.
je veux bien l'entendre.
Bon j'attends le livre d'Aaron Hillegass en feuilletant ceux que j'ai sous la main.
super l'allusion à Sisyphe
>:D Apple garde maintenant une grande partie de la doc et des exemples sur son site (ADC). Ce n'est plus livré avec Xcode 3.2.2!!!!! Moi qui n'ai le réseau que la moitié du temps et souvent à basse vitesse, çA ME FOUT LES BOULES!!
Enfin je suis allé dans les préférences de Xcode, onglet "Documentation", et j'ai choisi les sets de documentation qui m'intéressaient de télécharger (iPhoneOS 3.2, iOS 4.1, MacOSX 10.6) j'ai cliqué sur "Get" en face, et hop
Disons que Core Graphics (Quartz est son nom commercial) est un bibliothèque de fonction d'assez bas niveau. Pour une appli qui est basée sur l'imagerie (comme la mienne), ça vaut le coup de l'utiliser directement, mais il existe des classes de plus haut niveau dans Cocoa (NSBezierPath, NSImage et NSImageRep, NSColor, NSGradient, etc.) qui rendent les travaux ordinaires plus faciles.
Tout est faisable pour une AU. La partie graphique est comme une appli ordinaire, sauf qu'elle est compilée en un bundle intégré dans le bundle de l'AU. C'est pour cela qu'il faut déjà que tu apprennes à créer une appli Cocoa ordinaire.
bon tuyau la doc dans Xcode, j'avais bien vu cela dans une démo, mais n'étais pas passé à l'action.
ok je vais essayer avec les classes cocoa dont tu m'as parlé, Céroce.
mais si je dois faire par exemple, un analyseur de spectre, j'imagine que c'est quartz qui le fera le mieux, non?
donc pour cela mon coeur balance, le rendu des classes NS est-il suffisament rapide?
Je ne veux pas me retrouver avec la lourdeur d'une api de dessin trop éloignée du cpu (je suis coutumier de l'as3 dont c'est un peu le cas semble-t-il), enfin vous me direz peut-être que la différence n'est pas si grande entre le bas niveau et haut, chose que j'ai du mal à évaluer.
Les classes NS sont des interfaces de plus haut niveau, mais dessous, c'est bien Core Graphics qui fait le boulot. Je n'ai jamais eu besoin d'accéder à Quartz directement pour des questions de performances: à chaque fois, c'était parce que je faisais des choses très spécifiques (par exemple, travaux avec les espaces colorimétriques), ou parce que j'avais une meilleure vision du travail de CGBitmapContext que de NSBitmapImageRep qui masque les détails de son fonctionnement.
Par ailleurs, le gros avantage des AU est de pouvoir les chaà®ner. Ainsi, je te déconseille d'intégrer un analyseur de spectre dans ton générateur. Si l'utilisateur veut un analyseur de spectre, il en placera un dans la chaà®ne.
Ce n'est jamais facile à évaluer. La bonne méthode consiste à programmer avec les interfaces de plus haut niveau disponible. Ceci permet de se concentrer sur ce qui est le plus important en terme de performances: le choix de l'algorithme. Ensuite, on fait des mesures pour localiser les goulots d'étranglement et on essaye d'y remédier. L'idée est qu'un programme passe 95% de son temps dans 5% du code. Il faut optimiser aux bons endroits, autrement le gain de vitesse sera ridicule. Par ailleurs, le code optimisé est souvent moins lisible, ce qui compromet les évolutions à moyen terme.
L'analyseur de spectre, je ne comptais pas le mettre dans ce programme-ci, c'était juste une question pour un développement futur.
Pour le code optimisé, je ne comptais pas procéder ainsi, tu me rassures sur ce point.
sinon j'ai reçu le bouquin d'Aaron Hillegass, et je vais le commencer ce soir, après mon taf.
Quant tu parles de mesures, il y a des outils pour cela, ou bien on les fait en créant des classes de mesure?
Les deux, mon colonel. Par exemple, tu pourrais faire une mesure du nombre d'échantillons générés pendant 5 s et essayer d'améliorer le score.
Un outil comme Shark mesure les fonctions/méthodes qui utilisent le plus de temps d'exécution (Instruments fait ça aussi).
J'en avais parlé dans un article.
waooo c'est vraiment bien foutu mac avec tous ces outils de dev.
bon bah je réouvrirai peut-être le topic quand j'aurai besoin de plus de conseils, mais là franchement, je ne vois pas trop comment ne pas vous remercier, tous les trois.