Reprise du message précédent :

 
Alors tu peux y aller les yeux fermés. C'est triste à dire, mais c'est le meilleur support qui existe, parce qu'ils remplacent quasiment systématiquement les appareils défectueux.

 
avoir un bon son sur une télé, c'est un peu la galère depuis l'arrivée du HDMI.
 
Est-ce que ta télé supporte bien le ARC ? Sans latence (certaines implémentations eARC peuvent ajouter une demi seconde de latence)
 
Si ton ampli n'est pas sur ARC, alors il faut qu'il supporte la norme HDMI pour les périphériques que tu brancheras dessus, même si c'est purement pour la vidéo.
Par exemple, les nouvelles consoles parlent de 8K et de 4K à 120Hz, est-ce que c'est quelque chose que tu penses vouloir un jour dans le futur ? Si oui, il faut que tu vérifies que l'ampli que tu choisis supporte la bonne norme HDMI ou sinon il faudra le changer le moment venu

Un peu... c'est même pire que ce que tu décris : la communauté C existe et est très active, mais elle est constituée essentiellement de néophytes d'une part, qui utilisent C parce que c'est un langage encore souvent présenté comme étant la base (ils sont de moins en moins nombreux) et d'autre part des types qui ont effectivement besoin du C, des malades quoi.
 
Je te suggère de le faire en Python, c'est pareil en plus simple.

 
Cela dit, certains SDK pour plateformes commencent à s'en écarter (genre Oculus, qui dès la sortie officielle du Rift, avait un SDK qui demandait du C++11)

 
après ils ont pas le S950H, et je pensais partir dessus.. Ca se réfléchit..

ok, je vais insister un peu

Perso, je me suis mis au C surtout parce que je "suis" des projets qui intègrent de l'embarqué . Et qu'il me fallait un langage pour les moments ou j'aurais un proto à faire (ça m'a été très utile jusque là).
Mais quand il s'agit d'aller travailler avec un OS, et pire, windows, ça se complique un peu

 
ben personne
surtout que je te laisse imaginé l'impact sur la batterie de l'écran allumé en permanence

 
Sauf qu'Apple a développé une API qui permet le contact tracing en tache de fond, de façon sécurisée et anonyme. Mais le gouvernement n'en veut pas parce qu'ils tiennent à une solution centralisée

ou plutôt : ils veulent une centralisation chez le gouvernement plutôt que chez Apple et Google

Google et Apple se sont basés sur DP-3T dont tout l’intérêt est d’être décentralisé non? Donc la version originale me semble plus correcte que la tienne. Surtout que les allemands et les suisses semblent aussi s’être barrés de pepp-pt pour passer sur dp-3t.

Dommage que DP3T ne soit pas plus utilisé pour le contact tracing. Perso, je suis pas chaud pour que des données persos en rapport avec du médical soient stockées chez des entreprises privées étrangères mais je ne suis pas chaud non plus qu'elles soient stockées de manière centralisée par notre gouvernement

J'avais cru comprendre que DP3T était un protocole à l'initiative de chercheurs de l'école EPFL (Lausane).

Entre autres, mais ça ne veut pas dire que le gouvernement était dessus.  

 
 
Tu t'imagines bien que si je prends un ampli HC, c'est pas pour sortir le son sur la télé.
 
Le son sort sur les 5 enceintes , et pas sur la TV, donc le eARC, je m'en fous
 
l'ampli fait du 4k, j'en ai pour un moment. J'ai une TV que full HD pour le moment, et pas l'intention d'en changer avant qu'elle tombe en rade.
 
Et au pire du pire, sur une télé plus moderne je peux dissocier le son (en optique ou coax) vers l'ampli, et l'image vers la TV, comme je fais maintenant. La Logitech Harmony me gère les switch de sorties, donc voilà.
 
 
 

La "defensive copy" en python et en général vous en pensez quoi ?
 
Utile ou branlette intellectuelle/perte de perfs/difficile à garder cohérent ?

 
De ce que j'ai compris, c'est décentralisé, mais il y a bien un endroit où  déclarer et propager  " l'ephemeral Id bidule  est malade, qui l'a croisé"

 
l'arc permet ce sortir le son de la tv sur l'ampli, si tu regardes la TNT, le son sort sur les enceintes
l'optique ne permet pas les format hd ( dts ma, dolby true hd et suivant) c'est dommage, même si dans les fait c'est difficile a différentier si tu n'as pas un sytème top et une pièce bien réglée

Ben ça dépend de la culture du langage je trouve. En C++ la différence entre copie et référence est assez fondamentale, mais si je code en C# je m'attends à ce que tout soit référence et à ne voir une copie que si j'appelle une méthode .Clone() ou truc du genre.

Ah oui, il y a ça aussi. Mais je m'en fous en fait : la TV ne me sert qu'à l'affichage, c'est la box qui reçoit la TV.

Le seul cas où ça pourrait m'ennuyer, c'est quand je lis des contenus depuis la TV (genre Arte.tv, ou les trucs sur le NAS), mais si c'est que ça j'ajoute un chromecast a une des entrées HDMI de l'ampli.

après, c'est quand même con qu'un appareil comme ça ne soit pas capable de lire des contenus vidéo..

