Le pub des programmeurs

Anonyme

521397

Sujet de la discussion Posté le 25/08/2005 à 17:21:03

Salut

y a des programeurs sur AF si oui vous bossez sous quoi ?

alex.d.

5820

Je poste, donc je suis

Membre depuis 10 ans

1801 Posté le 03/12/2018 à 22:58:13

Si, il y a UAD. Mais le DSP est plus un dongle matériel qu'un réel besoin de puissance de calcul...

0

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

1802 Posté le 03/12/2018 à 23:09:50

L'idée n'est pas que pour l'audio MAO, mais pour l'audio en général, tout comme OpenGL n'est pas pas que pour les jeux.

Ca peut servir aux téléphones, mp3, casques, consoles...

0

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

alex.d.

5820

Je poste, donc je suis

Membre depuis 10 ans

1803 Posté le 03/12/2018 à 23:12:30

Sur les casques, je ne sais pas ; mais sur les autres périphériques, ils embarquent de toute façon un processeur généraliste qui est largement suffisant pour les traitement audio.

0

Jimbass

11603

Drogué·e à l’AFéine

Membre depuis 19 ans

1804 Posté le 04/12/2018 à 01:26:59

Citation de miles1981 :

tout comme OpenGL

==> https://www.openal.org/ et https://www.khronos.org/opensles/

0

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watt s

[ Dernière édition du message le 04/12/2018 à 01:30:05 ]

Wolfen

14007

Rédacteur·trice

Membre depuis 23 ans

1805 Posté le 04/12/2018 à 09:51:42

Une discussion intéressante sur SOUL : https://llllllll.co/t/soul-sound-language-juce-roli/17752/30

0

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

EraTom

2282

AFicionado·a

Membre depuis 14 ans

1806 Posté le 04/12/2018 à 11:08:04

Citation de [newline :

jules]We’d obviously like to support as many platforms as possible, but exactly which ones we focus on will depend on partnerships as well as technical factors.

The long-term goal is of course to reach the point where we have enough users and enough hardware support that all the other hardware vendors will need to support it because of user demand and competition. Exactly which platforms we target in the short term to get there is what we’re currently figuring out.

Oui voilà.

Il faudra donc que le marché (de niche) évolue comme cela s'est produit avec les jeux vidéos... sauf que le bras de levier n'est pas le même.

En réalité, ça fait bien longtemps que les briques de bases sont matures (contrairement à ce qu'il s'est passé avec le GPU, par exemple) mais force est de constater que ça ne décolle pas.
Je doute que le problème soit l'absence d'un langage unifié simple... (en réalité, toutes les cibles techno type DSP proposent des compilateurs en C et des solutions compilation croisée) enfin ,voyons si cette proposition d'un langage de haut niveau permet d'initier le mouvement, mais j'ai peur que les archi matérielles actuelles engendrant de grosses latences ne le décrédibilise.

0

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

1807 Posté le 04/12/2018 à 18:20:41

Pourquoi il y aurait une grosse latence sachant qu'on deporte la ou il n'y a plus autant de latence ?

0

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

Jimbass

11603

Drogué·e à l’AFéine

Membre depuis 19 ans

1808 Posté le 04/12/2018 à 18:30:20

Le fait de déporter prend du temps, parfois plus que le calcul qu'on déporte.

0

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watt s

EraTom

2282

AFicionado·a

Membre depuis 14 ans

1809 Posté le 04/12/2018 à 19:43:07

Tant que l'ensemble des traitements ne sera pas envoyé vers le DSP et que la DSP n'aura pas un accès direct au DAC, il faudra faire des transferts de données gérés par le CPU et passant par le bus de données, etc.

Mais il n'y a aucune réelle difficultée technique hardware et ça serait évidement intéressant.

Je rabache, mais bon, en fait je ne vois pas trop comment le marché va se créer pour amorcer la transition techno.

Toujours en faisant le parallèle avec l'apparition des cartes graphiques avec GPU :
- la 3d mettait à genoux les CPU ;
- la plus value graphique était évidente ;
- le marché était juteux.

Il n'y avait pas vraiment d'alternative possible : pour avoir un "beau jeu 3d" il fallait passer par la carte dédiée.

Ça a attiré des investissements, les archi hardwares ont été crées (processeur massivement parallèle, bus de données dédié,...), les outils de programmation ont suivis, et des tentatives ont été itérées jusqu'à arriver à un concensus normé.

