Bonjour,
(Avec nos excuses pour les envois multiples)
Le CICM est heureux d'annoncer la nouvelle version de la bibliothèque Cream (v0.4) et de la bibliothèque HOA (v2.2).
La bibliothèque HOA (High Order Ambisonics) est une collection de classes C++ destinées à la spatialisation du son.
La bibliothèque HOA permet aux musiciens et compositeurs de synthétiser, transformer et restituer des champs sonores de façon créative et artistique. Elle vise à faciliter la compréhension et l'appropriation des concepts clés de l'Ambisonie. Elle propose des traitements originaux comme la synthèse de champ diffus, la distorsion de perspective ou le filtrage spatial ainsi que de nouvelles interfaces graphiques. La bibliothèque est disponible pour Pure Data, Max, openFramework, FAUST et sous forme de plugins VST.
La bibliothèque HOA est gratuite, open-source et mise à disposition par le CICM, le Centre de recherche Informatique et Création Musicale de l'Université Paris 8.
Le projet a été développé dans le cadre du Labex Arts H2H à la MSH Paris-Nord et la Plate-forme Arts-Sciences-Technologies.
Mise à jour et nouvelles fonctionnalités : nouveau rendu binaural, nouveau tutoriels, convertisseur de formats Ambisonics, optimisations, etc.
Informations et téléchargements :
http://www.mshparisnord.fr/hoalibrary/
La bibliothèque Cream est un ensemble d'objects graphiques pour Pure Data qui vise à améliorer les interactions utilisateur.
https://github.com/CICM/CreamLibrary/releases
Pour les développeurs, le CICM Wrapper a été mis à jour et possède désormais une nouvelle documentation avec des exemples. Pour information, le CICM Wrapper est une bibliothèque en C/TK qui vise à faciliter la création d'objects pour Pure Data. Un des principaux axes est la création d'interfaces graphiques. Il facilite aussi la mise en œuvre de traitements dynamiques et multicanaux et améliore la compatibilité avec Max.
http://cicm.github.io/CicmWrapper/
Retours et commentaires sont les bienvenus.
L'équipe du CICM.
Hors ligne
ça a l'air très intéressant, je vais explorer ça,
je suis en train de reconstruire un patch pour accompagner un univers 3D dans le Blender game engine (pour casque VR ou projection), jusqu'ici j'ai utilisé les abstraction de pdmtl, mais je vais vois ce que peuvent m'apporter celles ci
Hors ligne
Ugh,
pas testé HOA, mais rapidement Cream et il y a des objets qui comble un vide effectivement :
sélecteur multiple, menu déroulant, matrice, courbe multipoint...
(du peu dont je me souvienne, me rappelle pas de tout ce que j'ai vu d'intéressant, c'était hier soir il était tard...)
Pour moi qui en ce moment reprends des patchs, remet à jour des vieux trucs, ces objets tombent pile poil.
Beau boulot, et merci.
Il y a juste eu un espèce de bug à un moment, ou j'ai été obligé de forcer à quitter pd-ext (sous osx) mais je ne sais pas si c'est lié à Cream ou autre chose. Je reteste cette aprem' avec debian et vanilla...
Hors ligne
news :
sous debian 8.1, après avoir compilé :
./Cream.l_ia64: ./Cream.l_ia64: undefined symbol: canvas_dspstate Cream: can't load library
y'avait la même erreur avec le binaire fourni[*], je pensais que la compil résoudrait le truc du symbole pas trouvé, mais non...
[*] https://github.com/CICM/CreamLibrary/re … eamAll.zip
jretourne fouiller...
Hors ligne
gougleuh me renvoit ceci :
https://github.com/CICM/HoaLibrary/issues/21
pourtant :
rep@reep:~/Sources/CreamLibrary$ find /usr/include/pd/ -type f -a -exec grep -H canvas_dspstate {} \; /usr/include/pd/m_pd.h:EXTERN int canvas_dspstate;
Hors ligne
bon, finalement, après un :
make clean ./autogen.sh ./configure --with-pd=/usr/include/pd make pd -lib Cream
ça à l'air de marcher...
mais ça serait trop facile...
en fait
/usr/local/bin/pd (0.45.4) marche avec Cream
alors que
/usr/bin/puredata (0.46.2) me renvois : undefined symbol: canvas_dspstate
je patauge...
Hors ligne
hello,
je suis en train d'étudier la librairie, qui fonctionne apparemment bien ici (linux mint 18, pd 0.47, installé dans le dir ~/pd-externals/ comme le fait deken )
question :
je travaille sur la spatialisation d'une scene avec de multiples sources générées,
dans l'optique de les spacialiser chacune séparément, vaut il mieux avoir beaucoup de sous patchs avec un seul encodeur/décodeur mono ?
ou quelques sous-patch avec des encodeurs multisources avec plein d'entrées (16 ou +) ?
c'est aussi dans l'idée ensuite de pouvoir les regrouper en processus pd~ séparés sur plusieurs processeurs au cas ou ça devient lourd (le blender game engine p.ex. ne prends pas bien en compte les multi proc, ça laisse de la marge de calcul de coté sur une machine récente )
l'idée est de spacialiser des scène VR, et des "jeux video" (plutôt des "expériences ludiques") avec libpd incorporé dans Ogre, ou pd + blender game engine
avec blender il y a déjà le moteur de sonorisation fourni avec blenderVR, mais c'est fait en Max à l'ircam
https://blendervr.limsi.fr/doku.php?id=addons
je travailles à un embryon en pd avec Frankiezafe à F/LAT (http://f-lat.org) pour plusieurs projets ...
si vous avez des conseils, c'est bienvenu...
Hors ligne