XMMS2

Following up on my post from FOSDEM I have now started the process together with the XMMS2 community to define our Vision. We are working on getting a version of this vision that everyone feels ok with. You can see our work (and chip in if you want) at the following wiki page.

First episode of the much talked about Dollhouse was aired the other day. I got my hand on a digital copy and I watched it with a lot of anticipation. Aaaand it didn't let me down completely, but it didn't wow me either.. I like the concept, it's ... [More] pure close-future sci/fi with the whole download/upload of memory concept well in place, Elizas performance was solid, but still something was missing. I am not giving up on this yet, I have faith in you Joss Weadon! But I hope we will see more weadon-esque humor and cleaver twists in the coming episodes. [Less]

Ask anyone on the street why they are not using XMMS2 right now and they will tell you the same thing: But, like, all your GUI clients suck lol! You needn’t have punched the poor guy in the face, because I also believe it is quite true. We have quite ... [More] a few clients (you will have to check out the matrix by yourself), but none that can really be called polished, mature or attractive enough to motivate people to switch. No disrespect to the authors (I’m even one of them), some cool stuff has been done, but graphical clients aren’t really “ready for the desktop” yet. Which is really a pity, given the awesome framework we have in place to create a great music player. I believe that the reason for this isn’t that we don’t have competent developers, but rather that all of these projects are one- or two-men effort and not really thrived by the community. Because of the freedom you have to write your own client, well, people do: they follow their personal vision of what they want their music player to be like and start coding. Unfortunately, this isn’t the most effective strategy. Perhaps thanks to the physicality of our meeting at FOSDEM, or to all the Belgium beer, we acknowledged that and decided that, now that the new official command-line interface (AKA nycli) has been merged and is being worked on by various people (thanks greafine, AnthonyG, nesciens!), it was time to get serious about a graphical client. The best way to get people to work together on a new project is to establish a clear and common vision of what we’re aiming at, what are the ideas that structure the project, and get people excited about it! The vision should be compatible with the XMMS2 vision we’re currently discussing (thanks to Debian’s Bdale Garbee for the inspiration). I want to make it clear that even if members of the XMMS2 community start working together on a common client, it is in no way incompatible with other people writing their own client if they so wish. Simply, we hope to gather people working on similar clients and focus the effort to build something really, really cool! So I’m going to start posting things on this blog to propose directions for a vision to follow, and everyone is welcome to comment, reply, blog and debate the ideas so we solidify the basis we will start from. There will be a lot of things to discuss, from technical choices to interface challenges, so let’s get started! [Less]

Over last weekend (February 6-8), I shared a fantastic time in Brussels with people from the XMMS2 team (and a few thousands over geeks and almost as many beers). We got together, mostly off our Google Summer of Code money, and spent some IRL time ... [More] thinking of how to make XMMS2 better. Thanks to everyone who was involved, it’s been great fun! Although tilman and DraX hacked fervently on GenIPC, most of what we worked on wasn’t code, but rather discussions on the organisation of the project, the status of projects waiting to be merged into the main tree (GenIPC, service clients, collections 2.0), as well as future projects we want to explore, such as mergestatus (a pimped up iteration of the merge page) and an official GUI (yes!). The main issue we identified with organisation is the lack of clear vision of where we are heading. Projects like GenIPC or mergestatus are being worked on without a general and agreed upon (let alone written down) specification of all they entail. The decision we took was to try to get tru back into a role of project manager and require proper wiki pages to be written about all the major features that are being developed. I personally want to start blogging more about thoughts and projects I’m working on (I know I’ve said it before, but this time it is true). Saturday Night Hacking, by theefer I had several discussions with nesciens, who has been hacking on collections 2.0 last summer, and we identified different topics that should be explained on the wiki and possibly discussed with the rest of the team: Advanced (insane) queries (to retrieve all sorts of information and structures from the mlib using collections) Source goodness (server magic to make collections select the right value according to a global ranking of sources) Token operator (to match tokens, which is what you usually search for, using an external token table) Other new collection operators (in particular, related to treating medialists, i.e. keep collections ordered throughout the DAG) Note: most of the links above are work in progress, meaning they’re not total rubbish, but don’t rely on them to launch your personal space capsule. Other fancy stuff that has been debated: Proper serialisation of the collection DAG over IPC Usage of xmmsv_t dict to store collection attributes, possibly richer than strings (already started by anders) Idlist as a simple attribute in Idlist collections String table (optimisation of strings in the DB to avoid duplication of data) nesciens has already started updating the todolist/roadmap. And of course, the super exciting new project that nobody even expected: a common effort to work on an official GUI client! I have a lots of thoughts about this, and I need to summarise all the discussions related to it at FOSDEM. And that will be the topic of my next post! (Who said you couldn’t have cliffhangers in blog posts?) Farewell group photo, by theefer [Less]

