Tous les articles par Jean-Claude Dufourd

jcd
module: informatique

Module: Communication Client Serveur

Contact pour le module :

Jean-Claude Dufourd (at telecom-paris.fr), 5D30
Jean-Claude Moissinac, 5D26

Description du module :

Dans tous les cas où plusieurs entités informatiques discutent entre elles au sein d’un projet, une communication « client-serveur » est mise en oeuvre (même quand les deux entités sont des pairs).

Ce module permet d’explorer les aspects simples de la communication entre deux programmes et/ou entre deux machines par le réseau, avec pas mal d’options:

  • communication entre deux programmes Java tournant sur la même machine
  • les options ci-dessus entre deux PC différents, ou entre un appareil Androïd et un PC, ou entre deux appareils Androïd
  • les options ci-dessus avec plus de 2 entités communicantes
  • les options ci-dessus utilisant Internet/Wifi ou bluetooth
  • une communication simple commande/réponse en texte
  • une communication plus complexe incluant aussi des transferts de ressources
  • une communication à débit plus élevé nécessitant l’utilisation d’un format binaire…

Objectifs du module :

  • Savoir communiquer entre deux programmes tournant sur la même machine ou sur des machines différentes par le réseau.
  • Définir le bon niveau de communication et les éléments du dialogue entre les deux (ou plus) entités.

Livrables envisageables :

En fonction de la complexité du module à réaliser tout ou partie des points suivants pourrait être considéré comme des étapes réaliste de la mise au point de votre application concurrente ou répartie :

  • PAN1 :
    • Ecrire la description de toutes les commandes et de toutes les réponses possibles entre le client et le serveur.
  • PAN2 :
    • Livrable: identification des interface utilisées et des bibliothèques offrant le motif socket + socket server; premier squelette de code réalisant la connexion entre nœuds du réseau.
  • PAN3 :
    • Livrable : code Java / Android réalisant une communication de messages entre les deux nœuds (initialisation de l’interface, formatage et décodage de messages simples).

Ressources :

Uncategorized

PAN3: salles et heures

Voici les salles et horaires pour le PAN3. Les soutenances ont lieu avec deux groupes présents dans la salle.

Groupes 1

  • en B543 1.3 et 1.4: 8h30/9h15 (vous resterez ensuite dans la salle)
  • en B316 (l’installation des 12 le nécessite)  1.1 et 1.2: 10h15/11h

Groupes 2 en B555

  • 2.3 et 2.4: 8h30/9h15
  • 2.1 et 2.2: 10h15/11h (les groupes 2.3 et 2.4 vont travailler en B551 exceptionnellement)

Groupes 3 en B567

  • 3.3 et 3.4: 8h30/9h15
  • 3.1 et 3.2: 10h15/11h (les groupes 3.3 et 3.4 vont travailler en B559 exceptionnellement)

Groupes 4 en C47

  • 4.3 et 4.4: 8h30/9h15
  • 4.1 et 4.2: 10h15/11h (les groupes 4.3 et 4.4 vont travailler en C46 exceptionnellement)

Groupes 5 en C49

  • 5.3 et 5.4: 8h30/9h15
  • 5.1 et 5.2: 10h15/11h (les groupes 5.3 et 5.4 vont travailler en C48 exceptionnellement)

 

Uncategorized

PAN2: salles et heures

Le second PAN a lieu le 19 janvier de 8h30 à 11h45.

L’ordre de passage est:

  • groupe x.2 à 8h30
  • groupe x.3 à 9h15
  • groupe x.4 à 10h15
  • groupe x.1 à 11h00

Les salles sont:

  • jury des 1.* en F900
  • jury des 2.* en E800-1
  • jury des 3.* en F503
  • jury des 4.* en F603
  • jury des 5.* en B549

Il y a dans chaque jury un membre du copil, un encadrant SES et un encadrant GL, mais les tuteurs et experts sont encouragés à assister aux soutenances s’ils sont disponibles.

Les attendus sont:

