agardelein a écrit 6 commentaires

  • [^] # Re: Bon point pour le bluetooth

    Posté par  . En réponse à la dépêche Publication de Textoter 0.51. Évalué à 2.

    Oui pas besoin d'installer d'application sur le téléphone. Textoter utilise directement l'interface Bluetooth du téléphone.

  • [^] # Re: python3-pip

    Posté par  . En réponse à la dépêche Publication de Textoter 0.51. Évalué à 1.

    Merci pour ces retours encourageants !

    Il y a effectivement une erreur stupide qui s'est glissée dans le code de configuration… Elle est reportée également sur Github, avec un contournement en attendant la correction, prévue pour la semaine prochaine.

    Pour le paquet python3-pip, issue créée.

  • [^] # Re: trop tard (pour moi)

    Posté par  . En réponse à la dépêche Sortie de Oscopy 0.71. Évalué à 1.

    Je viens d'ajouter comme objectif de la version 0.72 l'optimisation de la relecture des fichiers et de la mise à jour des graphes. Cela devrait permettre une meilleure réactivité pour afficher des graphiques plus rapidement.

  • [^] # Re: trop tard (pour moi)

    Posté par  . En réponse à la dépêche Sortie de Oscopy 0.71. Évalué à 4.

    Tout d'abord une clarification pour éviter toute confusion: actuellement Oscopy est un oscilloscope pour simulateur électronique. Il lit des fichiers contenant des données pour ensuite les afficher après éventuel post-traitement. Voir aussi ce commentaire ci-dessus.

    Ceci posé, l'intégration d'un affichage temps réel dans Oscopy se traduit par une extension de la classe Figure. Qu'as-tu utilisé pour l'affichage "temps réel" ?

    Pour répondre à tes questions:

    • Avec la configuration actuelle la fréquence max d'acquisition/visualisation doit être de l'ordre de 1-2 Hz le temps que Matplotlib redessine la Figure.
    • Le flux de données est ouvert, du moment qu'un Reader existe pour le lire. Un Reader est juste une classe qui lit un flux et le transforme en Signal, qui encapsule deux simples vecteurs numpy –abscisse et ordonnée. Actuellement les flux utilisés sont des fichiers, mais l'architecture d'Oscopy ne devrait pas poser d'obstacles à l'utilisation d'autre types (pipes, shm, dbus…). Par contre je ne dispose pas des middlewares que tu mentionnes, je ne suis pas en mesure d'ajouter moi-même un tel Reader.
    • Matplotlib pour la facilité d'intégration dans une application Python et le rendu.

    L'affichage dans des onglets ou fenêtre est un long débat… De ce fait, je vais intégrer les onglets dans les objectifs pour la version 0.72, tout en gardant la possibilité de faire de nouvelles fenêtres.

    A toutes fins utiles, je viens de rajouter sur le site officiel le manuel de l'API qui détaille comment étendre les possibilités d'Oscopy.

  • [^] # Re: Acquisition de signaux

    Posté par  . En réponse à la dépêche Sortie de Oscopy 0.71. Évalué à 5.

    De manière générale j'ai conçu Oscopy pour qu'il soit extensible facilement, pour que la taille de code d'interface soit minimale. Si le format d'entrée est trivial, juste quelques lignes de Python suffisent (voir le Reader pour le format cazm). D'autre part Oscopy accepte des signaux soit POSIX ou transmis via DBus, principalement pour déclencher la relecture des fichiers d'entrée.

    Pour transformer Oscopy en oscilloscope low-cost, il faut un module Oscopy Reader permettant de lire une entrée audio ou une carte d'acquisition, puis déclencher éventuellement la relecture de l'entrée par un programme tiers en utilisant DBus ou les signaux POSIX.

  • [^] # Re: Linux et bricolage maison

    Posté par  . En réponse à la dépêche Oscopy 0.70 aka 20110921 disponible. Évalué à 0.

    Oscopy est conçu pour supporter de nouveau formats d'entrée (les Readers) avec très peu de code, cf la branche expérimentale d'oscopy actuelle.
    Du moment qu'une interface en Python existe pour l'acquisition des données, les deux peuvent communiquer ensemble facilement.