NintendojoFR : Le forum

Ctrl + F sur la page précédente, puis "olognion".

meduz' a écrit : 02 juin 2020 10:25 Ctrl + F sur la page précédente, puis "olognion".

Le pire c'est que je l'avais vu sans prendre le temps de visiter le site, et je l'ai oublié

Dans les navigateurs, y’a une API super cool qui s'appelle AudioContext. En gros, ça permet de mumuse de façons très avancée avec du son : distorsion, réverbération, spatialisation, synchronisation sonore au micropoil près, etc.

Et ce qui est rigolo, c’est que le code donne vraiment l'impression de jouer à l'apprenti ingénieur son en train de brancher ses câbles, genre « alors, on demande à notre centrale sonore de choper le son MACHIN, tu me le décodes et le connectes au buffer BIDULE, puis tu l'alignes juste après tel autre câble », etc.

C’est vraiment monstrueux et ça défonce.

Exemples :
- des boîte à rythmes : https://codepen.io/teropa/pen/JLjXGK https://codepen.io/sgput/full/vGRvMW
- spatialisation
- visualisation en fonction du rythme :winamp: : https://codepen.io/soulwire/full/Dscga
- un oscillateur (il a son API dédié) : https://webaudioapi.com/samples/oscillator/

Là je suis en train de dév. un petit truc qui utilise la fonction la plus basique du monde : t'appuies sur un bouton, ça joue le son. Ça, on peut aussi le faire sans cette API spécifique, mais sans cette API, impossible d'avoir dans Safari une synchro parfaite entre le moment où on tape le bouton et le moment où la lecture du son est effective.

Parmi les fonctions de « branchements », y’a decodeAudioData. C’est le morceau de l’API qui doit être utilisé pour transformer les octets qui composent un son en un AudioBuffer qu’on va ensuite connecter à la sortie audio (grosso merdo).

Donc typiquement, pour gagner en lisibilité, j'ai écrit une fonction qui va grouper quelques étapes :
- choper le son sur base de son URL
- le décoder
- retourner l’AudioBuffer obtenu.

Ça marche nickel, tout le monde est content. J’ai au final une classe nommée Sfx qui au final limite l’usage à Sfx.makeFrom(url) pour initialiser, et Sfx.play(bufferSourceNode, delay) pour le jouer autant de fois qu'on veut.

Sauf que Safari fait chier ! Normalement :
- decodeAudioData est asynchrone mais, contrairement aux autres, Safari ne retourne pas une Promise : il faut tout gérer dans le callback ;
- le buffer décodé peut être cloné pour être réutilisé plus tard, mais pas dans Safari qui le tue dès la fin du callback (mon but était d’éviter la cascade de callbacks) ;
- au lieu de retourner une erreur parce qu'il a pas géré le buffer, Safari retourne null ;
- et j'en passe.

Je vais d’abord voir si je peux changer l’architecture de ma classe, quitte à avoir du #callbackception, mais c'est juste super pénible comme juste une seule méthode de l’API peut être foutue à ce point et avoir des implications sur l'architecture du code .

Si ça marche pas, je vais tenter la librairie que quelqu’un a écrite pour standardiser AudioContext. Son adaptation de decodeAudioData fait 100 lignes (soit ma classe Sfx entière ) + appel à d’autre trucs, donc ça alourdira probablement mon projet de manière considérable .

"On fait jamais rien comme tout le monde".
- Apple

Ça a l’air bien pété comme truc… Et ça devient presque inquiétant : avant ton navigateur il devait juste faire du rendu et c’était pas simple. Avec tous ces nouveaux trucs (WebGL, Audio, etc…), bientôt il va avoir 3 ou 4 trous du cul et on va trouver des failles dedans tous les 2 jours

Là on parle d’une API installée 6 à 8 ans selon les navigateurs.

La plupart des specs maintenant sont en “living standard”. Tant qu’elles finissent pas en “recommandation”, ce qui peut prendre une décennie, elles sont susceptibles de bouger. Dans ce cas, en excluant les bugs, la « nouvelle » syntaxe a été implémentée par Firefox et Chrome en 2016-2017.

Bienvenue dans mon monde.

Perso, le logiciel universel qui fait tout, c’est moyen mon trip et plus ça va, plus les navigateurs deviennent ça.

Et ca a tué Winamp.

Au début, un simple lecteur mp3 bien light et qui faisait son job niquel, à la fin... un navigateur web intégré.

Sur Windows et Android, j’utilise AIMP depuis environ 10 ans, et il est excellent.

Android
Windows

Mortal a écrit : 08 juin 2020 08:01 Perso, le logiciel universel qui fait tout, c’est moyen mon trip et plus ça va, plus les navigateurs deviennent ça.

Personnellement, je vois plus le navigateur comme une VM/runtime avec un framework de GUI intégré et beaucoup de limitations pour la sécurité de l'utilisateur. Même pour un utilisateur averti, lancer un jeu dans un navigateur ça fait moins peur que double-cliquer sur un .exe dont tu es rarement sûr de l'origine. Et ça apporte une couche d'interopérabilité non négligeable.

Je suis allé voir juste pour constater la présence de la team premier degré, y'en a mais pas tant que ça.

Parachuté au milieu d'un projet en état ubber-bordélique avec une équipe que j'ai eu le droit de choisir presque entièrement, 1 an et demi après, on livre le "final" setup (les guillemets sont importants xD)

Ca fait tout chose !

On est remerciés à coup de prime et de bonnes augmentations, ca fait plaisir aussi.
Mais je sais pas si c'est une délivrance ou le début des emmerdes xD

Le plus compliqué, c’est pas de construire un truc. C’est de vivre avec pour les 15 ans qui viennent…

tu parles du boulot ou de ta maison ?

Ou de tes enfants ?

Les 3. Vous le savez aussi bien que moi

IMPA : Industrialisation du Management des Processus pour l'Amélioration.

Voilà. Ce perso de Zelda est niqué à tout jamais.

?

https://github.com/danielmiessler/SecLi ... /155/files

Tain, mais tellement… Quand je vois que le moindre WP ridicule qu’on nous fait maintenir au taf a au moins 15 plugins…

On pourrait dire la même chose des utilisateurs de vim.