Installed the Last.FM player on my Android yesterday and I suddenly knew that I had just taken a leap into the future. The days of myPod’s and other digital music players are reaching their end. I realise that while writing this, millions of people ... [More] sit in front of their computers pushing music into their little gadgets before heading out in the street or whatever, and you know what… <blink>THEY’RE DOING IT WRONG!</blink> What they should do is to get themselves an Android or iPhone, install the Last.FM app, just head outside and click the “xxxx’s Library” station and enjoy song after song they probably just want to hear right now, for free! The whole world of music instantly available from that Internet enabled device in their pocket. <blink>THIS IS THE FUTURE! IT’S HERE!</blink> It’s has also revolutionized my use of Last.FM. As I’m using it on the go I’m not really doing anything other than listening to music so it brings me closer to the music in a whole new way. If I hear a song it’s really easy to just pick up the phone from my pocket and press the <3 button, maybe skip to the next song if the current one doesn’t fit my mood, or if the song reminds me of someone, the share button is just a click away, both share to email from the android contacts list, or to my friends at Last.FM. I haven’t been this excited about a piece of software since I first started using Xbox Media Center, this IS the best thing since sliced bread (or XBMC in this case). [Less]

I am currently sitting in one of the Hacker Rooms at FOSDEM in Brussels. I have spent my last two days together with a great group of XMMS2 developers, just as last year. I really enjoy these events where you have the possibility to actually meet the ... [More] people you spend a lot of your spare time with.The discussions this year was very different than last years topics. This year people was more concerned about how to organize the distributed team and work on the "right stuff". I find it pretty funny since this is just the things I have started to do at Purple Scout recently.I have decided to give it a go for the XMMS2 community as well. I am sure that I can leverage on some of the things I have learned recently, but I also know that it will be very different since the developers of the XMMS2 community are not working on XMMS2, just doing it for the kicks (and possibly the chicks, but I think that is just a big misunderstanding).One of the talks that inspired the discussion was Bdale Garbee's keynote about the Debian community. He said that you shouldn't underestimate the values of values. Basically you'll need to share common values and goals within a community in order to get everyone aligned. Debian has a Social Contract that outlines the vision for the Debian project.My plan is to establish a similar document for the XMMS2 project. It will be a document that is created by the community for the community and will hopefully allow us to align better towards the ultimate world domination goal.After this document is done I will move on and establishing our "Code of Conduct" or "Development Guidelines", this document will outline how we work together as a group and what processes we follow.So the current plan for world domination is:Establish the XMMS2 vision documentEstablish the XMMS2 code of conduct documentGet everyone super-hyped about XMMS2 developmentHack!????World Domination! (Or at least 'Ready to amaRock'). [Less]

We had a blast at FOSDEM as usual. Here is the obligatory group-photo:From the right: Erik Massop, Alexander Botero-Lowry, Auke Schrijnen, Daniel Svensson, Tilman Saurbeck, Tobias Rundström, Sébastien Cevey, Kate and Sebastian Woetzel.