Les joueurs/consommateur mettent la main au porte-monnaie sans trop se soucier de l'obsolescence tellement les promesses sont grandes à leur yeux : la claque graphique (et d'experience ludique) à chaque nouvelle génération les fait saliver.

Est-ce que l'on est dans la même situation pour l'audio ?
- le marché est moins important ;
- les CPU suivent finalement pas mal ;
- l'obsolescence pose problème ;
- il y a pas mal de techno alternatives pour arriver à une production au top.

Je ne cherche absolument pas à défoncer le concept ; ça m'intéresse réellement et j'adorerais pouvoir jouer avec quelque chose de ce genre pour l'audio... mais plus pour mon côté geek et nerd, la technique et le TSI.
En tant que consommateur de plugin et musicien, je ne comprends pas trop la promesse et je ne vois pas trop l'intérêt.

Ah et concernant le GPGPU vs la solution DSP, la possibilité des calculs massivement parallèlisables ouvre la porte à une nouvelle génération de synthèse additive, aux traitements particulaires, etc.

0

[ Dernière édition du message le 04/12/2018 à 19:50:03 ]

Anonyme

30851

1810 Posté le 04/12/2018 à 20:17:22

Les traitements pourront aussi être de plus en plus décentralisés et "cloudifiés" non ? Quand on voit les débits et les latences d'une bonne ligne internet d'aujourd'hui ca serait pas si déconnant

0

Jimbass

11603

Drogué·e à l’AFéine

Membre depuis 19 ans

1811 Posté le 04/12/2018 à 21:32:54

Il y a aussi des effets de mode sur les différentes technologies.

Ce que je vois dans l'industrie-pas-spécialement-audio, c'est que les DSP sont vus aujourd'hui comme des architectures relativement dépassées (je ne suis pas vraiment d'accord avec ca, je constate seulement). Par exemple dans les gros DSP haut de gamme, les Keystone 2 de Texas Instruments sont sortis en 2012, et il n'y a rien de nouveau depuis.

Les GPGPU ont été très à la mode il y a quelques années, et ca se tasse en ce moment. Les applications pour lesquelles c'est bien adapté s'en servent, mais pour les autres les grands espoirs se dégonflent. Ah quand on a pas des grosses quantités de données bien homogènes, ou qu'on a de fortes contraintes de latence, ca pose de soucis. On n'a pas le contrôle sur le scheduler/dispatcher interne et l'énorme latence d'accès à la mémoire est masquée seulement en moyenne par le fort parallélisme.

Le truc qui est en vogue en ce moment, ce sont les accélérateurs pour algorithmes d'"intelligence artificielle" (deep learning et assimilé). Ca revient à avoir un réseau de plein de DSP, avec une forte connectivité. Deux exemples :
https://www.movidius.com/myriadx
https://www.xilinx.com/support/documentation/white_papers/wp506-ai-engine.pdf

Citation de Patrick :

Les traitements pourront aussi être de plus en plus décentralisés et "cloudifiés" non ? Quand on voit les débits et les latences d'une bonne ligne internet d'aujourd'hui ca serait pas si déconnant

N'oublie pas qu'il n'y a pas de cloud, seulement l'ordinateur de quelqu'un d'autre.
Pour des applications à faible latence, et l'audio "boucle fermée" en fait partie, passer par internet reste rédhibitoire. On verra les développements des réseaux TSN, ca intéresse beaucoup l'automobile.

0

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watt s

[ Dernière édition du message le 04/12/2018 à 21:37:25 ]

jujupauty

1154

AFicionado·a

Membre depuis 22 ans

1812 Posté le 06/12/2018 à 12:13:20

S'il y a une adoption de SOUL dans les plateformes HW, la frontière entre plug in et HW sera de plus en plus floue.

0

Jul

[ Dernière édition du message le 06/12/2018 à 12:13:34 ]

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

1813 Posté le 06/12/2018 à 19:00:46

Citation de Jimbass :

Le fait de déporter prend du temps, parfois plus que le calcul qu'on déporte.

Deporter quoi ? On est deja sur le DSP qui fait deja le calcul ausio sur le meme flux.

0

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

[ Dernière édition du message le 06/12/2018 à 19:00:57 ]

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

1814 Posté le 06/12/2018 à 19:02:11

Citation de EraTom :