1- présentation : elle durera entre 10′ et 15′ (au dessus elle sera coupée) avec les points suivants :
* rappel très succinct du sujet
* modification apportées depuis le PAN1
* avancement global dont en particulier l’avancement des modules (en % par rapport aux attendus du PAN2 tels que décrits),
difficultés identifiées le cas échéant
* point module ses
* point GL
* point matériel
l’ordre n’est pas imposé.
A l’issue de la présentation, le jury discutera avec vous et vous fera un retour à chaud.

2- les modules
au PAN2 une évaluation de l’avancement des modules sera faite par les experts (Ils ont reçu un formulaire pour cela).
Il s’agira notamment d’une note A,B,C ou F.
IMPORTANT : il vous incombe de rencontrer/contacter les experts pour qu’ils effectuent cette évaluation et discutent cela avec vous.

3- le document évolutif d’avancement
les modifications par rapport à PAN1 concerneront notamment :
– les corrections demandées par le jury
– la mise à jour du diagramme temporel, accompagnée d’un commentaire (rapide) des ajustements
– le détail des tests pour le GL
– l’ajout des fiches modules manquantes le cas échéant
– en annexe, une description rapide de l’avancement de chaque module avec éventuellement une analyse des difficultés.

Date limite de retour  : Mercredi 14/01 à minuit
+ par email à bertrand dot david at telecom-paristech dot fr avec pour sujet [PACT][Doc PAN2][GXX] où XX est votre numéro de groupe.
+ en pdf uniquement

Uncategorized

Android sur Mac

Suite à divers problèmes avec Android sur Mac, voici la démarche conseillée. Si vous installez Android Studio pour Mac, contrairement à ce qui est marqué sur le site, vous devrez séparément télécharger les SDK Android.

Ensuite, vous aurez une version d’Android Studio 0.8.14 (de mémoire). Si vous faites « CHECK FOR UPDATES », il vous proposera de télécharger une mise à jour vers 0.9.9: faites le.

Une phase de mise à jour de SDK sera peut être déclenchée automatiquement à la première exécution.

Si vous faites encore « CHECK FOR UPDATES », il vous proposera une mise à jour vers 1.0.2: faites le aussi.

A la première exécution, vous aurez sans doute une fenêtre de mise à jour des SDK et build tools, et vous aurez peut être un échec avec gradle, avec un message du genre:

to use gradle with android-21, JDK 7 is required

Allez sur le site Java d’Oracle. Choisissez la dernière version de Java SE pour Mac (8u25 à ce jour). Téléchargez, installez. Dans les préférences du PROJET dans Android Studio (pas les préférences générales), choisissez « JDK Location » et mettez un équivalent de:

/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home

Attention, la JVM d’Apple est dans /System/Library, celle d’Oracle est dans /Library. La version 1.6 continue d’être utilisée par toutes les applications sauf Android Studio.

J’utilise l’émulateur qui est assez rapide sur ma machine. Si vous utilisez GenyMotion, il faudra sans doute aussi installer ou mettre à jour VirtualBox, puis installer ou mettre à jour les VM de terminaux.

Uncategorized

PAN1: heures et salles

Le premier PAN a lieu le 1er décembre de 8h30 à 11h45.

L’ordre de passage est:

  • groupe x.1 à 8h30
  • groupe x.2 à 9h15
  • groupe x.3 à 10h15
  • groupe x.4 à 11h00

Les salles sont:

  • jury des 1.* en C47
  • jury des 2.* en C017
  • jury des 3.* en F503
  • jury des 4.* en F801
  • jury des 5.* en F804

Il y a dans chaque jury un membre du copil, un encadrant SES et un encadrant GL, mais les tuteurs et experts sont encouragés à assister aux soutenances s’ils sont disponibles.

module: informatique

Module: Intégration et Tests

Expert : votre encadrant GL

coordinateur: Jean-Claude Dufourd, email : dufourd_at_telecom-paris.fr

Objectif du module : Mettre le résultat de tous les autres modules ensemble et faire marcher le tout.

  • Vérifier que chaque module implémente l’interface prévue (par compilation)
  • Vérifier que chaque module a été testé (présence de tests dans le module)
  • Créer les tests globaux, équivalents des méthodes de tests des modules au niveau du projet entier
    • tests de fonctionnalité : ça fait ce qu’il faut
    • tests de performance : ça va assez vite
    • tests d’utilisabilité : c’est compréhensible par un utilisateur extérieur
    • …
  • Appliquer un par un les cas de tests globaux prévus dans le plan de test:
    • Faire des retours aux créateurs des modules sur les problèmes.
    • Trouver des solutions pour les problèmes non spécifiques à un module.