Wow, it really took a long time to write this entry. I have now been working at Purple Scout for around two weeks and it has been really good. I have a fantastic team to work with and I have already done some good work (in my own humble opinion). I ... [More] have also had the chance to really start using GTD in my daily life (it's hard to organize your life when you only play video games, which was what I did during my vacation). So far I am very pleased with it, but the test of time will really show if it reduces my stress and improves my efficiency.I am using Things from Cultured Code as my organizer software. It's a very clean software that implements the basic lists from GTD (Inbox, Next, Someday, Scheduled, etc). It also have a very flexible tags system that I use for a number of things and most important it has iPhone synchronization.I use the iPhone application as my on-the-go collector. Most things I have to do pops up in my head when I am taking a walk or sitting in a meeting, in true GTD style my brain is stupid as well, so I just flick up my iPhone and scribble a few words in there. I concentrate to get a reminder mostly in the iPhone because it doesn't take that long to do that way and then expand on it when I sync it to my desktop client.Collection with the desktop client is also very good, when I identify a task I just press my globally recognized shortcut (meta ctrl space) and it brings up a dialog where I can enter my task.Things has the concept of Areas of Responsibility and Projects. I use the Areas as "larger projects" that can have several sub-projects. For example is 'Home' one of my areas, in there I can have projects like 'Redecorate the room' which in turn can contain specific tasks. Another area is "Work" but I also have a area for one of the bigger customers we are working with, since we are running ~8 projects together with this customer. Important to note is that tasks that are organized into a project can not be scheduled, they can only be 'next' or 'someday' as far as I understand it, but tasks that belong to the area directly can be scheduled. I am not really sure why this is, or if it's a bug.When I get to my organization phase I first scan items that should be put into projects and put them there and then areas. I don't have item outside any area. Tasks that goes into projects get the tags of the project so usually I don't have to apply any extra tags to these tasks, but since areas doesn't have tags I have to apply them to these posts. The most common tags for me is "work" and "home" because when I head over to the "do stuff" phase I can filter my things based on tags, which removes a lot of distraction "now I am at work and can only see things I should do at work" works great for me.Things isn't without flaw, the things that annoys me most are:Pressing the icon in the dock doesn't bring up the minimized Things window.Synchronization with iPhone only works over wifi and you have to be on the same network. Also if your firewall/router/switch for some reason filters bonjour (mDNS) it will not work (I had to fight the system administrator at work for this).I hope these issues will be addressed in future updates of things.That's it for today, next entry will probably be about SCRUM, since we just implemented this at work. [Less]

Antes de comenzar a programar un cliente para el xmms2 tendremos que investigar como funciona, como es que logra comunicarse con un o muchos clientes al mismo tiempo. Para interactuar con el servicio xmms2d es necesario hacerlo por medio de un ... [More] intermediario (middleware) que llevara la comunicación entre el servidor y el cliente. Es decir, el demonio xmms2d se ejecuta a la espera de peticiones, mismas que le serán pedidas por el intermediario; en la imagen superior vemos a dos objetos de tipo libxmmsipc quienes son los que están enlazados y pueden comunicarse en el mismo lenguaje, empero, el de la izquierda se entiende con el demonio, y el de la derecha con el cliente. A estos dos en conjunto les llamamos Middleware. Afortunadamente existe una libreria en python que ayudara a actuar como intermediario entre el demonio y nuestro cliente. Esta libreria es llamada python-xmmsclient. Los desarrolladores de xmms2 nos proponen algunas reglas de deberemos seguir para tener un buen funcionamiento entre nuestro cliente y el servidor, y no afectemos configuraciones que todos los clientes utilizan. Entre ellas, respetar la variable de entorno  XMMS_PATH, o si nuestro cliente guarda configuraciones podremos hacerlo dentro del directorio apuntado por $XDG_CONFIG_HOME. Así como algunas otras mas (para mas información aquí). Los desarrolladores nos han facilitado tanto el trabajo que disponemos de Medialib, que es una función que parsea la información Tag de un archivo de audio, poniéndola en una tabla que fácilmente podremos manipular. Existen dos modos de comunicaciones básicamente, un modo síncrono y uno asíncrono, cada uno con su respectiva función para determinados casos. Vamos, que si desarrollamos un cliente en modo texto plano para consola, podremos usar un modo síncrono sin ningún problema, pero si nuestra aplicación será algo mas sofisticado y gráfico, lo mas recomendable es usar una comunicación asíncrona. ¿Por que asíncrona? Bien, para que me puedas entender mejor voy a tratar de explicar algunas funciones que se llevan a cabo en la comunicación cliente-servidor. Pongámoslo fácil, cuando nosotros ponemos play, estamos ejecutando un comando, y este comando envía una señal al demonio que interpreta y regresa un resultado, mismo que el cliente puede interpretar a como le de la gana. Pero, supongamos que abrimos 2 clientes, ambos saben que existe una lista de reproducción cargada, en el primer cliente se nos ocurre borrar esta lista, entonces el segundo seguirá teniendo la lista completa sin sufrir ningún efecto y esto podría causarle problemas, por lo tanto, este debía ser avisado (por medio de una emisión del demonio) del cambio y tener la misma información que el primero, por ello que la comunicación debería ser asíncrona. Por ahora todo ha ido perfecto, en los próximos post’s tratare de mostrarles como hacer una conexión con un sencillo script en python. Enlaces: Writing Xmms2 Clients [Less]

En el post anterior hable de este misterioso reproductor de audio para sistemas operativos de tipo unix, y debido a la falta de interfaces gráficas (Clientes) que satisfagan mis necesidades como usuario he decidido programarme uno. El lenguaje que ... [More] elegí eventualmente es python usando la librería wx; ya que quiero probar mi suerte en diseños de GUI y ver que tan adaptables pueden ser. Bien, algunas características que quiero implementar. Panel de Control Controles de Next, Back, Play, Stop, Pause, etc. Panel de reproducción. Donde mostrará información del track en reproducción (tiempo, artista, titulo, etc). Playlist Lista de reproducción. Mostrando Artista y Titulo de la pista. Opciones para añadir o quitar archivos de audio, así como salvar o abrir listas de reproducción al estilo del xmms en su primera versión. Opción de Búsqueda. xmms disponía de la opción de búsqueda rápida (esto se hacia  presionando la tecla J) que es lo que quiero lograr. Por el momento he diseñado una interfaz que me agrada (un poco parecida a esperanza), aunque probablemente pueda cambiar en algún momento y quiero usar mi blog para dar a conocer el seguimiento que le estoy dando. Afortunadamente existe una librería para python (python-xmmsclient) que me facilitará el trabajo, pero de ello hablare un poco después. Aquí muestro el interfaz que he diseñado. El proyecto llevará por nombre Angel, aunque no es el definitivo, y el motivo, bueno, este si es personal. Y si alguién se anima a contribuir al proyecto hagamelo saber, toda ayuda es bienvenida. [Less]