(et je viens de vérifier, ma TV bien que de 2015 a l'ARC, donc ça clôt le débat )

Ce qui change entre les 2 amplis est assez subtil :

le 950 fait l'upscaling 4K, que le 1600 ne fait pas,
le 1600 a le bluetooth 4.1 contre 3.0 + EDR pour le 950.

Le 950 a un plus gros transfo..D'après ce que j'ai pu lire à droite à gauche, les gammes S et X de Denon se "recouvrent" :

S650 / S750   / S950
          X1600 / X2600 / X3600 ....

Et effectivement, niveau chassis/poids, etc..le 950 et le 2600 ont l'air d'être identiques.

Le ARC, c'est justement pour ne pas avoir le son sur la télé.
En gros tu as deux possibilités :
1/ Source -> Ampli -> TV
Ton ampli doit être mis à jour si tu veux supporter un affichage qu'il ne supporte pas, même si tu veux juste conserver l'audio telle quelle

2/ Source -> TV -> Ampli (sur port HDMI supportant ARC de la TV)
Ton ampli devient décorrellé de tes considérations vidéos.

Dans les deux cas le son sort des enceintes connectées à l'ampli.

La sortie optique des TV n'est pas nécessairement prête à supporter du 5.1 au plus, pas mal de TV downgrade vers du 2.0 comme demandé pour les sorties qui ne supportent pas le HDCP.

Yep

Les codecs video/audio bougent vite, et les lecteur (mibox, chromecast ) coutent une misère et peuvent être changés plusieurs fois au fil de la vie de l'ampli
 
Perso pour l'ampli (onkyo) je me suis concentré sur la connectique (norme hdmi, arc, wifi, bluetooth, nombre de sorties, ...) , sur les format de flux supportés, plutôt que sur l'aspect logiciel

 
De ce j'imagine t'es obligé de centraliser les infos que untel est malade pour pouvoir le broadcaster. Mais t'as pas besoin de centraliser les croisements, ça peut rester en local.

ok, c'est une différence importante

 
Tu as quoi comme ampli ?

un 545 : https://www.son-video.com/article/a [...] nr545-noir

Les denon sont surtout apprécié pour leur truc "Audyssey" et la calibration donc. En tout cas je vois toujours ça sur le topic HC.

 
Toutes les marques ont des systèmes de calibration automatique, maintenant.
 

Certes, mais aucun n'arrive à le cheville de Denon, toujours selon HFR, ca vaut ce que ça vaut.

dans une salle dédiée avec des cables en poil de cul de yack, je veux bien le croire
dans mon salon avec des meubles et de l'écho, je ne suis pas sur que la différence soit notable

J'ai un Onkyo 656 depuis fin 2016 (j'avais un 607 avant).
 
Le système Audissey est beaucoup plus précis en effet (plusieurs points de mesures, tu peux acheter l'appli de calibration dédiée). Le 3600H a l'air top d'après les reviews.  
 
J'ai craqué récemment pour ce pack : https://www.supersonido.es/p/q-acou [...] -pb-2000__
Le caisson remue bien  
 
J'en ai profité pour faire un pied en chêne pour un des satellites.  

J'aurais justement dit que c'est dans ce cas que ça se joue.
 
Si ta pièce est bien propre et sans défaut, c'est plus facile pour le micro de bien tout capter et calibrer ensuite. Quand y'a de l'écho ou une archi chelou, c'est plus compliqué.

Voilà, en python j’en ai rarement / jamais eu le besoin, en C ça semble plus touchy.  

C’est aussi ce que j’ai compris.  
 
Quand X declare qu’il est malade, il balance ses ephid au serveur, les clients récupèrent la liste, regardent s’ils ont été en contact avec un des ephid, et notifient leur utilisateur si oui.  
 
Donc le serveur central n’est utilisé que pour propager une information d’infection, et n’a aucune info sur les croisements.

Ouais c'est le design 1 : https://github.com/DP-3T/documents/ [...] 0Paper.pdf
C'est ce design chez Apple et Google d'après le readme du projet.  
 
Y a un second design dans le white paper.

 
 
Une version plus "lègère" de l'explication: la vidéo de science4all  
https://youtu.be/RKZOBSdkUBo

ça sent le bloom filter...

Putain, Florian Schneider, fondateur de Kraftwerk est mort. Fait chier

L'inconvénient (du point de vue gvt) c'est que l'utilisateur est alors le seul à savoir qu'il a été en contact avec le malade. On ne peut donc pas contrôler qu'il prend les bonnes mesures

Connnaissant Harko je cherche la contrepèterie, mais je trouve pas

Sinon aujourd'hui j'ai vu :
- la fille qui porte un masque et des gants dans la rue et qui abaisse le masque sur le menton pour faire la bise à ses copains qu'elle croise
- mon chef le polytechnicien qui écrit "comme même"
 
Je crois que je vais me coucher tôt

Je sais pas si les quantités valent le coup pour un bloom filter, si les ephid ont une durée de vie de 5mn ça n'en fait que 300/jour/appareil, donc tu vas probablement être sous le million de croisements par an.

Chercher une fenêtre de 15j (4500 ephid) dans une année d'enregistrement, trivialement, en Python (avec deux gros set dégueu en mémoire) ça prend moins d'une demi seconde.

Rien n'empêche que l'application envoie l'information automatiquement je présume, le but de la décentralisation c'est principalement d'éviter le tracking de toutes les interactions (et donc de tous les mouvements), et les dérives qui peuvent trivialement s'en suivre.