Supports de cours :

Attentes pour les différents PAN:

PAN 1 :

Une partie de ce qui suit est de la responsabilité de tout le groupe, mais il est bon de le rappeler ici:

  • Description textuelle et schéma décrivant l’architecture du système
    • formalisme libre mais cohérent et légendé
  • Diagramme d’activité et/ou de séquence (temporel)
    • Faisant apparaître les acteurs et actions
    • Et les transitions avec leur(s) condition(s)
  • Description des interfaces entre modules (texte)
  • Dépot Git unique
    • Avec la bonne structure de dossier
    • Avec un commit par personne dans readme.txt

PAN 2 :

  •  Plan de test global
    • Liste des tests de fonctionalité, de performance, d’utilisabilité, d’acceptabilité… (tous les types de test be sont pas forcément pertinents pour votre projet)
    • Pour chaque test
      • contexte de test
      • liste des entrées à fournir
      • liste des sorties attendus, avec la méthode de validation (est-ce qu’on attend exactement ce résultat au bit près, ou dans une certaine marge d’erreur, ou un résultat de cette forme…)
  • Squelettes de toutes les méthodes principales
    • sous forme simulée
      • Fantôme : méthode vide utilisant System.out.println pour indiquer qu’elle est appelée.
      • Bouchon : méthode renvoyant toujours le même résultat.
      • Substitut : implémentation de la méthode très simplifiée.

PAN 3 :

  • rapport sur l’état de l’intégration des modules (quel module, quelle version, quels problèmes) dans le proto allégé
  • résultat des tests (passés, échoués, résultats quantitatifs/qualitatifs sur les performances, l’acceptabilité …) du proto allégé
  • Note: le rapport et les résultats se feront en utilisant les modules tels qu’implémentés, testés et livrés par les responsables des autres modules à une date à déterminer entre les responsables de modules. Il est acceptable qu’un livrable du module « test et intégration » ne contienne pas la dernière version d’un module (si ce dernier est en retard). Les retards seront cependant à justifier et feront l’objet d’une appréciation par le jury dans la notation de ces modules.
  • Note: l’encadrant va vérifier sur le dépôt Git que le code est documenté, lisible, maintenable, que tous les élèves ont contribué…

PAN 4 :

  • comme le PAN3 pour le prototype final…

 

module: audio et langage, module: traitements

Module : Détection d’attaque / fonction de détection

Titre du module : Détection d’attaque
proposé par :

  • Geoffroy Peeters (geoffroy.peeters_at_telecom-paristech.fr)
  • Roland Badeau (roland.badeau_at_telecom-paristech.fr)
Descriptif
Le mot « attaque » désigne le début d’un évènement sonore, et par extension, l’instant correspondant ou par exemple, une note est jouée. Détecter ces attaques est un aspect fondamental nécessaire dans les applications d’inférences rythmique (tempo, métrique, mesure) et plus généralement dans l’analyse de scènes audio. La fonction de détection est le terme utilisé pour décrire un signal temporel ou les attaques sont mises en évidence sous forme de pics saillants.L’algorithme de base de ce type de détecteur est le suivant :

  1. Détection d’enveloppe :  traduit les propriétés énergétiques locales de ce dernier. La détection d’enveloppe permet d’obtenir cette information. En général obtenue à l’aide d’un filtrage passe-bas de l’énergie instantannée.
  2. Dérivation de cette fonction enveloppe : on utilise un filtre RIF qui simule l’opérateur de dérivation. Les valeurs positives de de cette dérivée mettent en évidence les front montant d’énergie et constituent une bonne fonction de détection.
Ressources dont le module dépend
  • wikipédia : filterbank, spectrogram, filter, cours oasis (SI101) filtrage
  • bibliothèques JAVA à mettre en oeuvre : math common api
  • compléments : un  tp de 2007 en signal, détecteur de mélodie (contient de la détection d’enveloppe et de la détection de hauteur notamment).
  • biblio et slides : sur cette page (intranet)
