Bon c'est pas tout à fait un cacadavre exquis vu que c'est une collab à distance, mais y'a une progression à tour de rôle avec les éléments que chacun ont conçu au préalable, alors …

• cadavres_de_4_comperes.pd
• Je viendrai mettre les autres versions progressivement ici …

Si vous avez des envies folles, stimulez vos connexions neuronales (avec ou sans drogues) et complétez.

• Le mix des 3 pistes mono du dessus de Benoît, de .

Quelqu'un a pu récupérer l'enregistrement de notre joyeux plantage au CCL? fab> mince non j'ai pas demandé mais le pote est en plein déménagement et son ordi risque de rester au placard tout l'été, j'redemanderai à tout hasard.

Cross FM synthesis : L'article de François Pinot @ Csound journal

Un exemple de patch

Tour d'horizon…

PD Vanilla ne contient aucun outil pour envoyer du son par le réseau. Il peut par contre envoyer des données (avec netsend).

• Voir help de [netsend], [netreceive]…
• http://puredata.hurleur.com/sujet-8672-connect-netreceive - Un moyen de faire une «reverse connection».

Différents plugins ont été conçus:

• C'est par là bas: http://www.nullmedium.de/dev/netsend~/
• Ne pas oublier d'installer puredata-dev pour compiler.
• Ne semble pas compiler sur du 64bits

• A été forkée/reprise par pd-iemnet, sauf que iemnet ne reprend pas les objets destinés aux signaux audio (udpsend~…) !
• Fait partie des libs intégrées à pd-extended, mais en “unsupported”, fournies tant qu'elles fonctionnent. Voir: http://puredata.info/docs/LibrariesInPdExtended/
• On reçoit de jolis messages udpreceive~: got incomplete header tag quand on s'envoie des données par UDP (sur des architectures d'ordi différentes: 32 et 64bits).

This is a fork of martin peach's “net” library, that allows low-level interaction with networks on OSI-layer 5 (transport layer).

• http://puredata.info/downloads/iemnet
• Fournit les objets tcpreceive, tcpsend, tcpserver… mais pas de trucs pour les signaux audio.
• Les objets doivent être préfixés de iemnet/<nomobjet> pour qu'ils se chargent.
• ? - https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/iemnet/FEATURES.txt ; sans utiliser OSC, on devrait balancer des octets de 0 à 255. Ca pète ! :D

• Explication: date de la fin 2010, n'a pas évolué depuis …

Conclusion ⇒ le netsend intégré à puredata, c'est mieux.

Une solution de streaming généraliste. Sert pour des radios web. Le hic: de façon interne, le logiciel induit un décalage (temps d'encodage, tampon…) entre la source sonore et le moment auquel elle est émise. N'est pas prévu pour un truc qui se joue à la seconde près.

La latence est de l'ordre de 15 secondes d'après mon expé et témoignages internet, en règlant les buffers certains disent qu'on peut la descendre mais ça a l'air inexploitable.

Darkice peut servir à récolter le flux sur la machine du “DJ”. Tandis que Icecast sert à diffuser le son vers le “public”.

butt semble s'être popularisé comme interface simple de diffusion destinée aux artistes/diffuseurs.

Développement actif.

Opensource + Codec Opus + Windows/Mac/Linux (jack).

Pas de binaire distribué pour plateformes Linux, nécessite d'être compilé.

• http://llcon.sourceforge.net/
• http://www.linuxmao.org/Jamulus

Développement actif, au point sous Mac OS X mais pas trop sous Linux.

• https://www.soundjack.eu

Permet de pallier à la latence en faisant jouer les séquences avec un retard prédéfini pour synchroniser les sons. Vieil outil mais pourrait encore marcher aujourd'hui. → N'est plus maintenu depuis 2005.

Un client libre, JamTaba2, est encore entretenu code sur GitHub. Problème, libqt5multimedia ne gère pas JACK, et le projet ne semble pas maitriser la situation.

Un tuyau réseau pour le système audio JACK. Fonctionnerait, mais JACK n'est pas dispo sous Windows… quoique: http://www.jackaudio.org/netjack, le site indique que c'est aussi dispo sous Windows. Jack.trip ne l'est pas. Netjack2 ne semble pas passer par un WAN (uniquement LAN). Netjack1 semble tolérer les pertes de données, donc fonctionne par WAN.

zita-njbridge est packagé dans Debian, semble le plus cool !

Tiré de : https://ikiwiki.laglab.org/SoundNet/

• network audio sync https://github.com/blaa/WaveSync
• https://gavv.github.io/articles/new-network-transport/
• https://github.com/roc-project/roc (currently no jack support, but its on todo list)
• https://kokkinizita.linuxaudio.org/linuxaudio/ zita-njbridge

Mumble est une solution de VoIP, comme Skype/Teamspeak, utilisée surtout par les joueurs de jeux vidéos. L'outil gère désormais JACK en plus de ALSA et Pulseaudio. Cependant, un seul bus (mono ou stereo) est utilisé pour faire transiter l'ensemble des voix des intervenants : on ne peut donc pas séparer les flux réseau en sortie.

Mumble essaie d'ouvrir son architecture, notamment via ICE. Voir le wiki : https://wiki.mumble.info/wiki/Main_Page

Malheureusement, ICE est surtout utilisé pour script le client, et je n'ai pas trouvé d'outil qui permettrait de manipuler les routes des flux audio.

Mentionné sur le forum Hydrogenaudio en 2013.

Il faut s'inscrire pour télécharger le truc, aucune idée de si le projet est encore actif.

Ils sont tarés ils veulent que ça fonctionne en P2P.

https://www.soundjack.eu/

Flux audio faible latence qui possède une implémentation libre.

Il faut compiler… pas essayé.

• https://github.com/quiniouben/vban

Un nouveau codec standardisé, libre, faible latence et de bonne qualité.

• https://wiki.xiph.org/OpusFAQ#How_do_I_use_Opus
• https://wiki.xiph.org/OpusSupport

Applications listées peu pertinentes. On y trouve webrtc (c'est à dire une boite noire dans le navigateur et mal gérée par Firefox). Eventuellement, un serveur WebRTC pourrait faire le job.

Et Jitsi, retiré de Debian en 2017.

Semble ne pas évoluer mais est entretenu.

• Site: http://netpd.org/
• Git: https://github.com/reduzent/netpd
• Une conférence video: http://lac.linuxaudio.org/2013/program

Directement avec JACK, fonctionne sur un modèle Master/Slave.

J'avais testé en réseau local, il fallait une latence un peu réhaussée, et il a tout de même tendance aux xruns.

Un autre problème est que l'ordi en Slave ne récupère pas son propre canal audio transmis par le réseau, et qu'il n'a aucun retour de la part de Master.

C'est donc conçu pour des ordis qui diffusent depuis une même pièce, avec un unique dispositif de reproduction sonore.

Note: pas grand chose d'entretenu par ici: http://wiki.linuxaudio.org/apps/other_apps#network_audio

Pas de conclusion !