Tant que l'ensemble des traitements ne sera pas envoyé vers le DSP et que la DSP n'aura pas un accès direct au DAC, il faudra faire des transferts de données gérés par le CPU et passant par le bus de données, etc.

Le principe, c'est de deporter sur le DSP qui s'occupe deja du DAC.

0

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

Jimbass

11603

Drogué·e à l’AFéine

Membre depuis 19 ans

1815 Posté le 07/12/2018 à 00:55:28

Citation de miles1981 :

On est deja sur le DSP

Ou pas, justement.

0

Musikmesser 2013 - Bullshit Gourous - Tocxic Instruments - festivals Foud'Rock, Metal Sphère et la Tour met les Watt s

EraTom

2282

AFicionado·a

Membre depuis 14 ans

1816 Posté le 07/12/2018 à 00:56:01

Oui on est d'accord sur le principe, mais il faudra bien que l'ensemble des traitements soit déporté.

Tant qu'il y aura seulement un élément de la chaîne qui tournera sur le CPU, le problème de la latence se posera.

1

Wolfen

14007

Rédacteur·trice

Membre depuis 23 ans

1817 Posté le 11/01/2019 à 13:44:51

Nouvelle vidéo sur SOUL :

https://skillsmatter.com/skillscasts/13153-adc-january

1

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape | Soundcloud

miles1981

8370

Je poste, donc je suis

Membre depuis 21 ans

1818 Posté le 11/01/2019 à 14:18:35

Ah, c'etait au meetup auquel je n'ai pas pu assister

0

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

Anonyme

30851

1819 Posté le 01/02/2019 à 18:41:22

Hello je reviens (encore) avec python. Bon finalement je suis bien obligé de m'y mettre, la je développe un petit programme en python qui exécute une liste de commandes via SSH sur un serveur (sous linux) depuis mon PC pour faire de l'automatisation. Jusque la rien de bien spécial, ca marche plutôt bien.

Par contre, ce serveur a deux autres machines (aussi sous linux) qui sont connectées dessus et qui elles, ne sont pas accessibles depuis l'extérieur.
Pour accéder à ces deux autre machine je dois lancer une session ssh à partir du serveur pour m'y connecter et faire ce que j'ai à faire.

Depuis mon script j'aimerais quand même pouvoir m'y connecter et lancer quelques commandes. J'y arrive en faisant exécuter à mon programme une ligne du style (qui du coup est exécutée sur le serveur) :


ssh user@ip_d'une_des_seconde_machine 'cd /home && echo bonjour > toto.txt && ls -l'

Mais bon je suis moyennement satisfait, le but de mon programme est d'automatiser d'une manière propre des tâches. j'aimerais plutot que ca fasse un truc du genre :


instructions serveur

ssh machine_1
instructions machine 1
exit

instruction serveur

Vu que les machines connectées ne sont pas visibles depuis mon poste ou le programme est exécuté, pas moyen de rouvrir une autre session ssh vers ces machines, et je n'ai pas le droit de changer les règles réseau, et il faut que j'évite au maximum d’exécuter quoi que ce soit d'autre que des commandes standards sur le serveur :??:

Sur les deux autres machines impossible d'installer quoi que ce soit.

pour schématiser voila la tronche du réseau :



                      +---> Machine 1
                      |
PC ------>Serveur-----+
                      |
                      +---> Machine 2

Est ce qu'il y aurait un moyen d'améliorer un peu ce cas de figure ?

J'imagine bien qu'il y a déjà des solutions qui pourraient répondre à ce genre de besoins, mais j'aimerais autant que possible le faire moi même pour pratiquer un peu python.

0

Anonyme

4548

1820 Posté le 01/02/2019 à 19:01:11

Question peut être conne mais y'a une raison particulière pour toi de faire ça en python et pas en script bash directement ?

Sinon y'a une option déjà toute faite pour ça dans OpenSSH à partir de la version 7.3 (proxy jump).


ssh -J user@serveur-public user@machine-privee

