Quelqu'un a t-il déjà fait un Audio Unit?
Herve
Membre
Bonjour,
Je me suis lancé dans la programmation Cocoa pour faire des synthés avec des interfaces graphiques innovantes. Super, mais maintenant que je m'y mets, je rencontre plusieurs surprises. Quelqu'un a peut-être une expérience sur ce sujet?
1 : Core Audio n'est pas en Objectiv-C mais en C++. Quelle idée!! Bon, je m'y ferai, mais si les classes gérant l'interface graphique sont en Objectiv-C, y a t-il "bonne entente" au sein du logiciel final? En particulier, est-ce que l'interface créée par Interface Builder est opérationnelle? Apparemment, mes premiers tests me laissaient à penser que les "Blind" dans IB retrouvaient les valeurs C++, mais je n'ai pas réussi à faire marcher le soft.
2 : Justement, les "nouveaux projets Audio Unit Instrument" ne proposent pas dans XCode de générer une interface graphique (contrairement aux effets qui peuvent créer un .xib). J'espère que l'on ne détruit pas le protocole Audio Unit si on la crée soi-même?
3 : En suivant le tutoriel "tremolo", j'ai bien obtenu un .component dans mes plugs in audio, mais ni AULab, ni GarageBand ne l'ont détecté. J'en ai conclu qu'il n'était pas aux normes. Mhh?
4 : Enfin, je voudrais faire un logiciel utilisable en "stand alone" comme en AudioUnit. Je n'ai pas trouvé de doc à ce sujet. En connaissez-vous?
Merci à celui, celle ou ceux qui pourront me guider un peu dans cette nouvelle démarche.
Je me suis lancé dans la programmation Cocoa pour faire des synthés avec des interfaces graphiques innovantes. Super, mais maintenant que je m'y mets, je rencontre plusieurs surprises. Quelqu'un a peut-être une expérience sur ce sujet?
1 : Core Audio n'est pas en Objectiv-C mais en C++. Quelle idée!! Bon, je m'y ferai, mais si les classes gérant l'interface graphique sont en Objectiv-C, y a t-il "bonne entente" au sein du logiciel final? En particulier, est-ce que l'interface créée par Interface Builder est opérationnelle? Apparemment, mes premiers tests me laissaient à penser que les "Blind" dans IB retrouvaient les valeurs C++, mais je n'ai pas réussi à faire marcher le soft.
2 : Justement, les "nouveaux projets Audio Unit Instrument" ne proposent pas dans XCode de générer une interface graphique (contrairement aux effets qui peuvent créer un .xib). J'espère que l'on ne détruit pas le protocole Audio Unit si on la crée soi-même?
3 : En suivant le tutoriel "tremolo", j'ai bien obtenu un .component dans mes plugs in audio, mais ni AULab, ni GarageBand ne l'ont détecté. J'en ai conclu qu'il n'était pas aux normes. Mhh?
4 : Enfin, je voudrais faire un logiciel utilisable en "stand alone" comme en AudioUnit. Je n'ai pas trouvé de doc à ce sujet. En connaissez-vous?
Merci à celui, celle ou ceux qui pourront me guider un peu dans cette nouvelle démarche.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je pense qu'Apple a fait le choix du C++ pour des questions de performance. La résolution des méthodes par le runtime ObjC prend pas mal de temps, alors qu'en C++, il s'agit d'un simple pointeur de fonction. L'impact sur les performances est très significatif pour les méthodes appelées très fréquemment comme dans une Audio Unit.
Le code de l'interface utilisateur est stockée dans un bundle séparé. En fait, deux processus tournent en parallèle, l'un pour l'IHM (écrit en ObjC) et l'autre en C++ qui génère les échantillons.
Je ne sais trop quoi te dire, le tuto Trémolo est fort bien fait de mon point de vue, et l'effet fonctionne dans AULab (il faut parfois relancer l'appli).
Enfin, on ne peut pas créer directement d'application "Stand-alone". Les Audio Units sont faites pour être chaà®nées. Ce qu'il est possible de faire est de créer un ersatz de AULab qui intègre automatiquement ton AU.
"/Users/(mon nom)/Library/Developer/Xcode/DerivedData/SinSynth-fmtthcswgxjmhbgsnfitmhwxepor (...)", avec une terminaison qui n'existe pas. C'est la première fois que je remarque ce chemin. Ce sont les copies sauvegardes?
Dans le dossier "/Documents/Mac et iPod/SinSynth", pas de AU par contre alors que je trouvais les exécutables Cocoa dans les sous dossiers built avec le projet XCode. Encore une nouveauté...
J'ai lu depuis mon post des discussions dans un forum US concernant l'emploi de C++ qui rejoint tes idées Céroce.
http://www.mailinglistarchive.com/html/coreaudio-api@lists.apple.com/2010-10/msg00179.html
Le débat n'est pas aussi clair, mais bon...
Depuis Xcode 4, il n'y a plus de répertoire Build/ dans le répertoire du projet. Il est maintenant placé dans le répertoire DerivedData/.
Je commence à bidouiller les codes du tremolo et du SinSynth initial. Cela marche bien. Je vais maintenant tenter de faire marcher les classes filtre par exemple. Cela m'intimide un peu, mais bon!