-
-
Notifications
You must be signed in to change notification settings - Fork 1
Processing (Fr)
La vidéo ci-dessous montre quelques captures d'écran de la représentation visuelle d'objets sonores réalisée dans Processing.
Live.mp4
Le code dans Processing, qui est disponible dans ce dossier, fonctionne avec la version 4.3 de Processing et nécessite l'installation dans Processing de la librairie externe oscP5, disponible dans ce dossier ou directement sur internet.
Afin que les données sonores dans SuperCollider soient transmises via OSC dans Processing :
- La variable
~visualizeProcessing
doit être égale à 1 dans le fichier_0_Init_Live4Life.scd
. Il est donc nécessaire d'évaluer la ligne après avoir modifié la variable à 1. Voir le début du processus d'installation dans le ReadMe pour savoir comment évaluer une ligne de commande dans SuperCollider. - Le fichier
_3_Init_Pattern_182.scd
doit être évalué, soit en sélectionnant tout le fichier ou bien simplement avec cette ligne dans le fichier_0_Init_Live4Life.scd
. Si cette ligne a déjà été évaluée, arrêtez l'exécution de certaines fonctions du langage viaStop
dans the menuLanguage
ou le raccourci clavier Control (on Windows) / Command (on Mac) +.
et ré-évaluez le fichier_3_Init_Pattern_182.scd
comme indiqué précédemment.
2. Détails des données sonores générées à partir de SuperCollider et transmises via OSC à Processing
Globalement, deux types d'informations sonores sont transmises à Processing :
- sur chacun des événements sonores (contrôlés par l'interface graphique) venant du langage, comme :
- le numéro de piste ou éventuellement de séquence,
- la durée de l'évènement,
- le numéro de type de synthèse utilisée,
- l'amplitude,
- le type d'enveloppe de volume (percussive, gaussienne, etc.),
- la vitesse de lecture ou fréquence,
- le numéro de dossier sonore, le type de dossier sonore, le numéro de fichier sonore,
- la position de début de lecture dans le fichier sonore,
- le type de spatialisation,
- l'envoi vers des numéros de haut-parleurs ou d'autres paramètres spatiaux en fonction du type de spatialisation,
- l'envoi vers des pistes d'effets,
- ainsi que certaines variables paramètres associés au type de synthèse.
Cette liste de paramètres pour chaque événement sonore déclenché n'est pas exhaustive et pourrait inclure plusieurs autres types de paramètres. Des dizaines, voire des centaines d'événements, peuvent être générés en même temps dans une même piste. Les données des paramètres des événements sont accumulées dans des listes dans Processing et retirées en fonction de leurs durées.
- sur le signal sonore venant du server audio en temps-réel :
- a : le volume perçu,
- b : la hauteur (pitch),
- c : certaines informations sur le spectre sonore, comme :
- le centroïde spectral (fréquence moyenne pondérée, brillance perceptive d'un signal, masse centrale d'un spectre, zone de fréquences la plus importante du point de vue perceptif),
- la complexité d'un signal (spectral flatness : sinus = 0 et bruit blanc = 1),
- un indicateur de la présence de pics dans la distribution de l'énergie spectrale (FFT crest : sinus = 1 et bruit blanc = 0),
- la dispersion spectrale (FFTSpread),
- la dissonance (SensoryDissonance : consonance = 0 et dissonance = 1),
-
La représentation spectrale du signal sonore venant du server audio : les données FFT du spectre sonore,
-
On pourrait aussi éventuellement la représentation temporelle de l'onde : valeur du sample audio représentant des milliers d'informations par seconde.
Il aurait été intéressant d'utiliser les informations de bas-niveau pour détailler chaque information de haut niveau et plus particulièrement pouvoir regrouper ensemble les informations sur l'évènement et le signal sonore. Mais les ressources de calcul seraient trop importantes, car ils faudrait considérer d'envoyer les données FFT des signaux sonores de centaines d'événements sonores simultanément au lieu de chacun des deux serveurs audio actuellement. On aura donc une information segmentée précise des évènements et en arrière fond une quantité considérable d'informations globales sur le signal sonore de chacun des serveurs, mais malheureusement "déconnectée" des événements sonores.
Actuellement, je génère :
-
à partir des informations de haut niveau des des évènements sonores : des formes simples, qui apparaissent au premier plan et s'éloignent pour finalement disparaître dans le lointain à la fin de l'événement. Ces formes distinguent actuellement seulement les sons percussifs avec des cubes, des autres avec des sphères. Le mapping choisi est celui du tableau 4 de la page
Extension audiovisuelle
et ne représente qu'une partie très limitée des données spatiales, en l'occurence le panning stéréo fixe des événements sonores. -
à partir des informations de bas niveau des données FFT du signal sonore : des lignes verticales en arrière fond représentant linéairement l'amplitude de chaque bande spectrale avec l'alpha (plus ou moins visible). L'intensité sonore agit sur la hauteur globale des bandes verticales.
En effectuant différents types de transformations (rotations et étirements sur différents angles) à différents endroits de la boucle de rafraîchissement visuelle dans Processing, ou bien en les cumulant, il est possible de générer, comme le démontre les figures capturées dans la vidéo en haut de cette page, une très grande quantité de formes et figures.
-
Elaboration d'un visuel s'écartant d'un mapping littéral, où le visuel aurait son propre langage.
-
Amélioration de l'objet visuel via :
-
Représentation précise de la position dans l'espace des objets sonores, aussi bien en stéréo que dans l'espace 3D.
Xon - ChristOn - Live 4 Life
ResearchGate | YouTube | Vimeo | FesseBook | Buy me a coffee | Patreon
- Home
- Photos
- Relationship with the tool
- Motivations behind Live 4 Life
- Global setup and usage
- GUI-views
- Code details
- Audiovisual extension