jcelerier a écrit 17 commentaires

  • [^] # Re: La documentation automatique

    Posté par  . En réponse à la dépêche [Faust] Coder de l’audio en sifflotant. Évalué à 9.

    Est-ce que tu aurais des exemples d'installations artistiques montées avec Faust ?

    En général (en tout cas dans mon expérience) Faust est à un niveau un peu plus bas que Pd: par exemple, on va écrire un module d'effet spécifique en Faust, comme une disto ou un synthé, qui va être inclus dans le contexte un peu plus large d'un show qui lui sera souvent écrit avec Max / Pd / Supercollider / Ableton Live / etc. Les fichiers d'architecture de Faust sont très pratiques pour ça: à partir du code Faust on exporte un objet Pd puis ça roule.

    Dans les proceedings des ICMC et autre (http://www.icmc2017.com/en/download.html) il y a souvent des retours d'expérience et installs qui sont décrites. Au SCRIME des gens s'en sont servis notamment pour faire de la spatialisation sur dôme de HP.

  • [^] # Re: Introduire un nouveau soft ?

    Posté par  . En réponse à la dépêche LibraZiK : nouveautés des six derniers mois. Évalué à 2.

    edit: le dns a l'air en rade, l'addresse https://ossia.io marche

  • # Introduire un nouveau soft ?

    Posté par  . En réponse à la dépêche LibraZiK : nouveautés des six derniers mois. Évalué à 4.

    Hello,
    je travaille sur un séquenceur libre qui s'appelle Ossia Score (www.ossia.io). Il permet notamment de contrôler les softs comme PureData, Supercollider, etc. par OSC. Est-ce que vous pensez que c'est jouable et pertinent de faire rentrer ça dans votre distrib ?

  • [^] # Re: OS Temps Réel

    Posté par  . En réponse à la dépêche LibraZiK : nouveautés des six derniers mois. Évalué à 2.

    À priori OS / GUI avancée et RT ne vont pas de paire.

    Bof, ça ne pose pas vraiment problème : en pratique, temps réel pour de l'audio ça veut juste dire < 8ms ce que tous les OS desktop peuvent faire sans souci. D'autant plus que le thread audio est toujours (en tout cas dans tous les logiciels sérieux :p) séparé du thread GUI, et généralement mis sur un autre scheduler (par exemple FIFO sous linux) ce qui permet d'approximer assez bien du temps-réel, cf http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

    une - vrai - plateforme arm pour le temps réel, io, i2s, dsp, midi ?

    Il y a bien la Bela qui est très sympa, mais on ne peut faire tourner même pas un dixième de ce qui peut tourner sur un gros i7 (eg des centaines de reverb à convolution sans trop sourciller).

  • [^] # Re: KDE presque un 10 sur 10 comme DE.

    Posté par  . En réponse à la dépêche Nouvelles de KDE (saison 2016-2017). Évalué à 3.

    Arch:
    * KDE Frameworks 5.37.0
    * Qt 5.9.1 (construit sur 5.9.1)

    j'ai du mal à comprendre le principe de la distro qui reste sur Qt 5.6 (en tout cas pour un usage de bureau / dev), y'a eu teeeeeeeellement de bugfix depuis.

  • [^] # Re: GNOME en minuscule

    Posté par  . En réponse au sondage Quel est votre environnement de bureau préféré ?. Évalué à 0.

    J'essaye aussi de me forcer à écrire les noms en majuscules correctement, mais à partir de 5-6 lettres ça devient ridicule.

    Ben c'est un acronyme (GNU Network Object Model Environment si je ne m'abuse) donc bon… pas trop le choix.

  • [^] # Re: Meson ?

    Posté par  . En réponse à la dépêche Outils utiles pour développeur. Évalué à 3.

    C'est un peu un cas pathologique ton example CMake, il peut se réduire à ça :

    project (glib-test)
    cmake_minimum_required (VERSION 3.6)
    
    find_package (GLib REQUIRED)
    
    add_executable (glib-test glib-test.c)
    target_link_libraries (glib-test PRIVATE glib-2.0)
    

    Si tu installes le module FindGLib.

    Pour énormément de bibliothèques (Qt, SDL, OpenGL, wxWidgets, OpenSceneGraph, libpng, GTK, SFML, BLAS, openssl, etc..) ces modules sont fournis en standard avec CMake et il n'y a rien besoin d'installer, sinon c'est juste un fichier en plus à copier.

  • # D'autres outils utiles

    Posté par  . En réponse à la dépêche Outils utiles pour développeur. Évalué à 3.

    Je ne les ai pas vu cités :

    • Heaptrack : super pour voir l'utilisation mémoire, les allocations, etc.
    • Clazy : plein de checks qui utilisent clang, certains adaptés à un développement avec Qt, d'autres plus généraux pour le C++.
    • GammaRay là encore vachement utile pour le développement Qt, permet de faire énormément d'introspection.
  • [^] # Re: euh ?

    Posté par  . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 1.

    Par exemple le compilateur peut réordonner le flot des instructions un peu comme bon lui semble tant que ça fait le bon résultat à la fin : https://godbolt.org/g/bvePqx

  • [^] # Re: What you see is not what you get

    Posté par  . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 3.

    Dans un autre registre, je déteste particulièrement les templates. À la moindre connerie, je me retrouve avec des dizaines ou centaines d'erreurs de compilation qui me rappellent le Cobol sur AS400 à l'IUT en 1990 …

    Il y a un secret (en tout cas avec GCC et Clang) pour rendre les erreurs de templates pas trop insurmontables.
    95% du temps, la ligne d'ou provient l'erreur dans ton code est indiquée par la ligne d'erreur "Required from here" de GCC qui va être au début de l'erreur; si tu utilises QtCreator par exemple tu peux double-cliquer dessus et ça t'y emmène dans le code.

    Qui peut prétendre être un gourou C++ ? Très peu de personnes je pense.

    Bjarne lui même a dit qu'il devait se référer au standard pour être sûr de tout.

    À quoi bon mettre tout ça dans la norme si, au mieux, personne ne les utilises,

    Ce sont surtout les auteurs de bibliothèques qui les utilisent.

    Regarde par exemple le code de Eggs.variant ou Boost.Hana

  • [^] # Re: Nouveau langage

    Posté par  . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 1. Dernière modification le 06 décembre 2016 à 00:14.

    En attendant, on peut tricher un peu en faisant ça :

    #include <boost/unordered_map.hpp> 
    #include <variant>
    struct js_object;
    using js_value_t = std::variant<int, std::string, bool, js_object>;
    
    struct js_object
    {
        template<int N>
        constexpr void set(const char (&s)[N], const js_value_t& value) 
        {
          if ( str_equal(s, "foo") )
          {
            m_foo = std::get<int>(value);
          }
          else if ( str_equal(s, "the_bar") )
          {
            m_bar = std::get<int>(value);
          }
          else
          {
            m_other[s] = value;
          }
        }
        template<int N>
        constexpr js_value_t get(const char (&s)[N]) const
        {
          if ( str_equal(s, "foo") )
          {
            return m_foo;
          }
          else if ( str_equal(s, "the_bar") )
          {
            return m_bar;
          }
          else
          {
            return m_other.at(s);
          }
        }
    
      private:
        template<int N, int M>
        static constexpr bool str_equal(const char (&s)[N], const char (&s2)[M])
        {
          if constexpr (N == 0 || N != M)
            return false;
    
          for(int i = 0; i < N; i++)
          {
            if (s[i] != s2[i]) 
              return false;
          }
    
          return true;
        }
    
        int m_foo = 0;
        int m_bar = 0;
        boost::unordered_map<std::string, js_value_t> m_other;
    };
    
    auto my_function(js_object& b)
    {
        b.set("the_bar", 1111);
        return std::get<int>(b.get("the_bar"));
    }
    
    auto other_function(js_object& b)
    {
        using namespace std::literals;
        b.set("random_value", "a string"s);
    }
    

    Avec GCC à -O3, my_function se simplifie.

    my_function(js_object&):
    mov DWORD PTR [rdi+4], 1111
    mov eax, 1111
    ret

  • # Cas "optional"

    Posté par  . En réponse à la dépêche C++17 indique la disponibilité des en‐têtes (header). Évalué à 2.

    Je m'en sers quasiment exactement comme ça dans mon code : https://github.com/OSSIA/i-score/blob/master/base/lib/iscore/tools/std/Optional.hpp

    Mais le optional boost et le optional std n'ont pas une API compatible, par exemple pour vider un optional c'est boost::none vs std::nullopt donc il faut définir des choses en plus :( :( :( :(

  • [^] # Re: Double underscore

    Posté par  . En réponse à la dépêche C++17 indique la disponibilité des en‐têtes (header). Évalué à 2.

    En faisant une petite recherche Github sur "has_include" :

    https://github.com/search?l=C%2B%2B&p=2&q=has_include&type=Code&utf8=%E2%9C%93

    On voit qu'il y a déjà du code qui s'en sert comme un identifiant. Vu que c'est nécessairement une macro de préprocesseur, avoir #define has_include casserait le code existant, ce que le standard essaye d'éviter. S'ils avaient eu cette idée il y a 30 ans on n'en serait peut-être pas là :p

  • [^] # Re: Cross compile pour Mac ?

    Posté par  . En réponse à la dépêche CatchChallenger version 2. Évalué à 1.

    Le plus simple je pense est d'utiliser Travis et Appveyor, c'est comme ça que je fait avec mes soft. On a accès à des machines virtuelles qui vont compiler chaque commit et on peut dire "ok, quand le ocmmit est taggé, déploie machintruc.app / linux-fr.exe / pouet.appimage sur github.

  • [^] # Re: libgccjit incompréhensible

    Posté par  . En réponse à la dépêche Sortie de GCC 6. Évalué à 3.

    De ce que j'ai cru comprendre, GCCJIT permet d'accéder au back-end de GCC et permet donc d'implémenter un interpréteur pour ton propre langage, pas de réutiliser les front-end existant (C, C++, ADA, Go)… C'est plus proche de LLVM que de Clang si tu veux.

  • # Différence avec Guitarix ?

    Posté par  . En réponse à la dépêche La pédale MOD. Évalué à 2.

    Surtout que Guitarix est maintenant basé sur FaUST qui est un langage adapté à la spécification d'effets DSP très en vogue et qui permettrait notamment de compiler du code DSP de haut niveau directement dans de l'asm optimisé pour le CPU du MOD.

  • [^] # Re: À bas COW, vive SSO!

    Posté par  . En réponse à la dépêche Le compilateur GCC 5.1 : harder, better, faster, stronger. Évalué à 3.

    L'optimisation précédente, qui était d'utiliser de la copie sur écriture, était de moins en moins efficace dans les applications lourdement parallèles tournant sur des serveurs à grand nombre de cœurs, car il faut acquérir des mutex (cher!) et faire des barrières mémoire pour flusher les caches de chaque cœur (très cher!) tout le temps.

    Est-ce qu'on a quand même des benchmarks de la différence entre la SSO et le COW sur des cas single-threadés (qui sont laaargement majoritaires je pense dans beaucoup de logiciels ou ça ne sert absolument à rien d'avoir de l'écriture sur des std::string depuis plusieurs threads distincts (pour un tant soit peu qu'il y ait besoin d'avoir plusieurs threads…)). Pas envie que ça ralentisse mon desktop ça!