XMMS2

xmms2: RT @newsycombinator: GUI vs CLI: Operation vs Expression http://t.co/c5v44fJX

xmms2: GSoC Mentors Summit 2011 is on!

Finally!A long long long overdue release, mostly due to the developers having more fun with the next release, DrParnassus, instead of getting this release out (~300 commits screaming to be merged).DrO_o can be considered a service/polish release to ... [More] DrNo, and should not contain any big surprises to the end user. On the development side there are some new nice features that we've been wanting on for a long time now.As usual there was a lot (33!) of people...Adam Nielsen, Anders Waldenborg, Anthony Garcia, Benjamin Drung, Benjamin Schmitz, Brad Jorsch, Christopher Rosell, Daniel Svensson, David Richards, Dries Harnie, Erik Massop, Fabian Roth, Frank Dischner, Frank Terbeck, Guilherme Gonçalves, Henrik Gustafsson, Hugh Davenport, Igor Byelogurov, Jan Braun, Jari Aalto, Juan Antonio Osorio, Juho Vähä-Herttua, Raphaël Bois, Richard Kralovic, Rémi Vanicat, Sebastien Cevey, Sergei Trofimovich, Thomas Frauendorfer, Tilman Sauerbeck, Timo Paulssen, Tobias Hieta, Uli Franke, Yang Zhe...involved in in getting this release out, they have our gratitude!It's available for download over at SourceForge as usual:https://sourceforge.net/projects/xmms2/files/xmms2/ [Less]

The GSoC project time is officially over, but the multichannel and resampler project of XMMS2 is not quite over yet. Biggest setback that came up was the fact that libresample and other related libraries didn't support multichannel interleaving, so ... [More] that needs to be done manually instead. My attempt at hacking it into the sample.c was a big failure and resulted in spaghetti code, so it's better to do it properly. The list of things to do now is somewhat: Write a clean resampler interface that can use both libresample (LGPL) and libsamplerate (GPL) and doesn't depend on XMMS2. If it is possible to make it resemble libsamplerate API a lot of other applications might benefit from it as well.Patch the current sample.c code to use the cleaner resampler interface, which should be quite straightforward.Write the converter plugin support for multichannel, it would need a lot of thinking, but that can be avoided pretty much by looking at the logic presented in PulseAudio calc_map_table found from src/pulsecore/resampler.cAdd channelmap support for pulse output plugin, add multichannel support to ALSA output plugin, add multichannel support for waveout plugin (easiest, but who's gonna test?)Write tests and make sure everything works, especially coerce needs new tests because it's a bit broken already now. (output plugins with no channel count defined don't work nicely) [Less]

In the last progress update, I talked about how we were moving to the client side of the Service Clients implementation. Things have progressed quite a bit since then, but unfortunately that part of the project is nowhere near ready (nor will it be ... [More] by the end of GSoC, which is right around the corner). Anyway, I thought I’d share a bit of what I’ve been working on during the past weeks of coding. The lower level of what we have in mind for the client side is complete and somewhat solid. This means it is possible for clients to pass messages and replies around reliably, using the server as a bridge. The plan now is to use that capability to model the Service Client functionality. As a demonstration/proof-of-concept, we decided to brush up the very first two service clients that were conceived, sumclient and sumservice, and add them to the xmms2-tutorials submodule as tut9 and tut10. I’m currently working on a higher level layer on top of that, which is the actual modelling of remote procedure calls and introspection. As a general concept, we agreed on allowing service clients to define and expose three types of basic entities to other clients: namespaces, methods and broadcasts. This means offering a service will be a matter of defining one (or more (or nested)) namespaces containing methods and broadcasts which can be accessed by regular clients by sending a specially-formatted message to the service client. My work on this last week of GSoC has been on the code that defines these entities, which (I think) started to take shape around this commit. That code hasn’t yet been reviewed and may soon suffer alterations. With that out of the way, the remaining work roughly boils down to implementing the code that articulates these data structures to offer the Service Client functionality. Basically that code should be a callback to the MESSAGE broadcast (which carries client-to-client messages routed through the server) that reacts to predefined types of messages, thus being able to dispatch method calls, reply to introspection calls, record a subscription to a broadcast and so on. [Less]

