Threads for ubitux

  1. 2

    Essentially neovim + vimwiki, manually git versioned, and immediately accessible through the i3 scratchpad.

    In more details, every day when I wake up I’m typing newday:

    newday() {
        cd ~/notes
            set -e -x
            git diff-index --quiet HEAD  # make sure the repository is clean
            e +VimwikiMakeDiaryNote +w +VimwikiDiaryIndex +VimwikiDiaryGenerateLinks +q
            git add diary
            git commit -m "WIP: $(date -I)"

    And at the end of the day, I review my daily diff, remove the WIP mention from the commit message and sink into the night. I git commit -a --amend and push force several times a day.

    Random info:

    • After trying to find a tree structure that makes sense, I ended up with a fully flat layout (with very few exceptions). It helps moving stuff around a lot and building new relationships.
    • I’m using the markdown markup, so I can open my notes with other tools such as Obsidian or Logseq (beware the latter automatically git commits!) in order to contemplate the mind graph. Of course, markdown support is not the same in every tool.
    • I use fzf to jump between wiki pages; I have almost no plugin, but this tool was a life changer in my workflow
    • I’m using the wiki to store and sort all the www links; I have about 4000 links in it
    • Started taking notes in 2020-03-15, pages:1333 lines:53829 words:314997


    • Image support: while I can do [my schema](files:medias/my-schema.webp), neovim doesn’t render them inline, so I have to press enter on each of them. It’s pretty primitive.
    • Similarly with math formulas: while simple formula such as $f_{n+1}(x)=x^n$ are live changed into their unicode equivalent, you can quickly get to the limits (as expected), and you would need some form of web preview for proper rendering.
    • Live preview technologies involve crappy nodejs technologies, fragile markdown parsers, and are generally an annoyance to setup
    • Vimwiki is slow af, in particular because it has no indexing; renaming a file takes a very long time
    1. 1

      So far my struggle with QML has been almost exclusively about the bindings, in particular double directional bindings. For that, those were helpful debugging tools:

      1. 7

        Very nice. I worked on a similar project a few years back. This is actually very similar to the MusicBox project by Anita Lillie back in 2008 (see demo at:, thesis at, which itself was build on top of the analysis provided by Echonest.

        Using the open-source aubio for the analysis and building playlist instead of working out a new player are very good decisions. When we tried to do something similar, this was also the direction we picked, and then had layers for sending playlists to various players.

        Now what’s missing here is an UI to “build” the playlist visually (check the demo in the link earlier). The principle for building such an UI is very simple: instead of just 1 distance between 2 songs, you have a set of N distances (corresponding to similarity to various parameters such as rhythm, loudness, pitch, but also tag metadata, etc) which is then reduced to 2 dimensions (using PCA), and you get a 2D map of all your music library. Then you can draw a path for building your playlist.

        This is in my opinion the only sane answer to “the music classifying nightmare” ( – author here).

        For a more traditional approach to solving the music classifying problem, I’d recommend looking at

        1. 2

          Thanks a lot for the very interesting references - I’ll take a look at implementing the PCA for blissify, to check how it performs.

          I’ve actually checked the landscape of tools like this before starting the project, and saw that there were a lot of music similarity thesis, but very few tools actually usable “out of the box”. So, instead of trying to make something really innovative, I’ve tried to aggregate the existing results to build a (somewhat) usable / maintainable “real-world” tool.