Je te conseille de combiner ça avec un fichier config pour ssh histoire de simplifier le tout (et en fait d'utiliser un fichier config dans tous les cas quoi que tu fasses avec ssh).



~/.ssh/config

Host serveur-public
  Hostname ip-du-serveur
  IdentityFile ~/.ssh/cle-privee-a-utiliser
  User user

Host machine-privee
  ProxyJump serveur-public
  Hostname ip-de-la-machine
  IdentityFile ~/.ssh/cle-privee-a-utiliser
  User user

Une fois que tu as ce fichier config tu fais


ssh machine-privee

et pif paf pouf tout se fait tout seul (si tu as ssh-agent déjà correctement configuré et qui tourne sur la machine client pour assurer le forward des clés, ça c'est encore un autre sujet).

Si tu veux chercher plus d'info ça s'appelle un bastion SSH (un serveur sur réseau public qui sert d'intermédiaire d'accès à des serveurs sur réseau privé).

1

[ Dernière édition du message le 01/02/2019 à 19:02:04 ]

Al1r

2356

AFicionado·a

Membre depuis 17 ans

1821 Posté le 01/02/2019 à 19:39:51

Citation :

Hello je reviens (encore) avec python. Bon finalement je suis bien obligé de m'y mettre, la je développe un petit programme en python qui exécute une liste de commandes via SSH sur un serveur (sous linux) depuis mon PC pour faire de l'automatisation. Jusque la rien de bien spécial, ca marche plutôt bien.

Pour palier ce genre de problème, RedHat développe un produit qui est très souple pour ce genre de sport: Ansible.
plus accessible, tu peux installer Jenkins. Jenkins + ansible dans le genre automatisation c'est assez top.

0

AL1

Djardin

19834

Drogué·e à l’AFéine

Membre depuis 20 ans

1822 Posté le 01/02/2019 à 21:14:40

Citation :

Question peut être conne mais y'a une raison particulière pour toi de faire ça en python et pas en script bash directement ?

c'est plus facile de faire des tests unitaires et du TDD en python qu'en bash ? Et de maintenir, faire des libs, réutiliser et faire relire ?

On a un truc du genre au taf, en bash et au début c'était un mini-script, donc pas besoin de quoi que ce soit.
Mais plus ça va, plus il grossit et là après quelques années il fait énormément de trucs. Et on se rends compte que si au lieu de faire du bash on aurait fait du python on aurait pu avoir des tests, des librairies, un truc maintenable et fiable.
Alors que là on a un très gros paquets de scripts.

0

Référence en matière de bon gout capillaire et vestimentaire.
homme à tête de zizi.

http://soundcloud.com/djardin

Anonyme

30851

1823 Posté le 01/02/2019 à 21:35:31

Citation :

Question peut être conne mais y'a une raison particulière pour toi de faire ça en python et pas en script bash directement ?

Pour une raison toute simple le serveur n'est pas à l'heure ni à la date. Et les deux machines privées non plus et pour parfaire le truc tout ce petit monde n'est absolument pas synchronisé, et je ne peux pas modifier ca. Et pour faire de l'archivage c'est vraiment pas pratique du tout :??:

Merci pour le conseil open ssh je vais regarder ca.

Al1r > Oui, j'imagine bien, mais j'aimerais autant que possible mettre moi même les mains dans le cambouis et développer le truc. Je ne pense pas faire mieux que les développeurs de jenkins ou autre (très très trèèèès loin de la c'est le premier vrai truc en python que je fait qui dépasse 3 lignes) mais j'ai envie de comprendre et de bricoler par moi même. Et je voudrais faire aussi quelque chose de très léger le plus générique possible et facile à déployer.

La pour l'instant le programme arrive à ouvrir des scripts qui sont dans un fichier texte, à reconnaitre des mots clés et à les remplacer par autre chose (genre mkdir %DAY_DATE%_fichiers devient mkdir 2019_02_01_fichiers) mais il y a moyen de pousser encore un peu et d'avoir un petit outil bien sympathique je pense

0

[ Dernière édition du message le 01/02/2019 à 22:02:12 ]

Truelle est un manchot

10417

Drogué·e à l’AFéine

Membre depuis 15 ans

1824 Posté le 01/02/2019 à 21:50:11

Je ne suis pas sur mais je crois que SaltStack est le genre d'outil du type ansible qui peut faire ce boulot.

Sinon pour les scripts bash trop gros il y a Xonsh pour faire à la fois du python et du Bash dans sa console. C'est devenu mon shell par défaut.

0

Anonyme

4548

1825 Posté le 01/02/2019 à 23:04:37

djardin > je suis d'accord avec toi mais ce n'est sans doute absolument pas la raison pour laquelle truelle fait ça en python.

0