Work status Things are moving on, but they are never as simple as they look on the surface. For example, when changing the properties to store an xmmsv_t value instead of a GTree * containing xmms_config_property_t nodes, I had not realized that the ... [More] fact that xmms_config_property_t is an xmms_object is very significant, as signals are registered to the objects, and callbacks depend on this. So I’ve had to do a bit of a kludge, but it’s the best I could think of… I added a void pointer to the xmmsv_t structure which holds an xmms_object_t whenever a callback is registered to it. The other issue is that since the xmmsv_t values are always copied on insert, as it would be unsafe to use only references since the tree can be modified in any way, the object pointer will be destroyed when xmmsv_t is released, so I’ve had to manually transfer ownership of the object when necessary. This is really close to working but there are a few bugs and kinks to iron out. I’ve also started to add the new config schema API to the LADSPA host plugin, by exposing the config API to xform plugins, which has also served to ponder on improvements to the new API, which should be as simple to use as possible. One idea is to use more const references, which will get rid of many xmmsv_unrefs and g_frees which make the new API a big risk for leaks as it’s easy to forget to free that data. This could lead to stale pointers, but it would simplify usage greatly. What’s left IRC chats after this post will probably reveal more thinkgs I hadn’t counted on, but I would think this is what I have left to do: Get the callback mechanism working again Make sure callbacks work for old and new API Implement ideas for callbacks from next section Allow nyxmms to set lists (and to handle schemas correctly (e.g. set a n int when the schema is of int type) Get the LADSPA host to accept a list of plugins instead of a single plugin. Any other lurking bugs or improvements that come up. Other possible improvements are: Use more references for the schema API to simplify its usage Mark old API as deprecated so that a compile time warning encourages devs to use the new API Ideas on how callbacks should work with schema properties Callbacks can be registered for any node in the config tree, including dicts and lists. When a callback is set for a certain dict, it should be triggered whenever anything inside it changes, be it a single value change or  a new node added or deleted, so when triggering callbacks, all parent nodes need to be checked for callbacks and call them. Also whenever a large xmmsv_t structure is set (e.g. when you set a number of parameters at once, or even a list of parameters within a dict) all callbacks for the changed items should be triggered. [Less]

Those who live in emacs all know the pain of manually installing extra modes and extensions, especially on different hosts. System packages sometimes help, but they differ on every OS (Debian packages, MacPorts, etc.), don’t always exist, and need to ... [More] be installed manually. A better alternative is to use emacs itself to manage, install and update all the required extra code. The ELPA project provides a way to install packages from different repositories, while el-get can help you declare recipes to install and update code from ELPA, or even Github or Emacswiki. First, let’s setup some code that tries to load ELPA and el-get, and installs them if they are not present. ; derived from ELPA installation ; http://tromey.com/elpa/install.html (defun eval-url (url) (let ((buffer (url-retrieve-synchronously url))) (save-excursion (set-buffer buffer) (goto-char (point-min)) (re-search-forward "^$" nil 'move) (eval-region (point) (point-max)) (kill-buffer (current-buffer))))) ;; Load ELPA (add-to-list 'load-path "~/.emacs.d/elpa") (defun install-elpa () (eval-url "http://tromey.com/elpa/package-install.el")) (if (require 'package nil t) (progn ;; Emacs 24+ includes ELPA, but requires some extra setup ;; to use the (better) tromey repo (if (>= emacs-major-version 24) (setq package-archives (cons '("tromey" . "http://tromey.com/elpa/") package-archives))) (package-initialize)) (install-elpa)) ;; Load el-get (add-to-list 'load-path "~/.emacs.d/el-get/el-get") (defun install-el-get () (eval-url "https://github.com/dimitri/el-get/raw/master/el-get-install.el")) (unless (require 'el-get nil t) (install-el-get)) Note that when using emacs 24, package.el is distributed with emacs but it points to the GNU package repository; the code above adds tromey’s more complete ELPA repository to the sources. Unfortunately, the ELPA installer script appends a snippet of code to the end of the ~/.emacs file to auto-load package.el on startup. To avoid any problem, it is best to manually remove that code any only keep the load-or-install code above. Now that ELPA and el-get are setup, we can declare all the packages we want installed. They will be installed the first time emacs is started, and simply loaded in the future. ; extra recipes for packages unknown to el-get (yet) (setq el-get-sources '((:name css-mode :type elpa) (:name js2-mode-mooz :type git :url "git://github.com/mooz/js2-mode.git" :load "js2-mode.el" :compile ("js2-mode.el") :features js2-mode))) ; list all packages you want installed (setq my-el-get-packages (append '(css-mode egg gist js2-mode-mooz) (mapcar 'el-get-source-name el-get-sources))) (el-get 'sync my-el-get-packages) The el-get 'sync call does all the magic, based on all the packages past in argument (as my-el-get-packages). Any packages for which el-get has a recipe can be installed. The el-get-sources variable allows to declare extra custom recipes for code to install. In the example above, css-mode is simply pulled from the ELPA repository, while js2-mode-mooz is fetched directly from Github. Replicating this code in all your ~/.emacs files is a very easy and convenient way to bootstrap the same emacs environment on multiple hosts. [Less]

So this tech blog is back with a new theme after a long hiatus (and major hardware failure). Hopefully, I’ll be talking about Ruby, Javascript, thick web apps, REST, Git, emacs and other things here soon. Let’s see how long I can keep it going.

Having spent quite a few total hours in GDB over the past weeks it started to get boring to print *res->value.list->… etc over and over to see what weird value was harassing my tests. I had heard that GDB had gained Python support  some time ... [More] ago and decided to write some useful tools for debugging XMMS2 related code. This is now what it looks like when you print a xmmsv_coll_t: (gdb) print *coll $11 = { "attributes": { "type": "id" }, "type": "XMMS_COLLECTION_TYPE_ORDER", "idlist": [], "operands": [ { "attributes": {}, "type": "XMMS_COLLECTION_TYPE_UNIVERSE", "idlist": [], "operands": [] } ] } …and a regular xmmsv_t: (gdb) print *fetch $15 = { "type": "cluster-list", "data": { "type": "organize", "data": { "id": { "aggregate": "first", "type": "metadata", "get": [ "id" ] } } }, "cluster-by": "id" } The code is a bit under 100 lines of Python and should be a nice inspiration for people who still haven’t added this huge help to their projects. The code can be found here, and checked out via: git clone git://git.xmms.se/xmms2/xmmsgdb.git [Less]

My original proposal has of course changed substantially! First, instead of defining a new data structure with multiple types, I’ve started using xmmsv_t which already exists and does most of the work (IPC interchange, value serializing, memory ... [More] mangement). I only needed to add support for floats. Easy, right? It turned out to be very complicated as there is no way to serialize float values in a portable manner, because locales would interfere (if you plan to use sprintf) and because you cannot guarantee how floats will be stored in memory on all platforms (especially those which are not IEEE 754 compliant!). So I ended up with a comprimise which is using frexp to separate the float values mantissa and exponent, and encode them as two integers. This appears to give on simple testing a presicion of about 6 or 7 significant figures, which should be sufficient for XMMS2 config values. This is now available at my git repo: https://github.com/mantaraya36/xmms2-mantaraya36/tree/config-schemas I’ve also started work on the config properties side, and have settled on the following API for the new system: /* * New config properties using schemas */ xmms_config_node_t *xmms_config_node_lookup (const gchar *path); xmms_config_node_t *xmms_config_node_create (const gchar *name, xmmsv_type_t type); /* Register nodes in the property tree. Callbacks are ignored for lists and dicts */ xmms_config_node_t *xmms_config_node_register (xmms_config_node_t *node, xmms_object_handler_t cb, gpointer userdata); gboolean xmms_config_node_unregister (xmms_config_node_t *node); /* check node types */ gboolean xmms_config_node_is_type (xmms_config_node_t *node, xmmsv_type_t type); /* node query operations. Will return the first element if node is a list or array*/ gint32 xmms_config_node_get_int (xmms_config_node_t *node, gboolean *ok); /* ok can be NULL */ gfloat xmms_config_node_get_float (xmms_config_node_t *node, gboolean *ok); const gchar *xmms_config_node_get_string (xmms_config_node_t *node, gboolean *ok); xmms_config_node_t *xmms_config_node_get_index_node (xmms_config_node_t *parent_node, gint index); xmms_config_node_t *xmms_config_node_get_key_node (xmms_config_node_t *parent_node, const gchar *name); /* node value setters. will set the vaue for the first element if node is a list or array */ void xmms_config_node_set_int (xmms_config_node_t *node, gint value, gboolean *ok); void xmms_config_node_set_float (xmms_config_node_t *node, gfloat value, gboolean *ok); void xmms_config_node_set_string (xmms_config_node_t *node, const gchar *value, gboolean *ok); /* for dicts only: */ void xmms_config_node_set_from_hash (xmms_config_node_t *parent_node, GHashTable *table); /* for lists only: */ void xmms_config_node_set_from_array (xmms_config_node_t *parent_node, GArray *list); /* element operations (for lists and dicts) */ gint xmms_config_node_element_count (xmms_config_node_t *node); void xmms_config_node_element_remove_index (xmms_config_node_t *parent_node, gint index, gboolean *ok); void xmms_config_node_element_remove_key (xmms_config_node_t *parent_node, xmms_config_node_t *node, gboolean *ok); /* query node elements values */ gint xmms_config_node_get_element_int (xmms_config_node_t *parent_node, gint index, gboolean *ok); gfloat xmms_config_node_get_element_float (xmms_config_node_t *parent_node, gint index, gboolean *ok); const gchar *xmms_config_node_get_element_string (xmms_config_node_t *parent_node, gint index, gboolean *ok); /* set node elements values */ void xmms_config_node_set_element_int (xmms_config_node_t *parent_node, gint index, gint value, gboolean *ok); void xmms_config_node_set_element_float (xmms_config_node_t *parent_node, gint index, gfloat value, gboolean *ok); void xmms_config_node_set_element_string (xmms_config_node_t *parent_node, gint index, const gchar* value, gboolean *ok); /* list node operations */ void xmms_config_node_resize (xmms_config_node_t *node, gint size, gboolean *ok); void xmms_config_node_append (xmms_config_node_t *parent_node, xmms_config_node_t *node, gboolean *ok); void xmms_config_node_insert (xmms_config_node_t *parent_node, gint index, xmms_config_node_t *node, gboolean *ok); /* callbacks (can only be set for value nodes) */ void xmms_config_node_callback_set (xmms_config_node_t *node, xmms_object_handler_t cb, gpointer userdata); void xmms_config_node_callback_remove (xmms_config_node_t *node, xmms_object_handler_t cb, gpointer userdata); Nodes will hold a copy of the value in the tree and the node’s address,, so any operations on nodes can be made thread-safe. [Less]