Exemples d’utilisation du module
  • dans des composants pact :
    • dans la détection du rythme
    • pour synchroniser musique et image
  • dans des systèmes existants :
    • editeurs audio (beat tracking)
    • détection d’activité
Résultats attendus
  • connaissances : filtrage RIF, passe-bas, passe-haut, dérivateur, méthode de Parks-mc Lellan (ou Remez)
  • compétence : savoir expliquer avec ses propres mots le principe de fonctionnement d’un détecteur d’attaque, savoir choisir les filtres (longueur, type), être capable de mettre un oeuvre un filtre numérique simple
  • PAN 2 : notice descriptive précise (choix de paramètres, justifications des choix, description mathématique, description informatique) contenant le pseudo-code à mettre en oeuvre, éventuellement implémenté en matlab/octave sour forme de fonction.
  • PAN3 :
    • code java commenté et structuré de manière à être lisible.
    • tests de la fonction d’attaque :
      • sur un signal avec des sons bien séparé de batterie
      • sur des signaux plus complexes
  • PAN 4 (éventuel) :
    • pour des signaux plus complexes : rajouter un banc de filtre (module banc de filtre)
    • calculer une fonction de détection dans chaque bande et fusionner l’ensemble (somme pondérée des fonctions dans chaque bande)
    • tester les améliorations par rapport au modèle plus simple précédent sur des cas plus complexes que vous définirez vous même.
module: audio et langage, module: traitements

Module : synthèse à table d’onde

Titre du module : Synthèse à table d’onde
proposé par :

  • Geoffroy Peeters (geoffroy.peeters_at_telecom-paristech.fr)
  • Roland Badeau (roland.badeau_at_telecom-paristech.fr)
Descriptif
La synthèse sonore regroupe un ensemble de procédés numériques et d’algorithmes destinés à produire des sons. Ces sons peuvent être environnementaux, comme par exemple dans le cas des jeux vidéo (vent, bruits lors de contacts ou d’interaction avec des objets, bruits d’ambiance tels que les chants d’oiseaux…) ou musicaux. La synthèse à table d’onde consiste à enregistrer simplement les sons en mémoire morte pour les rejouer ensuite. En général on n’enregistre pas tous les sons possibles : il est nécessaire de reconstituer les sons par rééchantillonnage et interpolation à partir des notes dont on dispose. Souvent, le son est enregistré en plusieurs morceaux (attaque-sustain-release) par exemple et il est nécessaire de boucler dans la partie de maintien tant que la note est jouée.
Ressources dont le module dépend
  • Cours SI340, synthèse sonore, Curtis Roads « Audionumérique », M. Kahrs « Application of digital signal processing to audio and acoustics »
  • en anglais : wavetable synthesis.
  • bibliothèques JAVA à mettre en oeuvre : math common api
Exemples d’utilisation du module
  • dans des composants pact :
    • synthèse sonore
  • dans des systèmes existants :
    • la plupart des ordinateurs
    • synthétiseurs dit « à échantillonnage »
Résultats attendus
  • connaissances : synthèse sonore, sous/sur échantillonnage, filtrage, interpolation fractionnaire
  • compétence : savoir expliquer les problèmes liés au rééchantillonnage d’un signal, savoir expliquer les problèmes liés au bouclage d’une forme d’onde, savoir mettre en oeuvre plusieurs types d’interpolation et comparer leur effets sur le spectre des sons produits.
  • PAN2 : notice descriptive précise (principe général et systèmes mis en oeuvre, choix et réglages des paramètres) contenant le pseudo-code à mettre en oeuvre, év. une implémentation de démo sous matlab ou octave. Définition de la base de sons préenregistrée.
  • PAN3 : code java commenté et structuré de manière à être lisible mettant en oeuvre une interpolation d’ordre 1 et év. bouclage (selon les sons choisis).
  • PAN4 : eventuel : code java et démonstration avec interpolation d’ordre supérieur (B-splines). comparaisons et tests d’écoute. Mise en oeuvres de traitements complémentaires (filtrages, reverb, modifications de timbre)